Arbee's WIP Emporium

MAMEception

2026-07-03T18:46:00-04:00

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

Machines may calculate, but only humans can dream

2026-06-23T11:31:00-04:00

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…

I need your clothes, your boots, and your motorcycle

2026-06-16T12:53:00-04:00

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.

What’s a little undocumented behavior between friends?

2026-05-09T15:51:00-04:00

(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:

SUB DX, DX zeros out DX and sets the zero flag
MOV CX, 0Ah loads CX and doesn’t affect any flags
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.

Dropping the ball on 2025, my MAME year-in-review

2026-01-01T09:46:00-05:00

I just realized I haven’t posted in almost a year, and yet things have been happening. Let’s talk about them!

Late last year, right around Christmas, I got a message from classic Mac hacker Doug Brown about some issues with the Cuda, a 68HC05 microcontroller that appeared in a whole bunch of Macs from around 1993 to 1998. In particular, he wanted the debug key sequence (Command-Power) to work and drop into a debugger like it does on hardware, and he pointed out that improper hookup of the Power key was causing misbehavior in some versions of the Mac OS when you pressed certain modifier keys (Shift, Option, Command, etc). Because Doug’s both a scholar and a gentleman, he came armed with a suggested patch, which was adapted and applied.

While doing a regression test on every system with a Cuda that we have a MAME driver for, I ran into my ongoing nemesis, the Power Macintosh 6100 (aka “PDM” or “Piltdown Man”; the initial PowerPC machines were named for famous scientific hoaxes). At that time, the machine had a working keyboard and mouse and preliminary audio and floppy DMA support. This all netted us the ability to boot the System 7.6 install floppy and make it all the way into the installer. But no further. Any attempt to boot a fully installed System would fail with a not-very-helpful error message. So after buckling in and staring at way too many instruction traces, I discovered the error was the result of IBM POWER instructions attempting to be executed. For the uninitiated, the PowerPC chip was derived from IBM’s POWER processor, but had an instruction set that was similar but not compatible. But the first PowerPC chip, the 601, included some of the old POWER instructions alongside the new PowerPC instructions, and in spite of copious warnings to third party developers it turns out Apple used those instructions themselves.

MAME’s PowerPC support was mostly “pure”; it did not include the carry-over POWER instructions and so they were causing an illegal instruction fault. Implementing those instructions caused System 7.1.2 to boot properly all the way to the Finder. I continued on improving various rough or preliminary aspects of the rest of the machine emulation and the machine was somewhat usable. You could even play some Marathon. And that’s pretty much where things left off, likely due to errors in the emulation of the PowerPC instruction set itself. I’m looking to finally tackle that in 2026, which should also improve things for the Sega Model 3 games. No promises on when that happens or how good the improvements will be though.

In 2024 there had been several breakthroughs in the emulation of the Macintosh PowerBooks with 68030 processors (the 140, 160, 165, 170, and 180). The next step to complete the set of 68030-based portables, the PowerBook Duos, beckoned. But they were based around a heavily customized 68HC05 microcontroller called “PG&E”. You can get some idea how loaded with functionality this chip is from my extensive comments at the top of the implementation, but it handles powering the system up and down, power saving modes, sleep/wake, the keyboard, the trackpad, the screen backlight brightness, and a number of other functions. Emulating that chip, as well as the GSC (Gray Scale Controller, a Chips & Technologies 65210) and CSC (Color Screen Controller, a Chips & Technologies 65220) video chips and the MSC system controller chip resulted in all of the 68030 and 68040 based PowerBook Duos graduating to fully working.

While the PowerBook Duo emulation was happening, I got another ping from Doug Brown. He’d noticed that the Mac Classic II emulation in MAME worked normally with Mac OS set to 24 bit mode (which limits it to 8 megs of RAM but was more compatible with loosely-written early Mac software). But setting it to 32 bit mode to get the full benefit of the system’s up to 10 megs of RAM resulted in a “Sad Mac” error icon once the OS started loading. Doug’s full writeup on what happened next is well worth the read, but I’ll summarize by saying that due to a bug in the ROM for the Classic II, it was accidentally executing an invalid 68030 instruction when it attempted to deal with sound interrupts. Invalid instructions are supposed to cause an illegal instruction fault but this particular one doesn’t for whatever reason and we were 35 years too late to report the error to Motorola. Anyway, the exact behavior of the illegal instruction on a real chip isn’t fully understood (even now) so MAME now patches a few instructions in the Classic II’s ROM, which permits the machine to operate normally.

In the meantime I emulated and hooked up a custom Taito volume control chip for the arcade game Operation Wolf, and continued on to the next big thing for the PowerBook Duo line. The Duo machines were smaller than normal laptops but could be inserted into a docking station in a manner similar to a cartridge in a game console. When so docked, the Duos gained the ability to connect to a keyboard, mouse, and monitor, additional SCSI support, additional serial ports, and even NuBus expansion slots. There were also third party docks that added a single function, like an Ethernet interface, and which attached in a manner more familiar to today’s Thunderbolt docks.

While the dock slot support was cooking, I took time out to take a pass over the existing emulated NuBus cards, which fixed a lot of small issues and improved accuracy (and in a few cases performance). Additionally, Olivier Galibert’s rewrite of MAME’s central audio support had gone in. Instead of being stereo-only and output-only, MAME now supported an arbitrary number of input and output channels across an arbitrary number of devices. Fully supporting this on modern macOS hosts required extensive modifications to MAME’s code that made use of Apple’s CoreAudio API, and we eventually got there. Additionally, I did some widespread cleanup work across various Macs and their video cards so that everything was using proper RAMDAC devices. In general this caused no real change, but it further improved the code and made it more maintainable. For a project on the scale of MAME, that’s always a good thing!

In the spring, a patch to MAME’s support for the DP83932 “SONIC” Ethernet chip came in from Brice Onken, one of the contributors who’s into old workstation support. (In his case, the Sony NEWS Unix systems that were in some ways predecessors of the PlayStation). Anyway, his change to make the machines he was interested work also fixed issues that I had seen with the Mac OS driver for the chip, which is built in to many Quadra models and was used on NuBus and PDS-slot cards for many other Macs. So working built-in Ethernet for many Mac Quadra models happened in April’s 0.277 release, and SONIC-based cards happened 2 months later in 0.278. (May’s MAME release was skipped to give more time to address issues caused by the new audio system I mentioned earlier).

Also landing in 0.278 was the PowerBook Duo dock slot support. Docks supported included Apple’s fully featured Duo Dock, Apple’s tiny Floppy Dock (which added a floppy drive to the Duos), and the Newer Technology Ethernet Microdock (which adds an Ethernet interface). The ROM for the full-size dock came from the perpetually amazing Al Kossow, who runs bitsavers.org and works for the Computer History Museum, and the ROM for the Ethernet Microdock came from Doug Brown. 0.278 also got a fix for a long-standing bug with the 6502 I/O coprocessor emulation in the Macintosh IIfx, Quadra 900, and Quadra 950 that prevented System 7.5 and later from booting properly.

In July’s 0.279 there were a number of improvements for the PowerBook Duos, including smoother keyboard and mouse support and the ability to press any key to wake the emulated machine from sleep. The Apple IIGS also got a stereo channel fix, support for the 4-channel “4soniq” card, and a fix to the ADB implementation that improved mouse tracking smoothness and fixed hangs in games like Xenocide and Chessmaster 2100. Long-standing issues with the real-time clock chips used in the IIGS and various Macs were finally fixed for real, and various fixes to the PowerBook 100 series went in that fixed the one-second interrupt used by the Alarm desk accessory among other things. The IIGS additionally got a fix in the Ensoniq ES5503 emulation that solved an issue with Commodore legend Rob Hubbard’s music in EA’s Skate or Die!. Hey, it’s 30 years later, all of us 6502 fans can get along now!

August’s 0.280 was quieter, involving a few random Apple IIe fixes, some accuracy improvements for the Mac 128, 512, and Plus from Lord Nightmare, and hooking up the correct video RAMDAC on the Mac IIci and IIsi.

In September, the next adventure began. 0.280 had marked the Hyper Neo Geo 64 arcade games as working since they were completable. But there was a major issue with them still: the sound emulation was essentially missing. The games used an unusual sound system: an NEC V53 8086-based system on a chip driving a custom 32-voice sample player labeled as “L7A1045 L6028 DSP-A”. Where did they find that? From a bunch of professional drum machines and samplers made by Akai in cooperation with Roger Linn. Linn designed the LinnDrum and LM-1 drum machines in the early 1980s, and those machines appeared on hits by Prince, Billy Idol, Tears for Fears, and many more artists.

Waaaay back when the HNG64 was first emulated I’d taken some preliminary stabs at the sound chip, which is fairly unusual, but didn’t make much headway. Since that time, MAME developer Happy had done an in-depth reverse-engineering of the V53 sound driver code and what he felt that meant in terms of the chip’s registers. I spent a few days experimenting based on that information and the sound went from occasional blasts of loud static to recognizable music, although there was still far to go. Work on that continued into October’s 0.282, at which point it was in very good shape.

November and December went mostly to work on the actual Akai machines that originated the sound system. Work continues on those as of this writing.

And to bring things full circle, right before Christmas of 2025 I got a ping from Doug Brown regarding a long-standing issue in MAME with Macintosh models losing sound interrupts and the emulated machine freezing or having sound stop in the middle of a game. But more on that when there are finalized results.