CPU clock speed

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!

CPU clock speed

Postby Ian » Sat Jan 13, 2018 4:19 am

I noticed that daytona's detection of the CPU/bus speed is totally broken ? Maybe this is effecting how timing works.

What daytona should look like

Image

Comparison at different CPU frequencies

Image

Image

Image
Ian
 
Posts: 1485
Joined: Tue Feb 23, 2016 9:23 am

Re: CPU clock speed

Postby Jiterdomer » Sat Jan 13, 2018 9:16 am

This would he a hint that affects all Model 3 games?
Feel the heartbeat of my machine through this tight seat. I feel every motion of my machine
Image
User avatar
Jiterdomer
 
Posts: 494
Joined: Mon Sep 26, 2011 6:37 pm
Location: Los Angeles, CA

Re: CPU clock speed

Postby HarryTuttle » Sat Jan 13, 2018 1:02 pm

Ian wrote:I noticed that daytona's detection of the CPU/bus speed is totally broken ? Maybe this is effecting how timing works.


Very interesting... all these times under my the nose and never noticed :)
User avatar
HarryTuttle
 
Posts: 646
Joined: Thu Mar 09, 2017 8:57 am

Re: CPU clock speed

Postby Ian » Sat Jan 13, 2018 1:22 pm

I only noticed it because the guy made a video of daytona booting for spindizzi. There must be something off with our CPU emulation or something if the values are so way off. Maybe Bart will have some ideas about this.
Ian
 
Posts: 1485
Joined: Tue Feb 23, 2016 9:23 am

Re: CPU clock speed

Postby Spindizzi » Sun Jan 14, 2018 12:32 am

I think it's due to the design of the emulator itself (how it is programmed)
Mainly the way cpu are emulated
for the 68k, it is given a number of cycles to work for a lapse of time, but during this time, it does not necessarily use all these cycles that it has (no op).
An asm instruction has a predifined number of cycles. I do not think I saw in the code, you cpu, you have to operate at such frequency (frequency is derivated by cycles)
We see very well the phenomenon when using the supermodel debug mode. I guess it's the same for ppc
Spindizzi
 
Posts: 119
Joined: Thu Nov 17, 2016 8:55 am
Location: France

Re: CPU clock speed

Postby Bart » Sun Jan 14, 2018 2:45 pm

Nik had it working once, I think. Without having looked at how Daytona 2 measures clock speed, I suspect there are a few things at play here. I actually wrote a CPU timing routine that works on Model 3 and to start with, that one might be a better one to test against because we know exactly how that one is supposed to work. Daytona 2 almost certainly does something similar because, well, how else would you do it? Here is my code (edited for clarity):

Code: Select all
  uint32_t tb0 = ppc_get_tbl();
  prev_second = rtc_get_time().second;

  while (!quit)
  {
    // Whenever the second rolls over, compute refresh rate and CPU frequency
    struct RTCTime t = rtc_get_time();
    if (t.second != prev_second)
    {
      uint32_t tb = ppc_get_tbl();
      prev_second = t.second;
     
      // Compute CPU clock speed assuming a 1:1 processor/bus clock multiplier.
      // Time base registers tick every 4 bus cycles.
      double mhz = 4.0 * (tb - tb0) / 1e6;
      tilegen_printf_at(2, 6, "CPU: %1.3f MHz", mhz);
      tb0 = tb;     
    }   
  }


Pretty simple, right? We need something that counts the passage of real time: the real-time clock module. This is a CMOS device that returns a "wall clock time" and date in seconds. All you need to do is wait one second of real wall clock time and then count the number of ticks elapsed according to the PowerPC's time base register, which ticks every 4 *bus* cycles. I think on all Model 3 systems, the bus frequency is 66 MHz but the CPU is 66 (Step 1.0), 100 (Step 1.5), or 166 (Step 2.x) MHz. So the number of CPU clock cycles per time base tick differs. On Step 1.0, it's just 1 tick = 4 bus cycles = 4 CPU cycles.

So what's going on with Daytona 2? Well, I don't know for sure, but let's think about it. We emulate the CMOS clock by returning the real wall clock time. So if you increase the frequency to 166 MHz and the frame rate dips below 60 FPS, the game will see that fewer than 166 million CPU cycles were executed in one actual second. So that's one potential problem. Nik also wrote code to further scale the time base ticks to the emulated frequency so that they always matched the correct frequency. The emulator ticks the time base register such that after emulating N cycles (where N is the frequency we set in Supermodel, I think 50 MHz by default), the time base register should look as though the *true* number of cycles (e.g., 166 million for Daytona 2) has elapsed.

It *should* be possible to get Supermodel to report the correct clock frequency even when running at a lower simulated frequency because of this multiplier. I vaguely recall Nik saying it didn't quite work for some reason but I don't know why. I think a better place to start would be my timing program. If anyone's interested, I could supply the ROM set and the necessary entry for Games.xml to get it up and running. Even without it, you could probably just print the difference in TBL after each second and see if makes sense from a timing perspective. You'll probably first want to undo the effect of that extra scaling value Nik multiplies by somewhere in the PowerPC core (set it to 1). I'll need to look into that at some point for frame timing because you guys are right -- it should just work.
User avatar
Bart
Site Admin
 
Posts: 2178
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: CPU clock speed

Postby Jiterdomer » Sun Jan 14, 2018 2:52 pm

This is because Spindizzi emulated the network emulation and three games (Harley, Dirt Devils, and Ski Champ) worked without issues and when he tried Daytona 2 and Scud Race, it just keep resetting the networking process at boot.
Feel the heartbeat of my machine through this tight seat. I feel every motion of my machine
Image
User avatar
Jiterdomer
 
Posts: 494
Joined: Mon Sep 26, 2011 6:37 pm
Location: Los Angeles, CA

Re: CPU clock speed

Postby Ian » Sun Jan 14, 2018 3:15 pm

This isn't specially network related. General timing in the emulator is slightly broken. Maybe if we can fix this other things might fall into place.

I did try this in mame and it was also broken. I think under mame Daytona reported the same bus speed as clock speed.
Ian
 
Posts: 1485
Joined: Tue Feb 23, 2016 9:23 am

Re: CPU clock speed

Postby Bart » Sun Jan 14, 2018 3:31 pm

Ian wrote:This isn't specially network related. General timing in the emulator is slightly broken. Maybe if we can fix this other things might fall into place.

I did try this in mame and it was also broken. I think under mame Daytona reported the same bus speed as clock speed.


I notice now that you're getting a consistent 60 FPS so we can rule out emulator slowness as an issue if the game uses the real-time clock for wall clock time. It's really bizarre how the bus frequency goes down as the clock speed is increased. I just checked and my timing test works. If you want to give it a go you can download it here and do: supermodel -game-xml-file=test.xml crom.zip

Daytona 2 must be doing something different to measure frequency. I wonder if its method for timing is somehow linked to overall frame timing? The CPU frequency *is* correctly derived from the bus frequency: CPU = (166/66) * bus.
User avatar
Bart
Site Admin
 
Posts: 2178
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Re: CPU clock speed

Postby Bart » Sun Jan 14, 2018 3:40 pm

If someone could help identify *where* the timing code exists I could reverse engineer it probably without too much difficulty.
User avatar
Bart
Site Admin
 
Posts: 2178
Joined: Thu Sep 01, 2011 2:13 pm
Location: New York City

Next

Return to The Dark Room

Who is online

Users browsing this forum: No registered users and 3 guests