VBI immediate and deferred

[texacala]

"De Re Atari" describes the time limit for an immediate VBI as 2000 cycles and deferred VBI as 20,000 cycles, with the warning that long deferred VBI routines may cause graphics problems since "many" of the cycles are executed while the electron beam is being drawn. "Mapping the Atari" says an immediate VBI has about 3,800 cycles to use (20,000 for deferred VBI) and adds that "it is suggested that you do not execute graphics routines in deferred VBIs." It also describes the tantalizing possibility of bypassing the OS VBI routine entirely to gain more time/speed.

 

My plan is to just test out immediate and deferred VBI routines with my animation loop and see what happens graphically, but I'm curious if you guys generally use immediate or deferred routines, which one is best, and also whether I'm better off using VBI for calculations other than graphics in the first place.

[Rybags]

Immediate is variable depending on if you want serial I/O to still work - of course you usually don't have much stuff moving around while loading.

 

The descriptions as you quote relate to where the electron beam is, and that will be also different for Pal vs NTSC. Pal has an extra 60 scanlines which equates to a lot of extra cycles.

 

One danger with a too long Immediate VB is that the shadow register updates to the hardware regs might take place during the active 240 scanlines of display. Display List pointer is an especial problem there since updating the HW register at the wrong time can corrupt the display.

Another as mentioned is that serial I/O can be affected, IRQs are disabled in early VBlank which means overrun can occur.

 

Too long running Deferred means you could get overrun conditions where the next VB NMI is triggered before the current one finishes, and also the normal foreground process would get no cycles. Eventual result could be stack wraparound and likely lockup or crash.

 

These days if you're doing a game or something that just takes over the machine, the done thing is often to just take the Immediate vector and do the stuff the OS does yourself, ie shadows, read joystick etc. You generally save some cycles since you only do the stuff that's needed, e.g. no need to process 8 paddles + buttons if you're not using them.

 

In the case you do everything yourself, either JMP $E462 at the end or do the stack pull/RTI sequence yourself.

 

Other advantage of taking over early and doing all yourself is that deferred VBlank processing is aborted by the OS if IRQs are disabled or the CRITIC flag is set. These things can occur during SIO or if an active IRQ is in progress, e.g. sometimes during a keypress.

Edited March 26, 2013 by Rybags

[texacala]

Thank you, that's very helpful. Looks like I'll experiment with the immediate VBI and take over the OS myself to get the most cycles. Is it a bit trial and error to determine the number of cycles available before problems crop up? I want to modify my display list and then animate objects onscreen, both playfield animation and some PMG (NTSC machine). Also, do I gain some VBI cycles (or other speed benefits) if I use narrow playfield?