The frame and NMIs: Difference between revisions

From NESdev Wiki
Jump to navigationJump to search
(Executive summary of Disch's article)
 
No edit summary
Line 7: Line 7:
On NTSC, count on being able to copy 160 bytes to nametables or the palette using a moderately unrolled loop, plus one 256-byte display list to OAM.
On NTSC, count on being able to copy 160 bytes to nametables or the palette using a moderately unrolled loop, plus one 256-byte display list to OAM.


Full story: [http://sites.google.com/site/nesdevhandbook/theframe.html The frame and NMIs] by Disch
Full story: [http://web.archive.org/web/20090714010738/http://nesdevhandbook.googlepages.com/theframe.html The frame and NMIs] by Disch

Revision as of 23:57, 30 June 2013

The PPU generates a video signal for one frame of animation, then it rests for a brief period called vertical blanking. The CPU can load graphics data into the PPU only during this rest period. From NMI to the end of the pre-render scanline, the NTSC NES PPU stays off the bus for 2273 cycles. Taking into account overhead to get in and out of the NMI handler, you can probably use roughly 2250 cycles. To get the most out of limited vblank time, don't compute your changes in vblank time. Instead, prepare a buffer in main RAM (for example, use unused parts of the stack at $0100-$019F) before vblank, and then copy from that buffer into VRAM during vblank. On NTSC, count on being able to copy 160 bytes to nametables or the palette using a moderately unrolled loop, plus one 256-byte display list to OAM.

Full story: The frame and NMIs by Disch