← All Essays
Technology 12 min read

How the Sega Genesis Actually Worked

The 68000, the VDP, Blast Processing's reality, and why the Genesis sounded and looked the way it did

The 68000 and what it meant

The Motorola 68000 was the processor of choice for high-capability personal computers of the early 1980s: the Apple Macintosh used it, the Atari ST used it, the Amiga used it. It was a 16/32-bit processor — 16-bit data bus, 32-bit internal registers — with a clean instruction set architecture and strong support for the address modes that systems programming and game code required. Sega chose it for the Mega Drive (released in Japan in 1988, North America as Genesis in 1989) running at 7.67 MHz, which made it the fastest processor in any home gaming device available in 1988.

The Genesis also included a Zilog Z80 processor running at 3.58 MHz. The Z80 was included primarily for backward compatibility: it was the same processor used in the Master System, and running it alongside the 68000 allowed the Genesis to play Master System games through an adapter. In practice, the Z80 functioned in Genesis games as a dedicated sound coprocessor, running audio code for the YM2612 FM synthesis chip while the 68000 handled game logic and graphics. This division of labour — 68000 for game, Z80 for audio — was not mandatory, but it was the approach most games used because it kept the 68000 free for its primary work.

The 68000's 7.67 MHz clock speed was the real difference from the SNES's 3.58 MHz, and "Blast Processing" was the marketing name Sega gave this advantage. The claim was directionally accurate: the Genesis CPU ran at more than twice the SNES CPU's clock speed. What the marketing didn't address was that raw clock speed was one factor among several determining game performance, and that the SNES compensated with co-processor chips in cartridges that handled specific tasks faster than any general-purpose CPU at any clock speed. Sonic the Hedgehog was faster and smoother than most SNES platformers because it was designed specifically to showcase what the Genesis hardware could do, not because the Genesis was uniformly superior.

The VDP and its colour limitations

The Genesis's Video Display Processor — a Yamaha-designed custom chip designated the VDP — managed all graphics output. The VDP supported a resolution of 320×224 pixels in most games, with an optional 256×224 mode and limited high-resolution modes. It could display 64 colours simultaneously from a palette of 512 possible colours — three bits per colour channel (red, green, blue) giving 8×8×8 = 512 combinations. The 512-colour palette was the Genesis's most significant graphical limitation relative to competitors: the SNES could select from 32,768 possible colours (five bits per channel), making its colour reproduction substantially more accurate for natural imagery.

The consequence was visible in any game that required naturalistic colour gradation — flesh tones, skies, water. The Genesis's restricted palette produced visible colour banding where the SNES rendered smooth gradients. Developers who understood the limitation designed around it: using bold, high-contrast colour choices rather than subtle gradations, or using dithering — alternating pixels of two different colours to simulate a midpoint colour not in the palette — to approximate smooth transitions. The dithering approach was common in Genesis games and produces the characteristic stippled appearance of shadow and lighting effects that Genesis graphics are associated with.

The VDP could display 80 hardware sprites simultaneously — objects drawn separately from the background layers — with each sprite tile being 8×8 pixels. The actual practical limit was lower due to hardware restrictions on horizontal sprite density, but 80 sprites was a significant number for its era. Background graphics were stored in pattern tables as 8×8 tiles and arranged in a tilemap, with two background planes available (plane A, plane B, and a fixed window plane for HUD elements). The Genesis's scrolling support — horizontal and vertical scroll with per-line scroll options on plane B — allowed the horizontal scroll variation used in games like Sonic to create the ground and sky layers moving at different rates that contributed to the illusion of depth.

Why Sonic sounded and moved the way it did

Sonic the Hedgehog's visual speed was partly hardware and partly design. The Genesis's 68000 was fast enough to update Sonic's position and the level's scroll position at sixty frames per second in the original game, and the VDP's pattern table and tilemap design allowed the level background to scroll smoothly without the CPU needing to redraw the entire screen each frame — only new tiles entering the visible area required CPU attention as the level scrolled. The Sonic team, under Yuji Naka's programming direction, wrote an engine that kept the CPU overhead of scrolling low enough to leave cycles available for Sonic's physics calculations, enemy processing, and the animation of other onscreen elements simultaneously.

The audio that defined the Genesis's sound — and specifically Sonic's sound — came from the YM2612 FM synthesis chip. FM synthesis produces sound by modulating one sine wave with another, creating complex harmonic spectra from simple mathematical operations. The YM2612 provided six FM synthesis channels, each configurable with a set of "operators" (oscillators that could act as carriers or modulators in various configurations) and a sixth channel that could operate as a PCM sample playback channel for drums or voice. Masato Nakamura, who composed the Sonic 1 and Sonic 2 soundtracks, used the YM2612 to produce the synthesised bass guitar, electric piano, and percussion that define the sonic identity of the early Sonic games — sounds that are immediately recognisable as Genesis audio and that have acquired the status of cultural artefacts independent of the games they were composed for.

What the Genesis was and wasn't

The Genesis was a well-designed piece of hardware for its price and its era, with genuine strengths and genuine limitations that were different from the SNES's strengths and limitations rather than uniformly better or worse. The 68000's speed advantage was real for CPU-limited tasks — scrolling, physics simulation, enemy AI — and the SNES's co-processor advantages were real for specific graphical tasks — Mode 7 transformations, SuperFX polygon rendering — that the Genesis couldn't match without its own cartridge hardware additions. The Genesis had no equivalent of the SNES's large co-processor ecosystem.

The comparative quality of Genesis and SNES versions of multiplatform games was determined by each game's specific requirements more than by hardware hierarchy. Street Fighter II Turbo (1993) on SNES was widely considered superior to the Genesis version because the SNES's audio hardware produced the voice samples and music more faithfully. Mortal Kombat (1993) was considered superior on Genesis because the Genesis version included blood (with a code) while the SNES version had sweat substituted. Sports games often looked better on Genesis due to the faster CPU; RPGs often looked better on SNES due to the colour palette. The console war's winners and losers were determined by these specific category comparisons multiplied across entire software libraries.

The Genesis's hardware legacy is the Motorola 68000's role in shaping what game programmers of the late 1980s and early 1990s learned to do well. The 68000 was a genuinely excellent processor for assembly language game programming, with registers large enough to hold game state values directly and address modes that made sprite manipulation straightforward. Programmers who learned game development on Genesis hardware developed techniques and intuitions that translated to subsequent platforms. The hardware didn't survive into the 32-bit era — the Saturn's architecture was entirely different — but the generation of developers who grew up with the 68000 carried their understanding into everything they built after it.