The Episode I Rag On My Favorite Architecture

My favorite computer architecture of all time is the Motorola 68000. I love the instruction set, as it is very simple to write assembly code for, while also being very powerful, and the ideal target for compiled languages like Pascal and C. But my God, Motorola was far from perfect. So today I'm going to discuss the various mistakes and fuckups involving the 68000. I'm so sorry, buddy.

Part 1: Thinking Ahead For Once

In 1974, when Motorola released the 8-bit 6800 CPU, other semiconductor manufacturers had started working on making 16-bit designs. However, many of these were terrible due to the available technology at the time, either requiring a boatload of individual ICs or being slow as dirt. There was also the major issue of discarding backwards compatability, and would very likely do it again in the future. So rather than try to match what Intel and Zilog were attempting to cook up, a team called Motorola Advanced Computer System on Silicon, or MACSS, was formed at Motorola to try and come up with a better design that targeted the higher end market. And they did that by NOT making a 16-bit CPU! Instead, they skipped over it and went straight to a 32-bit design.

Initially, they had considered making it backwards compatible with the 6800, but ultimately decided that perhaps a clean break may very well be a good idea. Taking inspiration from DEC's PDP-11, an orthogonal instruction set was devised that allowed for very flexible addressing. This was accomplished using microcode, where opcodes are further broken down within the CPU into smaller instructions. However, IC packaging at the time did not provide enough pins for a 32-bit address and data bus, and it would be incredibly foolish to do something like multiplex pins. So, the external interfaces for the address and data buses were reduced, with 24 pins for address and 16 pins for data. This allowed enough space for the extra interfacing pins needed for a CPU, and even the peripheral bus from the 6800 to take advantage of existing products. Internally nicknamed the "Texas Cockroach", this was the original 64-pin 68000 CPU.

Now it was just a matter of producing the thing. Unfortunately, Motorola's fabs were getting outdated compared to the competition, so they partnered with Hitachi to revamp their fabs and collaborate on designs. Not only did this result in Motorola getting the manufacturing overhaul they needed for producing the 68000 at scale, but it also resulted in Hitachi becoming a second source for the CPU. The 68000 was finally revealed in 1979, one year after Intel got their 8086 out the door, and then sold to consumers in 1980. Initially, the price was $487 and later dropped to $125, but Steve Jobs had managed to talk Motorola into dropping the price later on down to roughly $15.

Part 2: Spectre in the 80s

So despite everything, there was a single, critical flaw in the original 68000. The CPU was mainly intended to be used for microcomputer systems, which are generally single-user devices. But people took the description "VAX on a chip" a bit too seriously, and were making multi-user minicomputer systems with it. This would require the use of virtual memory, and in order to correctly have virtual memory, you had to meet the Popek and Goldberg virtualization requirements. These were requirements that would prevent breaking out of the illusions crafted by virtual memory, thus allowing for things like info stealing or privilege escalation. And in the ultimate "whoopsie" moment, MACSS missed one operation: "MOVE from SR". This allowed for the reading and manipulation of the Status Register, which can allow for things like spying on other processes or just, making yourself supervisor and taking over the entire machine.

In 1982, Motorola addressed this with the 68010, a newer revision of the 68000 that did not have this problem, while also increasing speed by about 14%. That's great! Except, it too came with its own critical flaw: software incompatability. The entire idea of doing the 32-bit design was to have a "future proof" ISA that would be forward compatible with all new CPUs, thus avoiding the backwards compatability problem in the first place, and was part of the marketing for the CPU itself. And they immediately broke this promise with the very first CPU revision. "MOVE from SR" was now privileged, and a "MOVE from CCR" was added that allowed for unprivileged access to the Condition Code Register, which is the lower half of the Status Register. The Exception Stack Frame was also reworked, to allow for better recovery from bus faults. And these changes did, in fact, break existing software. As an example, if you have one of the old versions of Amiga Workbench and use it on a 68010 CPU, the calculator will cause a system-crashing Guru Meditation.

The best that Motorola could do in this situation was to sell both the older 68000 alongside the 68010. The 68010 was advertised as being the virtual memory option, and the 68008 being the 8-bit migration helper. Oh, right, the 68008 also came out around the same time as the 68010, and further reduced the buses to 20 pins for address and 8 pins for data, but was otherwise the same as the original 68000. As stated, its purpose was to help designers migrate away from older 8-bit designs while offering compatability with 8-bit peripherals, albeit at reduced speed since it takes twice as long to fetch an instruction or data than with the 16-bit data bus. There is also the very rare 68012, which was a 68010 in a Pin Grid Array package that exposed far more of the internal address bus, allowing for 2GB of memory space, while also adding the Read-Modify-Write Cycle pin for multi-processor designs.

Part 3: Complex Complications

In 1983, the proper successor was nearing design completion. The 68020 "super chip" was an evolution of the 68012, now with a fully exposed 32-bit data and address bus. This would also be paired with two more chips, a Memory Management Unit and a Floating Point Unit, as customers who were making UNIX workstations and minicomputers kept asking for these features - or in the case of some vendors like Sun, would just make their own with blackjack and hookers. Initially, the price was again going to be $487, but it would take some time until vendors created new computers, so keeping the cheaper $15 68000 around helped.

And boy, did they need the help. The fab that the CPU was to be made at was producing zero working CPUs. This was because the person in charge of the fab was instead just screwing around, using the space as a R&D lab instead of, you know, manufacturing products. Upper management yeeted the floor manager and replaced him with someone that would get shit done, even if it meant flying to the headquarters of one of the equipment manufacturers and smashing their CEO's desk in pure rage to get them to fix things YESTERDAY. This resulted in all the manufacturing issues being ironed out, and the chips were ready for customers in 1984.

And the 68020 was already being replaced with the 68030, which started being developed quickly after the '020 was launched. Which was good, because all those extra chips made for very complex circuit designs. At least the '020 was a massive speed boost over the older designs, because it had the full bus available, therefore fetching instructions and data was twice as fast, even when running at the same clock speeds. It also made the 68008 irrelevent, as it was possible to select the bus width, so you could use the '020 with an 8-bit bus if you wanted, if you didn't mind the speed penalty.

In 1987, the 68030 was released, putting the MMU onto the CPU chip itself, thus simplifying designs. It was bus compatible with the '020, meaning it could be dropped into existing designs with a bit of work. This is considered to be the peak of the 68K family, as there is really no actual fault with this product. Instead, the problem it faced was external, as the rise of RISC has started. While Sun used the '030 for a brief period in their UNIX workstations, they quickly switched to a new CPU they developed from Berkeley's RISC project, SPARC. And now, Motorola was forced to compete with a new paradigm of CPU design.

Part 4: Taking RISCs

In 1988, Motorola released their answer to RISC, the 88000. It's not related to the 68000 in any way, aside from the concept of being a completely clean break from previous designs. It used RISC concepts without naming RISC directly, used a "scoreboarding" system for doing out-of-order processing, and oh who cares nobody actually liked this thing. It was expensive and required multiple chips; the FPU was mandatory whereas with the 68030 it was optional. The only real user was Data General, but that was before they switched to Intel. NeXT was considering using it for a new workstation but that was cancelled when NeXT's hardware division itself was cancelled.

However, some ideas from this did make their way into the 68K line. In 1990, the 68040 was released, which actually managed to cram the FPU into the CPU itself, meaning there was no longer a need for an external coprocessor system. However, many features of the FPU were lost in the process, requiring software emulation through TRAP calls. Motorola did provide the code for developers to actually implement this, but that code appears to be lost to time. Also, packing the FPU, MMU, and CPU together tightly made the chip run much hotter than before, requiring the use of cooling to run at high speeds. While we think of using a large heatsink with a fan to be normal nowadays, overclockers used just that to get the '040 to run up to 50MHz - a speed grade that was planned, but cancelled due to running too hot.

The '040 had incredibly fast processing speed, averaging 1 cycle per instruction, which is on par with RISC designs despite using microcode. This would make it the greatest 68K member ever... except the FPU emulation trapping is faulty on certain batches of the CPU. Notably, in the "Low Cost" 68LC040 variant, which removes the FPU entirely, thus all FPU functionality has to be done through software. When using the traps to emulate the FPU, instead it can just fail to write data and forget what it is doing, leading to software crashing. It wouldn't be so bad if this version of the chip wasn't widely used, except Apple was using it in a bunch of their Macintosh computers at the time (for example, the LC 475). A mask revision that fixed this finally came out around 1995, which is kind of a long time to fix something this serious. Then it would just be a matter of replacing the CPU with oh wait these CPUs are soldered to the motherboard, they aren't socketed. Oh, Apple.

Part 5: Losing The Plot

In 1994, the last of the 68K family, the 68060, was released. Looking more like the Intel Pentium internally, this was a very fast CPU that, if cooled properly, could hit 150MHz. But nobody remembers this CPU because nobody actually used it. The three major vendors that used 68K CPUs were Apple, Atari, and Commodore. Commodore managed to slip in the shower and kill itself, Atari bet the entire farm on the Jaguar and lost, and Apple was approached with Motorola by a seething, freshly-betrayed IBM that offered a deal to create a RISC platform that would make the rest of the industry regret ever crossing them. This last one was the start of the AIM Alliance, and the PowerPC architecture that Motorola would produce. This ultimately killed any serious marketing of the 68K for desktop computing.

And honestly, the 68060 was going to be problematic from the start if it actually was used. Up until now, the only time backwards compatability was compromised was with the 68010, which was very early in the lifespan of the architecture. Here, a bunch of opcodes were removed; some of them were no longer required like co-processor interface stuff, and some were just rarely if ever used, but they got rid of hardware multiply and divide for 64-bit numbers. If any software used these, software emulation would be required or else things will just break.

The 68K family attempted to get into the embedded and portable space and had some solid success, until ARM came in and kicked everyone else out. In 1994, Motorola released the ColdFire CPU, and in 1995 released the DragonBall CPU. The latter was basically a microcontroller based on the original 68000, and was used to power the Palm OS ecosystem until they switched to ARM with Palm OS 5; it has been replaced with ARM-based designs itself. The former is amazingly still in production today, but the instruction set has been heavily lobotomized. Many instructions and addressing modes were completely deleted, to try and make it more RISC-y, at the cost of making it painful and difficult to program in assembly for, favoring only compiled C code. Every other version of the 68000 is no longer in production, unless you count the lichs at Rochester Electronics.

NEXT TIME ON EDUCATION YOURSELF

Some kid makes a hobby project, not going to be a big thing.