In my last post about hard drives that go bad over time, I hinted at having rescued a lost piece of obscure Apple software history from an old 160 MB Conner hard drive that had its head stuck in the parked position. This post is going to be all about it. It’s the tale of a tad bit of an obsession, what felt like a hopeless search, and how persistence eventually paid off. There’s still an unsolved mystery too, so I’m hoping others will see this and help to fill in the blanks!
This whole saga starts with a very interesting blog post written by Pierre Dandumont in 2022. Pierre’s (excellent) blog is in French — Google does a good job of translating it for me. He found a quote in a book referring to special functionality bundled with Apple’s Macintosh Performa 550 computer:
The LC 550’s Secret Partition
If Apple’s programmers, in creating the Performa series, were aiming to make idiot-proof computers, they were serious about it. The Performa 550 is an amazing case in point. When you run the included Apple Backup program (see Chapter 15), you get a little surprise that you didn’t count on: a hidden partition on your hard drive!
This invisible chunk of hard drive space contains a miniature, invisible System Folder. Apple’s internal memo explains it this way:
“When a system problem (one that prevents the Performa from booting) is detected, a [dialog box] informs the user of a system problem. The user can choose to fix the problem manually or to reinstall software from the backup partition’s Mini System Folder.”
If you choose to reinstall your System software, you get the wristwatch cursor for a moment while the miniature System Folder is silently copied to your main hard-drive partition. The Performa restarts from the restored hard drive, and the invisible system partition disappears once again.
We got a Performa team member to admit that this kind of sneaky save-the-users-from-themselves approach may well be adopted in other Performa models.
Who knows what goodness lurks in the hearts of men?
As part of my work toward an upcoming post about a lost piece of very obscure Mac history that has finally been found, I’ve been playing around with old Apple-branded SCSI hard drives made by Quantum and Conner in the 1990s. What I’m about to describe is already common knowledge in the vintage computing world, but I thought it would be fun to share my take on it anyway.
What I’m talking about is how a lot of these hard drives just refuse to work anymore. This is very common with old Quantum ProDrive models, like the LPS or the ELS. The drive spins up, you don’t hear the expected pattern of click sounds at startup, and then after a few seconds, it spins back down.
This is the story of how Apple made a mistake in the ROM of the Macintosh Classic II that probably should have prevented it from booting, but instead, miraculously, its Motorola MC68030 CPU accidentally prevented a crash and saved the day by executing an undefined instruction.
I’ve been playing around with MAME a lot lately. If you haven’t heard of MAME, it’s an emulator that is known best for its support of many arcade games. It’s so much more than that, though! It is also arguably the most complete emulator of 68000-based Mac models, thanks in large part to Arbee‘s incredible efforts. I will admit that I’ve used MAME to play a game or two of Teenage Mutant Ninja Turtles: Turtles in Time, but my main use for it is Mac emulation.
Here’s how this adventure begins. I had been fixing some issues in MAME with the command + power key combination that invokes the debugger, and decided to see if the keystroke also worked on the Classic II. Even though this Mac model has a physical interrupt button on the side, it also has an “Egret” 68HC05 microcontroller for handling the keyboard and mouse (among other things) that should be able to detect the keypress and signal a non-maskable interrupt to the main CPU. I believe the Egret disables this keystroke by default, but MacsBug contains code that sends the command to enable it.
I didn’t get very far while testing the command+power shortcut in MAME’s emulated Classic II, because I observed something very odd. It booted up totally fine in 24-bit addressing mode, but I could not get it to boot at all if I enabled 32-bit addressing, which I needed in order for MacsBug to load. It would just pop up a Sad Mac, complete with the Chimes of Death. On this machine, the death chime is a few notes from the Twilight Zone theme song.
There have been some past rumblings on the internet about a capacitor being installed backwards in Apple’s Macintosh LC III. The LC III was a “pizza box” Mac model produced from early 1993 to early 1994, mainly targeted at the education market. It also manifested as various consumer Performa models: the 450, 460, 466, and 467. Clearly, Apple never initiated a huge recall of the LC III, so I think there is some skepticism in the community about this whole issue. Let’s look at the situation in more detail and understand the circuit. Did Apple actually make a mistake?
I participated in the discussion thread at the first link over a decade ago, but I never had a machine to look at with my own eyes until now. I recently bought a Performa 450 complete with its original leaky capacitors, and I have several other machines in the same form factor. Let’s check everything out!
Here’s the affected section of the board before I removed the original capacitors. You can see that all three of these caps (C19, C21, and C22) have their negative side pointing upward, matching the PCB silkscreen that has the + sign at the bottom.
In my last post, I figured out how to use Apple’s leaked Flasher utility from the 1990s to reflash a ROM SIMM inside of my Performa 630. It’s basically the Mac equivalent of a BIOS update, but only for Apple’s developers. The research involved in that post was quite a journey of reverse engineering from both a software and hardware perspective. I had to disassemble the code to figure out which computers were compatible and what the software was expecting to find. I also had to create a replica of an Apple development ROM SIMM that was wired exactly the way Macs of the era expected it. Although I was very excited about my discoveries, one big question remained:
What was the purpose of the bottom right half of the main window labeled “PDS ROM Info”? And what would it take to enable it?
After I wrote about the possibility of programmable Mac ROM SIMMs in Quadras a couple of months ago, I suspected that there had been a way for developers at Apple in the 68k Mac era to reflash the ROM in their Macs during development, just like BIOS updates on PCs. The reason I believed this is because the ROM SIMM socket in the Quadras brought out pins for 12V (VPP) and write enable (/WE). I had verified that the write enable pin was going into the memory controller chip in several Mac models, so I was pretty confident that in-system programming was possible.
As luck would have it, multiple people pointed out to me that an Apple internal utility used for ROM flashing had been uploaded to the Macintosh Garden. It was recovered from a prototype PowerBook 520 purchased in 2020. Of course, I had to download this utility and figure out how it works.
I ran it on my LC 475 and this is what it looked like:
TL;DR: The pinout of modern programmable Mac ROM SIMMs needs to be changed for correct operation in Quadras. If you’re interested in how I reached that conclusion, or at least want to see some cool pictures, read on below.
One thing that you usually discover when searching for info about these programmable ROM modules is that they’re compatible with the earliest 68030-based desktop Macs: the SE/30, IIx, IIcx, IIci, IIfx, and IIsi. The most common use of them is to set up a special custom bootable ROM disk using Rob Braun’s driver, Big Mess o’ Wires’ driver based on Rob’s, or Garrett’s Workshop’s driver. In general, the compatible ROM images out there are all using the IIsi ROM which is capable of booting any of the aforementioned Macs.
What you may not know is that most of the later 68k Macs also have provisions for a ROM SIMM socket, but aside from the very first Quadras (700/900/950) which always have the socket installed, it’s not usually populated. Some early production or prototype units have it, but most just have empty through-holes filled with solder where the socket would go.
Don’t worry, I already replaced those leaky capacitors before they had a chance to damage the board.
Several months ago, Will from CayMac Vintage reached out to me looking to resurrect my old Mac ROM SIMM programmer project. As a quick summary of that project, it provides a convenient way to program custom 64-pin ROM SIMM modules for vintage Macs from the late ’80s to early ’90s. There are several reasons you might want to do this, including: replacing an original ROM module that has gone bad, disabling the startup RAM test to decrease boot time in systems with a lot of RAM, bbraun’s amazing bootable ROM disk hack, or my startup chime hack. JDW recently made a cool YouTube video explaining custom ROM SIMMs if you’re curious about them. He even included some footage from 2003 of me playing basketball!
I used to make programmer boards and programmable ROM SIMMs and sell them to hobbyists, but it burnt me out. In particular, assembling the boards and the logistics of shipping were not fun to deal with. Thankfully, in 2016, Steve from Big Mess o’ Wires stepped in to take over. He made his own customizations to the programmer and made some really neat improvements to the bootable ROM disk driver. He still sells the Mac ROM-inator II SIMM to this day, but he stopped selling the programmer board. In the meantime, many other players have entered the market with custom ROM SIMMs, but nobody has been making the programmer available to the community, likely due to my non-commercial license on the PCB design.
Will was looking to fill that void. I helped him get going, but we discovered that the AT90USB646 microcontroller that I originally used was hard to find due to the chip shortage. At the time, it was easier to find the AT90USB1286 instead, which is essentially just the exact same chip, but with 128 KB of flash instead of 64 KB of flash.
I was looking at one of my classic Macs a few weeks ago, and noticed that my Ubuntu 18.04 netatalk server wasn’t showing up in the Chooser anymore. If you’re not familiar with netatalk, it’s an implementation of Apple Filing Protocol (AFP) that runs on Unix-like operating systems such as Linux and NetBSD. It allows other operating systems to act as Mac file servers. Version 2.x, which I use, supports the ancient AppleTalk protocol. This allows it to work with really old classic Macs that don’t even have a TCP/IP stack installed. Support for AppleTalk was removed in version 3.x, so that’s why I’m still using 2.x.
I checked out the server, and noticed that atalkd wasn’t running.
After upgrading my Ubuntu server from 14.04 to 16.04, I noticed that legacy AppleTalk clients connecting to my netatalk (afpd) server showed an empty volume list; I could no longer access my “Home Directory” share that showed up by default in 14.04.
After some research, I discovered that the 14.04 to 16.04 upgrade brought netatalk from version 2.2.2 up to 2.2.5. It turns out that 2.2.5 has a bug which causes AppleTalk clients to not see anything from /etc/netatalk/AppleVolumes.default; only /etc/netatalk/AppleVolumes.system is read. Here is a link to the bug report I posted.
You could rebuild netatalk 2.2.5 with the latest unreleased patches as I mentioned in my first comment of the bug report above, or you can do what I did: just put your volumes into /etc/netatalk/AppleVolumes.system instead. I’m unsure if the “~” share works properly when it’s in /etc/netatalk/AppleVolumes.system, so I hardcoded it to my home directory path just in case. It works fine!
