Processor speed accuracy?

[EriolGaurhoth]

I'm unsure if this is a bug, intentional, or simply a feature not implemented yet but I noticed while running an emulated instance of the Power Macintosh 7500 using "--machine pm7500" and the correct ROM under System 7.5.2, Apple System Profiler 1.4 reports the CPU as a 601 running at 60MHz.

The actual original Power Mac 7500's 601 processor runs at 100MHz so I'm not sure if this is either

1. a bug where the processor speed is being underreported or
2. the emulator is actually running the emulated 601 at an underclocked 60MHz for this machine

If it is 1, then consider this a bug report to figure out why it's being underreported but if it's 2, then this is a feature request to bump up the speed of the emulated 601 for this machine to its original 100MHz spec.

...or I guess it could be that I've done something wrong in configuring the system, and there's some other option to boost the clock speed that I'm unaware of.

My host machine is a Lenovo Legion running the latest version of Windows 11 Professional with an AMD Ryzen 9 HX 470, 32GB of RAM and an NVIDIA GeForce RTX 5060 Laptop GPU.

[dingusdev]

There's not any speed control yet. I think it's just grabbing whatever the lowest possible value for speed is for a given processor. It happens across all machines.

[EriolGaurhoth]

There's not any speed control yet. I think it's just grabbing whatever the lowest possible value for speed is for a given processor. It happens across all machines.

Got it. I'd then consider this to be a "feature request" with the potential addition of a speed control. If the overall goal of the project is accurate emulation of these guest machines, I'd say having the right CPU speed is essential.

[joevt]

Changing icnt_factor changes the the number of nanoseconds per instruction.
It needs to be a value that the ROM accepts (not an invalid frequency).
But it should also be a value that most matches the performance of the host (given all the overhead of the emulation - such as display redrawing).

     icnt_factor =
//          // 1 instruction =        // PDM cpu clock calculated at 0x403036CC in r3
//      11; // 2048 ns =    0.488 MHz // 00068034 =   0.426036 MHz = 2347.219 ns // floppy doesn't work
//      10; // 1024 ns =    0.977 MHz // 000D204C =   0.860236 MHz = 1162.471 ns // invalid
//       9; //  512 ns =    1.953 MHz // 001A6081 =   1.728641 MHz =  578.489 ns // invalid
//       8; //  256 ns =    3.906 MHz // 0034E477 =   3.466359 MHz =  288.487 ns // invalid
//       7; //  128 ns =    7.813 MHz // 0069E54C =   6.939980 MHz =  144.092 ns // invalid
//       6; //   64 ns =   15.625 MHz // 00D3E6F5 =  13.887221 MHz =   72.008 ns //
//       5; //   32 ns =   31.250 MHz // 01A7B672 =  27.768434 MHz =   36.012 ns //
         4; //   16 ns =   62.500 MHz // 034F0F0F =  55.512847 MHz =   18.013 ns // 6100/60 in Apple System Profiler
//       3; //    8 ns =  125.000 MHz // 069E1E1E = 111.025694 MHz =    9.006 ns // invalid
//       2; //    4 ns =  250.000 MHz // 0D3C3C3C = 222.051388 MHz =    4.503 ns // invalid
//       1; //    2 ns =  500.000 MHz // 1A611A7B = 442.571387 MHz =    2.259 ns // invalid
//       0; //    1 ns = 1500.000 MHz // 3465B2D9 = 879.080153 MHz =    1.137 ns // invalid

With a value of 4 (16 ns per instruction, 55.5 MHz), the Power Mac 6100 and the Power Mac 7500 show the CPU as 60 MHz.

For the Power Mac 6100, the MHz is converted to one of 3 machine gestalt ID values representing the 50, 66, and 80 MHz models:

//      [0,10] MHz = invalid clock for PDM gestalt calculation
//      (10,60] = 50, (60,73] = 66, (73,100] = 80 MHz
//      (100,∞) MHz = invalid clock for PDM gestalt calculation

A future change should change how g_icycles and icnt_factor work. g_icycles should count nanoseconds (with fractional bits). icnt_factor should be an increment (including the fractional bits). Conversion to virtual time just requires removing the fractional bits (a right shift instead of the current left shift in get_virt_time_ns). This change requires ppc_exec_inner to use the increment amount.

[EriolGaurhoth]

A future change should change how g_icycles and icnt_factor work. g_icycles should count nanoseconds (with fractional bits). icnt_factor should be an increment (including the fractional bits). Conversion to virtual time just requires removing the fractional bits (a right shift instead of the current left shift in get_virt_time_ns). This change requires ppc_exec_inner to use the increment amount.

Sounds like a great plan to me! From the end-user perspective, I think it would make sense to add something like a "--cpuspeed" parameter to set the requested clock speed, especially given there can be multiple acceptable clock speeds for the same machine+cpu combination. And I understand that without dynamic recompilation implemented, higher clock speeds might be painfully slow in practice on slower host CPUs, but it's still a nice feature to have for accuracy's sake, otherwise there's very little discernable difference between running a 6100 and 7500 if they have the same CPU speed.

[jumpon5]

Hi dingusdev, Please add the GUI window, including the window, choose machine, etc
If you said no, it's ok.

[dingusdev]

I'll worry about the GUI stuff later.

More relevantly, alicela1n submitted a pull request related to this (#172). I'll definitely want to optimize the interpreter at least before delving into this. joevt has updated it in his fork and when the emulator is advanced and stable enough to handle changes in speeds, I'll probably merge that in.

As for implementing this, I'm not exactly sure if messing with g_cycles and icnt_factor is the best method, given how sensitive those appear to be. There's also interesting thing going on with bus speeds and clock speeds and such, but I'd stick mostly with CPU speeds to avoid complications.

[mihaip]

#210 should help with this a bit.