The most recent essay from the team argues that recompilation and decompilation are not competitors but layers of the same preservation strategy. A recomp gets a game running natively now; disassembly annotations then make that output progressively more source-like.
\nThe concrete example is Super Mario World, where 1,937 of the recompiled game's 2,074 functions carry real names from disassembly data. That density is what turns a one-line change into a real mod: the essay demonstrates altering Mario's horizontal movement physics by overriding a single named address.
\nIt also shows where the ceiling is once a game is code instead of a ROM inside an emulator: NES-framework tech demos running 3D skeletal models, 44.1 kHz audio mixing, and particle effects, none of which the original hardware could do. The through-line is that framework improvements compound: every new game exposes an assumption hiding in the shared runtime, and fixing it benefits every other title.
\nRelated: Super Mario World on Super Nintendo.
", "date_published": "2026-08-17T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/generationamiga-prime-hunters", "url": "https://retroportingtoolkit.com/blog/generationamiga-prime-hunters", "title": "Metroid Prime Hunters recomp brings the Nintendo DS classic to PC", "summary": "GenerationAmiga reports on the Metroid Prime Hunters recomp alpha for PC.", "content_html": "Independent coverage from GenerationAmiga, published the day after the v0.3.0-alpha release. This is outside reporting rather than a team post, and it introduces the Metroid Prime Hunters recomp to an audience beyond the recompilation scene.
\nThe article covers the essentials of the release: a native Windows and Linux program rather than an emulator, Prime-style WASD and mouse controls in place of the DS's stylus scheme, adaptive widescreen with known visual bugs still being worked through, and experimental Wiimmfi support for online play. The alpha framing is preserved rather than oversold, which matches how the project describes itself.
\nThe piece is notable as the first press coverage of the Nintendo DS ecosystem, whose underlying framework is still very early pre-alpha even as its one public game consumer reached a playable public alpha.
\nRelated: Metroid Prime Hunters on Nintendo DS.
", "date_published": "2026-08-16T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/video-coverage", "url": "https://retroportingtoolkit.com/blog/video-coverage", "title": "Video coverage: recomps on YouTube", "summary": "Confirmed video coverage of the toolkit's projects.", "content_html": "Independent video coverage of the toolkit's projects, collected in one place. These are creators covering the releases in their own voice, not material produced by the team.
\nVideo Game Esoterica has covered five releases across the SNES, PSX, and DS ecosystems:
\nGamemaster1379 has followed the PSX and DS work from its earliest days:
\nRelated: Tomba! and Mega Man X6 on PlayStation, Mega Man X on Super Nintendo, and Metroid Prime Hunters on Nintendo DS.
", "date_published": "2026-08-16T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/retro-gamer-jp-twisted-metal-4", "url": "https://retroportingtoolkit.com/blog/retro-gamer-jp-twisted-metal-4", "title": "PS1 Twisted Metal 4 comes to PC/Mac/Linux: static recompilation project released on GitHub", "summary": "Japanese outlet retro-gamer.jp covers the independent Twisted Metal 4 recompilation.", "content_html": "Independent coverage from retro-gamer.jp, a Japanese-language outlet; the headline above is translated. This is outside reporting on a community project, not writing from the core team.
\nThe article covers TwistedMetal4 Recompiled, an independent project built on PSXRecomp, and gets the technical pipeline right: MIPS R3000A machine code translated to C and compiled to native x86-64, targeting PC, Mac, and Linux. It highlights the feature that matters most for this particular game: the original 4-player multitap multiplayer is preserved in the native build. Rollback netcode is reported as planned but disabled in the current release.
\nJapanese press picking up an independent PSXRecomp-based project is its own data point: the toolkit's downstream projects are now being covered on their own merits, in markets and languages the team itself does not publish in.
\nRelated: Twisted Metal 4 on PlayStation.
", "date_published": "2026-08-15T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/building-enhancing-recomps", "url": "https://retroportingtoolkit.com/blog/building-enhancing-recomps", "title": "Building & Enhancing Recomps: Ecosystem Updates", "summary": "A cross-ecosystem status report: the shared mod loader, GBARecomp past 6 games, adaptive 21:9, and LLE probing on real hardware.", "content_html": "This wide-angle update covers work spanning nearly every ecosystem at once. The centerpiece is a shared opt-in mod loader that now works across the PSX, SNES, GBA, and Genesis frameworks. Mods apply at runtime, which means the original ROMs are never modified, and an enhancement written against the shared machinery becomes available to every title on that platform.
\nOn the GBA side, GBARecomp had moved past 6 games by this point, including the Dragon Ball Z titles, Mario Kart Super Circuit, WarioWare Twisted!, Mega Man Zero 1-4, and the Shrek GBA Video. Adaptive 21:9 widescreen is shown running in both The Minish Cap and Mega Man Zero, a genuinely wider logical view rather than a stretch.
\nThe post also pulls back the curtain on the research end of the roadmap: low-level emulation work for the original Xbox and PSP, validated by probing softmodded real hardware rather than trusting existing emulators alone. It is the clearest picture yet of how the same methodology scales from an 8-bit console to far more complex machines.
\nRelated: The Minish Cap and Mega Man Zero on Game Boy Advance, plus Original Xbox research.
", "date_published": "2026-08-03T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/notebookcheck-pepsiman", "url": "https://retroportingtoolkit.com/blog/notebookcheck-pepsiman", "title": "A recompiled version of Pepsiman lets you play the PS1 cult classic natively in your browser at 60 FPS", "summary": "Notebookcheck covers the browser-native Pepsiman recompilation built with PSXRecomp.", "content_html": "Independent coverage from Notebookcheck, written by Rahim Amir Noorali. This is outside reporting on a community project, distinct from the team's own posts, and it covers the most unusual PSXRecomp derivative yet: a recompilation of Pepsiman that runs natively in the browser.
\nThe article describes how the community project used PSXRecomp to produce WebAssembly instead of a desktop binary, turning the 1999 PlayStation cult classic into a web app running at 60 FPS with widescreen support. The browser packaging brings browser-native extras: saves in the browser, online leaderboards, and PWA installation for offline play. Compatibility is reported as best on Chromium-based browsers, with known issues elsewhere.
\nAs a demonstration of what static recompilation output can compile to, this is the piece to point at: the same pipeline that produces native executables produced a web target, because the result is portable C rather than an emulator dependency.
\nRelated: Pepsiman on PlayStation.
", "date_published": "2026-07-28T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/recomp-ai-5-months", "url": "https://retroportingtoolkit.com/blog/recomp-ai-5-months", "title": "Recomp + AI: 5 Months Later", "summary": "A retrospective on five months of AI-assisted recompilation, and why 5 to 7 games per ecosystem is the sweet spot.", "content_html": "Five months into the project, this retrospective takes stock of both the games and the tooling. The AI side of the workflow had moved from Claude Opus 4.6 to the newer Fable and Sol models, and the essay reflects on what changed in practice as the models improved underneath the same recompilation pipeline.
\nThe title rosters at this point: on PlayStation, Tomba!, Mega Man X6, and Ape Escape; on Super Nintendo, Super Mario World, Mega Man X, and A Link to the Past. More interesting than the list is the thesis drawn from it: around 5 to 7 games per ecosystem is the diminishing-returns sweet spot. By then the shared runtime has absorbed most of the platform's hard problems, and each additional title teaches the framework less.
\nThe post also frames widescreen as the model cross-title enhancement. Because it lives in the shared layer rather than in any one game, solving it once makes it available to every title an ecosystem supports.
\nRelated: Tomba!, Mega Man X6, and Ape Escape on PlayStation; Super Mario World on Super Nintendo.
", "date_published": "2026-07-19T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/expanding-with-gbarecomp", "url": "https://retroportingtoolkit.com/blog/expanding-with-gbarecomp", "title": "Expanding the *recomp ecosystem with GBARecomp", "summary": "The first 32-bit target: ARM/THUMB interworking, the GBA BIOS as the first bootable binary, and five games booting to playable states.", "content_html": "This post announces GBARecomp, the project's first 32-bit target. The ARM7TDMI brings a challenge none of the earlier consoles had: ARM/THUMB interworking, where the CPU switches between two instruction encodings mid-program and the recompiler has to follow it across the boundary.
\nThe bring-up path is telling. The first binary GBARecomp ever booted was the GBA BIOS itself, and by the time of this announcement five games were booting to playable states. The framework backs its static output with a fallback interpreter plus a JIT that emits native shards, so code the static pass cannot resolve still runs while coverage improves.
\nThe post is also explicit about provenance from day one: the framework requires the user's own legally obtained BIOS and ROMs, and distributes neither. As the fourth-plus ecosystem built on the same playbook, GBARecomp is the strongest evidence to that point that the approach generalizes across architectures rather than being a MIPS or 6502 trick.
\nRelated: Game Boy Advance, including The Minish Cap and Mega Man Zero.
", "date_published": "2026-06-24T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/megaman-x-release", "url": "https://retroportingtoolkit.com/blog/megaman-x-release", "title": "Megaman X: Recompiled Release", "summary": "SNESRecomp's second fully playable game, and the first recompiled without an explicit disassembly as reference.", "content_html": "This release post marks a milestone for the SNES ecosystem: Mega Man X becomes SNESRecomp's second fully playable game, completable start to finish as a native executable.
\nThe technical significance is in how it got there. Super Mario World, the framework's first title, leaned on an extensively documented disassembly. Mega Man X is the first game recompiled without an explicit disassembly as reference, which meant the toolchain had to stand on its own analysis rather than borrowing structure from years of community reverse engineering. Clearing that bar suggested the pipeline could reach games that nobody has ever picked apart by hand.
\nAs with every release in the ecosystem, the build ships without game data: players supply their own US ROM, and the recompiled runtime does the rest.
\nRelated: Mega Man X on Super Nintendo.
", "date_published": "2026-05-29T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/journey-with-ai-and-recompilation", "url": "https://retroportingtoolkit.com/blog/journey-with-ai-and-recompilation", "title": "NES, SNES, Genesis, VirtualBoy, and PSX | A journey with AI and Recompilation", "summary": "The big-picture recap: five static recompilers in four months, each with at least one commercial game running.", "content_html": "This is the essay to read first if you want the whole arc in one place. It recaps how five static recompilers, covering the NES, SNES, Genesis, Virtual Boy, and PlayStation, came together in four months, each with at least one commercial game running natively.
\nThe scoreboard at time of writing: NESRecomp had reached 10 supported commercial titles, and PSXRecomp was booting the full PlayStation system BIOS, complete with working memory-card management, rather than shortcutting past it with high-level emulation. Those two data points bracket the range of the approach, from an 8-bit console with well-studied disassemblies to a 32-bit machine whose kernel itself gets recompiled.
\nThe essay is also candid about method: Claude Code became the primary development tool after October 2025, and the post walks through what a human-plus-agent workflow looks like when the output has to be verified against real hardware behavior rather than taken on faith.
\nRelated: NES, Super Nintendo, Sega Genesis, Virtual Boy, and PlayStation.
", "date_published": "2026-05-21T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/nesrecomp-10-titles", "url": "https://retroportingtoolkit.com/blog/nesrecomp-10-titles", "title": "nesrecomp Achieves 10 Commercial Titles", "summary": "Ten NES games across four mappers, one shared runner, and early recomp-to-decomp prototyping for Super Mario Bros.", "content_html": "Two months after its first public milestone, the NES ecosystem hits double digits: 10 commercial titles supported, spanning the NROM, MMC1, MMC3, and GxROM mappers. The pipeline translates 6502 assembly to C ahead of time, and every game runs on a single shared runner rather than a per-game fork.
\nThe post explains the selection strategy behind the roster: games with good public disassemblies were prioritized, because existing annotation makes verification faster and the recompiled output more legible. That choice foreshadows the ecosystem's later direction, and the article already includes early prototyping of a recomp-to-decomp source-port path for Super Mario Bros., treating the recompiled C as a starting point for something progressively closer to source.
\nTen titles on one runner is also the strongest argument in the post: mapper support, rendering, and input all live in shared code, so each new game is mostly a translation problem rather than a porting project.
\nRelated: Super Mario Bros., The Legend of Zelda, and Metroid on NES.
", "date_published": "2026-05-21T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/psxrecomp-bios-tomba", "url": "https://retroportingtoolkit.com/blog/psxrecomp-bios-tomba", "title": "psxrecomp Overhauled. Now BIOS + Tomba", "summary": "The PSX recompiler starts booting the real SCPH1001 BIOS as its kernel, with Tomba! reasonably playable on top.", "content_html": "This post documents the overhaul that defined PSXRecomp's architecture: instead of faking the PlayStation's operating system with high-level stubs, the recompiler statically recompiles the SCPH1001 BIOS itself and uses it as the kernel. The real boot sequence, disc detection, and memory-card management all run as native code.
\nOn top of that foundation, Tomba! is described as reasonably playable: BIOS boot, disc detection, FMV playback, memory cards, and gameplay all working. The post is equally clear about what does not work yet, with an honest caveat about functions the game loads into RAM at runtime, which the static pass cannot see ahead of time and calls \"dirty RAM\" code.
\nThe roadmap laid out here, multi-disc support, streamed music, and widescreen, reads in hindsight like a checklist the ecosystem then spent the following months completing.
\nRelated: Tomba! on PlayStation.
", "date_published": "2026-05-21T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/snesrecomp-super-mario-world", "url": "https://retroportingtoolkit.com/blog/snesrecomp-super-mario-world", "title": "snesrecomp's First Title: Super Mario World", "summary": "Why the 65816 is hard to recompile, and how the attract demo became the validation harness for Super Mario World.", "content_html": "The SNES ecosystem's debut post explains why the platform resisted longer than the others: the 65816's registers can switch between 8-bit and 16-bit widths at runtime, so the meaning of an instruction depends on processor state that static analysis has to track rather than assume. That single architectural quirk makes SNES recompilation substantially harder than the 6502 or 68000 work that preceded it.
\nSuper Mario World was chosen as the first title because of its documentation, and the development story centers on an unusual validation strategy: 80 to 90 percent of the cycle was spent getting the attract-mode demo to play back correctly, since a deterministic demo that diverges from real hardware pinpoints exactly where the recompiled code went wrong. The last blockers before release were overworld rendering and the Iggy Koopa boss fight.
\nThe result was the framework's proof that even the awkward 65816 fits the recompilation playbook, and Super Mario World went on to become the ecosystem's flagship title.
\nRelated: Super Mario World on Super Nintendo.
", "date_published": "2026-05-21T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/virtualboy-mario-tennis", "url": "https://retroportingtoolkit.com/blog/virtualboy-mario-tennis", "title": "VirtualBoy Recomp Gets Its First Title: Mario Tennis", "summary": "The Virtual Boy joins the ecosystem with Mario's Tennis, chosen for the system's simplicity despite no public disassemblies.", "content_html": "This post announces the Virtual Boy recompiler's first commercial title, Mario's Tennis. The platform choice is a deliberate inversion of the NES strategy: where earlier ecosystems targeted games with good public disassemblies, the Virtual Boy has essentially none. It was picked anyway because the system itself is simple enough that the recompiler could work without that scaffolding.
\nThat makes the project a useful stress test of the whole approach. If static recompilation only worked where the community had already done the reverse engineering, it would be a repackaging tool. Getting a commercial title running on a console with no disassembly heritage argues it is something more.
\nThe post closes with the platform's most evocative ambition: since the games become native code with a modern renderer behind them, the author wants to eventually visually enrich Virtual Boy titles beyond the hardware's red-and-black display, something no amount of emulation accuracy would ever offer.
\nRelated: Mario's Tennis on Virtual Boy.
", "date_published": "2026-05-21T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/genesis-sonic-2", "url": "https://retroportingtoolkit.com/blog/genesis-sonic-2", "title": "SegaGenesisRecomp Gets Game #2: Sonic the Hedgehog 2", "summary": "The Genesis framework's second title, and the de-hardcoding work that made a second game possible at all.", "content_html": "Two months after the Sonic the Hedgehog tech demo, the Genesis ecosystem gains its second playable title. This post announces Sonic the Hedgehog 2 running natively, and is frank that at this stage the milestone is playability rather than polish.
\nThe engineering story is about what a second game forces on a young framework. The original bring-up had let Sonic 1 assumptions leak into shared code, and supporting Sonic 2 meant de-hardcoding that behavior so the runner served both games from common machinery. That cleanup is the less glamorous half of the ecosystem model: the first title proves the concept, the second proves the framework.
\nThe post points ahead to Sonic 3 & Knuckles as the next target, keeping the roadmap inside the same family, where the games' shared engine lineage lets each title build on the previous one's fixes.
\nRelated: Sonic the Hedgehog 2 on Sega Genesis.
", "date_published": "2026-05-21T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/nesrecomp-4-titles", "url": "https://retroportingtoolkit.com/blog/nesrecomp-4-titles", "title": "NESRecomp: From Faxanadu to 4 Supported Commercial Titles", "summary": "The NES ecosystem's first milestone post: four commercial titles and the analysis techniques that got them there.", "content_html": "The NES ecosystem's first milestone post covers the jump from a single working game to four supported commercial titles: Super Mario Bros., Faxanadu, The Legend of Zelda, and Dr. Mario.
\nThe technical core is how the recompiler finds the code in the first place: walking the JSR/RTS call graph to discover function boundaries in 6502 binaries that carry no symbol information. For Zelda, the public zelda1-disassembly project provided leverage, an early instance of the pattern that later defined the whole toolkit, where community annotation work feeds directly into recompilation quality.
\nThe post is straightforward about rough edges at this stage: Dr. Mario had a minor audio timing issue and Faxanadu a minor transparency issue, both documented rather than glossed over. Read against the 10-title announcement two months later, this is the moment the NES work stopped being a single-game experiment and became an ecosystem.
\nRelated: Faxanadu, Super Mario Bros., The Legend of Zelda, and Dr. Mario on NES.
", "date_published": "2026-03-28T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/genesis-sonic-tech-demo", "url": "https://retroportingtoolkit.com/blog/genesis-sonic-tech-demo", "title": "segagenesisrecomp + Sonic the Hedgehog tech demo", "summary": "The Genesis recompiler's debut: dual-execution validation, 68k jump-table pain, and Sonic booting to Green Hill Zone.", "content_html": "This post introduces the Sega Genesis recompiler through its first tech demo: Sonic the Hedgehog booting to Green Hill Zone as native code, with known issues openly listed.
\nThe pace of the bring-up is the headline number: 133 functions verified in a single day using dual execution, where the recompiled code and a reference implementation run side by side and every divergence is caught immediately. Of those, 112 were validated across more than 200,000 frames. The post also explains why the 68000 is genuinely difficult for static recompilation: jump tables and indirect jumps hide control flow from ahead-of-time analysis, and a VBlank-ordering jump bug found during the work is documented in detail.
\nAs the tech-demo label says, this was a proof of concept rather than a release. But the dual-execution methodology it established, validating recompiled output frame by frame against a reference, became a fixture of how the later ecosystems verify their work.
\nRelated: Sonic the Hedgehog on Sega Genesis.
", "date_published": "2026-03-24T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/ps1-recompiler-claude-code", "url": "https://retroportingtoolkit.com/blog/ps1-recompiler-claude-code", "title": "I Built a PS1 Static Recompiler With No Prior Experience (and Claude Code)", "summary": "The origin story: three weeks with Claude Code and Ghidra, ending with Tomba! booting and starting a new game.", "content_html": "This is the post that started everything: an account of building a PlayStation static recompiler with no prior experience in the field, over roughly three weeks of iteration with Claude Code and Ghidra.
\nThe result at that point was Tomba! booting, playing its FMV intro, reaching the menu, and starting a new game. Modest next to what the ecosystems became, but the post's lasting contribution is a discipline rather than a demo: every fix goes into the compiler's inputs, never into hand-edits of the generated code. That rule keeps the entire output reproducible from the pipeline, and it is the reason later projects could regenerate their code freely as the tooling improved instead of accumulating unreviewable patches.
\nRead today, the post doubles as the toolkit's founding document. The Tomba! project it describes grew into PSXRecomp, and the workflow it sketches, a human directing an AI agent against ground-truth hardware behavior, became the method behind every ecosystem that followed.
\nRelated: Tomba! on PlayStation.
", "date_published": "2026-03-11T00:00:00.000Z" }, { "id": "https://retroportingtoolkit.com/blog/time-extension-openpete", "url": "https://retroportingtoolkit.com/blog/time-extension-openpete", "title": "PS1 Classic Spyro: The Dragon Comes To PC, With The Help Of AI-Assisted Tool PSXRecomp", "summary": "Time Extension covers OpenPete, the community Spyro PC port built partly on PSXRecomp.", "content_html": "Independent coverage from Time Extension, written by Jack Yarwood in August 2026. This is outside reporting on the ecosystem, not a post from the team, and it focuses on OpenPete, the community-built native PC port of Spyro the Dragon.
\nThe article describes OpenPete's v0.1.3 release for Windows, with Linux and macOS versions planned, and its enhancements: widescreen, higher frame rates, and extended draw distances. It also lays out the project's hybrid construction, combining altro50's unfinished Spyro decompilation with PSXRecomp covering the functions the decompilation has not reached, plus the Psycross platform layer. Matthew Stanley is named as the author of PSXRecomp.
\nCoverage like this marks a shift in the toolkit's story: the press attention here is for a third-party project that chose PSXRecomp as one of its building blocks, which is exactly the kind of downstream adoption an open toolkit is built for.
\nRelated: OpenPete on PlayStation.
", "date_published": "2026-01-01T00:00:00.000Z" } ] }