Legend of Mana Decompilation: 100 Percent Matched in Both the US and Japanese Releases

By Indie Kings | October 21, 2026

Updated October 21, 2026: The Legend of Mana decompilation is 100% matched for both the North American and Japanese PlayStation releases, and all 18 binaries of each version are fully linked. The Japanese version builds from the same C sources as the North American one, and the whole project is the work of a single contributor with 1,075 commits.

Image: GitHub repository card for celophi/lom-decomp.

What fully linked means here

Per the repository README, this is a matching decompilation of the PlayStation game Legend of Mana, and both the North American and the Japanese releases are 100% matched. The project reconstructs readable C source code that compiles down to the original MIPS machine code that exists on the disc, byte for byte.

The README defines fully linked precisely, and the definition is stricter than the progress badge. A module is fully linked when two conditions hold. The build has to produce an ELF whose bytes match the original decompressed file, and running the project's compressor on that ELF, stripped to a raw binary, has to reproduce an exact replica of the BIN file as it appears on the disc. The round trip from the original BIN through decompression, C source, compilation, ELF and back through compression to the BIN is bit-identical.

For both versions every module qualifies: the main executable and all 17 overlays. The main executable is not compressed, so for both target files the first condition is the whole check, and the linked ELF converted to a raw binary equals the disc file.

One exception is named in the README's roadmap: the Psy-Q SDK libraries are still linked from the original assembly. The repository layout does carry a reconstructed Psy-Q library source directory alongside that, so the picture is one of a game whose own code is finished and whose SDK libraries are partway there.

Two regions, one source tree

The Japanese release is the more interesting half of the project. The README says the original Japanese release, SLPS-02170, builds from the same source tree as the North American one, and that all 18 of its binaries are fully linked too. The README also notes that a configuration file for routing a file to assembly for the Japanese version only, for example while porting a unit whose code differs, is empty, and the repository's Japanese configuration directory holds no such file.

Only those two regional versions are supported. Other regional releases are not, and the Japanese version's files sit under a separate directory with a version flag on the make command line, while the rest of the build instructions refer to the North American version. The two versions share the source but not the data: the README says that where the code differs between releases the shared C source uses conditional blocks for the Japanese and North American versions, and that symbol names are shared while addresses are not, so each version has its own symbol files.

The round-trip check is worth pausing on, because it is stricter than a normal match. A decompilation normally proves that its source compiles to the retail bytes. This one also proves the compression side, reproducing the exact file on the disc from a rebuilt ELF. The README notes the compressor is, in its own words, honestly really amazing that it is bit identical and kind of extraneous, but cool nonetheless.

The project in numbers

GitHub reports 44 stars, 6 forks and no open issues for the repository, with a single contributor and 1,075 commits on the master branch. The ByteMatch report gives the function and unit counts.

The source tree holds 1,153 entries, of which 1,014 are files and 5 are submodules. The source directory accounts for 642 entries, the tooling for 194, configuration for 105, headers for 99 and documentation for 75. The GitHub language breakdown puts C at 7,648,239 bytes, which is 84.4% of the 9,067,078 bytes in the project, with Python at 1,313,055 bytes, Makefile at 84,674 and BitBake at 11,826.

Every figure above is for one person. The contributor list has a single entry, and the commit count matches it exactly.

The containerised build and the old compilers

Building this project needs Git with submodule support, Docker on Windows and macOS or Docker Engine on Linux, and a legally obtained copy of the game. The README is explicit that you do not need to install the historical PlayStation compilers, the Psy-Q tools, Python packages or a MIPS cross-compiler on your host, because the development container provides them.

The container image is built from the project and carries the compilers, the Psy-Q tooling, MIPS binutils, splat, the assembler tool, the pinned objdiff command line tool and the Python dependencies the project uses. The historical compiler images are built locally from a submodule, four variants of it: GCC 2.8.0 for PlayStation, GCC 2.7.2 in its CDK build, GCC 2.6.0 for PlayStation, and GCC 2.7.2 for PlayStation built with the GNU assembler.

One detail in the README explains why the container exists at all. The repository is mounted into Docker at one path, but historical compilation happens from a staging path on a native Linux filesystem inside the container, because some legacy 32-bit compiler and preprocessor binaries cannot safely stat files on Windows-backed Docker bind mounts and may fail with a value too large for defined data type. The Makefile works around it by copying the required inputs to the staging path and normalising text files to LF line endings before compiling, which is why the README asks you not to bypass the build system and invoke the old compiler directly.

The Makefile has a wide set of targets, and three of them define the project's quality bar. One verifies that the linked main executable equals the disc file, with an alias for the North American target. Another runs that check plus every registered whole-overlay SHA-1 check, and the third verifies the compressor against the 17 original overlay files of the selected version.

Where the project goes next

The README publishes a four-item roadmap with two items already done. The first is 100% matching, which is complete for both versions. The third is the Japanese version, also complete. What remains is the second item, cleanup and documentation, marked in progress, which covers removing decompilation artifacts and documenting functionality.

The fourth item is modding and source port, listed as the future goal, with the intent of building on the reconstructed source to make modding practical and to enable ports to other platforms. The stated motivation for the whole project is to preserve the original game's logic and behaviour for educational research and for potential modding capabilities.

That roadmap is the honest position of a finished decompilation. The bytes match, the work now is making the source readable enough to be useful to someone who was not there when it was written.

What the repository does not contain

The README states that this is a decompilation project, not a PC port, and that the repository does not include the game executable, overlay binaries, artwork, audio or other copyrighted game data. You must provide the required files from your own copy of the game, which means extracting the main executable and the game's BIN directory into the project directory, and the disc directory is gitignored with a note never to commit original game files.

That directory holds the main executable and 17 named BIN files, one for each overlay, named ADDHERO, CARDA, CHECKPS, CLOAD, FIELD, GNAME, GOLEM, GOSUB, GOVER, MENU, MOVIE, NIKI, SHOP, TITLE, WMAP, WSEL and ZUKAN. The README says you do not need to copy the rest of the disc into the repository.

FAQ

What does 100% matched mean for Legend of Mana?
Per the README, the reconstructed C compiles down to the original MIPS machine code byte for byte, and every module, the main executable and all 17 overlays, is fully linked in both the North American and Japanese versions. The Psy-Q SDK libraries are still linked from the original assembly, which the roadmap names as the exception.

Does the Japanese version use different source code?
No. The README says the Japanese release builds from the same source tree as the North American one, and that all 18 of its binaries are fully linked too. A configuration file exists that could route a file to assembly for Japan only, but the README notes it is empty.

What does the round trip through the compressor check?
That a rebuilt ELF can be compressed back into an exact replica of the BIN file as it appears on the disc, so the original BIN to decompress to C source to compile to ELF to compress to BIN is bit-identical. A verification target checks the compressor against the 17 original overlay files of the selected version.

Do I need the old PlayStation compilers installed?
No. The README says the development container provides the historical compilers, the Psy-Q tooling, MIPS binutils and the other tools, and that you do not need to install them on your host. You do need Docker, and the project asks that you never bypass the build system and call the old compiler directly against the mounted files.

Is a PC port planned?
Not yet. The README says plainly that this is a decompilation project and not a PC port. A source port is listed in the roadmap as a future goal alongside making modding practical, with the current in-progress work being cleanup and documentation.

Which regional versions of Legend of Mana are supported?
Only the North American release with the disc serial SLUS-01013 and the Japanese release with the serial SLPS-02170. The README says other regional versions are not currently supported, and the Japanese version's files sit under a separate directory with a version flag on the make command line.

Bottom Line

Legend of Mana is one of the most completely reconstructed PlayStation games in this decompilation's terms. All 5,975 functions match, all 229 units are complete, and both regional releases build from a single source tree, with the shared C source using conditional blocks where the two games differ. The standard for the project is even stricter than a normal match, since the rebuilt ELF has to compress back into an exact replica of the file on the disc. The build hides the hardest part behind Docker, because legacy 32-bit compilers cannot stat files on a Windows bind mount, and the project is candid about the one thing still outstanding, the Psy-Q SDK libraries linked from assembly. What is left is documentation rather than bytes, and the goal that follows is a source port and practical modding. All of it is the work of a single contributor with 1,075 commits.

Sources

• celophi/lom-decomp repository README, including the supported game versions table, the roadmap and the build target reference, accessed October 21, 2026
• Repository metadata, language breakdown, contributor list and commit history via the GitHub API, accessed October 21, 2026
• ByteMatch report for celophi/lom-decomp and the decomp.dev progress pages for SLUS_010.13 and SLPS_021.70, accessed October 21, 2026

Related: 24,515 Functions Later: The 3.3.5a Client Is 90 Percent Decompiled | 7 Unofficial PC Ports Worth Knowing in September 2026 [2026] | 21 Year Old Coder Ports Real PT To PC For Preservation