Here it says:
At the beginning of each frame, the contents of Loopy_T are copied into Loopy_V, as long as background or sprites are enabled. This takes place on PPU cycle 304 of the pre-render scanline.And
here it says:
During pixels 280 through 304 of this scanline, the vertical scroll bits are reloaded if rendering is enabled.I suppose that the second statement is the correct.
As I understand new information based on micrographs of the PPU die, it's actually updated continuously during the horizontal sync pulse at the end of the prerender line. Horizontal sync on any line lasts from 280 to 304. The "only on 304" is old empirical data, and I've updated the "PPU scrolling" page to clarify in what cases one can still rely on "only on 304".
But what happens then? loopy_v = loopy_t or loopy_v gets only the vertical bits?
In the pre-render's hsync, v gets all the t bits. Vertical bits are never copied on their own.
At (280, -1) through (304, -1): v := t
At (257, y) where 0 <= y <= 239: v[10,4-0] := t[10,4-0]
tepples wrote:
In the pre-render's hsync, v gets all the t bits. Vertical bits are never copied on their own.
At (280, -1) through (304, -1): v := t
Not true - 280-304 only copies the
vertical bits, while the horizontal bits get copied at 257.
Quietust wrote:
Not true - 280-304 only copies the vertical bits, while the horizontal bits get copied at 257.
I feel embarrassed at having got something incorrect and have lost some confidence, so I have to take a step back and act dumb while regrouping. This doesn't mean I have to turn on rendering before 257 on the pre-render line in order for the scroll to be correct, does it? Or did the writes to $2005 already copy the horizontal bits?
From what I can see, delaying render-on until after 257 (but before 304) would indeed cause the first scanline to render with the wrong coarse horizontal scroll offset, but it'd obviously correct itself for the next scanline; writing $2005 alone doesn't touch anything in V, only T.
Thank you. So it might appear as a scrolling glitch on Dendy that's well into the NTSC overscan. And because the first scanline never has sprites (and therefore never has sprite 0), it won't actually hurt anything unless the mapper relies on video memory fetch side effects (such as MMC4). Do I have this right?
I believe so. Still, it would definitely be good to double-check this on real hardware, just in case there's something I'm missing.