ppc: Model configurable CPU frequencies - #209
Merged
Merged
Conversation
Virtual time previously advanced by a fixed 16 ns per interpreted
instruction, making every CPU behave like the legacy 62.5 MHz model
regardless of the selected machine. G3 guests also received ad hoc HID1
values from individual machine implementations, while Gazelle supported
several frequencies that could not share that logic.
Require each machine to provide its hardware-appropriate bus, core, and
timebase clocks through one `PPC_CPU_Config` configuration object. We can then
derive things from it (e.g. supported MPC603ev and MPC750 HID1 PLL encodings).
We can also populate the `include_601` global based on `version` instead of a
separate flag.
To model time with more flexibility, we now use 60.4 fixed-point nanoseconds for
instruction timing. This lets us have a broad set of frequencies and still
support running the CPU for ~35 years of virtual time before it overflows.
This results in two emulation accuracy improvements:
- Tiger successfully gets to the Finder. The virtual time we were exposing to
the guest was advancing too quickly, preventing loginwindow from connecting
before WindowServer's internal five-second no-client timer expired.
The server then exited normally, loginwindow aborted when it could not
establish its CoreGraphics connection, and we remained stuck at the last
textual output from a verbose boot ("Waiting for IFC").
- Animations are now more accurate (e.g. Mac OS X dock icon bouncing is no
longer too fast on a G3)
dingusdev
approved these changes
Aug 13, 2026
dingusdev
left a comment
Owner
There was a problem hiding this comment.
This is a very nice commit which cleans up the virtual timer. A small bonus is the nicer CPU initialization.
Contributor
Author
|
(was reverted due to x86-64 performance issues, will try again) |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Virtual time previously advanced by a fixed 16 ns per interpreted instruction, making every CPU behave like the legacy 62.5 MHz model regardless of the selected machine. G3 guests also received ad hoc HID1 values from individual machine implementations, while Gazelle supported several frequencies that could not share that logic.
Require each machine to provide its hardware-appropriate bus, core, and timebase clocks through one
PPC_CPU_Configconfiguration object. We can then derive things from it (e.g. supported MPC603ev and MPC750 HID1 PLL encodings). We can also populate theinclude_601global based onversioninstead of a separate flag.To model time with more flexibility, we now use 60.4 fixed-point nanoseconds for instruction timing. This lets us have a broad set of frequencies and still support running the CPU for ~35 years of virtual time before it overflows.
This results in two emulation accuracy improvements: