Sometimes you have to bust out the ol' cork board and red string for a conspiracy theory involving leaked emails, supervillain islands, and heads of state desperate to deny they had anything to do with All That. But other times the conspiracy rabbit hole beckons in other forms. Like, say:
- 📌An emulated Macintosh Classic 2 that unexpectedly crashes on boot, leading to...
- 📌Intense debugging in the emulator and on another old Mac revealing a 34-year-old bug, leading to...
- 📌Buying and repairing a Macintosh Classic 2, leading to...
- 📌Confirmation that it indeed never should've been able to boot in the first place.
But the Apple Macintosh Classic 2 did boot just fine, which is what makes the pay-off of this blog from programmer Doug Brown so great. Through an intense, labyrinthine series of tests using both software and hardware, Brown discovered that the final all-in-one Mac to use a black & white screen shipped with a bug that would have disastrously crashed the computer every single time you turned it on—if not for a miraculous, unknown feature of its Motorola 68030 CPU that hid the problem from Apple's programmers.
Brown discovered the bug when he tried to boot an emulated Macintosh Classic 2 in MAME, an emulator best known for arcade systems that also supports a massive range of classic PCs and obscure systems. For compatibility reasons too complex to get into, the Mac Classic 2 was able to boot into two distinct modes, 24-bit and 32-bit, and the 32-bit mode crashed on startup in MAME.
"Why was this happening? Also, why didn’t this same failure occur on actual hardware?" Brown asks in his blog. "The Classic 2 wasn’t recalled … It would have been all over tech news. Not to mention the fact that the people actually working on the ROM code would have quickly noticed it while they were testing. It’s kind of a glaring issue. So what gives? Was MAME doing something wrong here that didn’t match hardware? … I have the answer to these questions, but as a forewarning, the situation is way more complicated than I expected it to be."
Brown goes into tremendous detail about how he figured out this complicated puzzle, and it's a fascinating read even if you're a non-programmer like me who can only truly grok about 30% of it. But it's still a wild story even if we zoom out from the granular computer instructions that he talks through step-by-step.
The thrust of the problem is that while running through its boot code in MAME, the Classic 2 would perform one instruction that jumped to an invalid address located at 'A1' in memory, and as a result when it tried to execute its next instruction, it was basically in the wrong spot. "And boom, Sad Mac."
When Brown debugged the code on a Macintosh 2ci from the same era (which notably also used a Motorola 68030 CPU), he found it did something a bit differently, transforming that invalid address into a valid one.
"The MAME-emulated Classic 2 was crashing because A1 didn’t change, so it still contained an invalid address," he writes. "On hardware, this weird instruction, which several disassemblers refused to touch, and wasn’t even intended to be jumped to because it starts in the middle of an actual valid instruction, was changing A1 to a new value that was a good address. …
"I was starting to believe something that sounded almost too crazy to be true: Apple had an out-of-bounds jump bug in the Classic 2’s ROM that should have caused a Sad Mac during boot, but they had no idea the bug was there because the 68030 was accidentally fixing the value of A1 by executing an undocumented instruction. How could I prove that my theory was correct?"
By testing on the real thing, naturally.
After coming up with this theory, Brown decided to buy a used Mac Classic 2, pull out its logic board, and clean it up to restore it to working order. I love this photo of his hacked-together Classic 2 that uses a modern ATX power supply and a Raspberry Pi to output the video signal to a capture device so he could take clean screenshots.
After writing some test instructions to see how the startup code would behave using the valid and invalid addresses he'd found in A1 on the Mac 2ci and in MAME, he confirmed what was going on.
"I’ve discovered an undocumented MC68030 instruction that performs a read-modify-write bus cycle and also changes the value of the A1 register," he writes. "This newly-discovered instruction turns out to be the glue that’s accidentally holding the Classic 2 together. Without this instruction modifying A1, the Classic 2 can’t boot. I’m confident that it was a mistake and not something intentional. A totally understandable mistake, at that. If the pesky 68030 hadn’t been hiding the bug from Apple’s ROM developers, there is no doubt they would have caught it before the Classic 2 shipped."
MAME's developers had no idea this instruction existed, so they had never implemented it in the emulator's behavior. That was the key to discovering the secret instruction and its clutch fix for what would've been a boot-breaking bug. A MAME contributor has since patched out the bug so that the Mac Classic 2 can boot in 32-bit mode.
But if not for MAME, Brown points out the bug likely "would have gone undiscovered for all eternity" because there's nothing obviously wrong in the boot up sequence on real hardware. That in itself is kind of amazing, though, because the Motorola 68030 belongs to one of the most-used processor families of all time, powering PCs, Sega consoles, printers, and more. How many more undocumented instructions are out there secretly making old devices work?
The discovery "goes to show you how bugs can be lurking in the background in places where you might think everything is totally polished," he writes. "I think it’s also a good example of how some bugs just aren’t that big of a deal. This bug fits that category pretty well. The machine worked fine and nobody noticed."
You must confirm your public display name before commenting
Please logout and then login again, you will then be prompted to enter your display name.
