The old MacMAME runs Pacman full speed with sound on the Power Macintosh 6100/60 driver now. Check it out!

Yeah, I’m gonna keep going with the Terminator 2 quotes. MAME now has an AI policy for contributors. It’s basically what I said in my previous post, but stated more formally. But you’re not here for that, you’re here to hear more about the Power Macintosh emulation, so let’s get started.

First up, since the last burst of activity on the pmac6100, the boot chime has played perfectly but sound in Mac OS was scratchy. I assumed for a long time it was due to PowerPC math issues when emulating the software mixer in Mac OS, but nothing improved with the mass of improvements to the PowerPC core. After accepting that my initial theory was wrong I aimed Claude at the audio output emulation, not expecting much. It came back and told me I was misreporting which half of the audio double buffer was currently active, causing newly mixed data to be written to the buffer half currently being played rather than the other half. I fixed that and got perfect clear sound.

Secondly, no version of Mac OS beyond 7.5.5 would boot. They’d act like there was no enabler for the machine. I dug into that with Claude assisting and found that the reason was a bit weird: the ROM for the 6100/7100/8100 sets the machine type by a combination of the system ID register and the measured CPU clock speed (!) It was measuring using the PowerPC’s ‘decrementer’, basically a free-running timer that can optionally generate interrupts. The problem? The PowerPC 601’s decrementer didn’t work like it does on other PowerPC chips. It measures nanoseconds rather than clock cycles. Implementing it to start counting immediately got the measured clocks in place and the ROM dutifully set the machine ID to “Power Macintosh 6100/60”, which is exactly what we wanted.

With the machine type correct, System 7.1.2P showed the proper machine type in the Finder’s About box. Systems 7.6 and 8.0 booted, and the 8.5 install CD would boot to Finder but randomly bomb out early in the install process. And 8.1 would boot to Finder but freeze right as the desktop appeared. A bit of tracing revealed all of these symptoms were due to memory at the very top of RAM getting corrupted. I eventually realized that was due to the RAM mapping not being exactly right (I was mirroring the wrong banks to the wrong places). I fixed that, with some help from a commented disassembly I made of the boot ROM’s memory sizing code, and all of those problems went away. 8.1 now runs perfectly (and much faster than on 68K machines) and with a small fix to the serial DMA register so the AppleTalk check doesn’t hang 8.5 and 8.6 also boot to Finder and run normally.

The final frontier is Mac OS 9, the last version before the whole code base was famously given a funeral by Steve Jobs. It boots to the initial “Mac OS 9” splash and then gets hung up trying to talk to a device that doesn’t exist, apparently SCSI of some kind. Stay tuned…

One 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.

(NOTE: this post will get very technical. Some knowledge of 16-bit x86 assembly will help).

From the MPC60 code that computes the duration of a note in timer ticks:

seg000:5659 sub dx, dx
seg000:565B mov cx, 0Ah
seg000:565E div cx
seg000:5660 jnz short loc_5665
seg000:5662 mov ax, 1
seg000:5665
seg000:5665 loc_5665:
seg000:5665 mov bx, ax

This was falling through the JNZ and giving a result of 1 every time, which doesn’t sound very good (the timer rate was around 290 Hz in this case, but it seems to depend on the current sequencer tempo). What influences the JNZ? It’s like this:

1) SUB DX, DX zeros out DX and sets the zero flag
2) MOV CX, 0Ah loads CX and doesn’t affect any flags
3) DIV CX does a division and is documented by Intel to have undefined effects on the zero flag. MAME i86.cpp expresses this as doing nothing to the flag, but we could also validly have set it to a random value according to that documentation.

So the zero flag was always set, and the JNZ always fell through, turning every sample into a short click.

It turns out that in the 80s it was known by some that the zero flag was set according to the quotient, so it’s cleared if the quotient isn’t 0. Roger Linn was apparently one of the people who knew, because it’s used multiple places in the MPC60 firmware.

But now that Ken Shirriff has dumped the 8086 and 8088 microcode, and you can run the microcode in order to run 8088 MPH and Area 5150 cycle-perfect in the XTCE-Blue emulator, we know that it’s not quite that way. Internally, the 8086 and 8088 use, essentially, long division with a series of subtracts. As a side effect of this, in most cases the zero flag is set as you’d expect with respect to the quotient of the DIV or IDIV instruction: set if the quotient is zero, cleared if not.

So what’s meant to happen is that you get a non-zero quotient (because you always will given constraints on the inputs here), the zero flag is cleared, the JNZ is taken, and everything works fine, plus or minus.