Fresh off of our last post about recent improvements to MAME’s Laser 128 series emulation and the addition of the Franklin Ace 500, the Franklin Ace 2200 has now been added. The 500 was an Apple IIc clone, while the Ace 2200 is a IIe clone. But much as the 500 doesn’t internally work the same way as a IIc, the 2200 has some important internal differences from the IIe. This includes two added soft switches which allow an 8K ROM to be banked into memory at $A000, which is not bankable on any real Apple II.

There’s also a built-in parallel port and a built-in floppy controller and drives. The Ace 2200 has 2 drives, there was also a 2100 with 1 drive and an Ace 2000 with no drives. We emulate the 2200 because maxing out the drives costs us nothing in emulation-land. If someone perversely wants to change the 2200 to a 2100 or even a 2000, that’s doable though.

Here’s a brief video where we boot up ProDOS 8 2.4.1 and CATALOG its contents to MAME’s emulated Epson ActionPrinter 2000. Other Apple II emulators have printer simulations; because this is MAME the ActionPrinter 2000 is running the printer’s original firmware and emulating the stepper motors, position sensors, and the dot matrix printhead itself to give a bug-for-bug reproduction of the original printer. Similarly detailed emulations of the Apple Silentype, ImageWriter, and LaserWriter printers are in the works and hopefully will appear in 2022.

Let’s chat about some new Apple progress! As the title suggests, the machines I’m going to discuss are not quite Apples. First up is the Laser 128 series. Earlier this year the Laser 128 got a bunch of supported BIOS revisions, its correct video ROM, and support for its built-in mouse port. Plus the original revision of the hardware was supported to allow the oldest known BIOS revisions to run correctly.

Great! Except this led to a regression – by default the 128 was using the incorrect character set from the font ROM (international rather than US English). This caused characters like the familiar AppleSoft ] prompt to show as the wrong thing. Also, the Laser 128EX and 128EX/2 models didn’t get the new character ROM at all – no Laser triangle logos in MouseText! Both of these things have been fixed for the upcoming MAME release, 0.239.

Beyond that, the Laser 128 had a unique feature – a switch selected if slot 1 was a serial port or a parallel port. MAME didn’t previously support that switch at all, you were stuck with serial printers while MAME currently only emulates a parallel printer (the Epson ActionPrinter 2000, which is back compatible with the old FX-80/MX-80). Added for 0.239: all Laser 128 models (including EX and EX/2) now have a switch in the Machine Configuration options to flip slot 1 to parallel, and it works.

While I was at it, I found a ROM dump for the Franklin Ace 500, which like the Laser 128 is an Apple IIc clone, and like the Laser 128 it has its own unique twists on the hardware that made it not just a drop-in-and-run proposition. There was some very non-standard banking on the ROM, and a few other undocumented twists. (Apparently a technical manual for this machine existed, but only the user’s manual has been scanned, which is unfortunate). The machine is still marked as “not working” for an important reason: ProDOS-based and custom-boot software works great, but standard DOS 3.3 System Masters will crash during booting. On the plus side, the Franklin’s internal mouse interface is fully supported. And unlike the Laser, slot 1 is fixed to a parallel printer. But MAME supports that too, so it’ll be there when the remaining gremlins are worked out.

On the non-clone non-Apple II front, the progress from earlier this year where we started supporting CD-ROMs on the 68K Macintoshes had a problem: only some versions of MacOS would recognize the discs. This was traced down to our not properly emulating a “genuine Apple” drive. Some versions of MacOS would only recognize certain models of CD-ROM drives and they had to support an undocumented extra SCSI command to return the string “APPLE COMPUTER, INC.”. It ignored drives that didn’t pass the whitelist or support the undocumented command. We’ve now fixed that 100% so MacOS thinks we’re an original Apple CDSC drive, just one that returns data a lot faster.

We’ve had lots of movement so far in 2021 on the 80s/90s Macintosh drivers, so let’s talk about it a bit. Things started off with my splitting the large, ugly, unwieldy mac.cpp driver into several new drivers. The “classic” black and white 68000 Macs went to mac128.cpp, the Portable and PowerBook 100 went to macprtb.cpp, the 68030 PowerBooks went to macpwrbk030.cpp, the Quadra 700 went to macquadra700.cpp, and the PowerMac 6100 went to macpdm.cpp. (PDM is “PiltDown Man”, the codename of the 6100; early PowerMacs were named for famous scientific hoaxes).

All of these drivers got cleanup and modernization along the way. The Portable and PowerBook 1xx series got improved video emulation and we now emulate their Power Management Units (PMUs) by running their original Apple code. The PMUs are microcontrollers that handle power management and control and also Apple Desktop Bus interfacing. The PMUs on these machines were Mitsubishi M50753 microcontrollers, and the emulation for that chip was improved by AJR and myself to make this possible. There is also partial ADB (Apple Desktop Bus; a USB-like way of connecting the keyboard/mouse) support working now on the Portable and PowerBook 100.

As part of that work, we needed to slow the ADB simulation down to match the speed of real hardware, and Olivier Galibert came up with a more accurate way to emulate the wait states incurred by the Mac’s main CPU when it was accessing certain chips in the system. This exposed an issue with our 68HC05EG emulation where it was using the wrong cycle counts; fixing that brought the emulated ADB bit cells into spec.

The next big step was brand new emulation by Olivier Galibert of the 4 major Apple floppy disk controllers, the IWM (Integrated Woz Machine, so-named because it was Steve Wozniak’s original disk controller on a single chip), SWIM (Sander/Wozniak Integrated Machine), SWIM2, and SWIM3. Emulating these enabled support for reading copy-protected images (also on the Apple IIgs) as well as 1.44MB high-density floppies. True to hardware, our SWIM and SuperDrive emulation supports 400K, 800K, and 1.44MB floppies interchangeably, and you can read/write 800K disks on the 1.44MB drive. We also have a feature for the Apple IIgs where when you create a new floppy image in MAME’s file manager menu, it now gives you the option of having it be pre-formatted for the ProDOS file system, which saves time formatting the disk in the emulation. We’re hoping to extend to the Mac’s MFS and HFS disk formats in the future.

After that, I worked with Patrick Mackinley to get the Mac Plus working with our new bit-level SCSI emulation and cycle-accurate NCR5380 SCSI controller chip. This allowed the Mac Plus to use our latest, most accurate SCSI emulation, but due to some problems that were thought to be insurmountable, later Macs weren’t allowed in. Olivier Galibert noticed that in fact the hardware wasn’t being quite as devious as we had thought, and AJR came up with a scheme which allowed all of the emulated Macs to use the newer and more accurate SCSI subsystem. This opened up the possibility of finally supporting CD-ROM drives on the Mac, but early attempts didn’t work. Al Kossow provided some SCSI bus snooping logs of a real Mac booting from a CD-ROM and I was able to modify our SCSI CD-ROM to comply with Apple’s specifications. As a result, most of our Macs now can both read and boot from CD-ROMs (this will be in MAME 0.232).

To match the added capabilities of the Mac drivers, the documentation has been greatly expanded in the form of a system-specific wiki page, similar to the one for the Apple II series. The page is still a work-in-progress but it hopefully already provides useful information.

A graphical install guide which shows how to format a new hard disk image and install the Mac OS in the driver is available. Note that the instructions WILL NOT work with the current release of MAME; you need either a build of an up-to-date GitHub pull or to wait for MAME 0.232.

UPDATE: MAME as of version 0.231 supports 3.5″ .WOZ images and can boot the original copy-protected Alien Mind, so this modified crack has been superseded. qkumba also made his own modified crack which is more compatible with various modern Apple II mass-storage solutions. The rest of this post remains for historical reference.

One of the major exclusive games for the Apple IIgs was Alien Mind, by programmer Robin Kar and artist Matt Crysdale. The game originally came on 2 protected 3.5″ disks using a non-standard format which fit 920K on a disk (Apple’s standard format fit 800K). There’s a common crack by a French group called the F.U.C.K. on 3 normally formatted disks which uses the standard SmartPort firmware interface to the 3.5″ drive. In theory, this should be able to work with a lot of mass storage devices for the IIgs, most of which implemented at least some version of the SmartPort API in their on-card firmware.

In practice, this didn’t work out so well, so someone who goes by ballmerpeak decided to fix some issues with the crack. First up, they made it work on ROM 03 machines, but it was still only the first disk and hardcoded slot 5. In part 2 they concatenated the 3 disks of the crack plus a 4th save game disk into a single .2MG image and made it all work that way. Unfortunately, that version doesn’t boot on any of the 3 available emulated mass storage cards in MAME that should otherwise work. The CFFA2 and CMS SCSI II Card (with the 3-1-1990 ROM revision) support SmartPort as originally defined, with 16-bit buffer and block addresses. The IIgs introduced an extension called “extended SmartPort” which made the buffer and block addresses both 32 bits if the command number has bit 6 set. And the F.U.C.K. crack as modified by ballmerpeak relies heavily on extended SmartPort, so those two cards are out without extensive patching.

However, MAME also supports the Apple Rev C. SCSI Card, which does support extended SmartPort. So it should work, right? Nope, trying to boot it there results in loading for a second and then the tell-tale Monitor beep of a BRK crash. (Alien Mind has set the text and background colors both to black at this point, so you can’t actually see what’s going on). Investigation with the MAME debugger showed that the SCSI Card firmware was actually doing the crashing, and it’s because Alien Mind was making SmartPort calls with the 65816 direct page register set to $AF00, when the card firmware assumed it would be at the classic 6502-compatible location of $0000. Fortunately, ballmerpeak included their disassembly of the boot loader and “DOS” code. I noticed some nice empty space at $B1C6 where a patch could go, and used MAME’s debugger to patch the code in RAM before it executed accordingly. That was successful!

The patch looks like this:
$B2D0 became JMP $B1C6. At $B1C6 we did SEC / XCE / PHY / PHX, imitating the original code at $B2D0. Next the patch did PHD / PEA $0000 / PLD (which saves the existing direct page and sets it to the $0000 the SCSI Card firmware is looking for) and then JMP $B2D5 to resume the code at the actual SmartPort call. (We couldn’t easily relocate the call itself because it’s patched by several places in the code). At $B2DD there was a BCS instruction checking for errors in the SmartPort call; we needed that space and since we’re targeting emulators primarily we can safely assume the reads will never fail. So at $B2DD we changed it to PLD / NOP to restore the original direct page, and the NOP simply takes out what was the second byte of the BCS.

Unfortunately, all of this code is compressed on disk, so we couldn’t easily modify it there. Fortunately, there’s lots of space in the initial boot loader after ballmerpeak disabled the F.U.C.K.’s original crack screen. There’s a routine at $0A3C that originally waited for a key or mouse press in the crack screen; we repurposed it to patch the freshly decompressed code with the patch above. We changed $091B to jump to our new patch code at $0A3C immediately after decompressing the next stage instead of actually running the decompressed code. The patch at $0A3C consists of JSR $0962 / LDX #$000c / $0A42: LDA $0A60,X / STA $22A2,X / DEX / DEX / BPL $0A42 / LDA #$EA2B / STA $23B9 / LDA #$C64C / STA $23AC / LDA #$B1B1 / STA $21AE / BRA $0AB0. The loop creates the main body of the patch at $B1C6, and the 3 LDA/STA pairs insert the JMP at $B2D0 and change the BCS to the PLD / NOP sequence.

With all of this fun out of the way, the game works fine on MAME with the Rev. C SCSI Card emulation:

And here is the patched .2MG image, renamed “alienmind2016b” from “alienmind2016a”, because I was too lazy to edit the title screen like ballmerpeak did. Sometime I might try and figure out why the SCSI Card’s firmware is failing and see if it can be fixed, but this works for now.