Supermodel Forum

PDNEJOH
In topic about bugs, I also want to ask about this bug occuring in Daytona USA 2 (BOTE). Specifically, during "Tips to Win" part when it shows how to drift your car. When the car is near the finish line it will try to steer left going out of track and grinding the backstretch(?).

Here's some videos linked to the right timecodes

https://youtu.be/t-dWPluAyJU?t=103
https://youtu.be/9vvtmFQXYLY?t=99

Looks like in the emulator the final angle of the car is off just a little bit.

Here is a comparison shot when the cars are at the finish line. You can see the end position is quite different in the emulated version.

gm_matthew
I tried tinkering with the emulated floating point calculations once and was able to get the car to behave slightly differently. But I had no luck in getting it to match real hardware

Could this be a CPU bug floating point bug? Maybe the correct rounding mode is not set? I assume animation happens against a time value, ie the difference between 2 frames. Maybe some time value is off somewhere.

Thought I'd try out mame just to see what it's like

https://youtu.be/57S4k_1nTxk

Mame has the same bug interestingly, only it's much worse. The cars spend a good amount of time just grinding against the walls, or going off course completely

This occurs in replays, too. I can find an example on YouTube where during the replay, the car veers off into grass whereas that never happened in the actual race. If these sequences are replaying control inputs, it could indicate a timing bug. It seems unlikely that being off by a single frame could cause this but if our timing is off by a few frames, a single mistake would end up invalidating the rest of the frames going forward. I would assume such a replay system is timed frame-by-frame but could they be doing something crazy like using the time base counter?

In mame the steering is happening too late. I am not sure how late but it's definitely more than a frame.
I wonder why the big difference in supermodel vs mame.

I tried changing the CPU frequency from 50 -> 166 and couldn't perceive a difference. That supports your theory that there is some sort of a floating point error.

But here's another oddity: Despite our efforts to make sure the time base registers count at the right rate, the clock speed measurement at the beginning of Daytona 2 is incorrect (it flashes for a moment). Nik at one point had figured out how to make it correct and I forget what the issue is. I can try to see if I still have that email. Maybe it's nothing but maybe the game is timing things in a way that is fundamentally prone to drift because of some issue with our frame timing or TBR registers. Even at 166 MHz, the game seems to think the PowerPC is running at sub-100MHz speeds.

Bart wrote:But here's another oddity: Despite our efforts to make sure the time base registers count at the right rate, the clock speed measurement at the beginning of Daytona 2 is incorrect (it flashes for a moment). Nik at one point had figured out how to make it correct and I forget what the issue is. I can try to see if I still have that email. Maybe it's nothing but maybe the game is timing things in a way that is fundamentally prone to drift because of some issue with our frame timing or TBR registers. Even at 166 MHz, the game seems to think the PowerPC is running at sub-100MHz speeds.

Yeah I've noticed that before. The clock speed calculation *works* in mame and gives stable values, only they seem to have sort of bug. Bus clock not being incremented correctly?



I wonder if it is using the real time clock for time calculations? Maybe we are incrementing too fast or too slow based upon number of clock cycles.

Ian wrote:

Bart wrote:But here's another oddity: Despite our efforts to make sure the time base registers count at the right rate, the clock speed measurement at the beginning of Daytona 2 is incorrect (it flashes for a moment). Nik at one point had figured out how to make it correct and I forget what the issue is. I can try to see if I still have that email. Maybe it's nothing but maybe the game is timing things in a way that is fundamentally prone to drift because of some issue with our frame timing or TBR registers. Even at 166 MHz, the game seems to think the PowerPC is running at sub-100MHz speeds.

Yeah I've noticed that before. The clock speed calculation *works* in mame and gives stable values, only they seem to have sort of bug. Bus clock not being incremented correctly?



I wonder if it is using the real time clock for time calculations? Maybe we are incrementing too fast or too slow based upon number of clock cycles.

Change to 57.524 and see what happens.

Or Look what i found here on this video.
https://www.youtube.com/watch?v=Q_h1WSXOGIA
If we pause at 0:11 we get this: https://i.ibb.co/NxsRBYS/Daytona-USA-2- ... shot-1.png

166.668 mhz
66.667 mhz

Search always some videos with real PCB's to find the real speed clock of daytona if you don´t have any.

Well, the answer to why the clock speed calculation is so b0rked is what I thought, it's using the real time clock. If you stub the last digit (seconds) to just return 0 it can take up to 10 seconds for it to calculate the clock speed lol.
I think if the RTC was just incremented with (emulated time) not real time, then the calculation might work correctly.

But I don't think this is what is causing the issues with daytona. The RTC clock is only accurate to seconds which is not really enough to do anything useful with for game logic.

Ian wrote:Well, the answer to why the clock speed calculation is so b0rked is what I thought, it's using the real time clock. If you stub the last digit (seconds) to just return 0 it can take up to 10 seconds for it to calculate the clock speed lol.
I think if the RTC was just incremented with (emulated time) not real time, then the calculation might work correctly.

That actually surprises me because with only 1 second granularity, the timing should only be off by about a frame, or a small percentage. This would be an easy fix and I can attempt it.

But I don't think this is what is causing the issues with daytona. The RTC clock is only accurate to seconds which is not really enough to do anything useful with for game logic.

I thought perhaps it was using the clock speed value to somehow calibrate a cycles -> real time conversion. But increasingly, I think you are right, and there is probably some sort of floating point bug.

The cpu multiplier is what 2.5? In mame it seems to be set at 1. If the issue is not there ... it could be some sort of cpu bug. In mame they are using a dynamic recompiler into native code. So there is a much greater chance of some sort of float or Nan handling issue to creep in.

Edit: well i tried messing with the multiplier, but it made no difference to playback. So yeah it could well be some sort of floating point bug. The question is, if it is how can we even check this? Buy an old mac with a 603e processor? lol

The
PowerPC architecture provides for hardware to implement a floating-point system as
defined in ANSI/IEEE Standard 754-1985, IEEE Standard for Binary Floating Point
Arithmetic.

Sounds similar to what i assume modern cpus would comply to?

I wonder if it could be this

The standard also recommends extended format(s) to be used to perform internal computations at a higher precision than that required for the final result, to minimise round-off errors: the standard only specifies minimum precision and exponent requirements for such formats. The x87 80-bit extended format is the most commonly implemented extended format that meets these requirements.

Maybe these older cpus didn't use any kind of float extended format?