Skip to content

Game Boy Advance Static Recompilation — State of the Art

A general survey of static/ahead-of-time recompilation for the Game Boy Advance, independent of any specific game. Companion docs: psx-recomp.md, ps2-recomp.md, ps3-recomp.md, ps4-recomp.md, snes-recomp.md, megadrive-recomp.md, saturn-recomp.md, amiga-recomp.md, arcade-recomp.md, engine-based-porting.md.

CPU architecture: the easiest 32-bit case in the series

Section titled “CPU architecture: the easiest 32-bit case in the series”

The GBA’s CPU is a single ARM7TDMI core (ARMv4T) at 16.78MHz: in-order 32-bit RISC, 16 general-purpose registers, dual ARM (32-bit) and Thumb (16-bit, compressed) instruction encodings selected via the BX interworking branch, a fixed three-stage pipeline, flat 32-bit address space (Copetti’s GBA writeup; gbadev CPU reference). For a recompiler it has no MMU (every address a program computes is the real address), no cache (no cache-coherency question ever arises — the same reason PS1’s single-core R3000A is tractable, see psx-recomp.md), no FPU, and, unlike almost every ARM core that follows it, no coprocessor wired up at all — ARMv4T defines CP0–CP15 coprocessor instruction space, but the GBA doesn’t populate it the way later ARM SoCs use CP15 for MMU control or CP10/11 for VFP.

That’s the sharpest contrast with PS1, this series’ other “easy” case: the R3000A also has no cache-coherency problem, but it does have the GTE (COP2), a fixed-function vector coprocessor a recompiler must still translate. The GBA’s PPU (background/sprite compositor) and sound mixer are real hardware blocks, but exposed purely as memory-mapped I/O registers — ordinary loads and stores, not coprocessor opcodes a lifter has to special-case. Nothing on GBA is comparable to PS2’s VU1, PS3’s SPUs, SNES’s cartridge DSP-1/SuperFX/SA-1 zoo (see snes-recomp.md), or Genesis’s Z80 audio co-CPU (see megadrive-recomp.md). A GBA recompiler’s job is close to the theoretical minimum for this survey: lift one simple instruction stream, model a fixed set of MMIO peripherals like any other device driver — arguably the single most tractable 32-bit platform surveyed, simpler in coprocessor terms than PS1, though the R3000A/GTE pairing is itself no small feat already solved.

The real existing situation: a mature source-decompilation scene

Section titled “The real existing situation: a mature source-decompilation scene”

Unlike most platforms in this series, GBA’s dominant “get the original game running natively and modifiably” story isn’t binary recompilation at all — it’s source-level decompilation, and for the games it covers it’s arguably a stronger result than any recompiler could produce: not lifted/translated code approximating the original, but the literal original C source, reconstructed function-by-function until it recompiles to a byte-identical ROM. This is only possible because the target games were compiled from C in the first place (unlike most hand-assembled SNES titles) and because the community recovered agbcc, a patched build of the actual era-appropriate GCC (named for “AGB,” the GBA’s internal Nintendo codename) whose code-generation quirks modern arm-none-eabi-gcc doesn’t reproduce — without matching the exact original compiler’s output, byte-identical decompilation isn’t achievable at all (background via Jadon Puckett).

The pret community’s flagship results are the Generation III Pokémon decompilations — pokeruby, pokeemerald, pokefirered — all SHA-1-verified byte-identical matches, all under heavy active development in 2026 (pokeemerald and pokefirered both saw commits this week). They anchor a secondary ecosystem: pokeemerald-expansion (772 stars, 20k+ commits) is a widely-used ROM-hacking base built directly on the matching decomp — leverage a lifted/translated recompiler output couldn’t offer nearly as cleanly, since modifying genuine original source beats modifying machine-translated C.

Non-Pokémon GBA decompilation is real and broader than a casual guess suggests, at varying maturity as of mid-2026: Sonic Advance 1 & 2 is an actively maintained decompilation-and-native-port (641 stars); Metroid: Zero Mission, from the Metroid Reverse Engineering Team, sits at 2,718/2,721 functions (99.89%) with all data extracted, though its own README still cautions it isn’t yet a verified match; sibling Metroid Fusion trails at 73.19%; Fire Emblem titles — fireemblem8u (Sacred Stones), fireemblem6j (Binding Blade), fe7_us — are active decompilation/disassembly hybrids at varying completion; Mother 3 already underpins real community patches; and Mario Kart: Super Circuit and Klonoa: Empire of Dreams show the pattern spreading beyond Nintendo. Notably absent: no matching or prominent WIP decompilation for HAL’s Kirby GBA titles as of this writing.

The shared MIPS-decomp toolchain this series already credits for PSX/N64 work (splat, decomp-permuter, asm-differ) has GBA-specific counterparts and forks; decomp.me itself has had ongoing work to formalize agbcc/agbccpp as a supported compiler target (m2c issue #283) — the tooling ecosystem, while GBA-specific in places, isn’t being built from scratch.

Separately from source decompilation, actual ROM-to-native-code static recompilers — the same category as this series’ other *recomp projects — do exist for GBA, in two independent, young efforts. gbarecomp is explicitly “Part of the R.A.I.D. community” (Retro AI Development — the same group behind psxrecomp and SNESRecomp, see snes-recomp.md): it analyzes ARM/Thumb control flow, tracks interworking, and emits sharded C++ against a shared GBA hardware runtime, falling back to an interpreter for anything unresolved. Labeled “experimental,” it has shipped verified builds for 14+ commercial titles, including several of the same Pokémon games pret has separately decompiled from source, plus The Minish Cap, Mario Kart: Super Circuit, Mega Man Zero, WarioWare: Twisted!, and the Dragon Ball Z trilogy — a useful natural experiment, since these titles now have both a from-scratch source reconstruction and an independently lifted binary translation to compare. JRickey/gba-recomp is a separate, solo, AI-assisted project (Ghidra plus LLM-driven function mapping) pursuing a more ambitious “every GBA game, zero interpreter” goal — by its own numbers, roughly 170,000 of an estimated 4.1 million functions mapped after several days of continuous runtime, one game reported fully mapped. It’s meaningfully earlier-stage than gbarecomp; neither claims turnkey, unattended coverage of arbitrary ROMs, and both trail this series’ more proven binary recompilers (SNESRecomp, ps1-recomp) in track record.

mGBA, by Vicki “endrift” Pfau, started in 2013 specifically to beat existing GBA emulators on both speed and accuracy, and is now widely treated as the de facto reference implementation — the correctness oracle GBA tooling of all kinds (decompilation, recompilation, and ordinary play) checks itself against, in the same reference-implementation role RPCS3, PCSX2, and bsnes play for their respective platforms elsewhere in this series (mGBA accuracy writeup).

GBA is a genuine outlier in this survey, but precisely which result is mature matters. Source decompilation for its flagship titles (pokeruby/pokeemerald/pokefirered, Metroid: Zero Mission at 99.89%) is as mature as anything documented in this whole series — verified byte-identical, under continuous active development in 2026, with a large derivative romhacking ecosystem proving the output is genuinely usable rather than a museum piece. That follows directly from the CPU story above: no coprocessor zoo to model per-title (unlike SNES), a single simple core (unlike PS2/PS3), plus the one piece of luck other platforms don’t share — a recovered original compiler (agbcc) that makes exact-match decompilation achievable at all for C-compiled titles.

General binary-level static recompilation, by contrast, is the thin part of the picture: two independent, active-but-early projects (gbarecomp, gba-recomp) exist, comparable in ambition to SNESRecomp or ps1-recomp but earlier in proof, lacking the multi-year track record those have. The takeaway: GBA’s CPU is arguably the easiest surveyed, but the platform’s real maturity advantage comes from source decompilation having a viable path here that most other platforms lack (no recovered compiler for SNES’s hand-assembled titles, no comparable win for PS2/PS3/Saturn), not from binary recompilation being especially far along.