It is currently Mon Oct 23, 2017 2:01 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 10 posts ] 
Author Message
PostPosted: Mon Sep 29, 2014 7:34 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
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.


Top
 Profile  
 
PostPosted: Mon Sep 29, 2014 7:39 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
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".


Top
 Profile  
 
PostPosted: Wed Oct 01, 2014 3:28 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
But what happens then? loopy_v = loopy_t or loopy_v gets only the vertical bits?


Top
 Profile  
 
PostPosted: Wed Oct 01, 2014 5:22 pm 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
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]


Top
 Profile  
 
PostPosted: Wed Oct 01, 2014 6:35 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3064
Location: Brazil
Got it.


Top
 Profile  
 
PostPosted: Thu Oct 02, 2014 6:44 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1390
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.


Top
 Profile  
 
PostPosted: Thu Oct 02, 2014 9:17 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Thu Oct 02, 2014 10:01 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1390
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.


Top
 Profile  
 
PostPosted: Thu Oct 02, 2014 10:46 am 
Offline

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19122
Location: NE Indiana, USA (NTSC)
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?


Top
 Profile  
 
PostPosted: Thu Oct 02, 2014 7:44 pm 
Offline
User avatar

Joined: Sun Sep 19, 2004 10:59 pm
Posts: 1390
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.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 10 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 4 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group