Homebrew is software for a games console written by people outside the console maker's licensed-developer program. No official development kit, no signed contract, no access to Nintendo's tools or documentation — just the machine itself, publicly available knowledge about how it works, and a toolchain built by volunteers. The word covers everything from a scrolling "hello world" demo to full games, media players, emulators and system utilities like Swiss, the Swiss-army-knife launcher that modern GameCube enthusiasts treat as essential equipment.

Draw the line clearly, because the internet often smudges it: homebrew is writing your own software. It is not copying games, and this course has nothing to do with piracy. The disc course's Part II told the story of the GameCube's copy protection from the defender's side; nothing in this course involves circumventing it to copy anything. You'll build programs from your own source code with a toolchain containing no Nintendo code whatsoever, and you'll run them either in an emulator or through hardware paths designed to load unsigned, homemade software. (The usual disclaimer: this is an educational overview, not legal advice, and the details vary by jurisdiction — but "I wrote a program and ran it on hardware I own" is about as clean as the hobby gets.)

How a closed console became programmable

The GameCube launched in 2001 with no intended path for hobbyist code: the console only booted discs pressed in Nintendo's deliberately off-spec format (the disc course explains why yours can't be). The scene's history is the story of finding legitimate entry points. Early on, Phantasy Star Online's online mode — which could download and execute updates over the network — famously became a way to load community code through the broadband adapter. The homebrew that followed built gentler doors: exploitable save files that bootstrap a loader from a memory card, commercial accessories (Datel's Action Replay family shipped its own boot disc that the console accepts), and eventually modern hardware like SD-card adapters for the memory-card slots and serial port. Module 07 walks the current routes in detail.

The second half of the story is the toolchain. Volunteers ported GCC — the free C/C++ compiler — to target the GameCube's PowerPC processor, and wrote libogc, a from-scratch library that talks to the hardware the way Nintendo's SDK does, but with independent code. That work grew into devkitPro, a maintained distribution of console toolchains that today installs with a package manager on all three desktop OSes. It is the reason this course can exist: the tools are free, open, current, and contain no copyrighted Nintendo material.

What you can realistically build

Everything the machine can do is on the table, because homebrew code runs with full control of the hardware — there is no operating system underneath you (a fact Module 11 turns into a superpower). The community has produced 2D and 3D games, ports of Doom-era classics, emulators for older consoles, media software, and serious system tools. Your ceiling is the console's: 485 MHz of Gekko, the Flipper GPU's fixed-function pipeline, 43 MB of total RAM, and the DSP for sound. Those courses taught you the machine as an examiner; this one hands you the keys.

Your computer and the GameCube speak different machine languages. Your laptop's processor executes x86-64 or ARM instructions; the GameCube's Gekko executes 32-bit PowerPC (the CPU course spent fifteen modules on it). A normal compiler produces programs for the machine it runs on. What you need is a cross-compiler: a compiler that runs on your machine but emits code for a different one. This is utterly routine in embedded development — it's how phone apps, router firmware and Mars-rover code get built — and it's the single concept that makes console homebrew possible.

The pieces, by name

The GameCube homebrew toolchain is distributed by devkitPro, the volunteer organisation that maintains cross-toolchains for many consoles. You'll see these names constantly, so meet the cast once, properly:

Every tool in devkitPPC carries the target's name as a prefix: the compiler is powerpc-eabi-gcc, the linker powerpc-eabi-ld, the object inspector powerpc-eabi-objdump. The prefix is your constant reminder that outputs are for the console, not for the machine you're sitting at. When the build system invokes the compiler it also passes Gekko-specific flags — you'll see -mogc -mcpu=750 -meabi -mhard-float in the standard makefiles — telling GCC to schedule code for the 750 core the CPU course described and to use its hardware floating point.

What "no operating system" means for the compiler

The eabi in the target triple means the compiler assumes a bare-metal environment: no Linux, no Windows, no system calls to lean on. So who provides printf, malloc and friends? A compact C library for embedded targets (devkitPPC ships newlib) implements the standard functions, and delegates the hardware-touching parts — "actually put this character somewhere", "give me more heap" — to hooks that libogc fills in. That's why printf in Module 05 can appear on your TV: the C library formats the string, and libogc's console code draws it into video memory. The stack of responsibilities is exactly the next module's subject.

A compiler gives you a language; it gives you nothing to say. On a PC, the operating system provides the verbs — open a window, play a sound, read the gamepad. On the GameCube there is no operating system: after boot, your program is alone with the hardware, and every device is programmed by reading and writing its memory-mapped registers. The other courses showed you several of these register interfaces up close — the disc drive's DI, the DSP's mailboxes, Flipper's command FIFO. You could program them all by hand. You'd just spend a year on plumbing before drawing a triangle.

libogc is the library that does the plumbing. It is the homebrew ecosystem's de-facto standard runtime: a from-scratch, community-written layer that initialises the machine, owns the interrupt handlers, and wraps each hardware subsystem in a sane C API. Its coverage maps almost one-to-one onto this collection's courses:

Above and beside libogc

libogc is deliberately close to the metal — GX_* is barely friendlier than Flipper's own registers (the graphics course is genuinely the manual for it). The ecosystem stacks convenience on top:

• GRRLIB — a much-loved 2D/3D convenience layer over GX: load a PNG, draw it at (x, y), print TTF text. The fastest route from zero to something moving on screen.
• libfat — a FAT filesystem driver, so an SD card in an adapter behaves like fopen("sd:/assets/level1.dat"). Module 10 leans on it.
• Ported middleware — the scene has ported classics of the open-source world (SDL, image and audio decoders, physics libraries), so a surprising amount of desktop C code compiles for the console with minor changes.

One absence to note: Nintendo's actual SDK. Leaked copies of it exist in murky corners, and using them contaminates a project both legally and morally — everything it enables, libogc does cleanly. The scene's healthiest projects are libogc all the way down, and this course follows suit.

The install has the same shape everywhere, because every platform uses the same package manager underneath: (1) get dkp-pacman onto your system, (2) ask it for the GameCube development group, (3) make sure two environment variables point at the result, (4) build an example to prove the chain works, and (5) install Dolphin as your test console. Pick your OS below — the page tries to guess it — and note that installer details drift over time: if anything below disagrees with devkitPro's own getting-started page, trust that page; the shape of the process is what this module teaches.

# already installed the GameCube workload? this is a no-op. otherwise:
$ pacman -S gamecube-dev
# confirm the compiler exists and answers:
$ powerpc-eabi-gcc --version
powerpc-eabi-gcc (devkitPPC release …) …

# pull the whole GameCube kit: compiler, libogc, tools, examples
$ sudo dkp-pacman -S gamecube-dev
# the installer drops the env vars into a profile script; open a NEW
# terminal window, then confirm:
$ echo $DEVKITPRO $DEVKITPPC
/opt/devkitpro /opt/devkitpro/devkitPPC
$ powerpc-eabi-gcc --version

export DEVKITPRO=/opt/devkitpro
export DEVKITPPC=$DEVKITPRO/devkitPPC
export PATH=$DEVKITPPC/bin:$PATH

# 1) install devkitpro-pacman per the wiki (deb package, or repo setup on Arch)
# 2) then:
$ sudo dkp-pacman -S gamecube-dev
# 3) log out/in (or source the profile script it installs), then:
$ echo $DEVKITPRO $DEVKITPPC
/opt/devkitpro /opt/devkitpro/devkitPPC
$ powerpc-eabi-gcc --version

Prove it works — build a real example

Never trust an install you haven't built with. The gamecube-examples package puts working projects under $DEVKITPRO/examples/gamecube/; copy the template out (the examples directory itself may need root to write into) and build it:

$ cp -r $DEVKITPRO/examples/gamecube/template ~/gc-hello
$ cd ~/gc-hello
$ make
template.c
linking ... template.elf
output ... template.dol

Those last two lines are the whole course in miniature — an ELF and a DOL, both of which Module 06 will teach you to read. Last step: install Dolphin (from dolphin-emu.org; it runs on all three OSes) and open the freshly built .dol with it. White text on a black screen — a running GameCube program you built — is the finish line for this module.

Here is the traditional first program, essentially as it appears in the devkitPro template. It looks longer than a PC hello-world because there is no operating system to inherit a screen from — you boot the display. Read it once, then we'll take it apart:

#include <stdio.h>
#include <stdlib.h>
#include <gccore.h>   // libogc's front door

static void *xfb = NULL;          // the external framebuffer
static GXRModeObj *rmode = NULL;  // the video mode we'll run in

int main(int argc, char **argv) {
    VIDEO_Init();                             // wake the Video Interface
    PAD_Init();                               // wake the controller ports

    rmode = VIDEO_GetPreferredMode(NULL);     // 480i/576i/480p — asks the console
    xfb = MEM_K0_TO_K1(SYS_AllocateFramebuffer(rmode));
    console_init(xfb, 20, 20, rmode->fbWidth, rmode->xfbHeight,
                 rmode->fbWidth * VI_DISPLAY_PIX_SZ);

    VIDEO_Configure(rmode);                   // program the VI's registers
    VIDEO_SetNextFramebuffer(xfb);            // scan out THIS buffer
    VIDEO_SetBlack(FALSE);                    // un-blank the screen
    VIDEO_Flush();
    VIDEO_WaitVSync();                        // let one field scan out
    if (rmode->viTVMode & VI_NON_INTERLACE) VIDEO_WaitVSync();

    printf("\x1b[2;0H");                       // cursor to row 2, column 0
    printf("Hello, world!\n");

    while (1) {
        PAD_ScanPads();                       // poll all four ports
        if (PAD_ButtonsDown(0) & PAD_BUTTON_START)
            exit(0);                          // back to the loader
        VIDEO_WaitVSync();                    // the 60 Hz heartbeat
    }
    return 0;
}

Every line is an old friend

If you've read the other courses, this program is a reunion:

• VIDEO_Init / VIDEO_Configure — programming the VI, the scan-out hardware from the graphics course's EFB→XFB→TV chapter. VIDEO_GetPreferredMode asks what the console is set to (NTSC 480i, PAL 576i, progressive if available) so your program works on any region's hardware.
• SYS_AllocateFramebuffer — reserves memory for the XFB, the very buffer the graphics course watched Flipper copy pixels into.
• MEM_K0_TO_K1 — pure CPU course: it converts a normal cached address into its uncached mirror. You write pixels through the uncached window so they land in real RAM immediately, where the VI's DMA can see them — instead of loitering in Gekko's data cache while the TV scans out stale memory.
• console_init — libogc's text console: it hooks printf's output and renders characters straight into the XFB. No GPU involved — which is why hello-world doesn't need a single GX_* call.
• PAD_ScanPads / PAD_ButtonsDown — Module 08's whole subject, previewed in two lines.
• VIDEO_WaitVSync — blocks until the VI finishes the current field. It's the metronome of every console game ever written, and Module 11 builds the entire concept of the frame budget on it.
• exit(0) — on a PC, "return to the OS". Here, "return to whatever loaded me" — Dolphin stops emulation; a hardware loader like Swiss takes the stage back. There's no OS to fall into, only the program that ran you.

The lab below replays that boot sequence on a mock TV: black frame at VIDEO_Init, cursor at console_init, your text at printf, then the vsync loop counting frames at 60 Hz until you press START. Change the message — it's your program now.

Typing make in Module 04 fired a four-stage pipeline. Nothing in it is exotic — it's the standard C build everyone half remembers, plus one console-specific final step:

• Compile. powerpc-eabi-gcc -c turns each .c file into a .o object file of PowerPC machine code with unresolved references ("I call something named VIDEO_Init, wherever that is").
• Link. The linker fuses your objects with crt0 and the libogc libraries, resolves every name to a real address, and lays the program out for the GameCube's memory map: code at the classic load address near the bottom of MEM1. Out comes an ELF — the standard Unix executable format — complete with symbol names and debug info.
• Convert. elf2dol strips everything the console's loaders don't need — symbols, debug data, section names — and writes the minimal format they expect: a DOL.

Keep both outputs. The .elf is your debugging artefact — Dolphin loads it directly and can show you function names in its debugger. The .dol is your shipping artefact — small, loader-friendly, and the thing hardware loaders like Swiss consume.

The DOL format — the game format itself

This is not a homebrew-only format. The disc course showed that every retail disc carries the game's main executable as a DOL, loaded by the apploader at boot. Your homebrew and Wind Waker ship in the same container — one of the tidiest facts in the whole scene.

And it is a gloriously simple container. A DOL is a 256-byte header followed by raw bytes — no compression, no symbols, no relocation, no metadata. The header is just three parallel tables and three scalars, all big-endian 32-bit values: up to 7 code ("text") sections and 11 data sections, each described by a file offset, a RAM load address, and a size; then the BSS address and size; and finally the entry point — the address the loader jumps to when everything is in place. Loading one takes a dozen lines of code: copy each section from file offset to RAM address, zero the BSS range, flush the CPU cache, jump to the entry point. That radical simplicity is why everything — the apploader, Swiss, Dolphin — happily loads DOLs.

The lab below is a real 256-byte header for our hello-world, synthesised by this page. Click each field group to see which bytes it owns and what they mean. (Grey 00 bytes are unused table slots — this little program needs 1 of its 7 text slots and 2 of its 11 data slots.)

Dolphin is your development console. It opens your .dol or .elf directly — no disc image, no ceremony: point it at the file (or drag the file onto it) and your program boots in a window, one second after make finishes. This tight loop is something 2001-era licensed developers would have envied, and it's made possible by everything the other courses' Part IIIs described: Dolphin recreates the VI, the PAD interface, the DSP and the rest faithfully enough that code which behaves in Dolphin almost always behaves on hardware.

• Load the ELF while developing — Dolphin reads its symbols, so the debugger shows main and VIDEO_Init instead of bare addresses. Enable the debugger UI and you get breakpoints, memory view and register state — the CPU course's Part III, now pointed at your code.
• Watch the log. Dolphin's log window surfaces your program's report output (and libogc's complaints) — the humble printf-debugging channel every console dev lives in.
• Map a controller — keyboard or any PC gamepad stands in for a GameCube pad. Module 08's lab shows exactly what your program will read.

Real hardware — the boot routes

Sooner or later you'll want the real thing: actual Flipper output on an actual TV. The console only boots what its IPL approves, so homebrew enters through one of a few well-worn routes — all of them ultimately loading Swiss (or another loader), which then runs DOLs from an SD card. Prices and product names drift; the categories are stable:

Controller input on the GameCube is refreshingly honest. There are no events, no callbacks, no queues. Once per frame you call PAD_ScanPads(), which polls all four ports over the Serial Interface and snapshots the state of every connected pad. Then you ask questions about the snapshot:

• PAD_ButtonsHeld(0) — a 16-bit mask of what is currently down on controller 0 (a level: true every frame the button stays pressed).
• PAD_ButtonsDown(0) — the buttons newly pressed since the last scan (an edge: true for exactly one frame).
• PAD_ButtonsUp(0) — newly released, the other edge.
• PAD_StickX/Y(0), PAD_SubStickX/Y(0) — the main and C sticks as signed values (working range roughly ±100 after libogc's calibration); PAD_TriggerL/R(0) — the analog trigger depth.

Hold and edge is a distinction worth tattooing somewhere: use held for continuous verbs (walking, aiming, charging) and down for discrete ones (jump, confirm, pause). The classic beginner bug — a menu that flickers through five options per tap — is a Held where a Down belonged.

Each button owns one bit of the mask, with names like PAD_BUTTON_A (0x0100), PAD_BUTTON_START (0x1000) and PAD_TRIGGER_Z (0x0010), so tests are single bitwise-ANDs — held & PAD_BUTTON_A — and checking three buttons at once is one OR away. The lab shows the live mask: drive the drawn controller with your keyboard (or plug in any USB gamepad — the browser's Gamepad API stands in for the Serial Interface) and watch bits flip in real time.

Hello-world drew text without touching the GPU, which reveals the first of three roads to the screen. Choose by ambition:

Road 1 in practice — and the format surprise

Poking pixels comes with a twist the graphics course foreshadowed: the XFB does not hold RGB. It holds YUY2 — a luma/chroma format where each pair of horizontally adjacent pixels shares its colour information: four bytes carry two brightness values (Y₀, Y₁) but only one shared pair of chroma values (U, V). Television signals work in luma/chroma, the VI feeds a television, so the framebuffer speaks the TV's language and halves its memory bandwidth in the bargain (your eye is far more forgiving about colour resolution than brightness — the same fact lossy image formats exploit).

The lab lets you feel it: choose two neighbouring pixels' colours and watch them encode into four bytes and decode back. Give the pair similar colours and the round trip is invisible; give them wildly different hues and watch the shared chroma split the difference — a real artefact that real GameCube 2D homebrew deals with (the practical dodge: work in an RGB buffer, convert whole frames, or just let GX do it — roads 2 and 3 handle all of this for you).

Road 2, briefly — GX in one paragraph

A GX frame follows the shape the graphics course drew: allocate a FIFO and call GX_Init; describe your vertex formats; set up the camera and load transform matrices; send vertices between GX_Begin/GX_End; configure TEV stages for materials; then GX_CopyDisp copies the finished EFB into the XFB and you call it a frame. Every one of those nouns has a chapter — and an interactive lab — in the graphics course; there is no better GX manual on the open web than understanding the hardware it drives. The gamecube-examples tree has working GX samples to crib from, and GRRLIB's source is a readable master-class in "how do I make GX do the normal thing".

Sound — the DSP works for you now

The audio course told the story of the DSP's interchangeable ucodes — and homebrew gets its own chapter in it. libogc ships a community-written mixing ucode and two API layers over it: AESND (lean, voice-based) and ASND (a friendlier layer used by ported libraries). Allocate a voice, hand it PCM sample data, set volume and pitch, and the DSP mixes it into the 48 kHz output stream exactly as the audio course described — except now the mix is yours. For music, the scene's tradition is gloriously retro: tracker modules (MOD/XM et al.), tiny files that libogc's modplay decodes on the fly — or stream and decode OGG with ported decoders.

Assets — baked in, or fetched from SD

Your game needs sprites, samples and levels, and a bare-metal program has no filesystem by default. Two idioms cover nearly all homebrew:

• Bake data into the DOL. The devkitPro makefiles convert any file you drop into the project's data/ directory into an object file with generated symbols — your PNG becomes mysprite_png[] and mysprite_png_size, linked straight into a data section (you watched those sections in Module 06's header lab). Zero I/O at runtime, perfect for jam-sized games; the cost is that every asset rides in RAM from boot.
• Read from SD with libfat. One fatInitDefault() and the SD card in your Gecko/SD2SP2 adapter mounts as a drive: fopen("sd:/mygame/level2.dat", "rb") and friends just work. Load what you need when you need it — the same streaming discipline the disc course showed retail games practising, with an SD card standing in for the miniDVD.

Saves — the memory card, like a real game

The CARD_* API speaks to memory cards over the EXI bus: mount, create a file with your game's identity, write your save struct, read it back next boot. Your homebrew's save appears in the console's memory-card manager next to the retail games' — banner icon and all, if you provide one. (Saving to SD via libfat is the lazier road; the memory card is the authentic one.)

Every module so far has been a part; this is the whole. A GameCube game — yours, or any retail game ever pressed — is one loop:

while (1) {
    PAD_ScanPads();      // 1 · snapshot the players' hands
    update_world(dt);    // 2 · physics, AI, rules — pure computation
    draw_world();        // 3 · issue GX commands / write pixels
    VIDEO_WaitVSync();   // 4 · block until the TV finishes the field
}

Step 4 is the one with teeth. The VI delivers a field to the TV every 16.7 ms (NTSC; 20 ms PAL), and VIDEO_WaitVSync() blocks until it has. So the loop runs at exactly 60 Hz — if steps 1–3 fit inside the budget. Spend 10 ms computing, wait 6.7: sixty perfect frames. Spend 17 ms — one millisecond over — and you don't get 59 frames: you miss the vsync, wait for the next one, and drop to 30 Hz. The budget isn't a speed limit you can nudge past; it's a train that leaves the station with or without you.

Two habits make console timing a gift instead of a terror. First, double-buffer: allocate two XFBs and alternate — draw into one while the VI scans the other, then swap at vsync (with a single buffer, the TV can catch you mid-drawing — the tearing artefact the graphics course demonstrated). Second, exploit the machine's determinism. There is no OS, no other process, no thermal throttling, no surprise background update: the same code path costs the same microseconds every single time. If your frame fits today, it fits forever. This is why 2001 games could promise a rock-solid 60 and keep the promise — and Dolphin's Part III chapters showed how much work it takes a modern multitasking PC to imitate that stillness.

The lab makes the budget physical. It's a tiny playable game — move the paddle with ←/→, A/D or the mouse — whose loop presents one frame per vsync, exactly like the code above. The slider adds simulated work to steps 2–3. Push it past the 16.7 ms line and watch the game snap from silk to judder: same game, one millisecond too greedy.

The default answer: ship the DOL

For almost all homebrew, the file you built in Module 06 is the release. Every relevant runner — Dolphin, Swiss, Wii loaders — opens a .dol directly, and users know exactly what to do with one: drop it on the SD card, pick it in the menu. Zip it with a README and a licence, publish it where the scene gathers (the community's homebrew directories, or simply your own repository), and you have shipped GameCube software. If you baked your assets in (Module 10), it's genuinely one file.

The fancy answer: build a disc image

Sometimes you want your project to be a disc: booted by a GC Loader or modchip as if pressed, aware of the disc course's whole apparatus. Recall from that course what a bootable disc actually contains, because now it's a packing list — every item something you must provide:

Community tools assemble all of that into a .gcm/.iso from a directory tree plus your DOL. The result boots in Dolphin like any image, and on hardware through the optical-drive-replacement routes. It's a wonderful capstone exercise — you will never look at a retail disc's innards the same way — but be honest about the audience: for SD-card users, the bare DOL was already perfect.

Release manners

• License it. The scene runs on source: GPL and MIT-family licences dominate, and releasing your source is both the custom and the reason the next generation learns. (You're reading a course that exists because Dolphin and libogc are open.)
• State your targets. "Tested in Dolphin and on NTSC hardware via SD2SP2 + Swiss" is one sentence and saves users an evening. Video modes are the classic gotcha — Module 05's VIDEO_GetPreferredMode pattern covers NTSC/PAL, so keep it.
• Version the ELF away. Ship the DOL; keep the matching ELF archived so you can debug crash reports against the exact build.
• Credit your ingredients. libogc, GRRLIB, any ported decoder — a credits line each. Small scene, long memories, good manners.

Here is the entire course in one chain. Trace it once with your finger; every link is now something you've either studied or built:

When the first module of any course in this collection began, the GameCube was a sealed appliance. Somewhere in the middle it became a diagram. If this course did its job, it is now something better: a target. The 485 MHz CPU whose pipelines you studied executes your opcodes. The TEV stages you toggled in a lab combine your textures. The DSP mixes your voices; the vsync you learned to fear and love paces your loop. There is no layer of the machine left that is someone else's business.

Where to go from here

• Mine the examples. $DEVKITPRO/examples/gamecube/ has a working sample for nearly every subsystem — the fastest way to learn any API is to build its example and start bending it.
• Read great homebrew. Swiss's source is a masterclass in the whole machine; GRRLIB's is the friendliest GX tutorial ever written, disguised as a library.
• Use Dolphin as a microscope. Its debugger, logs and graphics tools (the Part IIIs of this collection) are as good at inspecting your game as anyone else's.
• Join the room. The devkitPro forums/wiki and the GameCube scene's communities have answered every beginner question twice a year for two decades. Ask well: post code, name your toolchain versions.
• Revisit the other courses as manuals. They were written as teardowns — CPU, graphics, audio, disc — but every one of them reads differently now that the hardware is yours to command.

A good first project, if you want one: a one-screen arcade game — paddle, ball, score, one music track, one sound effect, saves its high score to the memory card. It touches every module of this course, fits comfortably in the frame budget, bakes into a single DOL, and it is exactly the kind of thing the scene has cherished for twenty years: proof that the little purple box still says yes to anyone who learns to ask.