The Motorola 68000 is a 16/32-bit microprocessor released in 1979, with eight data registers, eight address registers, a 24-bit flat address space, an orthogonal instruction set, and the distinction of being the most beautifully designed CPU architecture of the twentieth century — a distinction that is subjective, fiercely held, and impossible to argue against by anyone who has actually programmed it.
The 68000 was the CPU of the original Macintosh, the Atari ST, the Sega Genesis, the Sharp X68000, and — most importantly — The Amiga. It was the bridge between the 8-bit era and the modern world: powerful enough to run a real operating system with pre-emptive multitasking, simple enough that a single developer could understand the entire architecture, elegant enough that writing assembly for it felt less like work and more like conversation.
If the Z80 was the first love and the 6502 was YAGNI incarnate, the 68000 was the moment a programmer looked at a machine and thought: “Someone designed this with care.”
The Orthogonal Instruction Set
The 68000’s defining quality is orthogonality: any operation can be applied to any register using any addressing mode. MOVE works from any source to any destination. ADD works on any data register with any addressing mode. CMP works on anything. The instruction set is a grid, not a list of exceptions.
The Z80 has exceptions everywhere. LD A, (HL) works; LD B, (HL) works; but LD (HL), (HL) doesn’t. The 8080 heritage leaks through: some registers are special, some operations only work on A, some addressing modes only work with HL. The Z80 programmer memorises the exceptions. The 68000 programmer memorises the rules, because the rules are consistent, and the exceptions are almost nonexistent.
The 6502 doesn’t have exceptions because it doesn’t have enough features to create them. The 6502’s instruction set is minimal by necessity — one accumulator, two index registers, and whatever you can do with them. The 68000’s instruction set is minimal by design — sixteen registers, dozens of operations, every combination valid.
This is the difference between simplicity from poverty and simplicity from discipline. The 6502 is simple because it couldn’t afford complexity. The 68000 is simple because its designers refused complexity. Both produce clean code. But the 68000 produces clean code that is also powerful, and the experience of programming it is the experience of a tool that never surprises you, never frustrates you, and never makes you look up whether this particular combination of operation and addressing mode happens to be valid.
It is always valid. That is orthogonality. That is the 68000.
The Registers
Eight data registers: D0–D7. Thirty-two bits each. All equivalent. Any operation that works on D0 works on D7. No special accumulator. No preferred register. The programmer chooses which register to use based on what makes sense, not what the hardware demands.
Eight address registers: A0–A7. Thirty-two bits each (24 bits used for addressing in the original 68000). A7 is the stack pointer, but even this is a convention, not a hard constraint. Address registers can be used for pointer arithmetic, indexing, and indirect addressing.
Sixteen registers, all 32 bits, all named, all predictable. Compare this to the Z80’s hodgepodge (some 8-bit, some 16-bit, some paired, some with special purposes, some hidden behind EXX) or the 6502’s three (one of which is the accumulator and you’d better like it). The 68000 gives you enough registers that you rarely need to touch memory, and the registers are all the same shape, and the instructions work on all of them the same way.
The 68000’s register set is Go’s interface in silicon: uniform, predictable, no surprises. The Z80 is C: powerful but full of special cases. The 6502 is assembly itself: raw, minimal, everything visible.
The Flat Address Space
The 68000 addresses memory as a flat, linear 24-bit space: 16 megabytes, addressed byte-by-byte, with no segments, no banks, no page switching, no memory mapping tricks.
This seems unremarkable now. In 1979, it was revolutionary. The Z80 had 64K of address space, extended through bank-switching hacks that required hardware page-swapping and careful programming. The 6502 had 64K with the zero page as a special 256-byte fast-access region. The Intel 8086 had segments — the segmented memory model that would haunt PC programmers for twenty years, producing near and far pointers, segment registers, and the general sense that memory was not a thing you used but a thing you negotiated with.
The 68000 had none of this. Address register A0 pointed to a byte. Increment it. Now it points to the next byte. That’s it. No segment arithmetic. No bank switching. No page registers. No far pointers. Memory was a flat plain, and you walked across it freely.
This is why the Amiga could have pre-emptive multitasking in 1985: flat memory meant the operating system could give each process a region of memory and let it run. No segment table to manage. No bank-switching to coordinate. Just addresses, flat and linear, the way memory should always have been and — once the 68000 proved it — eventually was.
The Assembly Experience
Programming the 68000 in assembly is the closest that assembly language comes to being pleasant.
LEA message(PC),A0 ; point to the string (PC-relative)
loop: MOVE.B (A0)+,D0 ; load next byte, auto-increment
BEQ.S done ; zero? we're done
BSR.S put_char ; print it
BRA.S loop ; repeat
done: RTS
Six instructions. Compare to the Z80’s eight for the same operation. The 68000 has auto-increment addressing ((A0)+), which loads the byte and increments the pointer in one instruction. The Z80 needs separate LD and INC instructions. The 68000 has BEQ.S — branch if equal, short form — which tests the flag set by the previous MOVE instruction without needing a separate CMP. The Z80 needs an explicit CP 0.
Every 68000 instruction does slightly more than its 8-bit equivalent. Not because the instructions are complex — they are not, they are simple — but because the orthogonal design means you never waste an instruction working around a limitation. The instruction you need exists. The addressing mode you want is available. The register you want to use is interchangeable with any other.
This is why the 68000 was “too easy” compared to returning to the C64. The 68000 didn’t fight you. The 6502 fought you constantly, and the fight was the fun. The 68000 cooperated, and the cooperation produced results so quickly that the challenge shifted from can I make it work to what should I make — which is a better problem, but a less addictive one.
The Amiga Partnership
The 68000 was used in many machines. It was only loved in the Amiga.
The Macintosh used the 68000 politely. The Mac’s architecture treated the CPU as the center of everything: the CPU drew the screen, the CPU handled the mouse, the CPU managed the disk. The 68000 did all the work, alone, in a single-tasking operating system, like a talented musician playing solo in an empty room.
The Atari ST used the 68000 adequately. The ST’s shifter and sound chip were simple, and the CPU filled in the gaps. The 68000 in the ST was a worker in a functional but uninspiring workshop.
The Amiga used the 68000 correctly. The custom chips — Agnus, Denise, Paula — did the heavy lifting: DMA-driven graphics, hardware sprites, copper list display manipulation, four-channel sampled audio. The 68000’s job was not to do the work but to direct the work: set up the blitter, program the copper list, tell the DMA channels what to fetch, and get out of the way.
The 68000 in the Amiga was a conductor, not a soloist. And the orchestra was magnificent.
The Legacy
The 68000 family continued: the 68020 (full 32-bit, caches, barrel shifter), the 68030 (MMU integrated), the 68040 (FPU integrated, pipelined). Each generation added capability without breaking the instruction set. Code written for the 68000 ran on the 68040. The architecture was forward-compatible because the architecture was clean — there were no hacks to maintain, no segment workarounds to preserve, no accumulated exceptions to honour.
The 68000 family died not because it was inferior but because Intel won the volume war. The PC’s market share, driven by IBM compatibility and Microsoft’s software ecosystem, made the x86 the default, and volume drove prices down, and prices drove adoption, and adoption drove software, and software drove sales, until the technically superior architecture was irrelevant to a market that had chosen the technically inferior one.
The 6502 won on price. The x86 won on ecosystem. The 68000 won on design and lost on everything else.
But the developers who programmed it — the ones who wrote copper lists at 2 AM and blitter chains at sunrise and 488-byte bootblocks that contained entire universes — they carry the 68000’s lesson with them: that design matters, that orthogonality matters, that a clean architecture produces clean code, and that the correct tool, even when the market chooses the wrong one, is still the correct tool.
