Mixing Gr. modes on a screen while loading

[José Pereira]

Here we go...

Back then and in normal loaders I/you were used to have different GR. modes seen while the game was loaded.

Remember here most of the pirate tape copies had large letters GR:2 with the game title then under in GR.1 "BLOCKS TO LOAD - 000".

International Karate original tape version from System3 even had also in-between these two GR.0 hi-res showing the keyboard options during game playing (with blocks to load at the bottom 'blinking' in GR.1):

 

We normally (without tricks like xBios/@Tezz work on Zeppelin games,...) we can't have DLIs so that's why they're normally like this or pictures in 3+1 colours bitmap GR.15 mode.

Seeing this IK screen seems that what? PF1 on hi-res letters then the other 3 PFs are the normal 3 other 64chars of the GR.1 and Gr.2 modes is this it?

So here we don't really have any DLI but just different GR. modes down across the screen?

 

 

And if I want to have 2 modes that one is in Gr.15 bitmap and the other in GR.12 charmode? Can I. And this way can I in charmode (seems obvious but...) rebuild the in-A8 to gfxspixels to compose a picture (same as in gr.15 bitmap that is also more of the screen gfxs).

Explaining better showing this:

Think this is understandable. So I have or not to keep the same PF0/PF1/PF2 on the charmode because changing them I have to use DLIs so no way to be the screen present while loading?

 

 

 

[José Pereira]

If I can have this then can I alao, lets say add a 3rd one at the bottom (IK has 3 GR. modes)?

But it must be a bitmap one as nother charmode (in GR.0, 1, 2 or 13 will be other if I build it myself)?

 

On IK they're pre-build in A8 while for gfxs I must create ones with pixels data...

 

[+MrFish]

I'm not sure if I understand your question fully Jose; but graphics mode changes don't require any DLI's; they're defined in the display list. So, you can have as many different modes as you like, on a single screen, without having to deal with DLI's.

 

[shanti77]

As I understand it is a trick to change the mode in line to get more colors without dli interrupts. For example, a picture in Gr15 + a few lines in 4 (negative characters) and we have 5 color.

[kenjennings]

Are DLIs actually turned off during I/O or is it just the deferred VBI that is not called?

 

DeRe Atari says the DLI is not maskable. 

 

The NMI Handler
The OS has an NMI handler for handling the nonmaskable interrupts. Unlike the IRQs, the NMIs
cannot be "masked" (disabled) at the 6502 level. All the NMIs except SYSTEM RESET can be
disabled by ANTIC.

 

Mapping the Atari says the value CRITIC is set during I/O  which stops the system calling the deferred VBI, so OS shadow registers do not get copies to the hardware. (The immediate VBI is still called.)  It doesn't say anything about the DLI.

 

[ggn]

Not sure I understand 100% what is being asked here, but here is a video of the Trailblazer loader, which combines many graphic modes while loading:

 

 

[Rybags]

DLI will be needed in such cases as:

- changing GTIA graphics modes.

- multiple scrolling areas where HScrol or VScrol needs to be changed.

 

I do believe that DLIs aren't disabled during SIO.  But as stated CRITIC will be set a good deal of the time which means Stage 2 VBlank is skipped and stuff like controller reads and most of the colour register shadow copies won't occur.

 

You can do a custom immediate VBlank to cover things you can't do without.  But you'd need to keep the code tight otherwise it can cause missed bytes which = load fail in most cases for tape or annoying retries or long timeouts for disk.

 

With a custom SIO routine you could tailor it such that you can have lots of stuff going on.

But with the stock OS routine there's limitations which can easily be broken.

 

IMO for a loading screen it should leave SIO alone given that it's a good idea to allow the OS and driver structure handle that sort of thing given that emulated HDDs and the like are popular.

But still it leaves plenty of scope to have active loading screens.

Though you have to ask "If the game can be loaded in 5-10 seconds, why expend effort on something you'll barely see".

[Wrathchild]

Miss/defer a DLI and display messes up

Miss defer an SIO interrupt and loading screws up

 

So just don't mix them, or use custom SIO than handles the timing such that they don't clash.

[Rybags]

Yeah, you do have that problem that an IRQ can hit at just the right time to prevent the DLI being seen by the CPU.

A way around that can be to have 2 DLIs in quick succession then ignore the second one if the first has fired.

In theory at standard SIO rate with about 1,900 bytes/second being possible that equates to one IRQ every 8 scanlines.

 

It's a long time since I played around with this sort of stuff on a real machine but from memory the impact of the DLIs I was trying to run was worse than expected.

[José Pereira]

Similar to this:

Lets say that I have a hi-res area (some scanlines on a part of the screen) while other parts/scanlines are 2:1 or even blank on top and bottom:

 

So on hi-res the 'paper' is PF2 while on all others is BAK.

On hi-res is different. Can it be (is a DLI) but IK or Trailblazer use it?

 

Edited November 29, 2021 by José Pereira

[José Pereira]

On 11/25/2021 at 5:10 PM, José Pereira said:

Similar to this:

Lets say that I have a hi-res area while other parts are 2:1 or even blank on top and bottom:

 

So on hi-res the 'paper' is PF2 while on all others is BAK.

On hi-res is different. Can it be (is a DLI) but IK or Trailblazer use it?

 

Hi.

Sorry to ask again no answer(s)...

Did you get what I was saying and my question?

Thanks.

?

[thorfdbg]

On 11/10/2021 at 12:21 PM, Rybags said:

I do believe that DLIs aren't disabled during SIO.  But as stated CRITIC will be set a good deal of the time which means Stage 2 VBlank is skipped and stuff like controller reads and most of the colour register shadow copies won't occur.

It depends a bit on the Os version. For the original Os A and Os B, the DLIs are disabled as part of a side effect of SIO calling SetIRQ, which disables the DLI. This was fixed in the XL Os. Another problem with DLIs is that the Os keyclick function also interacts with DLI badly. This is fixed in Os++.

[Rybags]

Yeah, but generally you don't have keyclick occurring during SIO.   Another XL fix is that it uses wait loops on VCOUNT rather than hitting WSYNC for the keyclick generation.

I seem to remember on my 400 when playing around - you can just put code into an immediate VBlank routine to keep DLIs alive.

The OS disabling them as part of a SIO call - I reckon that could probably be gotten around by doing as above then make sure you call SIOV during the right time of the frame so that the DLI disable code doesn't affect you.

 

Re the mixed hires and normal modes with shared PF2 and changing it in DLIs - it should be no problem really.