An invalid 68030 instruction accidentally allowed the Mac Classic II to boot

> I’ve discovered an undocumented MC68030 instruction that performs a read-modify-write bus cycle and also changes the value of the A1 register.

Rather than a "real" instruction that CPU designers consciously created and which was meant to do something useful but wasn't documented, it could just be that this is an illegal instruction and the logic in the CPU is doing whatever it happens to do when given don't-care inputs. (Maybe this is what the author meant, and I'm just catching up.)

Normally the CPU would detect illegal instructions and cause an exception. This would mean there are certain situations where it doesn't.

I found a manual at https://www.nxp.com/docs/en/reference-manual/MC68030UM.pdf. On page 8-9 of the manual (which is page 276 in the PDF file), it says:

> An illegal instruction is an instruction that contains any bit pattern in its first word that does not correspond to the bit pattern of the first word of a valid MC68030 instruction or is a MOVEC instruction with an undefined register specification field in the first extension word.

Note "in its first word". According to the write-up, the instruction is 3 words long. The first word is normal, and the weird bits occur in the second word. So quite possibly the 68030 doesn't validate this second word, just plows forward with the logic that implements the CAS instruction, and lets whatever happens happen.

(Great write-up and amazing dedication, by the way!)

CAS has always been a bitch. I think I've received more bug reports about that instruction's emulation than any other instruction.

Incidentally, I remember another old "bug" in King of Fighters that "incorrectly" checked the carry flag of the SBCD instruction, which it used to decrement the round timer and end the current round. Completely undocumented of course, but if you don't emulate the arithmetic status flags when doing binary coded decimal operations, the round timer in KOF will just keep on going forever, cycling from 00 to 99 :P

SNK were really the gods of the 68000 chip.

That is quite the journey. I find I don't have the patience these days to go quite so far down the rabbit hole as the author does, but I resonate with that feeling of accomplishment in knowing something versus just thinking you know something.

30+ years later, I'm still always amazed at how effective the Mac debugger UI could be with such a tiny screen resolution. It's really quite masterful.

Nearly all CPUs have undocumented instructions, and the 68k is no exception; it's just that the vast majority of people with enough interest and low-level knowledge at the time were focused on the x86/PC instead, which was arguably a far more open and stable architecture than Apple's. The 8088 and 8086 microcode was disassembled and studied extensively a few years ago, and I believe there's been some attempts at simulating it at the transistor level already. Even before that, the structure of the x86 opcode space was also explored in detail by many, with documents like these resulting from such effort:

http://ref.x86asm.net/geek.html

https://gist.github.com/seanjensengrey/f971c20d05d4d0efc0781...

We don’t really know the exact details of what this instruction does. With some limited testing, I believe I’ve observed that the resulting value of A1 depends on the original A1 value, the value of A7, and the program counter. But I’m not sure. Maybe someone can make a program that tries out a bunch of different register values and memory contents, and attempt to deduce what exactly the instruction does so that it can be emulated accurately. Until someone decides that it’s worth trying to figure out, MAME is patching this bug out of the ROM in order to allow the Classic II to boot.

IMHO this is definitely worth figuring out for accurate emulation. I'm not familiar with 68k but the bits in the instruction offer a good clue - my theory is that bits 5:3 of the 2nd word seem like another mode field, and instead of selecting one of the Dn registers via mode 000, 101 is selecting (d16, An) again and the Dc field, containing 001, is being interpreted as A1.

I had an Amiga 2000 with an 68000 processor when I was a kid. How I got excited when I heared about the 68020, or even 68030! And then even RISC architecture. Those were things that got me excited back in those days. I could let my Amiga say a sentence like „Hello, how are you?“, in a robotic tone, and my friends were baffled as if they‘d been to the moon and back. I couldn’t have imagined that less then four decades later I‘d be talking to my computer in natural language using llms. And with Python, VS Code, and LLM in my toolbelt I can automate almost anything I wish to. Crazy times!

WOW.

Amazing work. Thanks for the exposition.

(I miss the 68000 line. Those were such great chips...)

Was this copy protection to keep it from running on systems or does this happen on all 68030?

This seems like it will be impossible in the future with today’s Macs. Apple’s technical documentation is rubbish these days.

Do the '040/060 also support this "undocumented instruction"?

Time to fuzz the rest of the processor.

Does Ken Shirriff have time to look at a 68030?

Re Egret and Command-Power, I’m pretty sure the key combination (and the command-control-power hard reset combo) is always active, and not a Macsbug thing. ISTR you can trigger sad Macs on boot with it, which would be before Macsbug is loaded (I think), and also access the mini debugger if Macsbug isn’t loaded. At least from what I remember about my old LCII (would have to dig it out to double check though).

Damn this instruction won’t speed up Amiga chunky to planar conversion.

> By buying a Classic II and hacking the ROM...

I think that to be a perfect article, they should wrote :

By the magic of buying a Classic II and hacking the ROM...

We’re confident this wasn’t some ROM DRM type feature?

Perhaps it is ‘undocumented’ and is used as proof of someone copying the source code some portion of the source code.

Another possibility is that is a special institution in the chip specifically for Apple that again was used as a copy write detection or protection scheme.

It's not miraculous. If the flaw had prevented the system from booting (in a way that has a high repro rate) they would have fixed it.

The system booted in spite of that undocumented instruction. When things work, you don't go looking for undocumented things that are contributing to the working state.

Millions of C programs work accidentally, in spite of undefined behavior. Nothing gets investigated until a compiler change triggers something.