So I pointed it at Pippin and said, “It won’t boot and it makes me sad”. (Not really. The actual prompt was not about my feelings, but was informed by my previous attempts to debug it myself). In a very short time it was discovered that communication with the Cuda 68HC05 was failing due to a glitch in MAME’s 6522 VIA emulation. We didn’t get very far on fixing it, but after about a week a half-dozen things were found wrong with the PowerPC emulation of MAME and several other things were wrong with MAME’s support for PCI-era Macintosh hardware. So Pippin now plays his (slightly scary) startup sound and shows the initial “P!PP!N” box logo, plus you can move the mouse pointer around the screen as if it wasn’t some very secret Macintosh or something. Wass observed an anti-pattern in the PowerPC DRC where values from the time the code was generated and cached were used during execution rather than the actual live machine state (something that is surprisingly easy to do when writing a DRC). I can’t point to anything specific that has been fixed, but it is a 100% accuracy improvement and will probably be quietly helpful later on.
Moving on from that, I wanted to add support for a real PowerMac with hardware close to Pippin to track the comprehensive result of debugging. The Power Macintosh 7200 fits that bill nicely (and it uses a version of the familiar DAFB video used in Quadras). At first it seemed to be going fine, thanks to all of Pippin’s fixes – it ran fine and was included in the startup disk polling routine. But it was never starting the on-board video. I told Claude that this was what was bugging me now and it came down to two bugs in the PowerPC 601 emulation. With their solution, the main screen now turns on and shows the familiar 3.5″ floppy of the boot search routine. However, flashing? This indicates that the disk was not found and was not working. Still pretty good progress though, and I put it aside.
The next thing I heard about the machine that saddened me was that the Power Macintosh 6100 froze when attempting to boot any system version newer than 7.5.0. Cloud very quickly discovered that the difference was the original PowerPC SCSI Manager versus the emulated 680×0 code in previous system versions, and traced its failure to improperly emulate the PowerPC’s atomic load/store instructions by MAME. These are often used by interrupt handlers to guarantee safe operation even if another device in the system, such as another CPU or DMA controller, has touched the memory and informed the processor about it. We received a pull request from the Sega Model 2 MVP gm-matthew Addressing this because it was breaking some things about the Sega Model 3 arcade game, but it was tied into the review. I grabbed the changes and applied them, and systems 7.5.3 and 7.5.5 booted straight into 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 caused Pippin to skip ahead in its animation showing that you need to insert a CD, and the PowerMac 7200 got flashing missing. not bad!
Back then, I was saddened that the famous graphing calculator that shipped with the Power Mac to show off some of the increased math power of the new CPU was not working in MAME. Cloud was quick to point out that none of the FPU opcodes updated status flags, which is not often used in highly optimized arcade games like the ones MAME’s PowerPC core was originally written to support. But they are very important to computer operating systems, and especially to Apple’s SANE floating point library. I have a fix in progress that allows the graphing calculator to run the 2D portion of its self-demo now correctly, but the 3D portion of the demo is not working. So some of the sadness has gone away and more work is being done as I type. (UPDATE: 3D works now. Alignment exceptions on 601 were not working properly, something I expected would have an even bigger impact than I can prove so far).
Also, AI is quite good at picking up the firmware binary for any kind of well-defined device, from a computer keyboard or mouse to a digital synthesizer, and giving you excellent early guesses about the memory map and where the key subroutines live and what they do. (Tip: tell it the functions of the device and where it can get a copy of MAME’s Unidsm disassembler. You can do without it, but you’ll get usable output much faster if you do). GPT 5.5 Pro (via Codex) has been particularly good for me in this regard, but the cloud is not far behind. Once you have a solid initial understanding of this you can move on to “Tracing the data flow from a MIDI note on message, what are the possible functions for each register in a custom sound chip?” You can write signs like: And get useful, actionable answers.
There are some caveats here, lest this come across as a blanket endorsement of AI. At first, this was all accomplished with an experienced emulation programmer (me) monitoring the AI and telling it “Hey, stop it!” Was interrupting to say. On occasions where it was pursuing some theoretical problem that was possible, I believed it was unlikely. Spoiler alert: I was almost always right. AI is helpful in many ways, and can randomly come up with amazing things like “Oh, this data structure at 0x123456 is a QuickDraw GraphPort” and be correct, but when it actually has to draw conclusions or make decisions from the data it can quickly get off track.
Secondly, AI found there were bugs but there were solutions written Except for a few trivial one-line cases (and even then I edited them to suit my personal stylistic and naming preferences). MAME doesn’t have a formal AI policy yet, but we don’t want to see “vibe code” submitted (and if you let an AI write your pull request description you’ll definitely annoy me, never mind some of the more AI skeptical members of the team). You’re free to do reverse-engineering and debugging of the AI all you want, but at the end of the day MAME requires code that the people submitting it can understand and maintain.
<a href