Let's start with what an optical disc physically is. Take a thin platter of clear plastic (polycarbonate), coat one side with a mirror-thin layer of metal, and seal it under lacquer and a label. The data lives in that metal layer, as a pattern of microscopic dents pressed into it at the factory. Each dent is called a pit; each flat, undented stretch between pits is a land. That's the entire storage medium: billions of tiny pits and lands, far too small to see — a pit on a DVD-class disc is shorter than a bacterium.

To read them, the drive shines a laser — a very narrow, very pure beam of light — up through the clear plastic onto the metal layer, and watches what bounces back with a light sensor called a photodiode (a component whose electrical output rises and falls with how much light lands on it). When the beam sits on a land, the mirror-flat metal reflects it cleanly and the photodiode sees a bright return. When the beam crosses a pit, the reflection drops sharply — the pit's depth is engineered (to around a quarter of the light's wavelength) so that light bouncing off the pit and light bouncing off the surrounding land interfere and largely cancel. Bright, dim, bright, dim: as the disc spins, the photodiode's output becomes an electrical signal that traces the pattern of pits flying under the beam.

From bright-and-dim to bits

Here's the part almost everyone guesses wrong: a pit does not mean 1 and a land does not mean 0. Instead, the drive watches for transitions — the moments where the signal changes, at a pit's leading or trailing edge. Each transition is read as a 1; every steady stretch (staying on a pit, or staying on a land) is a run of 0s. Edges are used because a sharp change is far easier to detect reliably than an absolute brightness level, which drifts with dust, disc tilt and laser ageing.

One more subtlety and the picture is complete. If the data were allowed to produce transitions bunched arbitrarily close together, the pits would have to be impossibly small; and if it allowed enormously long steady runs, the drive would lose count of how many 0s went by — it keeps time with an internal clock that re-synchronises on each edge, like a metronome you have to keep tapping. So the raw data is first re-written through a run-length code that guarantees every transition is followed by at least two 0s but never more than ten — CDs use a scheme called EFM, DVDs a close cousin of it. The result: pits and lands always come in a comfortable range of sizes, easy to press and easy to read.

Why this design is quietly brilliant

Two properties fall out of “reading with light,” and both matter enormously for a games console. First, it's contactless — no wear, ever, no matter how many hours a child leaves the disc spinning. Second, it's surprisingly durable: the laser is focused on the metal layer deep inside the plastic, so a speck of dust or a light scratch on the surface sits far out of focus — blurred into irrelevance, the way a smudge on your glasses doesn't blot out the world. Deeper scratches do get through, and Module 03 is about the mathematics that survives them.

The lab below is a magnified flyover: a strip of track scrolls under a fixed laser spot, and you can watch the reflected-intensity trace and the recovered bitstream being built in real time. Then flip the dust switch to drop a contaminated patch onto the track and watch the bits garble — remember what that looks like, because Module 03 exists to fix it.

Module 01 followed the track as a straight magnified strip. Zoom back out and you'll find it's not a set of concentric rings like the grooves you might imagine — it's one single, continuous spiral, starting near the centre hole and winding outward to the rim, exactly like a vinyl record in reverse. Unrolled, the spiral on a full-size DVD is over ten kilometres long. Neighbouring turns of the spiral sit astonishingly close together — the spacing between them is the track pitch, under a thousandth of a millimetre on DVD-class media.

Starting from the inside matters: every disc, regardless of how full it is, begins its data at the same small radius, and a half-empty disc simply stops partway out. The innermost turns also carry the disc's table-of-contents area — the lead-in — which the drive reads first to learn what it's holding. File that term away; it returns with a twist in Module 08.

The geometry problem

Now spin the disc. Here's the wrinkle: a point near the rim travels a much longer circle per revolution than a point near the hub. Spin at a fixed rate and the track flies under the laser faster at the outer edge than at the inner edge — same revolutions, more millimetres. Two speeds are in play and it pays to name them: angular velocity, how fast the disc turns (measured in RPM, revolutions per minute), and linear velocity, how fast the track itself streams past the laser (metres per second). Since pits are a fixed physical size, linear velocity is what sets the data rate: track passing twice as fast means bits arriving twice as fast.

Every drive designer must pick a side, and the trade-off shapes how the machine behaves:

• CLV — Constant Linear Velocity. Continuously adjust the motor so the track always passes the laser at the same speed: fast RPM at the hub, slow at the rim. You get a perfectly constant data rate — which is why audio CDs, which must feed a DAC at exactly 44,100 samples per second, chose it. The cost: every time the laser jumps to a different radius, the motor must physically speed up or slow down before reading can resume, and motors change speed slowly. CLV drives seek sluggishly.
• CAV — Constant Angular Velocity. Spin at one fixed RPM, always. The motor never needs to change speed, so jumps between radii are as fast as the optics can move — but the data rate now depends on where you are: slowest at the hub, fastest at the rim. Fine for a computer that buffers data anyway, and it makes the outer edge premium real estate — a fact game developers exploited, as you'll see in Modules 05 and 06.

The lab gives you the disc, the head and both strategies. Drag the read head to any radius; in CLV mode watch the platter visibly speed up and slow down to hold the data rate flat, and in CAV mode watch the RPM pin while the data rate climbs as you slide outward.

You saw it yourself in the Module 01 lab: drop a little dust on the track and the recovered bits turn to garbage. Now scale that up. A real disc lives a hard life — fingerprints, scratches from being slid across a carpet, microscopic pressing defects from the factory itself. At the densities involved, a scratch you can barely see can obliterate thousands of bits in a row. And here's the crucial observation about the damage: it is almost never one wrong bit here and one wrong bit there. Physical damage produces bursts — long, contiguous stretches of destroyed data — because a scratch is a physical object lying across a physical track.

So every optical format is designed around a blunt admission: the raw bits are unreliable, and that's fine. The disc deliberately stores more than the data — extra, mathematically-related check information — so the drive can detect damage and reconstruct what was lost. This is error correction, and it's the deepest magic in this whole course.

Parity: the small idea underneath

Start tiny. Suppose you send four numbers, plus a fifth number that is their sum: 3, 7, 2, 5 and the check value 17. If one of the four goes missing — say you receive 3, ?, 2, 5, 17 — you can rebuild it: 17 − 3 − 2 − 5 = 7. One extra number bought you the power to recover any one lost value. That extra number is parity. Add more check values, computed in cleverer ways, and you can recover more losses — the redundancy budget scales.

The industrial-strength version used on CDs and DVDs is the Reed–Solomon code. Without the heavy mathematics, here is its honest shape: data is processed in fixed-size groups of bytes called codewords, and each codeword carries some number of parity bytes — call it 2t of them. Those parity bytes buy a precise, guaranteed budget: the decoder can repair up to t corrupted bytes at unknown positions, or up to 2t erasures — losses whose positions are known, which are twice as cheap to fix (knowing where the damage is does half the work; the drive often does know, because the signal there was obviously mush). Stay inside the budget and the reconstruction is perfect, bit-for-bit. Go one byte over and the codeword is unrecoverable. It's not fuzzy — it's a hard contract.

Interleaving: turning one deep wound into many shallow ones

But wait — a budget of a few dozen bytes per codeword, against a scratch that kills thousands of bits in a row? A burst would blow through any single codeword's budget instantly. The fix is not more parity; it's a change of layout, called interleaving: before writing to disc, the bytes of many codewords are shuffled together, so that consecutive positions on the disc belong to different codewords. A physical gouge still wipes out a long run of disc — but after un-shuffling, that run turns out to be one or two bytes from each of hundreds of codewords. Every codeword takes a small, affordable hit; every codeword stays inside budget; everything is repaired.

Why scratch direction matters

This layout has a famous, testable consequence. A radial scratch — running from the centre toward the rim — crosses each turn of the spiral only briefly: a short burst once per revolution, exactly the pattern interleaving was built to absorb. But a circumferential scratch — running along the track, following the spiral — wipes out an enormous contiguous stretch of one region. Even after de-interleaving, the losses pile up in the same codewords and blow the budget. Same length of scratch, wildly different outcomes. This is why disc-care folklore says to always wipe a disc from the centre outward, never in circles: a cleaning scratch in the radial direction is the survivable kind.

The lab makes you the vandal. Drag across the block grid to scratch it, and watch which codewords survive. Then turn interleaving off and repeat the same scratch — the difference is the whole argument of this module in one gesture. Try a horizontal gouge (along the “track”) versus a vertical one (“radial”) and see the direction effect for yourself.

Everything you've learned so far — pits, the spiral, error correction — was invented for the compact disc in the early 1980s. The DVD, a decade and a half later, changed almost nothing about the ideas. It changed the scale. Three shrinks, multiplied together, are the whole story:

• Smaller pits. The shortest pit on a CD is about 0.83 µm; on a DVD, about 0.4 µm — each pit packs the same information into half the length of track.
• A tighter spiral. The track pitch drops from 1.6 µm to 0.74 µm — more than twice as many turns fit in the same band of disc.
• A sharper laser. You can't just declare pits smaller — the reading spot must shrink too, and a light spot can't be focused smaller than roughly its own wavelength. So the DVD moved from the CD's 780 nm infrared laser to a 650 nm red one, and paired it with tighter focusing optics. Shorter wavelength, smaller spot, smaller readable pits. (The next generation repeated the trick with a 405 nm blue-violet laser — hence “Blu-ray.”)

Multiply the gains — shorter pits, tighter spiral, plus somewhat more efficient coding and error-correction overhead — and a 12 cm disc goes from the CD's ~650 MB to the DVD's 4.7 GB on a single layer. Same plastic, same factory presses, roughly seven times the data.

“1×” is each format's original real-time job — playing music, playing a movie. A “16×” drive just spins proportionally faster. The figures above are the commonly quoted nominal values; real drives vary a little around them.

Sectors: the unit you actually read

One more piece of vocabulary completes Part I, and it's the one you'll use constantly from here on. Software never asks a drive for “bits” or “pits” — it asks for a sector: the disc's addressable block, which on DVD-class data discs carries exactly 2,048 user bytes. On the disc itself each sector is wrapped in overhead you never see: an ID number saying which sector it is (so the drive can confirm it landed where it meant to), a checksum, and the Reed–Solomon parity from Module 03 — on DVD the correction actually spans groups of sixteen sectors protected together, which is interleaving thinking at a larger scale. Roughly one byte in eight on the disc is overhead rather than payload.

And that's the whole optical toolkit: light reads pits, the spiral carries them, error correction makes them trustworthy, and sectors parcel them out 2 KB at a time. Every optical drive ever made is these four ideas. Time to meet a very particular one.

Open a GameCube's lid and you find something that looks like a DVD that shrank in the wash: a disc just 8 cm across — palm-sized, two-thirds the diameter of a normal 12 cm disc — holding roughly 1.46 GB. Technically it's a miniDVD: the same 650 nm-laser, small-pit, tight-spiral technology from Module 04, on a smaller platter. Less area, less spiral, less data — 4.7 GB scales down to about 1.46 GB. The drive that reads it was built by Matsushita (the company behind the Panasonic brand), and it is a proprietary unit through and through: custom mechanism, custom controller, custom firmware, custom disc format. This was not an off-the-shelf DVD drive with a small tray.

Why would anyone do this? Rivals were shipping full-size discs — the PlayStation 2's DVD drive held over three times as much and played movies. Nintendo never published a formal rationale, so treat what follows as the widely-reported reasoning rather than gospel; but three threads come up consistently:

• Piracy scars. During the Nintendo 64 era, Nintendo had watched CD-based rivals suffer rampant, trivial piracy — a stock PC burner could duplicate a PlayStation game. Cartridges had dodged that, at brutal cost-per-megabyte. A custom disc promised the economics of optical media without being writable or even readable by consumer hardware: there was nothing to burn it onto, and (as Module 08 details) a PC drive couldn't even see its contents.
• No DVD licensing. Shipping a standards-compliant DVD player means paying per-unit royalties to the DVD consortium and building in video-playback features Nintendo didn't want. A non-standard format sidestepped the licence entirely — the GameCube pointedly did not play movies. (Matsushita sold its own licensed hybrid, the Panasonic Q, a GameCube in a shiny steel body that did play DVDs — the exception that proves the licensing rule.)
• Speed of the small. On a small platter the read head simply has less distance to travel — the worst-case hop from hub to rim is shorter, so worst-case seeks are quicker. For a games machine, which hops around its disc constantly, snappy seeks matter more than raw capacity.

The drive spins CAV — the fixed-RPM strategy from Module 02 — so its read speed depends on where the head is: commonly quoted figures put it at roughly 2 MB/s near the hub rising to about 3 MB/s at the rim (treat the exact numbers as approximate; they vary by source and measurement). That inner-to-outer gradient is not trivia: it made the outer millimetres of every disc premium real estate, and in the next module's lab you'll watch developers exploit it.

One caution before we open the disc up: capacity discipline was real. 1.46 GB was generous in 2001 and cramped by 2004 — late-generation games shipped on two discs (you may remember swapping mid-game) and compressed their assets hard. Keep that pressure in mind through the next module: the layout you're about to see was drawn by developers fighting for every megabyte and every millisecond.

Pop the mental lid off a game disc and you will not find a general- purpose filesystem like a PC's — no directories being created, no files growing, nothing ever written. A GameCube disc is one big read-only filesystem, laid out once at mastering time and then pressed, identically, a million times. That permanence buys wonderful simplicity: everything can live at a fixed, known offset, and “opening a file” reduces to “read n bytes starting at sector x.” Here's the map, from sector zero outward:

• The boot header — the very first bytes of the disc. It carries the six-character game ID (something like GALE01: game, region, maker), the game's title, a magic number proving this is a GameCube disc, and — crucially — the disc offsets of everything below. The console's boot ROM reads this first.
• The apploader — a small bootstrap program (living at a fixed early offset, 0x2440). The console's ROM doesn't know how to load a game; it knows how to load the apploader, and the apploader — shipped on every disc, built from Nintendo's SDK — does the rest: it copies the main executable off the disc into RAM and jumps to it.
• The main executable — a file in DOL format (the extension is .dol): the game's actual code. It's a refreshingly simple format — a header listing code and data sections, the RAM address each should be copied to, and the entry point to jump to. No dynamic linking, no relocation: the game owns the whole machine.
• The FST — the File String Table, the disc's entire directory in one block: a tree of entries (file or folder), each file entry holding a name (pointing into a shared string table), a disc offset, and a length. When game code asks for audio/theme.adp, the runtime looks the name up in the FST — already sitting in RAM — and issues a raw read at the resulting offset. That's the whole filesystem.
• The files themselves — everything else, gigabyte and a half of textures, models, music, cutscene video, laid out in whatever order the developers chose. And between them…
• Padding and junk — files are aligned to convenient boundaries, and the gaps between them (plus all the unused tail of a not-full disc) aren't zeroed: the mastering tools filled them with pseudo-random junk bytes. Remember this detail — it looks like trivia now, but in Module 10 it turns out to decide how well a dumped disc compresses.

Layout as a performance tool

Because the disc is pressed once and read forever, where a file sits is a designer's decision — and it interacts with both facts you learned about the drive. The CAV gradient means data near the rim streams up to half again as fast as data near the hub, so mastering tools let developers push bandwidth-hungry files (streaming video, big level data) outward. And because seeks cost tens of milliseconds (Module 09 does the arithmetic), files read together were placed together — some games even pressed duplicate copies of small shared files next to each big level, spending cheap capacity to avoid expensive head travel.

The lab below is a full fictional game disc drawn as the spiral it really is. Click a file in the picker and watch the head do real work: slide to the radius, wait for the platter to bring the data around, then read — with a millisecond-by-millisecond breakdown, and the CAV rate difference plainly visible between an inner file and an outer one.

So far the drive has been a black box that “reads sectors.” Time to wire it to the rest of the console. The GameCube's main chip, Flipper, contains a small block of hardware called the DI — the disc interface — and it is the only doorway between the CPU and the drive. The CPU cannot touch the laser, the motor, or a single pit. It can only do one thing: fill in a short form and ring a bell.

The “form” is a handful of memory-mapped registers — special addresses that, when written, poke the DI hardware directly. To read from the disc, the game's runtime:

1. writes a command into the DI's command-buffer registers — an opcode (“read”) plus parameters (which disc offset, how many bytes);
2. writes a main-RAM destination address and a length into the DI's DMA registers;
3. sets the “go” bit in the DI control register — rings the bell;
4. …and walks away. This is the important part: the CPU does not sit there copying bytes.

The drive does the slow physical work — seek, wait, read, error- correct — and streams the resulting sectors back through the DI, which writes them into main RAM by DMA (Direct Memory Access: hardware-to-memory copying with no CPU involvement). When the last byte lands, the DI raises an interrupt — a hardware tap on the CPU's shoulder that runs a completion handler. Between the bell-ring and the tap, the CPU was simulating physics and building graphics frames. Small commands that need only a short answer (a status code, the drive's ID string) skip the DMA and return their reply in an immediate buffer register instead.

The command set

The vocabulary the CPU can put on that ticket rail is small. The exact opcode numbers are an implementation detail (Dolphin's source is the public reference), but the jobs are:

Two details in that diagram deserve a second look, because both return as emulation problems in Part III. First, the lid is an interrupt: opening the cover mid-game fires a DI interrupt, and games genuinely handle it — pausing, showing “the disc cover was opened,” then re-checking the disc and resuming when it closes. Disc-swap in two-disc games is built on this little dance. Second, the drive is a computer: its own controller and firmware handle focus, tracking, spin-up, retries and error correction privately. The CPU never sees a pit or a parity byte — it sees clean 2,048-byte sectors and status codes. Keep both facts warm for Module 08 (where the firmware becomes a battleground) and Module 11 (where Dolphin has to impersonate all of it).

A quick framing note before we start: this module is the history of a twenty-year-old protection scheme, told at the level long documented by the emulation and preservation community. It explains why things were built as they were — it is not a how-to for anything.

Here is the striking, easily-verified fact at the centre of it all: put a GameCube disc in an ordinary PC DVD drive, and the drive cannot read it at all. Not “the files are encrypted” — the drive typically reports no usable disc. Physically it's DVD technology through and through (same laser, same pit scale — Module 05), but the low-level format is deliberately off-spec: the widely-reported account is that the innermost structures a drive reads first — the lead-in from Module 02 — and the low-level sector scrambling don't follow the DVD standard's rules. A standard drive's firmware reads the opening structures, finds gibberish where a table-of-contents should be, and gives up. Nintendo never published the details, so treat the precise mechanism as community inference; the effect — stock drives refuse, and only the console's own Matsushita drive knows the dialect — is beyond doubt.

Two more layers completed the scheme:

• The barcode by the hub. Look at the inner rim of a GameCube disc and you can see a faint ring of marks — a BCA-style barcode (the DVD world's “Burst Cutting Area”), burned into each disc after pressing. It carries a small amount of data the drive can read and is understood to take part in the drive's disc-verification; the specifics of what's checked were never published. The salient property: a home-burned disc has no way to carry it.
• No writable medium existed. Even with a perfect image of a game (Part III is all about legitimate ones), there was nothing to write it onto: no consumer burner produced the non-standard format, and no blank “GameCube discs” existed. The Module 05 key-blank analogy, made literal.

Why the attacks went after the firmware

Now connect this to Module 07's closing thought: the drive is a computer running firmware, and the console trusts what it says. The disc format was effectively unforgeable — so the historical cat-and-mouse, as documented across two decades of emulator and homebrew history, went around the disc entirely and targeted the trusted messenger. Commercial mod-chips of the era attached to the drive's electronics and interfered with its firmware-level conversation, making the drive accept media or report checks as passed when they hadn't. In other words: nobody counterfeited the key — they suborned the doorman. Later, the community found gentler doors for legitimate homebrew: software exploits (famously via crafted save files) that ran code without touching the drive at all, which is the lineage today's homebrew and disc-preservation tools descend from. That preservation path — dumping a disc you own into a file — is exactly where Part III begins.

Time to put numbers on the drive's one great weakness. Reading sequentially is fine — 2 to 3 MB/s of steady flow. The killer is jumping. Every random hop pays a mechanical toll with several parts:

• Command overhead — the DI handshake and the drive's firmware deciding what to do: a millisecond or so.
• Sled move — the whole optical assembly physically slides along its rails to the target radius. Motors and mass: tens of milliseconds for a long hop.
• Settle & re-lock — the servo re-focuses the laser and locks onto the exact spiral turn: a few more milliseconds.
• Rotational latency — the head is at the right radius, but the data you want is somewhere around the circle. On average you wait half a revolution for it to come around.

Hiding the seams

Yet you rarely stared at a loading screen on a GameCube. That's not because the drive was fast — you've just seen it isn't — but because developers became masters of overlap: making sure that whenever the drive was paying its mechanical toll, you were looking at something else.

• Corridors, elevators & airlocks. That suspiciously long hallway between areas, the slow elevator ride, the door that takes two seconds to open — often load-bearing theatre. While you walk it, the game is streaming the next area in behind the scenes. Level designers shaped spaces around the drive's timings.
• Prefetching into ARAM. The console has a second, 16 MB pool of memory called ARAM — officially “audio RAM” (its starring role is in our audio course), but games treated it as a disc cache: stream likely-soon assets into ARAM during quiet moments, then copy them to main RAM in microseconds when actually needed. A software-managed read-ahead.
• Layout, again. Module 06's tricks — group files read together, duplicate small shared files next to each level — exist precisely to convert would-be seeks into sequential reads.
• Early seeks. The DI's seek command (Module 07) lets a game send the head toward data it will want soon, overlapping the sled move with gameplay before issuing the actual read.

The drive plays the music: DTK

One more streaming trick is so elegant it deserves its own heading. The drive can play background music by itself. A game issues the DI's audio-streaming command (Module 07) pointing at a compressed audio file on the disc, and from then on the drive — its own firmware, its own schedule — reads that stream and feeds it, decoded from its ADPCM encoding, straight to the console's audio output, with essentially no CPU involvement. This is DTK (“Disc Track”) audio. It's why music could keep playing seamlessly while the CPU was flat-out mid-load. The stream arrives at 48 kHz and joins the audio mixer's other sources — our audio course picks the story up from exactly that point (its Module 15, “The output path”). The cost: while the drive is busy streaming music, it is a shared, mechanical resource — game and stream take turns, which the layout planners of Module 06 also had to budget for.

In the lab, you are the streaming engine. Data flows from the drive into the buffer and drains out to the game. Trigger a seek — the player just entered a new area — and watch the buffer absorb the stall. Then set the drain faster than the fill, or seek twice in quick succession, and watch the tank run dry: that moment is a loading screen being born.

An emulator has no laser, so the first step of this whole Part is turning a disc you own into a file — dumping it. A dump is beautifully unmysterious: read every sector from first to last (homebrew on a real console is the classic legitimate path, since Module 08 explained why a PC drive can't do it) and concatenate the 2,048-byte payloads. The result is traditionally named GCM or .iso, and because Module 06's filesystem is just offsets, the file is the disc: byte 0x2440 of the file is the apploader, exactly as pressed. Every full dump of a standard GameCube disc is the same size — 1,459,978,240 bytes, about 1.46 GB (1.36 GiB) — whether the game “uses” all of it or not, because the dump includes everything: files, padding, junk and all.

Why a naive zip disappoints

1.46 GB per game adds up, so you compress — and get a nasty surprise: the ratio is often mediocre. The culprit is Module 06's parting detail. The gaps between files, and the unused tail of the disc, are filled with pseudo-random junk. A compressor works by finding patterns — repetition, structure, predictability. Random-looking bytes have none, by construction: to a compressor, junk is incompressible noise, and on a half-full disc there can be hundreds of megabytes of it, passed through at a stubborn ~1:1 while the real game data compresses politely.

Purpose-built formats: GCZ, then RVZ

Dolphin's community answered with formats that understand what they're compressing while staying perfectly lossless — the original image is reconstructible bit-for-bit:

• GCZ — the older format: slice the image into blocks, compress each with a general-purpose algorithm, keep an index so the emulator can jump straight to any block (random access matters — the emulator seeks, too!). Helpful, but it still chews on the junk.
• RVZ — the modern one. Dolphin's developers worked out how the mastering tools' junk generator behaves (it's derived from values like the disc's ID), so RVZ recognises junk regions and stores, in effect, “junk here, these parameters” — kilobytes describing hundreds of megabytes, regenerated exactly on demand. Zero-filled and repeated blocks are deduplicated similarly, and what remains — the actual game data — is compressed with modern algorithms (Zstandard and friends). Typical results are dramatically smaller than a zipped ISO, still byte-exact, still randomly accessible.

Trust, but verify

One last habit separates a preservation-grade dump from a hopeful one. Optical reads can fail silently — a marginal disc, a tired laser, and Module 03's error correction quietly gives up on a sector without your dumping tool noticing anything worse than a retry. The community's answer is verification by hash: compute a cryptographic fingerprint of your dump and compare it against a community database of fingerprints from many people's dumps of the same pressing (the Redump project is the best-known such effort). If your hash matches the consensus, your copy is bit-for-bit identical to everyone else's — about the strongest statement of “this dump is good” you can make. Dolphin can check a loaded image against these databases from its game-properties window (Module 12).

The lab packs a fictional disc three ways. Watch where the bytes go — especially the junk blocks, which sail through the zip untouched but collapse to a sliver of parameters under RVZ.

Here's the naive plan, and it's genuinely tempting: the game writes a read command into the emulated DI (Module 07), we memcpy the bytes out of the RVZ at the right offset, fire the completion interrupt on the next emulated cycle, done. Instant, perfect data. What could be wrong with faster and always correct?

Quite a lot, it turns out. Twenty years of GameCube games were developed against one specific physical drive, and they are shaped by its rhythms in ways both deliberate and accidental:

• Some games race the drive. Module 09 taught developers to overlap work with reads: kick off a read, then spend the “guaranteed” 80 ms doing setup. Some code — through bugs that never mattered on hardware — actually relies on the data not arriving too soon: an instant completion interrupt lands in the middle of the setup and fires callbacks in an order the developers never saw in testing. The game misbehaves — on data that is byte-perfect.
• Some games starve if it's too slow — or too fast in the wrong place: streaming systems tuned to the CAV rate curve (2→3 MB/s across the radius, Module 05) can stutter or desync if fed at one flat rate.
• Status must lie convincingly. Games poll the drive: busy? ready? error? A drive that is never busy is a drive that never existed — polling loops written as “wait until busy clears” can fall straight through, or spin forever, when the emulated status doesn't sequence like the real firmware's.
• The side-channels are load-bearing. The DTK music stream has drive-side state — position, looping, play/pause — that must tick along realistically (and survive savestates). And the lid: two-disc games orchestrate their swap around the cover-open and cover-close interrupts followed by a re-check of the new disc. An emulator's “change disc” menu item must perform that whole theatrical sequence — open, swap, close, interrupt, re-identify — or swap-time code breaks.

How Dolphin plays it

So Dolphin's disc emulation is a small physics act. The DI block is emulated register-for-register; disc reads are served from the image on a separate thread (decompressing RVZ blocks on the fly); and — the heart of it — completion is scheduled, not immediate: the emulator models the drive's behaviour, informed by measurements of real hardware — per-command overheads, head travel related to how far the target is, the CAV read-rate curve rising toward the outer edge, even buffering effects where recently-passed data returns faster (the fine details are tuned in Dolphin's source; treat the exact model as an implementation detail that keeps improving). Accurate disc timing ships enabled by default, because a handful of well-known games simply break without it — and a per-game escape hatch exists for the impatient, which is Module 12's business.

The lab runs the same scripted “load a level” sequence twice, side by side: once with instant reads, once against the modelled drive. It's a deliberately simplified dramatisation — real failures are subtler and rarer — but the shape of the problem is exactly this.

You now know what a disc image is, so let's put the knowledge to work in the emulator. (Menu wording shifts a little between Dolphin versions; everything below is described by function, so you can find it whatever it's currently called.)

• The game list. Point Dolphin at the folders holding your dumps; it accepts raw .iso/.gcm alongside compressed .gcz and .rvz (Module 10) and reads the boot header of each — the ID, title and banner you see in the list are Module 06's header, parsed live.
• Convert. A built-in converter turns raw dumps into RVZ and back — losslessly, as Module 10 promised. Converting your library is the single most practical thing this course can hand you: identical games, a fraction of the disk space.
• Verify. The game's properties window can hash your image and check it against the community databases — Module 10's “trust but verify,” one click away. If a game misbehaves, verifying the dump is always step one.
• Disc-speed emulation. Somewhere in the settings lives the toggle from Module 11 — an option controlling whether reads follow the real drive's timing or complete as fast as possible (it has gone by names like “emulate disc speed” and “speed up disc transfer” across versions). Accurate is the default; the fast path shortens loads in many games and breaks a stubborn few. Now you know exactly why both facts are true.
• Change disc. The disc-swap menu item performs Module 11's full theatrical sequence — cover-open interrupt, new image mounted, cover-close interrupt, re-identification — because two-disc games genuinely watch each step happen.

The whole journey, one last time

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

A good closing exercise: pick a game you know, convert it to RVZ, verify it, then boot it twice — once with accurate disc timing, once with the fast option — and pay attention to loading moments, streaming music, and area transitions. Nine times in ten you'll see nothing but shorter loads; you now know precisely what the tenth time would look like, and why.

The little drive you've spent twelve modules with did not retire when the GameCube did. Its direct descendant went into the Wii: a 12 cm drive from the same lineage, still speaking a proprietary DVD-based dialect — and, in the original models, still perfectly happy to accept an 8 cm GameCube disc, which is how the Wii ran GameCube games with no emulation at all: same drive family, same DI, same dance. The Wii U carried optical media one console further with a high-capacity custom disc, and then the line ended: the Switch went to solid-state cartridges and downloads, and Nintendo has not spun a disc since. Sony and Microsoft kept drives as optional Blu-ray appendages, but by the 2020s the industry's centre of mass had moved decisively to flash storage and downloads — no seeks, no rotational latency, no moving parts. Module 09's entire bag of tricks, obsoleted by silicon.

And be fair to the old machinery: in 2001, the spinning disc was the right answer, by a mile. A pressed disc cost mere cents to manufacture — orders of magnitude cheaper per gigabyte than any solid-state option of the day (N64 cartridges had cost dollars-per-megabyte territory to make; the exact figures varied by chip and volume, but the gap was brutal). The disc is why a GameCube game could afford 1.46 GB of textures, orchestral audio and full-motion video at a $49.99 price point. Every weakness you've studied — the seeks, the buffering, the corridor theatre — was the tax on an overwhelming bargain, and a generation of engineers paid it brilliantly.

If this course did its job, a GameCube start-up now sounds different to you: that whirr is a CAV spin-up, that first pause is the lead-in and boot header being read, the apploader is pulling the DOL into RAM, and somewhere a buffer is already filling ahead of the title screen. The same machine has more stories like this one. The audio course follows the DSP that DTK music flows into; companion courses on the graphics pipeline and the CPU trace the other paths out of that main RAM your sectors just landed in. And when you'd rather build than examine, the homebrew course shows you how to put a DOL of your own on the other end of this journey. Pick a door.