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.
Genuine binary-level static recompilation
Section titled “Genuine binary-level static recompilation”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.
Reference emulator: mGBA
Section titled “Reference emulator: mGBA”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).
Honest maturity assessment
Section titled “Honest maturity assessment”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.