Welcome to the Sega Genesis Systems Architecture Series. In this six-part deep dive, we deconstruct the hardware, microarchitecture, and bare-metal programming models of the 16-bit icon. This series is adapted from our comprehensive engineering textbook for bare-metal and SGDK 2.x developers.
1. System Topology & The Physical Bus
To write high-performance software for the Sega Genesis, an engineer must discard modern unified-memory abstractions. The Genesis is not a monolithic single-board computer; it operates like a heterogeneous distributed edge network with dedicated coprocessors, distinct clock domains, and independent memory spaces communicating over arbitrated physical buses.
The console architecture divides responsibilities across three core silicon components:
- Motorola 68000 CPU: The primary bus master running at 7.67 MHz (NTSC) or 7.61 MHz (PAL), governing game logic, entity transforms, collision trees, and system coordination.
- Yamaha Custom VDP (YM7101 / 315-5313): The visual display processor running at 13.4 MHz, operating as an autonomous rendering engine with its own isolated 64 KB VRAM, 80-byte CRAM, and 64-word VSRAM.
- Zilog Z80 Coprocessor: An 8-bit sound coprocessor running at 3.58 MHz with 8 KB of private audio RAM, driving the Yamaha YM2612 FM synthesis chip and the Texas Instruments SN76489 PSG sound generator.
When designing the Mega Drive in 1988 under project director Hideki Sato, Sega's engineering team faced severe silicon cost constraints. Adding a secondary 16-bit sound processor was economically prohibitive. However, Sega already possessed massive inventory, mature assembler toolchains, and proprietary silicon libraries for the 8-bit Zilog Z80 from the Master System and arcade boards. By keeping the Z80 (costing roughly $0.50 in bulk volume), Sega achieved two triumphs simultaneously: complete backwards compatibility with the 8-bit Master System via the passive Power Base Converter, and a dedicated, isolated sub-CPU to drive the YM2612 FM synth without stealing precious 68000 bus cycles.
The 68000 Asynchronous Bus Handshake (S0–S7)
Unlike modern synchronous buses where transactions complete in fixed clock intervals, the Motorola 68000 uses a true asynchronous bus handshake protocol. The CPU initiates a cycle and pauses indefinitely in wait states until the addressed peripheral explicitly signals data transfer completion via /DTACK (Data Transfer Acknowledge).
A standard bus read or write cycle spans exactly 4 clock cycles (8 clock states, S0 through S7), totaling 521 nanoseconds at 7.67 MHz:
- S0–S1: Bus cycle begins on S0 falling edge; CPU drives the 24-bit address lines (
A1–A23) and setsR//Whigh for reads. - S2: Address Strobe (
/AS) is asserted Low, signaling to all decoders that address lines are valid and stable. Data strobes (/UDSand/LDS) assert. - S3–S4: Addressed peripheral decodes the address and begins fetching data. At the falling edge of S4, the 68000 samples the
/DTACKline. If/DTACKis high, the CPU inserts 2-clock wait states until/DTACKgoes low. - S5–S6: Peripherals stabilize data on the 16-bit bus lines (
D0–D15). - S7: At the falling edge of S6 / start of S7, the CPU latches the data lines into its internal execution registers, then negates
/AS,/UDS, and/LDS, terminating the cycle.
The 68000 instruction set includes TAS (Test-And-Set), an atomic read-modify-write operation intended for multiprocessor semaphore synchronization. During a TAS cycle, the 68000 reads a memory byte, evaluates the sign/zero flags, and writes back with the most significant bit set, keeping /AS continuously asserted Low throughout the entire sequence. However, in Genesis Model 1 custom ASICs (315-5313 / FC1001), the system bus arbiter fails to handle indivisible RMW cycles properly, deadlocking the system bus and hanging the console. Production games and SGDK strictly forbid the use of TAS.
The 16 MB Physical Address Space
The 68000 features a 24-bit physical address bus, providing a flat 16 Megabyte memory space spanning 0x000000 to 0xFFFFFF:
| Address Range | Size | Decoded Hardware Device | Bus Constraints |
|---|---|---|---|
0x000000 – 0x3FFFFF | 4 MB | Cartridge ROM Space | Read-only (or Bankswitch mapper control) |
0xA00000 – 0xA01FFF | 8 KB | Z80 Sound RAM Window | Requires Z80 bus request arbitration |
0xA10000 – 0xA1001F | 32 B | I/O Ports & Peripheral Registers | Controller ports 1, 2, and expansion port |
0xA11100 – 0xA11200 | 2 B | Z80 Bus Request & Reset Control | Writing 0x0100 halts Z80; writing 0x0000 resets |
0xA14000 – 0xA14003 | 4 B | TMSS Security Register | Must write "SEGA" (0x53454741) on boot |
0xC00000 – 0xC0001F | 32 B | Yamaha VDP Data, Control & HV Counters | 16-bit ports mirrored every 32 bytes up to 0xDFFFFF |
0xFF0000 – 0xFFFFFF | 64 KB | System Work RAM (68000 WRAM) | Mirrored across 0xE00000 – 0xFFFFFF |
Beginning with Model 1 VA7 and Model 2 consoles, Sega integrated the Trade Mark Security System (TMSS). The hardware chip at 0xA14000 checks for the four-byte ASCII sequence "SEGA" (0x53454741) written by the 68000 during boot initialization. If the write does not occur, the hardware blanks the VDP data path. This security mechanism was at the center of the historic Sega Enterprises Ltd. v. Accolade, Inc. (977 F.2d 1510) lawsuit in 1992, establishing that reverse engineering and decompilation for interoperability constitutes legal fair use under copyright law.
In Part 2, we will step inside the silicon execution unit of the Motorola 68000, dissecting the 16-register file, status register bitfields, and the true physical 16-bit ALU.
