Another discussion got sidetracked by whether to explicitly disable rendering when updating video memory during vertical blanking.
The pre-render scanline precedes the active picture. The rendering circuitry needs from x=321 to x=336 of this line to fetch the first two slivers of line 0 of the background, but it uses the bus the whole time if rendering is enabled. During the prerender scanline, if rendering is enabled, the PPU copies some bits from the scroll position (address t in Loopy's "The skinny on NES scrolling") to the video memory address (address v) to set up scrolling:
It takes 6 cycles to disable rendering (LDA #$00 STA $2001 and 6 to reenable it (LDA #$1E STA $2001), yet it adds about 100 cycles (x=1 to x=300, 1 cycle per 3 dots) of usable video memory access time. I had to hack NES15, a game on the STREEMERZ multicart, to disable rendering while updating video memory because the multicart's NMI dispatch routine pushed updates just barely into the prerender line, causing visible artifacts on my NES.
Anyone have a specific test ROM demonstrating when video memory becomes inaccessible?
In this post, rainwarrior wrote:
You should only turn the PPU off when you need to take rendering down for multiple frames so you can place a lot of data into the PPU. For an update that happens every frame, do not turn the PPU off
tepples wrote:
A little strong. Turning off rendering frees up the first 100 CPU cycles on the prerender scanline. I'd have said you usually don't need to.
tokumaru wrote:
There's no performance boost, you just get a little extra time for PPU memory accesses because the PPU itself won't be accessing memory during the pre-render scanline when rendering is off.
tepples wrote:
The difference between enabling during prerender and enabling after start of picture is that as long as rendering is reenabled before x=304 of the pre-render line, no special "skinny" address write sequences are needed to set the scroll position.
The pre-render scanline precedes the active picture. The rendering circuitry needs from x=321 to x=336 of this line to fetch the first two slivers of line 0 of the background, but it uses the bus the whole time if rendering is enabled. During the prerender scanline, if rendering is enabled, the PPU copies some bits from the scroll position (address t in Loopy's "The skinny on NES scrolling") to the video memory address (address v) to set up scrolling:
- At x=257 (right side of picture), it copies the horizontal bits (0-4 and 10). This happens on the pre-render scanline and the active picture.
- From x=280 through x=304 (the vsync pulse), it repeatedly copies the vertical bits (5-9 and 11-14). This happens only on the prerender scanline.
It takes 6 cycles to disable rendering (LDA #$00 STA $2001 and 6 to reenable it (LDA #$1E STA $2001), yet it adds about 100 cycles (x=1 to x=300, 1 cycle per 3 dots) of usable video memory access time. I had to hack NES15, a game on the STREEMERZ multicart, to disable rendering while updating video memory because the multicart's NMI dispatch routine pushed updates just barely into the prerender line, causing visible artifacts on my NES.
Anyone have a specific test ROM demonstrating when video memory becomes inaccessible?