tmc: a decompilation of The Legend of Zelda: The Minish Cap

Rebuilding a game as C source from the binary

tmc is a decompilation project for The Legend of Zelda: The Minish Cap, and the stated purpose is to recreate a source code base for the game from scratch, using information found inside the game along with static and/or dynamic analysis.

That phrase, from scratch, is what distinguishes a decompilation from a port or a reimplementation. The goal is a source tree that compiles back into a byte for byte identical ROM, which means every function has to be reconstructed so that the compiler emits exactly the instructions the original did. That constraint is what forces the project to keep the original data, the original string tables and the original code layout, and it is why the work is measured in progress percentages rather than features.

The game targets the Game Boy Advance, and the primary language of the repository is C. The toolchain files at the root, Toolchain.mk and GBA.mk, along with a linker script named linker.ld, describe how the build targets that hardware.

The project is hosted under the zeldaret organisation, with a website at zelda64.dev, documentation at zeldaret.github.io/tmc and a Discord channel. The README states that this is a work in progress decompilation, and it warns at length about what that means in practice.

Five target ROMs, identified by hash

The project can target five different ROM images, and it identifies each one by a sha1 hash so there is no ambiguity about what the build expects.

sha1: b4bd50e4131b027c334547b4524e2dbbd4227130
sha1: 6c5404a1effb17f481f352181d0f1c61a2765c5d
sha1: cff199b36ff173fb6faf152653d1bccf87c26fb7

Those correspond to the USA release tmc.gba, the Japanese release tmc_jp.gba and the European release tmc_eu.gba. Two more are the demo builds, tmc_demo_usa.gba and tmc_demo_jp.gba, each with its own hash, and all five are linked to their entries in the No-Intro DAT-o-MATIC database.

The hash list is not decoration. A decompilation matches a specific binary, and the same hashes appear as files in the repository root, one .sha1 file per ROM, so the build tooling can check that the copy you are working against is the one the project expects.

The second point is the one to note carefully: the repository does not include any of the assets necessary to build the ROM, and a prior copy of the game is required to extract the needed assets. That is a deliberate line. The project ships the code and the extraction tooling, not the copyrighted material, and the assets directory in the repository holds the structure rather than the original artwork and audio.

The warning about shiftable code is the real limitation

The README opens with a warning block, and it is the most useful paragraph in the project for anyone considering using it.

It says the repository is a work in progress, and while it can be used to make certain changes, it is still constantly evolving. If you use it for modding purposes in its current state, you should be aware that the codebase can drastically change at any time. And some parts of the ROM may not be shiftable yet, so modifying them could be difficult.

Both halves of that are technical facts about this kind of project, and both have consequences.

The first is about churn. A decompilation that is still converging reorganises functions, renames symbols and moves files as it learns more about how the original code was written. A patch written against today's tree may not apply next month, and a mod that depends on a particular address may break when a function is reordered.

The second is about what is still assembly. Until a function is fully understood and reconstructed, it stays as hand written assembly in the asm directory, and a function that still has to sit at a specific address is described as not shiftable, meaning it cannot be moved without changing the layout the game depends on. Editing inside such a function means editing assembly against a reconstructed interface, which is exactly what the warning is telling you is difficult.

The progress badge linked from the README, served from zelda64.dev, is the honest way to judge how far the reconstruction has got.

The build is one Makefile per game version

The root Makefile is small and its structure explains the whole build. The default target is build, and the all target builds every supported variant at once.

all: eu jp usa demo_jp demo_usa
build: GAME_VERSION ?=USA

Each variant has its own target, eu, jp, usa, demo_jp and demo_usa, and each one sets the GAME_VERSION variable before delegating to GBA.mk. There is also a custom target, which builds with GAME_VERSION=USA and CUSTOM=1, which is the entry point for making your own variant rather than a matching one.

custom: tools

The tools are built first, and this is where the non-Rust, non-Make parts come in. The tools target creates a directory, configures the tools subproject with CMake in Release mode into a tools prefix, and then builds and installs it.

tools/bin:
	mkdir -p tools/cmake-build
	cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=tools -S tools -B tools/cmake-build
	cmake --build tools/cmake-build -j --target install

Two more targets matter for a modder. extract_assets runs the asset extraction step, which is where your own copy of the game comes in, and clean and clean-tools remove the build output and the tool binaries separately, so a stale tool build can be discarded without touching the main build tree.

The setup instructions live in a separate INSTALL.md file at the root, and the README does nothing but point at it.

The repository layout shows how far the reconstruction has got

The top level of the repository is a map of the project, and the directory names are the interesting part.

There is an asm directory, which is where the code that has not yet been reconstructed into C lives, and a src directory for the C sources, plus an include directory for headers. The assets directory holds the game assets that get extracted and placed, and there is a translations directory, which is how the Japanese, European and USA builds are kept as separate localisation data rather than as separate source trees. charmap.txt and a constants directory hold the character table and the shared constants, and there are data and sound directories for the game's data tables and audio.

The tooling directory holds the CMake project for the host side tools, and the tools themselves are what perform asset extraction and other chores. A tools directory that is built by CMake rather than shipped as binaries is a deliberate choice: the tools have to match the host, and building them locally avoids that problem.

There is a docs directory and a Doxyfile with a doxygen_config.py, so the project generates its own API documentation. A .devcontainer directory is present for editor set up in a container, a Jenkinsfile drives the continuous integration, a format.sh script with a .clang-format configuration keeps the C sources consistently formatted, and asmdiff.sh is a helper for comparing assembly against the original.

There is also progress.py, a script that reports how far the decompilation has progressed, and a CONTRIBUTING.md at the root for people who want to help.

Community infrastructure and an unstated licence

The decompilation effort is organised around shared tooling and shared status. The build badge points at a Jenkins instance running the TMC master job, and the progress badge is generated from a JSON endpoint hosted on zelda64.dev, which is the shared home of the wider community effort around this and other games. The Discord server, at discord.zelda64.dev, is where most discussion happens, and the README says so directly, pointing people there for help getting started and for questions about other decompilation projects as well.

The contributing section is unusually welcoming about scale. It says all contributions are welcome, that this is a group effort, and that even small contributions can make a difference, and it notes that some tasks do not require much knowledge to get started. For a project that is mostly reverse engineering work, that is the difference between a project that stalls and one that keeps moving, because the remaining work is measured in functions and there are always small ones left.

On licensing, the situation is unusual. The licence field for the repository carries no value, and there is no licence file among the top level entries, which is a visible gap in a project with this much contributed code. There are also no GitHub releases, so the project is consumed from the master branch, and the last push was on 2026-09-27. Anyone planning to reuse the code should ask the project about its terms rather than assume a permissive default, and should also consider the separate question of the game assets, which the repository deliberately does not include.

Editorial conclusion

Adopt tmc if you want to read, study or modify The Legend of Zelda: The Minish Cap at the source level, and if you are prepared to work on a codebase that changes under you and to supply your own copy of the game to extract the assets. Do not adopt it as a stable base for a long-running mod, since the README warns the code can change drastically and that some parts of the ROM are not yet shiftable, which makes editing them difficult. Before the first build, read INSTALL.md, check that your target ROM matches one of the listed sha1 hashes, and remember that the repository ships no assets of its own, so an asset extraction step against your own copy is required before anything links.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. zeldaret/tmc on GitHub