Motorola 68000 sits at the heart of three machines that helped define a generation of gaming. Atari put it inside the ST, Commodore used it in the Amiga and Sega chose it as the main processor for the Mega Drive. Years later, Atari even kept one inside the Jaguar.
On paper, that sounds like the beginning of a family resemblance. In practice, the machines could hardly have developed more distinct personalities. Atari ST games became closely associated with CPU-driven graphics and YM2149 sound, Amiga games leaned on custom chips and sampled audio, while the Mega Drive was built around tiles, sprites and FM synthesis.
The shared processor gave programmers a common instruction set and a body of knowledge they could carry between systems. It did not give them the same machine. They shared a language, but not the same workload.
Why the 68000 was such a big deal
Motorola introduced the 68000 at the end of the 1970s, and it offered a substantial step up from the processors familiar to most home-computer programmers of the previous generation. Internally it used 32-bit registers and a largely 32-bit programmer’s model, while the original chip exposed a 16-bit data bus and a 24-bit address bus.
For someone coming from a Z80 or 6502, there was far more room to work. Eight data registers sat alongside eight address registers, memory appeared as a large linear address space and the instruction set was well suited to the increasingly ambitious software being written for 16-bit computers.
The three main machines in this story ran it at broadly similar speeds. A standard Atari ST used an 8MHz 68000, a PAL Amiga ran a little over 7MHz and a PAL Mega Drive sat at roughly 7.6MHz. Looking only at those figures might suggest three machines with broadly similar game performance.
They were nothing of the sort.
The useful question is not simply how fast the processor ran, but how much work it had to do. If the CPU was copying graphics, shifting sprites and generating effects itself, those millions of cycles disappeared quickly. If specialist hardware could take over some of those jobs, the 68000 was free to concentrate elsewhere.
Atari ST: give the 68000 the job and get out of its way
The Atari ST is probably the cleanest example of the 68000 being asked to earn its keep. Atari built a comparatively straightforward machine around the processor, with dedicated hardware for video, storage, sound, memory control and I/O, but without the extensive graphics assistance that would define the Amiga or Mega Drive.
The ST’s Shifter read display data from main memory and turned it into the picture on screen. Its familiar low-resolution mode provided 320×200 pixels with 16 colours selected from a palette of 512, but the original machines had no hardware sprite system and no dedicated background scrolling hardware.
If a programmer wanted an object moving across the screen, much of the job came back to the CPU. Sprites could require shifting, masking and copying data into screen memory, so the quality of the 68000 routines underneath a game could have a huge effect on how smoothly everything moved.
That directness became part of the ST’s character. A programmer who understood the processor and the organisation of the screen could get close to almost everything the machine was doing, and generations of demo coders subsequently found ways to make supposedly fixed ST hardware behave in increasingly impolite ways.
Later machines improved the situation. The Blitter appeared in parts of the ST family before becoming standard with the STe, taking over some block-copying and logical graphics operations that otherwise landed on the CPU. The STe also added hardware scrolling and stereo DMA sample playback.
The problem for commercial games was the installed base. Publishers still wanted software to run on the large number of older ST and STF machines already sitting under people’s monitors, so the baseline remained far more modest than the newer hardware could offer.
Sound followed the same divide. The original ST used the Yamaha YM2149 programmable sound generator, with three tone channels, noise and envelope control. Talented musicians extracted far more from it than the bare specification suggests, but it was fundamentally different from the sample-driven audio system inside the Amiga.
This is why two versions of the same game could look broadly similar in screenshots and feel much further apart once everything started moving and making noise. The ST’s processor was often doing jobs another machine could hand to specialist hardware.
Amiga: the 68000 was only part of the machine
The Amiga approached the same processor from almost the opposite direction. Its 68000 actually ran a little slower than the ST’s in PAL machines, yet the computer around it was designed so the CPU did not have to handle every task alone.
Agnus coordinated much of the memory and DMA activity and contained the Blitter and Copper, Denise handled much of the display system and Paula provided audio alongside other I/O duties. Instead of making the 68000 personally move every piece of graphics or sound data, Commodore gave it several specialist partners.
The Blitter could copy and combine blocks of graphics memory. The Copper could change hardware registers in sync with the display, making it possible to alter colours or display parameters partway down the screen. DMA could move data without needing the CPU to perform every individual transfer.
None of this meant the 68000 could sit around doing nothing. The CPU and custom hardware shared access to chip memory, so good Amiga programming involved understanding when different parts of the system wanted the bus and arranging work accordingly.
For games, though, those custom chips changed what was practical. Hardware sprites, scrolling, bitplane graphics and the Blitter provided several ways of moving objects and backgrounds without treating every frame as a software-drawing problem for the 68000.
Paula gave the machine another instantly recognisable advantage. Four DMA-driven channels could play 8-bit samples from memory with independent pitch and volume control, turning recorded drums, basses, instruments, speech and effects into part of the normal audio toolkit.
That helped make tracker music inseparable from the Amiga’s identity. A game could have broadly similar logic on ST and Amiga while looking and sounding quite different because the machines were solving the presentation around that logic in completely different ways.
It also makes arguments based purely on CPU speed rather pointless. A calculation that lived almost entirely on the 68000 might favour the ST’s 8MHz clock. A sequence designed around the Amiga’s Blitter, Copper and DMA hardware could reverse the picture completely.
Mega Drive: same CPU, completely different rules
Then Sega put the 68000 in a machine that was not pretending to be a general-purpose computer at all.
The Mega Drive had no desktop environment to worry about, no mouse-led operating system and no expectation that somebody might stop playing and load a spreadsheet. It booted a cartridge, put a controller in your hand and devoted its hardware to games.
Its Video Display Processor had its own 64KB of VRAM, tile-based scrolling planes, a window plane, hardware sprites, palette memory and DMA facilities. Graphics therefore lived inside a system that looked nothing like either the Atari ST framebuffer or the Amiga’s bitplane arrangement.
A Mega Drive programmer generally constructed the screen from tiles and sprites, updating their attributes and feeding data into the VDP. Moving a character did not mean repeatedly redrawing a rectangular block into screen memory in the way an ST game might.
The console also contained a Z80 alongside the 68000. It became closely associated with running sound code around the Yamaha YM2612 FM synthesiser and PSG, although it was a general-purpose processor and the relationship between it and the 68000 involved its own rules about memory and bus access.
That audio hardware gave Sega’s machine another identity again. Where Amiga music often revolved around samples and ST music around programmable tones, the Mega Drive became known for FM synthesis, PSG channels and the occasional use of samples through the YM2612’s DAC.
The 68000 neither knows nor cares. It is the supporting hardware that gives each machine its accent.
The conversions that exposed everything
Multi-format games are where the differences become easiest to see. During the late 1980s and early 1990s, publishers routinely wanted Atari ST and Amiga versions, while successful titles increasingly travelled to consoles such as the Mega Drive.
The shared processor undoubtedly helped. A programmer who already knew 68000 assembly did not have to learn a new CPU every time, and game logic, data structures and some processor-side routines could potentially survive a move between systems.
The moment the code needed to draw, make sound, read controls or manage machine-specific memory, that advantage became much smaller. The shared CPU reduced the distance between the starting points. It did not remove the journey.
The Bitmap Brothers produced some useful examples. Gods and Speedball 2: Brutal Deluxe reached Atari ST, Amiga and Mega Drive, putting the same underlying game designs into three architectures that wanted graphics and sound delivered in different ways.
Sensible Software’s games crossed the same divide. Mega-Lo-Mania, versions of Sensible Soccer and eventually Cannon Fodder appeared across the three systems, although conversions were not necessarily written by the same people or developed alongside one another.
Sound alone could require a rethink. A piece built from samples on the Amiga could become a YM2149 arrangement on the ST and an FM version on the Mega Drive. The melody might survive, but the route from notes to speakers was different every time.
Graphics exposed an even larger divide. An Amiga version could rely on bitplanes, Blitter operations and the Copper. The ST might replace part of that work with carefully tuned CPU routines, while a Mega Drive conversion could be reorganised around tiles, scroll planes and hardware sprites.
That is why ST-to-Amiga ports became such a sore point among some Amiga owners. If a game was designed primarily around the simpler ST architecture and then moved across with minimal changes, the Amiga’s custom hardware could end up doing far less than it was capable of.
For ST owners, that shared development model often helped keep releases coming. For Amiga owners looking at a machine full of specialist hardware while playing something that behaved almost exactly like the ST version, the benefits were less obvious.
The reverse could be difficult too. A game built heavily around Amiga hardware might need substantial reworking to run well on the ST, where the 68000 had to pick up jobs that the custom chipset previously handled.
The Mega Drive introduced different compromises again. Mouse-driven interfaces needed to work on a gamepad, graphics might need reconstructing as tiles, music moved into Sega’s sound architecture and floppy storage became cartridge ROM.
A developer could carry knowledge of MOVE instructions, registers and addressing modes between all three. Knowing the Amiga Copper did not teach you Sega’s VDP, and understanding an ST framebuffer did not make somebody fluent in FM synthesis. The best conversions came from developers who knew when to stop thinking about the source machine and start designing for the destination.
The operating system changed the games too
There was another difference that had nothing to do with raw graphics hardware. Atari ST and Amiga were computers. Mega Drive was a console.
The ST was built around a keyboard, mouse, floppy storage and TOS with GEM. The Amiga likewise combined keyboard and mouse input with disk storage, Workbench and a broader expectation that the machine would run applications as well as games.
The Mega Drive booted a cartridge and expected somebody to pick up a controller.
That changed the kinds of assumptions game designers could make. Strategy games and simulations could rely on mouse input on the computers. Games could save to disk, ask for keyboard commands or spread across several floppy disks, while console versions had to reshape those interactions around a directional pad and buttons.
Cartridges offered advantages in the other direction. Data was available from ROM without waiting for a floppy drive, removing disk swaps and much of the loading that became part of home-computer gaming. The trade-off was that cartridge capacity cost money and could not be expanded by adding another disk to the box.
Then the Jaguar kept the 68000 alive in a very different Atari
The Atari Jaguar makes an interesting late addition to the story. It also contained a Motorola 68000, this time running at around 13.3MHz, but its role was completely different from the one it had played inside the ST.
The 68000 remained as a familiar general-purpose processor, but Atari’s architecture expected much of the demanding work to be handled by the custom processors inside Tom and Jerry rather than by the 68000 itself.
Its presence still had a practical advantage: developers arriving with years of Atari ST experience already knew the processor. Code that was not tied directly to ST graphics, sound or other hardware could potentially be adapted rather than rewritten from nothing.
Recent homebrew releases provide a neat demonstration. Return to Blacktooth: A Head Over Heels Adventure appeared first for Amiga and Atari ST before Reboot Games produced its Jaguar version, and the result remains recognisably the same game rather than becoming a completely different Jaguar interpretation.
That does not mean an ST executable can simply be dropped into a Jaguar and expected to work. Video, sound, input and the surrounding system are different, and a proper conversion still needs platform-specific code. The shared 68000 means much of the processor-side thinking can remain familiar.
It is a nice reminder that Atari’s decision to keep the chip around had value beyond a specification on the box. Decades later, developers can still exploit that common ground when moving new software between machines separated by an entire hardware generation.
The 68000 never really went away
Four decades after the original ST and Amiga appeared, people are still writing new software for these processors and the machines built around them.
UrbX Warriors: The Lost City is being developed for both Amiga and Mega Drive, giving a modern team the same broad challenge developers faced decades ago: one 68000 instruction set, two completely different graphics and sound architectures.
The Atari ST is being pushed in stranger directions still. Jonas Eschenburg’s Command & Conquer port is trying to reproduce a much later PC strategy game while preserving its behaviour on Atari hardware, making performance work around the 68000 central to the project.
The Motorola family continued beyond the original chip too. Later Amigas moved into the 68020 and 68030 generations, while Atari used the 68030 in machines such as the TT and Falcon. Our FalconFPGA coverage follows work testing an open 68030 implementation instruction by instruction against emulation and real silicon.
There is a practical reason these architectures remain attractive to developers. They are small enough to understand. One person can learn the CPU, examine the memory map, read the hardware registers and build a mental model of most of the machine without a separate team responsible for every subsystem.
The same appeal came through when Patricia Curtis spoke to SpriteFountain about modern retro development. The processor is different, but the attraction is related: older-style hardware lets an individual programmer get close enough to understand what their code is asking the machine to do.
The 68000 sits in a particularly appealing middle ground. It is capable enough to support substantial games and operating systems, yet straightforward enough that programmers can still reason about its behaviour at a level that feels tangible.
Same processor, three identities and one strange afterlife
It is tempting to group Atari ST, Amiga and Mega Drive together as one 68000 generation, and there is some truth in that. Programmers could carry processor knowledge between them, publishers saw obvious opportunities for multi-format releases and some games shared substantial parts of their underlying logic.
But the CPU was never the personality of any of those machines on its own.
Atari built a comparatively direct computer where the 68000 frequently had to earn its keep. Commodore surrounded it with custom hardware designed to move graphics and audio alongside the processor. Sega placed it in a dedicated game console where a VDP, Z80 and FM synthesiser gave the same CPU an entirely different working environment.
The Jaguar then took the story somewhere else again, keeping the 68000 around while pushing much of the demanding work towards newer custom processors. Even there, its familiar instruction set remained useful enough that modern developers can still find common ground with software built for the ST.
The result was never three versions of the same machine, or four once the Jaguar enters the picture. They were different answers to the question of what you could build around a processor developers already understood.
Perhaps that is why comparing versions of the same game remains so addictive. A missing sample, a smoother scroll, a rewritten interface, different colours or an unexpectedly faithful Jaguar conversion tells you something about what the destination hardware could do and which parts of the original code were able to come along for the ride.
The 68000 gave these machines a common vocabulary. What Atari, Commodore and Sega built around it turned that vocabulary into completely different languages, and developers are still translating between them today.
