nesdev.com
http://forums.nesdev.com/

Conflicting info: PPU scroll / loopy_v/t
http://forums.nesdev.com/viewtopic.php?f=16&t=11676
Page 1 of 1

Author:  Zepper [ Mon Sep 29, 2014 7:34 pm ]
Post subject:  Conflicting info: PPU scroll / loopy_v/t

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.

Author:  tepples [ Mon Sep 29, 2014 7:39 pm ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/t

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".

Author:  Zepper [ Wed Oct 01, 2014 3:28 pm ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/t

But what happens then? loopy_v = loopy_t or loopy_v gets only the vertical bits?

Author:  tepples [ Wed Oct 01, 2014 5:22 pm ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/t

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]

Author:  Zepper [ Wed Oct 01, 2014 6:35 pm ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/t

Got it.

Author:  Quietust [ Thu Oct 02, 2014 6:44 am ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/t

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.

Author:  tepples [ Thu Oct 02, 2014 9:17 am ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/t

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?

Author:  Quietust [ Thu Oct 02, 2014 10:01 am ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/t

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.

Author:  tepples [ Thu Oct 02, 2014 10:46 am ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/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?

Author:  Quietust [ Thu Oct 02, 2014 7:44 pm ]
Post subject:  Re: Conflicting info: PPU scroll / loopy_v/t

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.

Page 1 of 1 All times are UTC - 7 hours
Powered by phpBB® Forum Software © phpBB Group
http://www.phpbb.com/