GoKawiilOne of the reasons little progress was made on the Power Macintosh emulation in MAME for a long time is that it’s very tedious to debug. There’s a lot of code surface, it’s written in 3 languages (PowerPC, emulated 680×0, and compiled FORTH), and I’m not as familiar with the innards of the newer stuff like the Code Fragment Manager as I am with the behavior of the 680×0 codebase. So, this being 2026, I asked Claude Code if it could control and debug MAME. It came back with “yes, with limitations” and after a few tries settled in to using a combination of generating custom Lua boot scripts and modifying MAME to log what’s happening to a file.
So I pointed it at the Pippin and said “That doesn’t boot and it makes me sad”. (Not really. The actual prompt was not about my feelings, but rather informed by my previous attempts to debug it myself). In pretty short order it found that communication with the Cuda 68HC05 was failing due to a glitch in MAME’s 6522 VIA emulation. Fixing that got us not much farther, but after about a week it had found half a dozen things wrong with MAME’s PowerPC emulation and several other things wrong with MAME’s support for PCI-era Macintosh hardware. So the Pippin now played its (kinda creepy) startup sound and showed the initial “P!P P!N” box logo, plus you could move the mouse pointer around the screen like it was a not-very-secret Macintosh or something. Vas noticed an anti-pattern in the PowerPC DRC where values from when the code was generated and cached were used during execution instead of the actual live machine state (something that’s surprisingly easy to slip into doing when writing a DRC). I can’t point to anything specific that fixed, but it’s 100% a correctness improvement and likely will be silently helpful down the line.
Moving along from that, I wanted to add support for an actual PowerMac with hardware close to the Pippin to track the broader outcome of debugging it. The Power Macintosh 7200 fit that bill nicely (and it uses a variant of the familiar DAFB video used in the Quadras). At first it seemed to be going well, thanks to all of the fixes for the Pippin – it chimed and made it into the startup disk polling routine. But it wasn’t ever initializing the on-board video. I told Claude that’s what was now making me sad and it came up with two bugs in the PowerPC 601 emulation. With those resolved, the main screen now turns on and shows the familiar 3.5″ floppy of the boot search routine. However, the flashing ? that indicates a disk wasn’t found wasn’t working. Still great progress though, and I put it aside.
The next thing the machine got to hear about that was making me sad was that the Power Macintosh 6100 froze when trying to boot any System version newer than 7.5.0. Claude pretty quickly figured out that the difference was a native PowerPC SCSI Manager vs. the emulated 680×0 code in previous System versions, and traced its failure to MAME improperly emulating the PowerPC’s atomic load/store instructions. These are frequently used by interrupt handlers to guarantee safe operation even if another device in the system, such as a second CPU or a DMA controller, has touched memory and told the processor about it. We had a pull request from Sega Model 2 MVP gm-matthew addressing that because it was also breaking some things about the Sega Model 3 arcade games, but it had gotten tied up in review. I grabbed the changes and applied them, and System 7.5.3 and 7.5.5 booted straight to Finder and ran happily (and more efficiently, thanks to the native PowerPC SCSI driver). While regression-testing the changes I found that the same fix also caused the Pippin to advance into its animation showing that you need to insert a CD, and the PowerMac 7200 gained the missing flashing ?. Not bad!
After that, I was sad that the famous Graphing Calculator that shipped with the Power Macs to show some of the increased math power of the new CPUs didn’t work in MAME. Claude quickly pointed out that none of the FPU opcodes updated the status flags, which are not often used in highly optimized arcade games like MAME’s PowerPC core was originally written to support. But they’re very important to computer operating systems and specifically to Apple’s SANE floating point library. I have an in-progress fix there that allows the Graphing Calculator to run the 2D portion of it’s self-demo correctly now, but the 3D part of the demo isn’t working. So some sadness has been ameliorated and as I type this more is being worked on. (UPDATE: 3D works now. Alignment exceptions on the 601 weren’t working properly, something I would’ve expected to have a larger impact than I can prove it has thus far).
Also, AI is quite good at taking the firmware binary for some kind of well-defined device, from a computer keyboard or mouse up to a digital synthesizer, and give you excellent starting guesses about the memory map and where the major subroutines live and what they do. (Tip: tell it the functions of the device and where it can find a copy of MAME’s unidasm disassembler. It can do without, but you’ll get to usable output much faster if you do). GPT 5.5 Pro (via Codex) has been especially good at this for me, but Claude’s no slouch either. Once it’s got a solid preliminary understanding you can write prompts like “Tracing the data flow from a MIDI Note On message, what are the likely functions for each register in the custom sound chip?” and get useful, actionable answers.
A few caveats here, lest this come off as a full endorsement of AI. First off, all of this was accomplished with an experienced emulation programmer (me) supervising the AI and interrupting it to say “hey, stop that!” on the not-infrequent occasions where it was chasing some theoretical problem that was possible but that I believed wasn’t likely. Spoiler alert: I was almost always right. The AI is helpful in many ways, and can randomly pop out with amazing things like “oh, this data structure at 0x123456 is a QuickDraw GrafPort” and be correct, but when it has to actually draw conclusions or make a judgement from the data it can get off track quickly.
Secondly, the AI found the bugs but the fixes for them were written by me except in a few cases of trivial one-liners (and even then I edited them to fit my personal stylistic and naming preferences). MAME does not yet have a formal AI policy, but we don’t want to see “vibe code” submitted (and if you let the AI write your pull request description you will definitely annoy me, never mind some of the more AI skeptical members of the team). You are free to let the AI go wild reverse-engineering and debugging all you want, but at the end of the day MAME needs code that the people submitting it understand and can maintain.