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 Sega'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" to full games, demos, chiptune players and cartridge utilities. The Genesis is one of the friendliest consoles ever made for this: it never had a serious lockout on cartridges, its hardware is exhaustively documented, and a modern C toolkit — SGDK — makes it approachable in an afternoon.

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. You'll build programs from your own source code with a toolchain containing no Sega code whatsoever, and you'll run them either in an emulator or on a flashcart designed to load your own ROM images. (The usual disclaimer: this is an educational overview, not legal advice, and 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 1988 console stays programmable

The Genesis launched with cartridges as its only medium, and — unlike its rivals — never enforced a strong cryptographic lockout on them. Later models added TMSS, a light trademark check at boot (the reason your ROM header must begin with "SEGA"), but that is a formality any homebrew ROM satisfies for free. So the path for hobbyist code has always been open: build a ROM image, put it on a cartridge you can rewrite, and the console runs it. The scene's real work was the other half — a toolchain. Volunteers ported GCC — the free C/C++ compiler — to target the Genesis's Motorola 68000, and built libraries and asset tools on top. That effort's most polished form is SGDK, the kit this course teaches.

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 10 turns into a superpower). The scene has produced platformers, shmups, puzzle games, RPGs, chiptune demos and hardware test ROMs. Your ceiling is the console's: the 68000 at 7.67 MHz, the Z80 sound coprocessor, the VDP's tile-and-sprite engine, the YM2612 and PSG for sound, and 64 KB of work RAM. Those courses taught you the machine as an examiner; this one hands you the keys.

Your computer and the Genesis speak different machine languages. Your laptop's processor executes x86-64 or ARM instructions; the Genesis's 68000 executes Motorola 68000 machine code (the CPU course spent a long time 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 router firmware and spacecraft code get built — and it's the single concept that makes console homebrew possible.

The pieces, by name

The modern Genesis toolchain is bundled as SGDK — the Sega Genesis Development Kit, an open-source project created and maintained by Stéphane Dallongeville. You'll see these names constantly, so meet the cast once, properly:

Every tool in the toolchain carries the target's name as a prefix: the compiler is m68k-elf-gcc, the linker m68k-elf-ld, the object inspector m68k-elf-objdump. The prefix is your constant reminder that outputs are for the console, not for the machine you're sitting at. SGDK's makefiles pass the 68000-appropriate flags for you (-m68000, size-and-speed optimisation, the right memory layout) — you rarely type them yourself.

What "no operating system" means

The m68k-elf target means the compiler assumes a bare-metal environment: no Linux, no Windows, no system calls to lean on. When the console powers on it reads the 68000 vector table at address 0 of your ROM, loads the stack pointer and jumps to the reset vector — which is SGDK's startup code. That code clears RAM, sets up the VDP, initialises libmd, and then calls your main(). There is no printf to a terminal here; "output" means drawing tiles on the screen, which is exactly what Module 04 does.

SGDK is developed on Windows and ships a ready-made toolchain there, but it runs everywhere — the sanctioned cross-platform route is a Docker image that bundles the exact compiler and tools, so your build is identical on any OS. The shape is always the same: (1) get SGDK, (2) make sure the build can find it, (3) build a sample to prove the chain works, and (4) install BlastEm as your test console. Pick your OS below — the page tries to guess it — and note that details drift over time: if anything here disagrees with SGDK's own README, trust the README; the shape of the process is what this module teaches.

:: point GDK at your unzipped SGDK
$ set GDK=C:\sgdk
:: build the current project with SGDK's bundled make
$ %GDK%\bin\make -f %GDK%\makefile.gen
compiling main.c ...
linking ... rom.out
output ... rom.bin

# from inside your project folder (contains src/ and res/)
$ docker run --rm -v "$PWD":/src sgdk
# ↑ mounts the current folder as /src and runs SGDK's make inside
compiling main.c ...
linking ... rom.out
output ... rom.bin

# 1) build the image once, from the SGDK checkout:
$ git clone https://github.com/Stephane-Dallongeville/SGDK
$ cd SGDK && docker build -t sgdk .
# 2) then, from any project folder:
$ docker run --rm -v "$PWD":/src sgdk
output ... rom.bin

Prove it works — build a sample

Never trust an install you haven't built with. SGDK ships a sample/ tree; copy one out, build it, and you have a rom.bin to open in an emulator:

$ cp -r $GDK/sample/basics/hello-world ~/md-hello
$ cd ~/md-hello
$ make          # (or the docker run line for your OS)
rescomp resources.res ...
compiling main.c ...
output ... out/rom.bin

Last step: install BlastEm (from retrodev.com; it runs on all three OSes) and drag the freshly built rom.bin onto it. Text on screen — a running Genesis program you built — is the finish line for this module.

Here is the traditional first program in SGDK. It is startlingly short, because SGDK's startup code has already booted the machine before your main() runs — cleared RAM, initialised the VDP, loaded a default font into video memory. All that's left for you is to say your line:

#include <genesis.h>   // SGDK's single front-door header

int main() {
    // SGDK already initialised the VDP and uploaded a font.
    // VDP_drawText writes tile indices into plane A's tilemap;
    // (column, row) are in 8x8 tiles, so (10, 12) is near centre.
    VDP_drawText("HELLO, WORLD", 10, 12);

    while (1) {
        SYS_doVBlankProcess();   // wait for vblank; run SGDK's per-frame work
    }
    return 0;
}

Every line is doing something specific

• #include <genesis.h> — SGDK's umbrella header, pulling in the VDP, sprite, input, sound and DMA APIs in one line.
• VDP_drawText — the console has no text mode. This helper looks up each character in the font SGDK uploaded to VRAM, then writes the matching tile index into plane A's tilemap at the (column, row) you gave — in 8×8-tile units, not pixels.
• SYS_doVBlankProcess — blocks until the VDP finishes drawing the frame (the vertical-blank interrupt), then runs SGDK's own per-frame housekeeping: DMA queue flush, sprite list upload, input refresh, sound driver sync. It is the heartbeat Module 10 is built on.

Notice what is absent: no framebuffer, no pixel plotting. The Genesis is a tile machine. The screen is a grid of 8×8 tiles; "drawing text" means choosing which tile sits in which grid cell. Understanding that one fact is most of understanding the VDP, and Module 06 builds on it directly.

The lab below dramatises the first boot on a mock TV: a generic red boot wordmark (a clearly non-Sega stand-in — we ship no copyrighted logo or jingle), then the VDP comes up black, then your text is laid into the tile grid one cell at a time, then the vblank loop counts frames at 60 Hz until you press START. Change the message — it's your program now.

Typing make in Module 03 fired a multi-stage pipeline. Most of it is the standard C build everyone half-remembers, plus two Genesis-specific steps: a resource compiler for your art and music, and a final conversion to a raw cartridge image.

• Compile. m68k-elf-gcc -c turns each .c file into a .o object of 68000 machine code with unresolved references ("I call something named VDP_drawText, wherever that is").
• Resource-compile. rescomp reads your resources.res and converts each listed asset — a PNG tileset, a palette, a tilemap, an XGM track — into a data object with C symbols you can reference by name.
• Link. m68k-elf-ld fuses your objects and the resource objects with SGDK's runtime libmd, resolves every name to an address, and lays the program out for the 68000's memory map — code and data from address 0 upward. Out comes an ELF (rom.out), symbols and all.
• Convert. m68k-elf-objcopy strips the ELF wrapper and writes the raw bytes the console expects: a flat ROM image (rom.bin, sometimes .md). SGDK also fixes up the header — length and checksum — at this point.

Keep both outputs. The rom.out ELF is your debugging artefact — BlastEm and Genesis Plus GX can load its symbols so a debugger shows function names. The rom.bin is your shipping artefact — the exact bytes that go on a cartridge or flashcart.

The ROM header — the cartridge's ID card

A Genesis ROM begins with the 68000 vector table (the first 256 bytes), and immediately after it, at offset 0x100, sits a 256-byte header: the cartridge's ID card. This is not a homebrew invention — every retail cartridge carries the same structure, and TMSS-equipped consoles actually read the first bytes of it at boot. It is plain, mostly human-readable data: the console signature "SEGA MEGA DRIVE", the title in two languages, a serial number, a checksum, which peripherals the game supports, the ROM and RAM address ranges, and the region codes.

Everything in it is big-endian — the 68000 stores the most-significant byte first, the opposite of your x86 laptop. The lab below is a synthetic-but-format-correct header for a homebrew ROM, generated by this page. Click each field group to highlight its bytes (and their ASCII) and read what they mean. SGDK fills most of these in for you from a small config, but knowing the layout is what lets you set a title, declare 6-button support, or add save RAM.

The VDP is the chip you'll spend the most time with, and it thinks entirely in tiles. A tile is an 8×8 pixel block stored at 4 bits per pixel — so each pixel is a number from 0–15, an index into a 16-colour palette line. The VDP holds four palette lines (64 colours on screen), and every tile picks one of them. Colour 0 in a line means "transparent" for sprites and the front plane. That's the whole colour model: 512 possible colours, 64 visible, chosen 16 at a time.

Driving it from SGDK

You rarely poke the VDP's registers by hand — SGDK wraps the common jobs. The pattern is: load a palette, upload a tileset to VRAM, then write tile indices into a plane's tilemap.

// 'logo' is generated by rescomp from an image listed in resources.res
PAL_setPalette(PAL1, logo.palette->data, DMA);      // 16 colours → palette line 1
VDP_drawImageEx(BG_A, &logo,
    TILE_ATTR_FULL(PAL1, 0, 0, 0, TILE_USER_INDEX),
    5, 3, FALSE, TRUE);                    // place it on plane A at cell (5,3)

// scroll plane B slowly for a parallax backdrop
VDP_setHorizontalScroll(BG_B, offset++);

A tile attribute — the value stored per cell in a tilemap — packs four things into 16 bits: the tile's index in VRAM, which of the four palette lines to use, horizontal and vertical flip flags, and a priority bit that lifts the tile in front of higher planes. TILE_ATTR_FULL just builds that word for you. Scrolling is nearly free: the VDP reads scroll offsets from its own memory every frame, and it supports whole-plane, per-8-pixel-cell or even per-scanline horizontal scroll — the last of which, combined with the HBlank interrupt, is how the era's water ripples and gradient skies were made.

Planes are for backgrounds; sprites are for everything that moves independently — the player, enemies, bullets, the cursor. A VDP sprite is a small rectangle of tiles (up to 4×4, i.e. 32×32 pixels) that the hardware draws at any pixel position, over the planes, with its own palette line, flip and priority. The VDP keeps a sprite attribute table in VRAM — a linked list of up to 64 sprites — and composites them every frame.

The limits are real and worth memorising, because they shaped how every Genesis game looks:

Overrun the per-scanline budget and the VDP simply stops drawing the lowest-priority sprites on that line — the notorious sprite flicker. Games hid it by cycling sprite priority each frame so the dropout moved around and read as shimmer rather than disappearance.

Let SGDK do the bookkeeping

Managing the sprite list, uploading the right animation frame's tiles to VRAM at the right moment, and cycling priority by hand is a lot of plumbing. SGDK's sprite engine does it for you: you define a SpriteDefinition (frames, animations, collision boxes) as a resource, then create and move sprites with a few calls.

// 'imgHero' comes from a SPRITE line in resources.res
SPR_init();                                // start the sprite engine
Sprite* hero = SPR_addSprite(&imgHero, 120, 80,
    TILE_ATTR(PAL2, 0, FALSE, FALSE));

while(1) {
    SPR_setPosition(hero, x, y);           // move it this frame
    SPR_setAnim(hero, running ? ANIM_RUN : ANIM_IDLE);
    SPR_update();                          // rebuild the sprite list…
    SYS_doVBlankProcess();                 // …uploaded to VRAM at vblank
}

The engine streams only the current frame's tiles into VRAM (so a big animation doesn't need all its frames resident at once), builds the hardware sprite list from your logical sprites, and hands it to the VDP during vblank. You think in "the hero, at (x, y), running"; it thinks in tiles and list entries.

The Genesis makes sound with two chips, orchestrated by a third processor. The YM2612 is an FM synthesiser — six channels, each built from four operators wired together by one of eight algorithms — responsible for the console's punchy basses, brass and bells. Channel 6 can instead be switched to an 8-bit DAC to play digital drum and voice samples. Alongside it, the PSG (an SN76489) adds three square-wave tones and a noise channel — the chirps, hats and blips. Both are physically closer to the Z80 coprocessor than to the 68000.

That geography is the whole reason sound is easy in SGDK. Feeding FM registers in real time from the 68000 would eat your frame budget. Instead, SGDK ships the XGM driver: a small program that runs on the Z80, reading a pre-logged stream of register writes and pushing them to the YM2612 and PSG on its own schedule. Your 68000 code just says "play this track" or "play this effect" and gets back to the game.

In practice

// 'music' (an XGM track) and 'sfxJump' (a PCM/effect) come from resources.res
XGM_startPlay(music);              // start the FM/PSG music, looping
...
if (JOY_readJoypad(JOY_1) & BUTTON_A)
    XGM_startPlayPCM(sfxJump, 1, SOUND_PCM_CH2);   // fire a sound effect

You list music and effects in resources.res; rescomp converts a .vgm or tracker export into the driver's compact format at build time. From C it's a handful of XGM_* calls. (There is a newer XGM2 driver in recent SGDK with more PCM channels and lower CPU cost; the shape of the API is the same.)

Controller input on the Genesis is refreshingly honest. There are no events, no callbacks, no queues. Once per frame SGDK reads the pads for you; you ask JOY_readJoypad(JOY_1) for a bitmask of what's currently held on controller 1, and test bits with a bitwise AND. Under the hood, that mask comes from the controller port at 0xA10003 in the 68000's address space.

The original 3-button pad has a D-pad and four buttons: A B C and START. Reading it is almost trivial — but the port only exposes six lines at once, so the console reads the pad twice per frame, toggling a select line (TH) to get the D-pad on one read and the buttons on the other.

The 6-button pad adds X Y Z and MODE. It's backward-compatible: read it the simple way and you get A B C START as before. To reach the extra buttons, software toggles the select line several times in quick succession and the pad reveals additional banks — a little handshake SGDK performs for you. Your code just sees more bits set in the same mask. (There's a historical gotcha: MODE was designed partly so a game could detect the 6-button pad, since some older titles mis-read it; if you support 6-button, test it deliberately.)

Each button owns one bit, with SGDK names like BUTTON_A (0x0040), BUTTON_START (0x0080), BUTTON_X (0x0400) and BUTTON_MODE (0x0800). The lab shows the live mask: drive the drawn pad with your keyboard (or plug in any USB gamepad — the browser's Gamepad API stands in for the console's port) and watch bits flip. Toggle between 3- and 6-button to see the extra bank light up.

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

while (1) {
    u16 pad = JOY_readJoypad(JOY_1);   // 1 · snapshot the player's hands
    update_world(pad);                 // 2 · physics, AI, rules — pure computation
    draw_world();                     // 3 · queue VDP writes & sprite updates
    SYS_doVBlankProcess();            // 4 · block until vblank, then flush to VRAM
}

Step 4 is the one with teeth. The VDP scans a full frame to the TV every 16.7 ms (NTSC 60 Hz; 20 ms on PAL 50 Hz), and SYS_doVBlankProcess() blocks until the VBlank interrupt arrives — and only during that brief blanking window is it safe to push a lot of data into VRAM (draw outside it and you fight the beam for the bus). 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 vblank, 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 facts make console timing a gift instead of a terror. First, the VDP double-buffers for you conceptually: you build the next frame's changes during the visible portion and commit them in the vblank window, so the screen never shows a half-updated frame. 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 68000 cycles every single time. If your frame fits today, it fits forever. This is why 1990 games could promise a rock-solid 60 and keep the promise.

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 vblank, 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.

BlastEm is your development console. It opens your rom.bin directly — drag the file onto it, or pass it on the command line — and your program boots in a window a second after make finishes. This tight loop is something 1990-era licensed developers, burning EPROMs to test each build, would have envied.

BlastEm is a good choice for two reasons. It is accuracy-focused: its 68000, VDP and timing models are careful enough that code which behaves in BlastEm almost always behaves on hardware — the opposite of developing against a forgiving emulator and discovering your timing was luck. And it has a built-in debugger: a console where you set breakpoints, step 68000 instructions, inspect registers and memory, and watch VDP state. Point it at the rom.out ELF and it can use your symbols, so you break on update_world rather than a bare address.

• Debug with symbols. Load the ELF; the debugger shows function and variable names — the CPU course's Part III, now aimed at your code.
• Watch the VDP. BlastEm can show plane and VRAM state, so "why is my sprite invisible" becomes a thing you can see, not guess.
• Map a controller. Keyboard or any USB gamepad stands in for a Genesis pad — Module 09's lab is exactly what your ROM reads.

Sooner or later you'll want the real thing: your tiles on a real VDP, through a real CRT. Because the Genesis never locked its cartridge slot, getting there is delightfully simple — no exploits, no soldering for the common path. You need a flashcart: a cartridge with an SD-card slot and rewritable memory that presents your ROM to the console as if it were a mask ROM.

The small gotchas emulators hide

• Region & refresh. A Japanese or US console runs NTSC at 60 Hz; a European one runs PAL at 50 Hz with 240 visible lines instead of 224. If you assumed 60 Hz timing, a PAL machine runs your game ~17% slower. SGDK exposes the detected region; budget and pace against it, and test on the hardware you care about.
• TMSS. Later consoles check the header's "SEGA" signature and require the ROM to write "SEGA" to a register at boot. SGDK's startup does both, so a stock SGDK ROM passes — but it's the reason you can't just dump arbitrary bytes at address 0 and expect a boot.
• Real timing bites. Effects that "worked" in a lenient emulator — squeezing too much into vblank, racing the beam — can glitch on hardware. This is exactly why Module 11 argued for an accurate emulator: the gap between studio and stage should be as small as you can make it.

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 Genesis 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 68000 whose registers you studied executes your opcodes. The VDP planes you toggled in a lab scroll your tiles. The YM2612 plays your music; the vblank 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 samples. SGDK's sample/ tree has a working project for nearly every subsystem — the fastest way to learn an API is to build its example and start bending it.
• Read the source. SGDK is open; libmd's VDP, sprite and sound code is a readable master-class in driving the hardware you studied.
• Use BlastEm as a microscope. Its debugger and VDP views (Module 11) are as good at inspecting your game as anyone else's.
• Join the room. The SGDK community (its GitHub, the Spritesmind forums, and active Discords) has answered every beginner question many times over. Ask well: post code, name your SGDK version.
• Revisit the other courses as manuals. They were written as teardowns — 68000, VDP, audio, Z80 — but each 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 FM music track, one PSG sound effect. It touches every module of this course, fits comfortably in the frame budget, packs into a single rom.bin, and it is exactly the kind of thing the scene has cherished for decades: proof that a 1988 machine still says yes to anyone who learns to ask.