Page 1 of 1
Conflicting info: PPU scroll / loopy_v/t
Posted: Mon Sep 29, 2014 7:34 pm
by Zepper
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.
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Mon Sep 29, 2014 7:39 pm
by tepples
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".
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Wed Oct 01, 2014 3:28 pm
by Zepper
But what happens then? loopy_v = loopy_t or loopy_v gets only the vertical bits?
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Wed Oct 01, 2014 5:22 pm
by tepples
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]
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Wed Oct 01, 2014 6:35 pm
by Zepper
Got it.
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Thu Oct 02, 2014 6:44 am
by Quietust
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.
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Thu Oct 02, 2014 9:17 am
by tepples
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?
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Thu Oct 02, 2014 10:01 am
by Quietust
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.
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Thu Oct 02, 2014 10:46 am
by tepples
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?
Re: Conflicting info: PPU scroll / loopy_v/t
Posted: Thu Oct 02, 2014 7:44 pm
by Quietust
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.