I've no idea how to find where it does timing. But if you compile the network version and let it fail to connect it seems to reboot and every time seems to give different values. Need to double check but pretty sure that was what was happening which is puzzling.

Ian wrote:I've no idea how to find where it does timing. But if you compile the network version and let it fail to connect it seems to reboot and every time seems to give different values. Need to double check but pretty sure that was what was happening which is puzzling.

That is weird. It must be doing something weird to measure wall clock time. I wonder if it's relying on IRQs or assuming that frame timing (e.g., the decrementer value and the exception it generates on each frame based on the status bit timing value measured at boot time) is a correct reference. Locating the code will take some time. I'll try to have a look on Tuesday or Wednesday during some down time at work.

It says 60FPS in each case (or does it jump up to 60 when you pause?).

And, yes, it will definitely depend on real wall clock time. The CMOS clock chip is emulated simply as a pass-through to standard C library system time calls. If the game is running at 60 FPS, it should be fine, unless it is doing its timing one frame at a time rather than one second at a time (e.g., MHz = cycles / T where T is measured as milliseconds from beginning to end of frame, which will be less than 16.67 ms on a fast computer).

By the way, look at line 29 of RTC72421.cpp That comment has been in there since day 1.

I actually think the emulation should remain this way although we could add a mode that computes time from PowerPC clock ticks.

What's the resolution or accuracy of these C functions?If the system is polling the time register waiting for it to tick over. But we are only accurate to 1/2 a second maybe we'll be in trouble with regards to accuracy?

I'm not sure but millisecond resolution should not be a problem. These functions are widely used for timing and for calibrating high-precision timers. I suppose I could check and see if tying the RTC to the PowerPC clock fixes that screen. We know how to map between PowerPC cycles and real time, so it's a trivial calculation. I'll look at it tomorrow or Wednesday.