DLI & WSYNC 'effiency'

[glurk]

Looking for opinions on this.  For example, say that I have one (or more) DLI's, maybe like this:

DLI
   PHA
   LDA #0
   STA WSYNC
   STA COLBK
   PLA
   RTI

Wouldn't it be more efficient, and halt the 6502 for less time, if I put more stuff, like setting audio registers, reading joystick values, whatever, (up to 76 cycles worth) before the WSYNC.  I mean, stuff that has to run anyways.  Since the DLI is already set up, and has to run, and has overhead, it seems to make sense to me to do this.  "Fill it up" so to speak.  Is this a good idea, re: keeping the processor active, and "halted" for less time?

 

 

[phaeron]

Yes, though often you have much less than 76 cycles -- less than half that for normal mode E/F, and very minimal for a mode 2 line during vertical scrolling. Loading up A/X/Y is common, but it takes a bunch of cycles to save and load three registers. Occasionally people have also used a POKEY timer IRQ instead of a DLI since the IRQ can be timed later in the scanline.

 

Audio is practically the lowest priority, there's not really a reason to burn valuable VBI or DLI time on it when you could do it during the active frame. Joystick during the DLI might add up to a frame of latency if you've already run the game logic in the VBI and the joystick is being read high in the frame.

[Rybags]

There's considerations of DMA and jitter - the interrupt processing is delayed depending on what instruction was being executed and at what point.   And the DMA pattern can change if you're doing horizontal scrolling.

 

The most efficient way to process a DLI is to have the Ram under the OS supplying the NMI vector which means you can save cycles by just executing your own code directly (optionally skipping the check for VBlank)

 

If you know you have a certain number of cycles you can burn you could embed some code that might otherwise be in the VBlank.  Example might be clearing the ATTRACT counter so that it doesn't start up during a game.

You can even skip the WSYNC completely if you execute some code and guarantee that the colour change occurs offscreen.

 

An extreme example of cycle-saving is the Wolf3D engine "Project M" - instead of DLIs it uses a Pokey Timer IRQ at a selected cycle per scanline, such that waste is minimal.