M68kemu api migration - #2
Conversation
Adopt the new CPU-core API and use it to speed up ROM execution. - EnableTrace installs the observation callbacks through the single SetHooks call instead of the separate SetXxxTracer setters. - Boot-ROM fetches and TOS-vector reads bypass the bus through a read-only flat memory window (SetFastMemory) over each isolated ROM mirror. EmuTOS runs entirely from ROM, so this is ~14% of an EmuTOS-boot benchmark; wait-state accounting matches the bus path exactly, so a 45-frame boot-parity test and the full debug-trace suite are byte-for-byte identical to the pure-bus path. machine.disableFastMemory forces every access back through the bus. - devices.Interrupt.Vector and Machine.RequestInterrupt take a plain uint8 (devices.AutoVector / 0) instead of *uint8. - The eight single-range peripherals (ACIA, GLUE, MFP, PSG, FDC, Blitter, STE sound, cartridge ROM) expose AddressRange() and drop their identical Contains boilerplate; the bus page-maps them. Devices with non-contiguous or state-dependent decode keep Contains. docs/m68kemu-api-proposal.md records the design and the parts of it that have not landed (the scheduler / IRQ-line adoption, which needs an event-driven device layer first). Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 0cd6e267c9
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| if err := m.cpu.Reset(); err != nil { | ||
| return err | ||
| } | ||
| m.installFastMemory() |
There was a problem hiding this comment.
NewMachineWithCartridge returns a runnable CPU after cpu.NewCPU, and existing boot paths invoke StepFrame directly without calling Machine.Reset (for example, TestMachineTwoMegRAMBootsBundledROMToActiveScreenBase). Because SetFastMemory is reached only through this reset path, fastRegions remains empty for those normal launches and every ROM fetch continues through the bus; the advertised boot-speed improvement is therefore limited to callers that explicitly reset. Install the regions once the Machine is assembled, or before its first execution.
Useful? React with 👍 / 👎.
1 participant
No description provided.