Pokemon Emerald Decomp: A 2015 Repository Still Builds a Byte Exact ROM

By Indie Kings | October 28, 2026

Updated October 28, 2026: On October 1, 2026, a pull request numbered 2364, titled Report SaveBlock1/SaveBlock2/PokemonStorage usage, was merged into pret/pokeemerald, a repository created on October 5, 2015. Eleven years on, its build output is still pinned to SHA1 f3ae088181bf583e55daf962a92bb46f4f1d07b7, the hash of a retail Pokemon Emerald cartridge dumped by No-Intro, which means a clean build from the repository still reproduces the commercial ROM byte for byte.

Image: a purple Game Boy Advance, the hardware Pokemon Emerald shipped on, via Wikimedia Commons.

The checksum promise

A matching decompilation is a stricter claim than a source port. It means the C files, headers, assembly fragments and asset conversions in the repository compile to the same machine code the original developers shipped, not merely to software that plays the same. The proof lives in the repository twice: rom.sha1 holds the expected hash, and the Makefile carries a compare target that builds the ROM and checks it against that stored value. Makefile comments are blunt about the intent, noting that comparison only makes sense for the non-modern build, because the matching build has to use the compiler the original project used, while the modern build is a convenience for people who want to compile the code with a current toolchain and accept different output.

The compiler in question is agbcc, maintained by the pret group itself, a reconstruction of the old GCC 2.95 era ARM compiler that Nintendo's developers used for Game Boy Advance titles. Building it is a documented first step, and the repository vendors its own copy under tools. The ROM header at the top of the Makefile spells out what is being rebuilt: TITLE POKEMON EMER, GAME_CODE BPEE, MAKER_CODE 01, REVISION 0. There is no ambiguity about which cartridge this project targets. Anyone who runs make with the default settings and gets a matching hash has reproduced a 2004 retail release from a public source tree, which is the entire point of the exercise and also the reason these repositories are treated as reference material by everyone working on GBA software.

Why forks outnumber stars

The repository's counters tell an unusual story: 3,649 stars against 4,894 forks. On GitHub, a fork is usually a passive act, a bookmark of something a developer intends to read later, but in this corner of the site forks are working copies. A matching decompilation of a mainline Pokemon game is the starting point for ROM hacks, difficulty rebalances, randomizers, and the long tail of projects that want to change game logic in C rather than patch assembly by hand. Each fork is a person who intends to modify the code, and the ratio here says the repository is less a museum piece than a workbench.

Contributors reinforce it. GitHub counts 134 people with committed work in the repository, and 84 issues remain open, which is a healthy backlog rather than an abandoned one. The project also sits inside a family: the pret organization hosts parallel repositories for Ruby and Sapphire, FireRed and LeafGreen, and Crystal, and the tooling, naming conventions and directory layouts are deliberately shared between them. That consistency is why a fix merged in Emerald can be ported to Ruby, and why the latest Ruby commit, dated September 29, 2026, is literally a sync of player controller code taken from this repository.

Eleven years of pull requests

The October 1 merge is the kind of unglamorous maintenance that keeps a decompilation usable: it documents how the save blocks and Pokemon storage structures are used, which matters to anyone writing tools that read or modify save files. The number 2364 is also a scale marker, because GitHub numbers pull requests and issues in one shared counter. Very few fan projects push that counter into four digits, and doing so while still accepting external contributions suggests a review pipeline that has survived changes in maintainers, toolchains and GitHub itself. The commit history starts in 2015, before the current wave of decompilation interest, when the practice was still mostly confined to a handful of Nintendo 64 and Game Boy projects.

What that longevity buys is a known baseline. A hack built on a 2015 era tree would be stranded; a hack built on a 2026 tree can rely on years of corrected symbol names, documented structures and tooling fixes. It also buys a public record of how the work was done, which is arguably the more valuable artifact: the project documents, in source form, how a commercial GBA game was assembled, and every one of those numbered changes added a piece of that record. The repository is not news because something dramatic happened this week. It is news because it is still happening, quietly, in a codebase most of its players will never see.

Project card

FAQ

What is pokeemerald?
A community decompilation of Pokemon Emerald that rebuilds the Game Boy Advance game from source code, with the goal of producing a ROM that matches the retail cartridge exactly.

How do I know the build is accurate?
The repository stores the expected SHA1 in rom.sha1 and provides a compare target that hashes the built ROM and checks it against that value. A match means the output is identical to the retail dump.

Why does it use an old compiler?
Because matching the original machine code requires the same code generation the original developers used. agbcc recreates that compiler, and the MODERN build option exists for people who would rather use a current toolchain and do not need an exact match.

Do I need a copy of the game to build it?
The repository carries the graphics, audio and data as editable source assets, so the documented setup is a toolchain install and a make command. The INSTALL file lists build dependencies, not a ROM extraction step.

Can I use it to make a ROM hack?
Yes, and that is why forks outnumber stars. Editing C and rebuilding is far more tractable than patching assembly, and the shared pret conventions mean fixes and tooling carry across the sibling projects.

Is the project finished?
The matching build is the finished part. Maintenance continues because documentation, symbol naming and tooling keep improving, and 84 open issues remain at the time of writing.

Bottom Line

Eleven years is a long time to keep a checksum honest, and the interesting thing about pokeemerald is not that it exists but that it is still being edited by strangers in 2026. The fork count exceeding the star count is the clearest signal of what the repository actually is: a shared workbench for people who want to change a 2004 game at the source level, backed by a verification target that keeps everyone honest about whether the baseline still matches the cartridge. Decompilation projects usually get attention when they finish. This one deserves attention for the quieter achievement of staying correct and open long enough to become infrastructure.

Sources

• GitHub pret/pokeemerald README, rom.sha1, Makefile header and compare target, INSTALL.md dependencies, accessed October 28, 2026
• GitHub API metadata for pret/pokeemerald, stars, forks, contributors, issues and latest commit, accessed October 28, 2026

Related: We Lurk Below Mod: It Lurks Below Gets a Fan Decompilation and Native Port | Metroid Dread: Unofficial PC Port Hits 240 FPS With Widescreen