SGDK 2.11: the C toolchain that turned Mega Drive development into ordinary work

What the kit is, and what it asks of you

The README's opening instruction is blunt about prerequisites. SGDK is a free development kit for writing software in C for the Sega Mega Drive, and it assumes you already know C and have at least a basic grasp of the hardware video system. The author goes further, warning that trying to learn the language and the console at the same time is difficult enough to get you nowhere.

That framing is the honest description of the project. It is not an engine, not a level editor, and not a game framework. There is no scene graph, no asset importer, no entity system. The repository root looks like a toolchain project rather than a library one: `build_lib.bat`, `build_adv.bat` and `build_samples.bat` sit next to `common.mk`, `makefile.gen`, `makelib.gen`, a `CMakeLists.txt` and a linker script named `md.ld`. Source lives under `src/`, headers under `inc/`, compiled libraries under `lib/`, and the custom asset tools live in `bin/`.

Around 2,200 stars and 230 forks on MIT terms, it has become the default way to write C for this console. Assembly is possible, the README says, but not necessary, and the hardware that gets abstracted away is exactly the hardware that makes the Mega Drive interesting.

The build chain, from C source to ROM image

The path from source to a bootable image runs through GCC targeting the m68k-elf triple, libgcc, and a handful of Java tools. Windows binaries of the compiler are provided for convenience, while other operating systems require you to install the toolchain yourself. Java is not optional, because the custom tools are Java programs, and the biggest of them is rescomp, the resource compiler.

Rescomp is the piece newcomers underestimate. SGDK leans on resources so heavily that the README points readers at the tool's own text documentation before showing any code, telling them to work out which resource kinds exist and how to declare them. Once that file is understood, the pipeline is straightforward: you declare tilesets, tile maps, sprites, sounds and palettes in a resource file, rescomp converts them, and the C code references the generated symbols.

The sound path has its own tools. Version 2.00 added a new xgm2tool and a new XGM2 resource type, which is what lets music with per-channel effects survive the trip from a tracker to the ROM. The same release renamed the sound drivers, so older tutorials that call the previous names will not compile against a current checkout.

Two licenses, and why the split matters

SGDK distributes its library and its custom tools under MIT. The compiler is a different matter. GCC and libgcc are under the GPL, and anything you build with them, including the SGDK library itself, falls under the GCC runtime library exception. The repository carries both texts: `license.txt` for the MIT side and `COPYING.RUNTIME` for the exception.

This is a well-trodden arrangement for compiler tooling, and it resolves in your favour: you are not distributing GCC when you ship a game, you are distributing your own code and object files linked against an exception. What you cannot do is assume the whole chain is MIT and relicense your game's toolchain assumptions accordingly. For a hobbyist this is invisible. For a studio that audits licenses before a release, having both files sitting at the repository root, rather than hidden in a wiki page, saves an afternoon.

The practical license consequence for the SGDK code itself is simple and unusually generous: you can read it, modify it, and ship it inside a commercial game without attribution obligations beyond the MIT terms.

The samples are the real documentation

The tree carries fifteen sample directories, and they form a curriculum: `basics/`, `sys/`, `snd/`, `fx/`, `bitmap/`, `tiled/`, `joy-test/`, `serial/`, `linkcable/`, `megawifi/`, `flash-save/`, `benchmark/`, `demo/`, `game/`, and `advanced/`. Between them they cover input, audio, the link cable, the serial port, the Wi-Fi adapter, save memory, sprite effects, bitmap modes, and a complete Sonic-style game.

The README calls out one of them specifically. For general usage it points at the Sonic sample as a good demonstration of how functions and resources fit together in a real project, which is the correct advice: a full game shows how a resource declaration, the generated symbol, and the drawing call line up in practice, in a way that isolated snippets cannot.

Two of those directories also answer questions that come up immediately in search. There is no 32X sample and no 32X directory anywhere in the tree, and no Sega CD sample either, so treat any expectation of 32X support as unfounded. Sega CD shows up in the toolchain rather than the sample set: XGMTOOL gained recognition of commands from the RF5C68 and RF5C164 PCM chips, which is what lets Sega CD audio commands in a music file survive conversion.

What version 2.10 changed, and what 2.11 fixed

Release notes for this project are written in a plain, categorized style, and 2.10 is the largest recent one. It updated GCC to version 13.2, removed the Docker files, removed the Visual Studio template, and removed the sjasm and musicg git submodules by fixing their versions inside SGDK itself. It added a VSCode template in place of the Visual Studio one, and set up automated Doxygen documentation generation through a GitHub Action, which is how the online API reference produced from the headers stays current.

The same release is where the tool consolidation happened. musicg sources were integrated directly into xgm2tool, and the notes itemize a run of audio fixes: the maximum frame limit, preservation of special modes and frequencies, key operating packing, a loop point bug, swapped START and STOP PCM commands, and the initial PSG state. RESCOMP picked up array-format support for per-frame sprite animation timing, a new ordering option for tilesets, tile maps and maps, an export option for tilesets, and a special marker that enables optimization for one VDP sprite.

Version 2.11, published a single day after 2.10, is a corrective release: it fixed incorrect naming of the fixed-point maths methods that caused errors when calling F16_computePosition and its Ex variant, and renamed the corresponding point-moving functions to match. A one-day gap between the two tags tells you these are cut from a working branch rather than planned on a calendar.

Windows first, community wrappers for the rest

The README offers binaries for Windows and tells other operating systems to install the toolchain themselves. Rather than pretending that is solved, it lists three routes for Linux and macOS. One is a script from Vojtech Salajka that runs SGDK through Wine. Another is SGDK Helper from tlsa, which works both natively and inside a container. A third option is cut off in the version of the README available here, which is a fair illustration of a general truth: the wiki is the authority on setup.

The removal of the Docker files in 2.10 fits that pattern. The project tested a container setup, decided the maintenance cost was not worth it, and pointed people at community tooling instead. The same release removed the git submodules for sjasm and musicg and pinned those versions in-tree, so a checkout no longer depends on submodule state, which is a real reliability improvement for a toolchain people install once and keep.

The install instructions themselves live on the project wiki rather than in the repository. That is the single most common source of confusion for newcomers, and the README is direct about it: read the wiki for the basics, then go to the Sonic sample for real usage.

Where the edges are, and what fills them

The first boundary is sound. The README is upfront that the bundled drivers may not suit a project, and names three alternatives with distinct designs: MDSDRV for FM and PSG effects plus pitchable PCM, Echo which runs entirely on the Z80 side, and MiniMusic, a small Z80 driver that lives entirely in Z80 RAM and never touches the cartridge slot. That list is more useful than it first appears, because audio is where a homebrew either feels authentic or does not, and swapping the driver is the accepted fix.

The second boundary is asset tooling. SGDK delegates art, maps and music to third-party software, and the README curates the options carefully: Aseprite, Grafx2 and Pro Motion for pixel art, Tiled and LDTK for maps, an online palette quantizer for fitting images to console palette constraints, and Deflemask and Furnace for trackers. Several entries are SGDK-specific rather than general purpose, including 16Tile, a dedicated tile map editor, and a PNG editor built for setting tile palette indices and priority information.

The third boundary is 32X and Sega CD hardware, which the kit does not cover at the library level. So the practical shape of SGDK is: an excellent C toolchain and library for base Mega Drive, an excellent set of samples, a documentation culture that points you at real hardware references rather than at abstractions, and a maintenance model where one maintainer sets the pace and the community fills the edges.

Editorial conclusion

SGDK succeeds because it refuses to be clever. It compiles C for a 68000, ships the library sources with them, converts your PNGs and XM files with tools whose documentation lives in a plain text file you are expected to read, and asks you to understand the video hardware before you start. The costs are equally clear. Release discipline is annual while the branch is not, non-Windows setup is delegated to community wrappers, and the hardware coverage stops well short of what Sega shipped. Pin your version, read rescomp.txt, and learn the VDP.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. Stephane-D/SGDK on GitHub