NMI thread

The NMI article describes the simplest possible working method to wait for vertical blank. This works for simple games without a status bar or for games whose upper limit on CPU use is easy to predict. It may also work for games whose mapper has a scanline counter that triggers an IRQ.

But once your game world becomes more complex, the simple method may cause problems. For example, consider a video game that has a status bar and several critters running around. It may occasionally longer than one screen to process AI, physics, and display updates once enough critters with complex movement patterns are spawned, such as multiple Hammer Brothers in Super Mario Bros. or the middle of World 3-7 of Super Mario Bros. 3. This will cause your game to slow down when an NMI occurs while your game is doing something else. And if your scanline counter is based on sprite 0 hit and not an IRQ, it will cause visual glitches as the status bar flickers.

To make the status bar rock-solid in the face of excessive game logic, you can break your program into two "threads" and move VRAM uploads into the NMI handler. Because the NMI handler itself is never interrupted, the locking can be much simpler than it is in multithreaded programming on a PC. In this program structure, the main thread prepares VRAM and maintains a flag VRAM_update_ready.

The NMI thread has these steps:

1. Let the main program know that NMI has occurred, as in the simple method.
2. Push all registers.
3. If VRAM_update_ready is false, go to step 5.
4. Copy data from RAM into VRAM.
5. Set VRAM_update_ready to false.
6. (Optional) Run the music code.
7. (Optional) Wait for sprite 0 hit and change the VRAM address.
8. Pull all registers and return.