It is currently Thu Dec 14, 2017 1:52 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 43 posts ]  Go to page Previous  1, 2, 3  Next
Author Message
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 12:54 pm 
Offline
User avatar

Joined: Sat Jan 22, 2005 8:51 am
Posts: 427
Location: Chicago, IL
Which games are you having problems with?

_________________
get nemulator
http://nemulator.com


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 1:28 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
29780 cycles between NMIs, always alternating by 1 cycle (even/odd frames).
James wrote:
Which games are you having problems with?

The Simpsons: Bart vs Space Mutants (shaking scorebar)
Kick Master (waving title screen)
Battletoads (hangs during stage 2)


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 1:46 pm 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 750
Location: New York, NY
Zepper wrote:
The Simpsons: Bart vs Space Mutants (shaking scorebar)


If I recall correctly, this has to do with handling the sprite 0 hit too early or too late.


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 2:28 pm 
Offline

Joined: Mon Sep 27, 2004 11:51 pm
Posts: 101
Zepper wrote:
29780 cycles between NMIs, always alternating by 1 cycle (even/odd frames).


Odd frames should be 1 PPU (not CPU) cycle shorter when rendering is enabled.

_________________
http://hydesprojects.cjb.net/


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 2:35 pm 
Online

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6524
Location: Seattle
341×262 = 89342 PPU cycles; ÷3 = 29780⅔ CPU cycles
341×262-1 = 89341 PPU cycles; ÷3 = 29780⅓ CPU cycles.

There might be some funny edge cases going wrong by rounding these thirds up and down, but it's on average correct.


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 3:05 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
I could make available my PPU C source code for help. Anyone interested in taking a look? ;)


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

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Zepper wrote:
29780 cycles between NMIs, always alternating by 1 cycle (even/odd frames).


No... I mean...

the game is changing the scroll to split the screen. How many cycles are between that and the last CPU interaction with the PPU (NMI? Sprite 0 hit?)

If the game is taking 500 cycles between when it detects sprite 0 and when it change the scroll, but your emu only gives 499, then that would cause shaking. You need to look at what the game is doing and how it is doing it so you can see where your emu is going wrong.


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 5:03 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Fine, but I have no reference about the number of cycles between a sprite #0 hit detection ($2002 reads $40 set) and $2006 (second write). Is the following helpful? (CPU cycles between $2002:$40 and $2006 sec.write)
Code:
-frame-
.$2006 (56)
.$2006 (638)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (59)
.$2006 (641)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (59)
.$2006 (641)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (61)
.$2006 (643)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (57)
.$2006 (639)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (60)
.$2006 (642)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (57)
.$2006 (639)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (56)
.$2006 (638)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (57)
.$2006 (639)
.sprite zero hit
.$2006 (114)
-frame-
.$2006 (58)
.$2006 (640)
.sprite zero hit
.$2006 (114)


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 5:18 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Quote:
I have no reference about the number of cycles between a sprite #0 hit detection ($2002 reads $40 set) and $2006 (second write).


That's what you need.

There are 2 critical times:
A) PPU->CPU interaction (NMI / Sprite 0)
B) CPU->PPU interaction (scroll change)


So you need to answer the following questions:

1) How many cycles does the game need between A and B?

2) How many cycles is your emu giving? (it's probably slightly less, or might be more)

3) Why?


Until you can answer those questions, you don't know what is going on and any "solution" you get will be a hack or just dumb luck. You can't solve this problem without knowing what the problem is.



EDIT:

All you need here is a tracelog of CPU execution for a frame that includes timestamps. Something that walks through each instruction that the game is doing, prints register contents, and tells you the time (scanline+dot) of the instruction. That should give you enough info to start putting the pieces together here.


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 5:47 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
Fine. I'll try. :| :mrgreen: :mrgreen:


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Mon Jan 11, 2016 6:35 pm 
Offline
User avatar

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Also if you can mark the time at which the scroll updates (Y scroll increment and X scroll reset) that would help too. That way you can see why if the $2005/6 writes are coming in too early or too late.


EDIT:

To clarify.... if the game is using Spr0 hit:

time 'A': PPU detects sprite 0 hit, raises flag in $2002
time 'B': CPU reads $2002, sees that flag is set
time 'C': CPU does $2005/6 writes to change the scroll
time 'D': PPU updates scroll at end of scanline


D-A is the 'window' that your PPU is giving

So if the game is expecting that window to be 500 cycles, but in your emu it is only 499 cycles, the you might get shakiness because the game might take too long to change the scroll.



Or... if the game is using IRQs, time 'A' / 'B' would be IRQ generated / IRQ taken.


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Tue Jan 12, 2016 11:36 am 
Offline
User avatar

Joined: Mon Dec 29, 2014 1:46 pm
Posts: 750
Location: New York, NY
@Zepper This log may help. The status bar in The Simpsons - Bart vs. the Space Mutants does not shake in my emulator. Maybe you can do a diff and figure out why.


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Tue Jan 12, 2016 6:34 pm 
Offline
Formerly Fx3
User avatar

Joined: Fri Nov 12, 2004 4:59 pm
Posts: 3076
Location: Brazil
zeroone wrote:
@Zepper This log may help. The status bar in The Simpsons - Bart vs. the Space Mutants does not shake in my emulator. Maybe you can do a diff and figure out why.


No :)

Found the reason, but I have no clue why.
A taken non-page-crossing branch (BVC #$FB) is executing an extra cycle. This is messing up the sprite zero timing. Isn't that extra cycle correct!? Games like Mega Man V, Kick Master and The Simpsons have no more flickering.


Top
 Profile  
 
 Post subject: Re: PPU timing?
PostPosted: Tue Jan 12, 2016 6:42 pm 
Online

Joined: Sun Sep 19, 2004 11:12 pm
Posts: 19345
Location: NE Indiana, USA (NTSC)
Not taken: 2 cycles
Taken: 3 cycles
Taken, different page from not taken: 4 cycles


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

Joined: Wed Nov 10, 2004 6:47 pm
Posts: 1845
Zepper wrote:
Found the reason, but I have no clue why.


If you don't know why, then you don't know that it's the reason. You're just guessing. And you're probably guessing incorrectly.

Quote:
A taken non-page-crossing branch (BVC #$FB) is executing an extra cycle. This is messing up the sprite zero timing. Isn't that extra cycle correct!?


Yes, BVC takes 3 cycles if a branch is taken and does not cross a page.

So that must not be the reason.



Zepper -- you can keep trying random things and hoping that you'll stumble across the solution, or you can do some real debugging and just find out what the problem is. I'm serious -- make a trace log. If your emu doesn't have a logger... write one. You need to know what your emu is doing when you run this game so that you can see what it's doing wrong. Without that information you're flying blind, and solving this problem will be impossible.


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

All times are UTC - 7 hours


Who is online

Users browsing this forum: Google [Bot] and 9 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