PPU timing?

Discuss emulation of the Nintendo Entertainment System and Famicom.

Moderator: Moderators

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

Re: PPU timing?

Post by Zepper »

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.
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPU timing?

Post by Disch »

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:
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: PPU timing?

Post by Zepper »

Code: Select all

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)
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: PPU timing?

Post by zeroone »

Can you sort those by (line, ppu_cycle)?
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: PPU timing?

Post by Zepper »

(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?
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPU timing?

Post by Disch »

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)"
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: PPU timing?

Post by zeroone »

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?
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPU timing?

Post by Disch »

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)
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: PPU timing?

Post by Zepper »

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".
User avatar
zeroone
Posts: 939
Joined: Mon Dec 29, 2014 1:46 pm
Location: New York, NY
Contact:

Re: PPU timing?

Post by zeroone »

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?
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPU timing?

Post by Disch »

Zepper: As zeroone said... 1 CPU cycle is too much. It should only be 1 PPU cycle
User avatar
Zepper
Formerly Fx3
Posts: 3262
Joined: Fri Nov 12, 2004 4:59 pm
Location: Brazil
Contact:

Re: PPU timing?

Post by Zepper »

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...
User avatar
Disch
Posts: 1848
Joined: Wed Nov 10, 2004 6:47 pm

Re: PPU timing?

Post by Disch »

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?
Post Reply