# Paper Mario Decompilation: C Source for Four N64 ROM Targets

> pmret/papermario is a work-in-progress C decompilation that targets the US, Japanese, PAL, and iQue versions of Paper Mario. It serves reverse engineering and preservation work, but undocumented build prerequisites and an unidentified license restrict wider reuse.

**pmret/papermario** — Decompilation of Paper Mario (Nintendo 64)

- Repository: https://github.com/pmret/papermario
- Website: https://papermar.io
- Stars: 1,637 · Forks: 172
- Language: C
- License: not declared
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/pmret-papermario

## What the Paper Mario decompilation covers

Paper Mario addresses a specific reverse-engineering problem: rebuilding the Nintendo 64 game from C source rather than treating the original release only as compiled machine code. Its audience is narrow. Contributors to decompilation projects, researchers studying game structure, and people involved in software preservation need something different from ordinary game players or teams looking for an engine that can run arbitrary games.

The repository describes itself as a work-in-progress decompilation. That status matters because the README lists four build targets without declaring every target complete. It provides separate progress pages and badges for US, JP, PAL, and iQue. A contributor must consult the page for the intended region instead of assuming that completion in one target applies to all four.

Each target has a SHA1 hash. The US entry identifies `3837f44cda784b466c9a2d99df70d77c322b97a0`, the JP entry identifies `b9cca3ff260b9ff427d981626b82f96de73586d3`, the PAL entry identifies `2111d39265a317414d359e35a7d971c4dfa5f9e1`, and the iQue entry identifies `5c724685085eba796537573dd6f84aaddedc8582`. The README does not explain how Paper Mario applies or verifies these values, so they should be treated as the documented identifiers of its four target ROMs.

The project website, `papermar.io`, hosts progress reporting outside the repository. The README links to `progress-us`, `progress-jp`, `progress-pal`, and `progress-ique`. This separation lets a developer check regional status without interpreting repository files. It also means that repository adoption alone does not provide a static completion declaration: checking the correct target page remains a distinct step.

## The repository layout behind the C build

Based on the repository layout, Paper Mario places implementation code under `src/`, declarations under `include/`, utilities under `tools/`, and target or version information under `ver/`. The root also includes `decomp.yaml`, `configure`, and a `Jenkinsfile`. These entries indicate a configured C build rather than a minimal compiler wrapper, although the README does not describe the internal module boundaries or the complete call graph.

The visible development utilities extend beyond compilation. The repository includes `diff.py`, `diff_evt.py`, `diff_settings.py`, `first_diff.py`, and `progress.py`. Their filenames associate them with comparison, event differences, settings, initial differences, and progress reporting. The README does not define their command-line interfaces, so it would be misleading to invent invocation flags or claim what any one script outputs.

Editor and static-analysis configuration is also visible. Root files include `.clang-format`, `.clang-tidy`, `.clangd`, and `.editorconfig`, while `.vscode/` contains editor-related files. In `pyproject.toml`, Black uses a `line-length` of `120`, excludes `tools/splat/`, and adds `diff.py` through `extend-exclude`. That configuration documents a formatting boundary for parts of the Python tooling. It does not reveal the C compiler version, linker flags, or complete ROM build procedure.

The `Jenkinsfile` and README badge point to the Jenkins job path `papermario/job/main`. This external service is the documented source of the main build badge. The README does not say whether a local build is expected to duplicate Jenkins exactly, whether all regional targets share one job invocation, or how a user selects a target. Those are setup questions rather than details that can safely be inferred from the repository entries.

## Following SETUP.md for a first build

The README does not provide a copy-and-paste installation tutorial. It directs users to `SETUP.md` for repository setup and to `CONTRIBUTING.md` for contribution details. The repository also contains `install_deps.sh` and `install_compilers.sh`, but the README does not quote their contents or state their supported operating systems. The exact installation sequence must therefore come from those project files.

A new user's first documented action is to open `SETUP.md` and follow its instructions in order. The reader should expect that file to define the host prerequisites and toolchain preparation needed before attempting a build. Paper Mario does not publish a release package through GitHub releases, so there is no documented binary release to download in place of following the repository setup.

After completing that setup, the user should identify which of the four target ROMs is intended and consult its linked progress page. The appropriate regional target matters because each version has a distinct hash and a separate progress report. The README also links Jenkins for the `main` build status, giving users a place to compare the documented project build with their local setup.

No build command appears in the README, so this article does not provide an invented `make`, CMake, Docker, or toolchain invocation. Users who require fully reproducible local instructions should read `SETUP.md`, then inspect `configure`, `decomp.yaml`, and the installation scripts as directed there. This documentation gap is a real evaluation constraint for anyone considering the project outside its established contribution workflow.

## Regional targets define Paper Mario's compatibility scope

Paper Mario names four supported build identities: US, JP, PAL, and iQue. The README does not claim that their source, assets, localization, or completion state are identical. Instead, it gives each version its own SHA1 hash and progress URL. A developer interested in the Japanese ROM should follow the JP report rather than treating the US report as evidence about that target.

The separate iQue entry is particularly relevant when scoping a contribution. It has its own hash and progress page, confirming that iQue is tracked as a distinct target in the README. The page does not explain regional gameplay differences, localization coverage, or special compatibility requirements. It should be used for status rather than stretched into claims the project has not documented.

This structure also shapes troubleshooting. Success with one regional target would not establish success with the other three. Although the repository includes comparison and progress utilities, the README does not state whether build errors identify the active region, whether target selection uses an environment variable, or whether users configure the target in another file. Engineers should verify the selector in `SETUP.md` and `decomp.yaml` rather than infer its syntax.

For preservation work, explicit regional targets are useful because the project can report status against known ROM identities. For a team seeking one release-independent source configuration, the same design introduces a constraint: users must account for separate versions and cannot assume that one completed build validates all supported outputs.

## Why source matching differs from ordinary C development

A decompilation has a different success criterion from most C repositories. Compilable source is not necessarily a completed reconstruction when the intended output is a ROM associated with a named target. The presence of `diff.py`, `first_diff.py`, `progress.py`, and target hashes is consistent with source reconstruction, but the README does not state whether matching is byte-for-byte, how mismatches are classified, or what completion condition Jenkins applies.

That distinction affects how engineers should interpret the project. Paper Mario does not present an ordinary library API that can be imported into unrelated software. Its documented result is a build that corresponds to one of the listed regional ROM identities. Code-level reuse may be possible under terms not identified here, but the repository cannot be treated as a standard package until its licensing status is resolved.

The build may also depend on a specific historical toolchain. Root files include `install_compilers.sh` and a `ver/` directory, suggesting that compiler and version handling are part of the setup. The README does not identify compiler versions, an SDK, a container image, or required system packages. Naming any of those would go beyond the documented setup route.

For an engineer unfamiliar with decompilation, reproducibility is the first hurdle. The developer needs the documented toolchain, an intended regional target, and a way to interpret comparison output. Paper Mario supplies source, configuration, utility files, and status infrastructure, but the README leaves the operational details to `SETUP.md` and the repository.

## Paper Mario's limitations, license, and maintenance costs

The clearest limitation is maturity. The README calls Paper Mario a work-in-progress decompilation and sends readers to regional progress pages rather than declaring all four targets complete. There are also no GitHub releases. As a result, there is no documented versioned artifact or release-based upgrade path in the repository metadata, and a user following `main` may receive changes without release notes.

The repository metadata does not identify a license. Neither the README nor `pyproject.toml` states one. This creates a concrete boundary for reuse: public source visibility does not by itself document permission to redistribute generated ROMs or incorporate code elsewhere. This is not a legal conclusion about the project. It means that engineers cannot identify a standard license from the repository information and must resolve usage rights before redistribution.

The repository is not archived, and its last push was on 2026-09-26. That fact supports recent development activity, but it does not guarantee stable releases, compatibility with an existing local setup, or ongoing support for a particular contribution. The documented contribution route is `CONTRIBUTING.md`, and the README links a Discord channel. Neither route promises a support lifecycle.

Maintenance also has an unusual cost for users. Regional status must be checked separately, local setup must follow a separate guide, and no GitHub release history is available. Contributors also operate in a matching-oriented C codebase with comparison and progress tools rather than a conventional versioned SDK. The unknown license is the largest nontechnical constraint, while target-specific setup and incomplete reconstruction are the main engineering costs.

## Comparing decompilation with binary modification or reimplementation

A practical alternative is to modify the original binary. Such a workflow starts with the shipped executable and changes selected code or data for a narrow purpose. It avoids reconstructing all game behavior in readable C, but it offers less source-level control and does not produce Paper Mario's documented C build. It is the wrong approach for a contributor whose objective is source reconstruction, but it can be more direct for a small binary-specific modification.

Another alternative is a source reimplementation for a modern platform. A new implementation may focus on gameplay or portability without requiring its output to match a historical N64 ROM. The trade-off is fidelity. Reimplementation can make independent architectural choices, whereas Paper Mario organizes work around four specific regional targets, their hashes, comparison utilities, and progress reports.

The appropriate choice depends on the requested result. A decompilation contributor needs the Paper Mario repository. Someone who only wants to execute an original file gains little from rebuilding the game from C. A team seeking a portable game implementation may find target matching and N64 tooling unnecessarily restrictive.

Paper Mario is therefore not a general-purpose engine or SDK. It is a title-specific reconstruction effort. That focus makes it relevant to reverse engineering and preservation, while limiting its appeal for unrelated C applications or consumers who need a stable, licensed library interface.

## Conclusion

Paper Mario contributors and preservation researchers should adopt the project when reconstructing one of the four named N64 ROM targets is their objective. General software teams should not treat it as a reusable library because it exposes no library API and the repository identifies no license. Prospective users should first read SETUP.md, inspect the target-specific repository configuration, and confirm what rights apply to their intended use.

## FAQ

### How do I set up pmret/papermario?

The README directs users to `SETUP.md` for repository setup. It does not include the required packages or commands in its published quick-start section.

### Which Paper Mario versions does pmret/papermario target?

The README lists US, JP, PAL, and iQue targets. Each target has a separate SHA1 hash and progress page.

### Can I download a release of pmret/papermario?

The repository has no GitHub releases. The README directs users to `SETUP.md` and links separate progress pages for each regional target.

## Sources

- [Issues](https://github.com/pmret/papermario/issues)
- [pmret/papermario on GitHub](https://github.com/pmret/papermario)
- [Project website](https://papermar.io)
- [README](https://github.com/pmret/papermario/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/pmret-papermario