Frame timing (again)

Technical discussion for those interested in Supermodel development and Model 3 reverse engineering. Prospective contributors welcome.
Forum rules
Keep it classy!

  • No ROM requests or links.
  • Do not ask to be a play tester.
  • Do not ask about release dates.
  • No drama!

Frame timing (again)

Postby Ian » Mon Oct 07, 2019 4:39 am

I know this is a horse we've beaten to death :)
Bart patched his vf3 and got it to dump some of the actual timing values from the GPU. Without these actual timing is complete guess work.
Anyway plugging in these values many of the games seemed to work really well. Some not at all..

Strangely I found with scud a big difference between laying the frame out like this

Code: Select all
                              11ms
----------irq2--------------------------ping_pong_flip


                 11ms
irq2-------------------------ping_pong_flip-----------



The first one works properly, the 2nd one is dropping frames all over the place during gameplay because the calculated frame time is too short. How can this be? I would expect that them two to be virtually the same, other than the frame writes would happen a bit earlier in the 2nd one since IRQ2 is called a bit earlier, but otherwise should be identical.

In virtua fighter 3 with the 'correct' timing values this is happening

Code: Select all
-----end frame-----
status 2000000 0
irq2 deassert data 2 0              <------- this frame got skipped
dec exception 65
-----end frame-----
status 2000000 0
irq2 deassert data 2 0
polygon RAM - 1 98003c80
database updated
high culling ram - 20 8e000000
flush - 20
status 2000000 20
tile gen - 20
irq2 deassert data 2 23          <---------- de-assert irq2 at 23% of the frame
reg c data 3 23
dec exception 86
-----end frame-----
status 2000000 0
irq2 deassert data 2 0
polygon RAM - 13 98003c80
database updated
high culling ram - 35 8e000000
flush - 35
status 2000000 35
tile gen - 35
irq2 deassert data 2 38          <---------- de-assert irq2 at 38% of the frame
reg c data 3 38
-----end frame-----


Frames seem to be off by 15%~ the values keep drifting in game the longer it runs. But every 3rd frame seems to skip.

If the tilegen is controlling the frame timing/drawing. Does this thing just start firing irq2 as soon as it's switched on. Does it sync with the CPU somehow. And I think the answer to this is it syncs with the CPU. The very first write to the is the hex value 6e or decimal 110. For most games, this is the ONLY time this value ever gets written. Sometimes it's polled. Like here it gets written twice.

Looks something like this

Code: Select all
-----end frame-----
-----end frame-----
-----end frame-----
-----end frame-----
-----end frame-----
irq2 deassert data 6E 2%
irq2 deassert data 6E 13%


For virtua fighter 3 it first gets written at 2% and then 13% of our frame. Im wondering if this command resets the timer in the tilegen and the start of the frame should start from here? If so that would explain the difference for scud with apparently the same frame times. It would also explain why games only work with such crazy different timing values.

I know we've been stabbing in the dark a lot with this problem, but I think this could well be correct.
Ian
 
Posts: 2044
Joined: Tue Feb 23, 2016 9:23 am

Re: Frame timing (again)

Postby sonic32 » Mon Oct 07, 2019 10:12 am

awesome job Ian :D
User avatar
sonic32
 
Posts: 169
Joined: Tue Dec 20, 2011 11:43 am
Location: Slovakia

Re: Frame timing (again)

Postby Ian » Mon Oct 07, 2019 2:28 pm

Some of these problems are super hard with no documentation
If only people knew how time / effort has been spent to try and solve them
Ian
 
Posts: 2044
Joined: Tue Feb 23, 2016 9:23 am


Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 0 guests

cron