Conflicting info: PPU scroll / loopy_v/t

Discussion about the site's wiki, including bugs/issues encountered

Moderator: Moderators

Post Reply
User avatar
Zepper
Formerly Fx3
Posts: 3190
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Conflicting info: PPU scroll / loopy_v/t

Post by Zepper » Mon Sep 29, 2014 7:34 pm

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.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by tepples » Mon Sep 29, 2014 7:39 pm

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

User avatar
Zepper
Formerly Fx3
Posts: 3190
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by Zepper » Wed Oct 01, 2014 3:28 pm

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

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by tepples » Wed Oct 01, 2014 5:22 pm

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]

User avatar
Zepper
Formerly Fx3
Posts: 3190
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by Zepper » Wed Oct 01, 2014 6:35 pm

Got it.

User avatar
Quietust
Posts: 1492
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by Quietust » Thu Oct 02, 2014 6:44 am

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, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by tepples » Thu Oct 02, 2014 9:17 am

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?

User avatar
Quietust
Posts: 1492
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by Quietust » Thu Oct 02, 2014 10:01 am

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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

tepples
Posts: 21752
Joined: Sun Sep 19, 2004 11:12 pm
Location: NE Indiana, USA (NTSC)
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by tepples » Thu Oct 02, 2014 10:46 am

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?

User avatar
Quietust
Posts: 1492
Joined: Sun Sep 19, 2004 10:59 pm
Contact:

Re: Conflicting info: PPU scroll / loopy_v/t

Post by Quietust » Thu Oct 02, 2014 7:44 pm

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.
Quietust, QMT Productions
P.S. If you don't get this note, let me know and I'll write you another.

Post Reply