Quick SIO/NMI question...

[Bryan]

Antic is always producing NMI's for VBLANK and the VBLANK routine can take some time to complete. Is this just an accepted fact in the SIO routines, that a single POKEY/SIO fetch may have the entire VBLANK routine executed inside of it? It seems preferable to have a UART service delay the start of VBLANK.. but I guess this is part of the reason for the 19.2K rate?

 

-Bry

[flashjazzcat]

I suppose this is the whole idea behind the immediate and deferred VBLs. The lengthy stuff goes in the deferred NMI and is skipped during IO. Overburden the immediate VBI at your peril... drop-outs, SIO hang-ups, the lot.

[Bryan]

That's the part I was forgetting... the multi-stage VBL. Just sitting here thinking about it and had a brain fart.

[Rybags]

Multi-stage with IRQ mask and CRITIC test are the answers. The OS manual mentions time limits for VBlank Immediate and Deferred although from memory in milliseconds, not cycles.

 

The XL Immediate VBlank is actually a bit longer than for the old 800 as well.

 

XL does CLD, also COLPF1 has the attract formula applied and stored - this is due to the fine-scroll text mode available, it uses a DLI at the bottom of screen where PF1 is set to same as PF2 to stop unwanted characters appearing due to the screen wrapping around the 4K boundary.

 

Although all this stuff isn't a huge amount, reason enough to use polling rather than IRQ mode for SIO with the lowest divisors... although at a certain point, polling is the only method that works.

[phaeron]

The OS VBI handler is reasonably quick when CRITIC is on, around 130 cycles or so. This is about as much overhead as 2-3 scanlines of mode 0, which the serial input IRQ handler has to deal with anyway.

 

Personally, I've found the deferred VBI to be pretty useless. It can be skipped randomly due to even a keyboard IRQ, and even when it does run, it runs after the stage 2 VBI code that updates hardware registers from the shadow variables. It's annoying that there isn't a vector to hook between stage 1 and stage 2.

[Rybags]

It was done with gaming in mind but like you said, they forgot some essentials.

 

Really, you'd want input stuff taken care of first, then call the user's routine, then stuff the remaining shadow registers.

I guess though that methodology would have risk factors of it's own, as in overrun of the user portion causing register updates to potentially occur in the active screen area.

 

Maybe the ideal situation would have been a third vector, and rehash the skipping a little. If an IRQ is active but CRITIC not set, then it'll practically always be the keyboard.