A Genesis game is not a program that lives “inside the console.” It lives inside the cartridge, in a single chip called a ROM — Read-Only Memory. Picture that chip as an enormous grid of tiny cells, each holding one bit: a single 1 or 0, stored as the presence or absence of a connection etched into the silicon at the factory. Group eight bits and you have a byte — a number from 0 to 255. A Genesis cartridge is, at heart, a few million of those bytes, frozen in place and never changing again.

The word that matters most is read-only. The pattern of bits was pressed into the chip when it was manufactured — this style of chip is a mask ROM — and nothing the console does can alter a single one of them. Contrast that with RAM, Random-Access Memory, the console's scratch pad: the 68000 can write to RAM freely, but it forgets everything the moment you switch off. The division is the whole architecture of a cartridge machine — the unchanging game lives in cartridge ROM, the changing state (where Sonic is standing, how many rings you have) lives in console RAM.

Addressing: how you ask for a byte

How does the console get one specific byte out of millions? Every byte in the ROM has a numbered slot, its address — byte 0, byte 1, byte 2, and so on. To read, the console places an address onto the chip's address lines (a set of wires, one per bit of the address), and the chip responds by driving the byte stored there back out on its data lines. There is no searching and no waiting for a mechanism to move — any byte is reachable in the same tiny sliver of time as any other, which is exactly what random access means. Give it an address, get back a byte. That's the entire contract of a ROM, and everything else in this course is built on it.

The lab below is that contract made visible. A little 256-byte ROM sits in the middle as a grid of cells. Set an address on the red address lines — by hand, or let it sweep like a CPU walking through memory — and watch the matching cell light up and drive its byte onto the blue data lines. Nothing moves, nothing wears; the same address always returns the same byte, because the byte was baked in at the factory and can never change.

Module 01 showed a chip answering an address. Now let's see the wires that carry the question and the answer. A bus is just a shared bundle of wires that several devices connect to. The Genesis's main processor — a Motorola 68000 — talks to the cartridge, the RAM and the video chip over two of them: the address bus and the data bus.

The address bus carries the number of the location the CPU wants. The 68000 has a 24-bit address bus, which means 2²⁴ = 16,777,216 distinct addresses — a 16 MB space. (Internally the chip works with 32-bit registers, but only 24 of those bits reach the outside world.) The data bus carries the actual value to or from that location, and it is 16 bits wide: the 68000 is a 16-bit machine on the outside, moving two bytes at a time. One number of wires sets how much you can address; the other sets how much you move per trip.

One read, as a handshake

A single read isn't instantaneous — it's a short, strict conversation timed by the CPU's clock, using a few extra control signals. The 68000 first puts the address on the bus and pulls a wire called /AS (Address Strobe) low to announce “this address is valid.” It signals a read by holding R/W high, and uses /UDS and /LDS (Upper/Lower Data Strobe) to say whether it wants the upper byte, the lower byte, or both of the 16-bit word. The addressed device — the ROM, say — decodes the address, drives its data onto the data bus, and pulls /DTACK (Data Transfer ACKnowledge) low to say “here it is.” The CPU latches the word and releases the strobes. That five-beat dance happens millions of times a second, for every instruction and every byte of every sprite.

The lab runs exactly that handshake in slow motion. Pick a target — a word in the cartridge, in work RAM, or a video-chip port — and step or run the cycle. Watch the address travel from the 68000 to the device, the control strobes light up in order, and the 16-bit data word travel back, acknowledged by /DTACK. That is the atom of everything the console does.

A bus is a shared set of wires, and that raises an obvious danger. The ROM, the RAM and the video chip are all wired to the same 16 data lines. If two of them tried to drive those lines at once — one pushing a wire high while another pulls it low — you'd get a short and garbage data. So every chip on the bus must stay politely silent until it, and only it, is spoken to. Two tiny control pins arrange that.

The first is chip-select, usually written /CS (the leading slash means “active-low” — the chip is selected when this pin is pulled low). Some external logic, the address decoder, watches the upper address bits and pulls exactly one chip's /CS low per access. An address in the cartridge range selects the ROM; an address in the RAM range selects the RAM; nobody else stirs.

The second is output-enable, /OE, and it controls the chip's mouth. A chip can be selected yet still not driving the bus; only when /OE goes low does it actually connect its outputs and push the byte out. When /OE is high, the outputs sit in a special third state — neither high nor low but high-impedance (“hi-Z”), electrically disconnected, letting go of the wires entirely. That hi-Z state is the secret to sharing: an unselected chip isn't fighting for the bus, it has physically released it.

Access time: the ROM's one performance number

From the moment a valid address and /CS/OE arrive, a mask ROM takes a small but non-zero time to settle its outputs to the correct byte — its access time, quoted in nanoseconds (Genesis-era mask ROMs were commonly around 150–200 ns). The console's bus timing has to allow at least that long before it latches, which is precisely what /DTACK from Module 02 is negotiating. A slower chip simply asks the CPU to wait a beat longer. Nothing here is exotic — it's the reason the handshake exists at all: the wires are instant, but the silicon at the far end needs a moment to answer.

The data bus is 16 bits, so the 68000 naturally thinks in units bigger than a byte. A byte is 8 bits; a word, in 68000 terms, is 16 bits (two bytes); a longword is 32 bits (four bytes). Addresses, jump targets and the header fields you'll meet in Module 07 are mostly words and longwords. But the moment a value spans more than one byte, a question appears that has started real arguments between real engineers: which byte goes first?

Take the 32-bit value $53454741. It's built from four bytes: $53, $45, $47, $41. When you store it at some address, do you put the most-significant byte ($53) at the lowest address, or the least-significant one ($41)? The first choice is called big-endian; the second is little-endian. The Motorola 68000 is big-endian: the big end goes first, at the lowest address — exactly the order we write numbers on paper. This is not a small footnote; it is baked into every multi-byte number in every Genesis ROM.

There's a lovely, concrete reason this matters for Genesis preservation. The very first bytes of a cartridge's readable header spell SEGA in ASCII: $53 $45 $47 $41. Because the 68000 stores them big-endian, dumping the ROM and reading the bytes in address order gives you the letters S E G A in the right order. If you ever open a ROM and see ESAG, you're looking at a byte-swapped dump — a classic sign of a tool that got the endianness wrong, and something Module 12's loaders actively check for.

The lab lets you play both sides. Type a 32-bit value, choose big-endian (the 68000) or little-endian, and watch the four bytes drop into memory. Then read them back as a byte, a word, or a longword — and tap a cell to move where the read starts. Leave it on the default $53454741 and flip the endianness to see SEGA turn into AGES before your eyes.

Crack open a Genesis cartridge and there is startlingly little inside: a small printed circuit board, usually one big mask ROM chip, and a row of gold-plated fingers along the bottom edge. That's often the entire game. There's no processor in the cartridge, no operating system, no drive — the cartridge is pure memory, and the console supplies everything else. Compared to the optical drives and custom silicon of later consoles, a Genesis cart is almost brutally simple, and that simplicity is exactly why it starts a game the instant you flick the power switch: there is nothing to spin up and nothing to load.

The row of fingers is the edge connector: 64 contacts that mate with the slot inside the console. Crucially, those contacts are not some abstract “cartridge protocol” — they are, almost literally, the 68000's own bus brought out to the edge of the board. The address lines, the 16 data lines, the control strobes from Module 02, power and ground: all of it runs to the pins. When you insert a cartridge, you are physically extending the console's memory bus onto the cartridge's ROM chip. The ROM appears in the machine's address space (Module 06 draws exactly where), and the CPU reads it with the same handshake it uses for its own RAM.

What else can live on the board

Most carts are just ROM, but the board has room for more, and the rest of Part II is a tour of the extras:

• Extra ROM + a mapper. Games bigger than the 68000's flat 4 MB cartridge window carry additional ROM plus a small chip that swaps chunks of it into view — bank switching, the subject of Module 09.
• A save chip + battery. RPGs and sports games add battery-backed SRAM (or a serial EEPROM) so your progress survives the power switch — Module 10.
• A passthrough slot. One remarkable cartridge, Sonic & Knuckles, has a second slot on top to accept another cart and combine with it — the lock-on trick of Module 11.

But hold the simple picture in your head first: a board, a ROM, and 64 gold fingers that are the CPU bus itself. Everything else is an addition to that foundation.

The 68000's 24-bit bus gives it one flat 16 MB address space, and the Genesis hardware designers divided that space into regions, each assigned to a different device by the address decoder of Module 03. This layout — the memory map — is the single most important diagram in the whole system, because it tells you what answers when the CPU touches any given address. Learn it and the rest of Part II falls into place.

Here are the landmarks, low addresses first:

• $000000–$3FFFFF — cartridge ROM. The cartridge occupies the bottom 4 MB. The 68000 starts here: the first eight bytes are the reset vectors (initial stack pointer, then the address of the first instruction), so at power-on the CPU literally begins executing out of your cartridge. Larger games reach beyond 4 MB with mappers (Module 09).
• $A00000–$A0FFFF — the Z80 area. The Z80 sound CPU's 8 KB RAM and the sound chips appear here, in a window the 68000 can reach after requesting the Z80's bus.
• $A10000+ — I/O and control. The controller ports and a version register sit at $A10000; Z80 bus-request and reset are at $A11000; and — important later — the mapper/TIME registers at $A130xx and the TMSS register at $A14000.
• $C00000–$C0001F — the VDP. The video chip's data & control ports, the HV counter and the PSG live here.
• $FF0000–$FFFFFF — 68000 work RAM. The console's 64 KB of read/write memory — the only big scratch pad the 68000 owns directly, and where all the game's running state lives.

Mirroring: the same house at many numbers

One subtlety trips up newcomers. The work RAM is only 64 KB, which needs just 16 address bits to cover — but the region reserved for it is far larger. The extra high address bits simply aren't decoded, so the same 64 KB of RAM appears to repeat, over and over, across the whole upper range. This is mirroring: reading $FF0000 and $FF0000 minus 64 KB hits the identical byte. It isn't a bug — it's what naturally happens when you don't bother decoding address lines you don't need, and emulators must reproduce it faithfully because some code relies on it.

The lab is the whole map, live. Type an address or jump to a landmark, and the region that would answer lights up with a plain-English note on which device responds. Poke around the tiny I/O and VDP ranges wedged between the giant ROM and RAM blocks, and land inside the RAM mirror range to see the mirroring note.

Right after the reset vectors, every Genesis ROM carries a fixed header: a 256-byte block, from $000100 to $0001FF, laid out to a standard format so that the console — and, decades later, an emulator — can learn what the cartridge is without running it. It is a little index card glued to the front of the game, and it's remarkably human-readable: much of it is plain ASCII text you can spot in a hex editor at a glance.

The header opens with the string the whole system hangs on: "SEGA MEGA DRIVE " (or "SEGA GENESIS" on some releases), sixteen bytes at $100. Then a copyright and build-date field, the game's title in both a domestic (Japanese) and an overseas form, a serial number, a checksum, a code describing which controllers it supports, the ROM and RAM address ranges from Module 06, an optional SRAM descriptor, and finally a region field. Each field sits at a known offset, so reading the header is just Module 01's game — fetch bytes at fixed addresses and interpret them.

The checksum, and why it's mostly ceremony

Two bytes at $18E hold a checksum: a 16-bit sum of every word of the ROM from $000200 to the end. In principle it's an integrity check — recompute the sum, compare it to the stored value, and a mismatch means a corrupt cartridge. In practice most Genesis games never bother to verify it (a few famously do), so a “wrong” checksum usually runs fine on hardware. It matters more to tooling: ROM utilities recompute and display it, and a handful of games and copy-protection tricks lean on it, which is why emulators and fixers still compute it.

The lab is a live hex dump of a synthetic-but-structurally-real header. Move your cursor over the bytes and each field lights up with its name and a decoded explanation — find the SEGA tag, the title, the region code, the SRAM descriptor and the checksum, and watch the ASCII column on the right spell the text fields out.

The earliest Genesis consoles booted any cartridge that presented a sane reset vector. Later revisions added a gate called TMSS — the Trademark Security System — and its mechanism is delightfully on-the-nose. When the console powers up, its own small boot ROM checks that the cartridge's header contains the "SEGA" string (Module 07), and then requires the game itself to write the ASCII letters ‘SEGA’ to a hardware register at $A14000 early in start-up. Only after that write does the console enable the VDP and let the game display anything. Skip the write and the screen stays blank.

Why so theatrical? The clever part is legal, not technical. Writing the letters “SEGA” and displaying the Sega trademark was something an unlicensed manufacturer couldn't do without reproducing Sega's trademark — turning a trivial technical check into a trademark tripwire. It was less an unbreakable lock and more a “you must show our logo to boot, and if you do, we can sue you for it” trap. Technically it's just a register write; the teeth were in court, not silicon.

Region locking: a separate gate

TMSS is about authenticity; region locking is about geography, and it's a different mechanism. The console has a hardware region (Japan / Americas / Europe), readable by software at the version register in the $A10000 I/O range. Region enforcement can come from two directions: some games check the console's region themselves and refuse to run on a mismatch, and some consoles refuse cartridges whose header region field doesn't include the console's region. There are also PAL/NTSC differences underneath — a European console runs the 68000 slightly slower (~7.60 vs 7.67 MHz) and draws 240 lines instead of 224 — so an out-of-region game might run too fast, too slow, or with a squashed or bordered picture even when it boots. This is why the retro scene is full of region-mod switches: they flip the console's reported region and video standard.

Module 06 gave the cartridge a fixed 4 MB window, $000000–$3FFFFF. For most of the Genesis's life that was plenty. But late, ambitious games — Super Street Fighter II most famously — carried more ROM than 4 MB, and the 68000 simply has no address lines to reach it. You cannot make the window bigger without a wider bus. So instead you make the ROM take turns being visible through the window you have. That trick is bank switching, and the little chip on the cart that arranges it is a mapper.

The idea is exactly the paged version of Module 01. Divide the big physical ROM into equal-sized banks — say 512 KB each. The 4 MB window is divided into slots of the same size. A set of mapper registers records, for each slot, which physical bank currently appears there. When the CPU reads an address in a slot, the mapper looks up that slot's bank number and fetches from the right chunk of the big ROM. Want different data? Write a new bank number to the register, and the bytes visible through that slot change instantly — no data is copied, the mapper just re-points the window.

Two real mappers

• The Sega SSF2 mapper. Used by Super Street Fighter II (a 5 MB game), it divides the window into eight 512 KB slots, with registers around $A130F1–$A130FF selecting which physical 512 KB bank each slot shows. Slot 0 is left fixed to bank 0 so the reset vectors and header always stay put. This is the mapper the lab below models.
• The Sega SRAM mapper. A simpler, extremely common scheme centred on $A130F1: a single register that toggles between mapping cartridge ROM or the cartridge's battery-backed SRAM into a slice of the upper cartridge region. It's less about “more ROM” and more about “let the save chip and the ROM share an address range,” which is Module 10's business.

The lab is a bank-switching playground built on the SSF2 model. On the left is an 8 MB ROM as sixteen 512 KB banks; on the right is the CPU's 4 MB window as eight slots. Pick a slot, choose a bank, and “write the register” — watch the connection re-point and the sweeping CPU-read cursor start returning bytes from a different bank. Slot 0 stays locked to bank 0, because that's where the machine starts every time.

Here's a puzzle the whole course has been circling. The cartridge is ROM — read-only, unchangeable. The console's RAM is writable but forgets on power-off. So where does your Phantasy Star save live, surviving weeks between play sessions? The answer is a third kind of memory added to the board specifically for the job. The commonest is battery-backed SRAM: a small static-RAM chip plus a coin-cell battery. While you play, the console powers the SRAM and the game reads and writes it like any RAM; when you switch off, the battery keeps just that chip alive, sipping a trickle of current, so the bytes persist.

The SRAM lives in the cartridge's address range, and how it appears varies. Often it sits in the upper part of the cartridge space (many games map it around $200000), and on carts using the Sega SRAM mapper from Module 09 it shares an address region with ROM, toggled in and out by writing the mapper register at $A130F1 — write a 1 to expose the save memory, write a 0 to see ROM again. The header's SRAM descriptor (Module 07) is what tells the console and the emulator that a save chip is present, where it lives, and whether it uses only even bytes, only odd, or both.

The other option: serial EEPROM

Some cartridges skip the battery entirely and use a small serial EEPROM instead. An EEPROM is genuinely non-volatile — it keeps its data with no power at all, so there's no battery to die — but it's written through a slow serial protocol (an I²C-style clock-and-data line), a few bits at a time, rather than being mapped as plain RAM. It typically holds far less than an SRAM (a handful of bytes to a couple of kilobytes) and is common in sports and puzzle games that only need to store a little. Emulators have to recognise which scheme a game uses, because “write a byte to this address” and “clock these bits out on a serial line” are completely different jobs — a distinction Module 12 returns to.

The most audacious cartridge Sega ever shipped was Sonic & Knuckles in 1994. Its case has a hinged flap on top hiding a second cartridge slot, and Sega called the trick lock-on technology. Plug another Genesis game into that top slot and the two carts combine. It works because, as Module 05 taught, the edge connector is just the 68000's bus — so S&K's board can pass that bus straight through to the cartridge above it, while its own mapper hardware decides how the two ROMs share the address space below.

What you get depends on which game sits on top, and S&K's hardware has three documented behaviours (the exact mappings below are illustrative):

• Lock on Sonic 3 and the two fuse into Sonic 3 & Knuckles: Sonic 3's ROM maps low at $000000, S&K's own ROM sits above it, and the combined 4 MB behaves as one enormous game that neither cart could hold alone. This was the intended headline act — the two halves of a game split across two release dates.
• Lock on Sonic 2 and you get Knuckles in Sonic 2: S&K overlays its Knuckles character and controls onto Sonic 2 using its own code plus a small patch region.
• Lock on almost anything else and S&K notices it doesn't recognise the cart and unlocks a hidden bonus — the “No Way?” Blue Sphere game — feeding the other cartridge's bytes in as level-generation data, so a different top cart literally makes different levels.

The lab makes S&K the base cartridge and lets you clip different games onto its passthrough. Choose the top cart and watch the combined 68000 address map redraw — which ROM lands at $000000, where S&K's own ROM goes, and what game the combination boots as.

The other expansion edge: Mega-CD & 32X

The cartridge slot wasn't the console's only bus door. The Genesis also exposed an expansion connector that gave add-ons direct access to the same 68000 bus, and two famous ones used it. The Mega-CD (Sega CD) bolted on underneath, bringing a whole second 68000, more RAM and a CD-ROM drive, and claimed a slice of the reserved $400000-ish region. The 32X plugged into the cartridge slot itself, adding two 32-bit SH-2 processors and its own video hardware, and mapped its resources into the upper cartridge/expansion space. Both are proof of the same principle you've followed all course: on the Genesis, everything — a game, a save chip, a passthrough cart, an entire CD-ROM subsystem — ultimately appears as regions on one shared 68000 bus.

To an emulator, a cartridge is its ROM dump: a plain file that is a byte-for-byte copy of the mask ROM's contents, starting at the reset vectors, then the header, then the code and data. You'll see two common extensions. A .bin (or .gen) file is the straightforward dump in the 68000's natural big-endian order. A .md file is a historical oddity from one family of dumpers that stored the ROM byte-swapped (interleaved), so loaders detect and de-interleave it. Both are covered by the endianness lesson of Module 04 — and a byte-swapped ROM is exactly the ESAG-instead-of-SEGA symptom you saw there.

Step one: read the header

The first thing an emulator like Genesis Plus GX or BlastEm does is check offset $100 for the "SEGA" string (Module 07). Finding it confirms the byte order is right (if it sees the swapped form, it de-interleaves and tries again) and unlocks the rest of the header: the title for the UI, the region field to pick a default video standard, the ROM/RAM ranges, and the SRAM descriptor. All of this is Module 01's read-a-byte-at-a- fixed-offset, done in software over the file instead of over silicon.

Step two: detect the mapper and the save

Next the emulator decides how the cartridge behaves. If the ROM is larger than 4 MB, or its serial/known-database entry matches a game that uses one, it enables the right mapper — the SSF2 registers at $A130F1–$A130FF, the Sega SRAM mapper, or one of the unofficial mappers used by certain unlicensed carts. It also reads the SRAM descriptor (or matches a known game) to decide whether to allocate battery-backed SRAM or an EEPROM, and where in the address map to place it. Because a few carts declare this incorrectly or use quirky hardware, accurate emulators keep an internal database keyed on the game's checksum and serial to override the header when needed — the reason those Module 07 fields matter to tooling.

Step three: the save file

When the game writes to its save memory, the emulator captures those bytes and, on exit, writes them to a companion file next to the ROM — conventionally .srm for SRAM saves (and formats like .eep for EEPROM). Load the ROM again and the emulator reads that file back into the emulated save chip, so your progress persists exactly as the coin-cell battery did on real hardware (Module 10) — except it never runs out. Back up the .srm and you've done what a battery replacement does on a real cart, without a soldering iron.

You now know what a Genesis cartridge is, so let's put the knowledge to work. (Menu wording differs between emulators and versions; everything below is described by function, so you can find it whatever it's called.)

• Open a ROM. Point the emulator at a .bin/.md/.gen dump of a cartridge you own. The title, region and any warnings it shows come straight from Module 07's header, parsed live as Module 12 described.
• Watch the region default. Emulators pick NTSC or PAL from the header's region field (Module 08) — and let you override it. Force the “wrong” one and you'll see exactly the speed and picture-size effects that module warned about.
• Find the save file. After you save in-game and quit, look for a .srm next to the ROM — that's your battery-backed SRAM (Module 10), captured to disk. Delete it and your save is gone, just like a dead coin cell.
• Try a big game. Load a >4 MB game like Super Street Fighter II and know that behind the scenes the emulator is servicing the SSF2 mapper's bank registers (Module 09) on every write to $A130Fx.
• Stack a lock-on. Good emulators let you specify Sonic & Knuckles plus a second ROM to reproduce lock-on (Module 11) — try it with Sonic 3, then with something random to unlock Blue Sphere.
• Open the debugger. BlastEm ships a capable debugger and Genesis Plus GX forks expose RAM/VRAM views — poke around $FF0000 work RAM and $C00000 VDP ports (Module 06) and watch the map you learned come alive.

The whole journey, one last time

Here is the entire course as a single chain — worth tracing with your finger, because every link is now a module you've done: