The brand-new MAME 0.253 has plenty of Apple related work in it! Starting with some bugfixes: monochrome double-hi-res wasn’t displaying correctly for the IIe RGB Monitor mode and all IIgs configurations. That’s been fixed. Crashes and hangs with the IIgs games GBA Basketball, Paperboy, and Zany Golf have been fixed, thanks to everyone’s favorite code golfer, qkumba. Ensoniq ES5503 sound on the IIgs (and the Ensoniq ESQ-1 and SQ-80, because we emulate those too!) is even more accurate.

In Mac land, it was The Final Cleanup. For those unfamiliar, when I originally got a bunch of Macs working circa 2011-2013, I jammed them all into the existing Mac driver (mac.cpp) regardless of if they had much in common other than being Macintoshes. This led to a giant unmaintainable blob and so a year or so ago I started splitting it up and emulating the shared major ASICs as separate devices (in MAME, a device is a C++ class with some minor extra powers granted by the core – they’re the key to our current modularity and ability to have freely configurable slots, among other things).

Anyhow, after the 0.252 release, mac.cpp had been cut down to contain the Mac II series (minus the IIvx and IIvi, which already moved to their own driver and the “VASP” ASIC device which powers them). Next on the chopping block was the IIfx, aka “Wicked Fast”. It had recently gotten some work done on hooking up its dual 65C02 coprocessors by contributor AJR so it showed the flashing question mark disk, but still has a ways to go. Now, in its own driver, it can more easily get some love. Last out of the blob were the IIci and IIsi, which are near-twins based on the “MDU” and “RBV” pair of ASICs. (That’s “Memory Decode Unit” and “RAM Based Video” if you don’t speak Apple). MDU doesn’t have CPU-accessible registers so there wasn’t a lot of point to making it a device, but RBV was the origin of a pretty long line of Macintosh system ASICs leading all the way into the PowerPC era and it definitely became a device.

For the PCI Macs, the Pippin driver was extensively cleaned up and renamed from macpci.cpp to pippin.cpp, because “macpci.cpp” was a hangover from when I was going to blob the PCI Macs. Fortunately I realized that was a bad idea before it actually happened. Pippin’s specialized PCI bridge chip “Aspen” is now supported as a subclass of the “Bandit” PCI bridge chip used in most pre-G3 PowerMacs, and the “Grand Central” PCI I/O chip is at the correct PCI address now so the system can find it.

Also, I transferred all of the now decade-old Mac technical information from the old MESS blog to MAMEdev.org’s blog. You can access all of that information right here. It’s all been corrected and expanded all the way out to the PowerMac G5s, with the correct chips assigned to some machines that were wrong in the old list. And the list of Apple chips by 3xx-xxxx number is significantly expanded and includes a bunch of Apple II-related chips.

What’s happening now for 0.254? I’m working on creating the “descriptor-based DMA” device that most of the PowerMacs rely on, which hopefully will lead to hearing the boot beep from the PowerMac G3 and the original Bondi blue iMac.

The MAME 0.252 release capped off a wild 2 months for Apple emulation in MAME. I started off switching the Apple IIgs emulation to exclusively use the emulated ADB microcontroller, and eliminated a chunk of old simulation code dating back to MESS in 2005. I then extended MAME’s ADB keyboard emulation to include the extra keys that an Apple Extended Keyboard has, including function keys and Insert/Delete and that kind of thing. Kelvin Sherlock helped there with some keypad key issues as well.

A wild new contributor benrg appeared around that time and started off strong with some great simplification of our 8-bit Apple II video emulation. He followed that up by actually improving MAME’s Apple II high-resolution NTSC artifact emulation to better match real TVs, so for instance the “V” in Ultima V’s title screen now looks smoother, as the creators intended. It’s a relatively subtle difference if you aren’t A/Bing it, but it is a definite improvement. Most recently, he’s also improved the Double Hi-Res emulation code (more in terms of code quality than results) and fixed some bugs in the unique double hi-res modes provided in RGB monitor mode on the Apple IIe. benrg’s work caused project leader Vas Crabb to notice that I hadn’t properly gone to a getter/setter model when I split out the Apple II video to a shared file, so I gave that stuff proper separation. No user-visible effects, but the code is cleaner and easier to understand now.

The focus then shifted back to ADB emulation. With the Apple IIgs now sharing it some long standing issues came to light. Devices were always responding to ADB TALK requests even when they had no new data to offer, and the Service Request mechanism used for devices to tell the host that they had new data wasn’t emulated correctly. I was able to fix those issues without angering any of the ADB microcontroller types we now support (IIgs M50740 & M50741, Mac PIC1654, Mac “Egret” 68HC05, Mac “Cuda” 68HC05, and Mac PowerBook M50753) and in fact with them fixed, using ADB Macs now feels subjectively better, especially when switching between the keyboard and mouse.

I also added support for a jumper that was added to ROM 03 Apple IIgs machines that disabled the Control Panel, primarily intended for school environments. With the ADB microcontroller emulated and running it was easy, and it’s something no other released IIgs emulator does. More IIgs excitement comes in the form of adding preliminary support for the “Mark Twain” prototype. The prototype’s improvements included SIMMs for RAM expansion, a built-in SCSI hard disk and DMA SCSI controller, and a built-in Apple “SuperDrive” 1.44MiB floppy. Emulation of those last two features isn’t working yet, but you can still pop any of our working mass storage cards into the MT emulation to take it for a spin.

There was a bug in our emulation of the Macintosh real-time clock chip, which was also in the IIgs where it wouldn’t tell time on Windows host systems but was fine on macOS and Linux. That was fixed, so the Brutal Deluxe Dragon’s Lair games now work for Windows users.

Finishing off, I piggybacked off of some great work by fellow dev Kale bringing up PCI-based PCs by starting work on some PCI-based Macs. There are now preliminary not-working drivers for the PowerMac G3 (the original beige one) and the Bondi blue iMac (the first iMac).

And there’s more to come in 0.253, including fixes for regressions in the IIgs games Zany Golf, GBA Basketball, and Paperboy and NCR5390-family SCSI improvements that make the Mac Quadra 700 able to boot from a hard disk for the first time.

And if you’re curious about what all happened with MAME in 2022, I highly recommend this excellent video by MAME contributor The Mog Miner. There’s even some Apple II and Mac content.

Starting off with the 8-bit Apple II, some issues were fixed causing joysticks to misbehave. On IIe-class machines the Zip Chip emulation was fixed so when it’s locked, it stays locked. The Apple IIc Plus switched to the new cycle-accurate IWM and Sony drive emulation, allowing writing to 3.5″ disks to work properly, and enabling the use of both 5.25″ and 3.5″ .WOZ images. (Formatting disks on that machine still has issues, but it’s possible to create pre-formatted ProDOS images in MAME’s file manager so that’s not as big of a deal as it used to be). A bug with the IIc Plus’ VBL registers was fixed that prevented Prince of Persia from working properly.

In Apple II clone world, a regression in the China Educational Computers (CECs) was fixed that broke Pinyin input mode on some machines. The Laser 128 and Franklin ACE machines were next to get the new cycle-accurate IWM and disk drives, and they can boot .WOZ images now too. Finally, preliminary support for the function keys on the Franklin ACE 500 and 2000 machines was added. It’s not 100% but the basics are there.

The would-be successor to the Apple II, the Apple ///, got a major fix with floppy handling, so it’s safe to write to floppy images in the emulation again.

Moving on to the 16-bit Apple IIgs, we started off adjusting our approximation of the machine’s infamous “slow cycles” when accessing certain parts of the system for better compatibility, issues with writing to 3.5″ disks were solved, some corner-case behavior used by the IIgs AOL client was fixed, some even more corner-case behavior involving how banks $E0 and $E1 respond to certain soft switches was fixed, and the IIgs’ clock/BRAM emulation was changed to interface to the device we wrote for the Mac emulation, as the IIgs shares that chip with the Mac. This fixed a few bugs and the IIgs gained some features of the chip it had been missing, including the write-protection setting.

And happening right at the end of the year and just missing the cutoff for this year’s last release, the IIgs got in on the ADB revolution happening on the Mac drivers that I’ll talk about shortly. All current IIgs emulators, including MAME, KEGS, and GSPlus/GSPort, have handled keyboard and mouse input by basically jamming it into the system and inexactly simulating some of the behavior of the Mitsubishi microcontroller (a 6502 derivative) that lives in the real IIgs. Starting with our January release (0.252), the IIgs in MAME runs the real code that lives on that microcontroller and interfaces it to our ADB keyboard and mouse emulation. As a result, everything input-related now works exactly like it does on a real IIgs. Hacks that were necessary to make things like the FTA Nucleus demo work properly before are gone, and games like Wolfenstein 3D that reprogram the microcontroller for special handling will just work.

For Apple II expansion cards, the IIe Standard 80 Column Card got correct emulation (there were some nuances to how it worked that were wrong), and we got preliminary support for the Apple 3.5″ Disk Controller Card (aka the SuperDrive card). It doesn’t work 100%, but it works for booting 3.5″ disks on the Apple IIe, which wasn’t possible until now.

In Mac world, lots of things happened. First up, the Mac LC III and LC 520 were split out of the huge mass that mac.cpp had grown into over the years, and built around a new properly device-ified emulation of the Sonora system ASIC. This makes the driver more lightweight, easier to understand, and easier to maintain going forward. Next up for this treatment were the Mac IIvx and IIvi and their VASP ASIC. And finally came the machines built on the V8 ASIC and its many variants: the Mac LC, LC II, Classic II, and Color Classic. In addition, all Macs got support for booting copy-protected originals via the new .MOOF format supported by the Applesauce imager.

Next up, the aforementioned ADB revolution. The earliest ADB Macs used a GI/Microchip PIC microcontroller as an “ADB Modem” to talk to the ADB port. We’ve had a pretty good simulation of what it does for many years now, but finally one of these chips was decapped and the ROM was extracted. MAME was happy to have that and some of those machines now happily run the real PIC microcontroller ROM to perform those functions. Due to timing issues that we’re working on, not all of the machines that could benefit from this currently do, however. Meanwhile, we’d had good success for a while running Macs that used a 68HC05 program called “Egret” to run ADB and other functions. However, Egret’s 2.0 rewrite, “Cuda”, wasn’t working properly. I figured out what was wrong with it, and that enabled keyboard and mouse input for the Mac LC 520 and Color Classic machines, and it also opens the door to emulating the remaining 68030 machines and starting on the 68040s. (Cuda itself was used in the later 68030 Macs, most 68040 Macs, and all PowerPC Macs through the original iMac).

Many of the emulated NuBus video cards for the Mac were improved this year by Vas Crabb. A variety of cards got cleaner, better emulation and some cards with “virtual desktop” and pan/zoom features including the SuperMac Spectrum series got those features implemented. The Apple cards in particular got full CRTC emulation, allowing them to set the exact correct video modes. Also, the acceleration feature in the SuperMac Spectrum PDQ was finally fully supported, giving faster desktop updates.

In May of 2003, I added a preliminary unplayable driver for Konami’s first-ever 3D game, Polygonet Commanders. It ran a Motorola 68EC020 main CPU with a Motorola 56156 DSP to do the 3D math and a Z80 driving a K054539 sample player. 19 years later, it’s working and running with the polygons. Mog’s new blog can tell you all about it.