It is currently Sun Dec 17, 2017 1:02 am

All times are UTC - 7 hours





Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3
Author Message
 Post subject: Re: PPU timing?
PostPosted: Tue Jan 12, 2016 6:48 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Calm down, please. I have a CPU/PPU log system... and I detected that such extra cycle messes up the sprite zero timing. Removing the extra cycle makes everything fine. I'm tracing the code, not "guessing" as you :twisted: think.
tepples wrote:
Not taken: 2 cycles
Taken: 3 cycles
Taken, different page from not taken: 4 cycles


Yes, 4 cycles = 3 + 1 cycle penalty. ^_^;; Correct.


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Tue Jan 12, 2016 10:57 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Sorry if I'm getting to aggressive, Zepper. I get a little carried away sometimes. :mrgreen: :oops:

It's less likely that your CPU timing is off (those kinds of errors would likely be exposed by test ROMs), and more likely that your CPU<->PPU interaction timing is off. So the idea of BVC being off by a cycle is very unlikely. It's more likely your sprite 0 hit is being raised too late or something similar.

If you have the logs, look at the following:

A) What scanline+cycle is Sprite 0 being hit?
B) What scanline+cycle is the CPU reading $2002 and seeing that result?
C) What scanline+cycle is the CPU changing the scroll?
D) What scanline+cycle is the PPU increasing Y scroll?


If you have all that information logged, you should be able to see where the problem is.

D-A provides a "safe" window.. and if C happens before D, then the game will work properly.
If C-B takes too long, it spills outside the window, and causes the scroll change to be pushed back a scanline, resulting in a shaking status bar.


I'm suggesting that your D-A window is too small. Either you're raising sprite 0 too late, or you're increasing scroll too soon. That seems much more likely to me than you being off by an entire cycle in your CPU instructions.

So yeah, if you have the logs, this should be straight-forward to spot, and you can start diagnosing from there. :beer:


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 7:16 am 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Code:
frame <number>
(line,ppu_cycle) action
* acknowledge 1 means reading $2002 1 cycle after the sprite zero hit.
--------------------------------------------------------
frame 1
(195,249) .hit
(195,250) .acknowledge 1
(195,256) .Y inc
(196,254) $2006 ** v(02C0) <- t(02C0)
(196,256) .Y inc

frame 2
(195,249) .hit
(195,256) .Y inc
(195,261) .acknowledge 4
(196,256) .Y inc
(196,265) $2006 ** v(02C0) <- t(02C0)

frame 3
(195,249) .hit
(195,256) .Y inc
(195,259) .acknowledge 4
(196,256) .Y inc
(196,263) $2006 ** v(02C0) <- t(02C0)

frame 4
(195,249) .hit
(195,256) .Y inc
(195,258) .acknowledge 3
(196,256) .Y inc
(196,262) $2006 ** v(02C0) <- t(02C0)

frame 5
(195,249) .hit 1
(195,256) .acknowledge 3
(195,256) .Y inc
(196,256) .Y inc
(196,260) $2006 ** v(02C0) <- t(02C0)

frame 6
(195,249) .hit 3
(195,256) .Y inc
(195,264) .acknowledge 5
(196,256) .Y inc
(196,268) $2006 ** v(02C0) <- t(02C0)


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 8:02 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 753
Location: New York, NY
Can you sort those by (line, ppu_cycle)?


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 3:36 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
(the game in subject is The Simpsons - Bart vs Space Mutants, with flickering scorebar)
I see that frames 2,3,4 seems to be the "correct" situation. The flickering occurs because of an early $2006 second write. The game detects sprite #0 hit and switches to a scroll-related subfunction. Since Y increment occurs after the write, the scorebar flickers. Problem is... You see the sprite #0 occuring always at same line & PPU cycle, but the CPU is "losing sync" with the PPU (off by 1). Since my emu get a PASS in all those test ROMs (CPU and PPU timing, including sprite stuff timing), I don't know how to solve this puzzle, but I hope to make it. ^_^;;
zeroone wrote:
Can you sort those by (line, ppu_cycle)?

Why?


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 3:43 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
These logs are great and tell us everything we need. Thanks Zepper. :mrgreen:

Looks like the problem was the opposite of what I was expecting. Your window is too large.

Frames 2-6 seem to be running as the game expects, but frame 1 is changing the scroll too early. It should be happening after the Y inc -- not before it.

Could be that your sprite 0 hit is happening just a cycle too early. Are you adding the 1 cycle delay for the pipelining effect?

http://wiki.nesdev.com/w/images/d/d1/Ntsc_timing.png

Note where it says: "Sprite zero hits act as if the visible image starts at h = 2 (i.e., the sprite 0 flag will be set during the third tick of a scanline at the earliest)"


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 4:11 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 753
Location: New York, NY
Disch wrote:
Note where it says: "Sprite zero hits act as if the visible image starts at h = 2 (i.e., the sprite 0 flag will be set during the third tick of a scanline at the earliest)"


Does that note mean that the sprite 0 flag is set 2 PPU cycles after the hit actually occurs?


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 5:48 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
No. The numbering on that page is based on what I assume is the numbering used in Visual2C02, which renders pixels on dots 1-256, and not 0-255 like you might be thinking.

So the very first pixel of the scanline is output on h=1, which means the earliest spr0 can hit is h=2. So only a 1 cycle delay.

(this might also explain why spr0 never hits when h=256 ... as the pipelining delay pushes it outside that "phase" of ppu operation)


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 6:01 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Delaying by 1 CPU cycle fixes the game & still got a PASS in sprite_hit_timing test. But I got a FAILED #2 with "sprite hit left clipping" test. Also fails in "sprite hit order FAILED #3" and "edge timing FAILED #2".


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 6:22 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 753
Location: New York, NY
Zepper wrote:
Delaying by 1 CPU cycle fixes the game & still got a PASS in sprite_hit_timing test. But I got a FAILED #2 with "sprite hit left clipping" test. Also fails in "sprite hit order FAILED #3" and "edge timing FAILED #2".


What about a delay of 1 PPU cycle?


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 6:23 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Zepper: As zeroone said... 1 CPU cycle is too much. It should only be 1 PPU cycle


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 6:35 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Disch wrote:
Zepper: As zeroone said... 1 CPU cycle is too much. It should only be 1 PPU cycle

Not good. :oops: If there are 3 or 2 PPU cycles left, there's no difference in delaying it by 1. If there's only 1 PPU cycle left, well... the sprite hit would take effect only in the next CPU cycle.
Still no lucky here... still trying...


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Wed Jan 13, 2016 7:10 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Quote:
the sprite hit would take effect only in the next CPU cycle.


But isn't that what you need? From the log you posted, your sprite 0 hit is just 1 cycle early, so if you push it forward a cycle, wouldn't that solve it?


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 5 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