The frame and NMIs: Difference between revisions
(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:// | 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
