Static Recompilation Prospects: PlayStation 2 (PS2)

General ecosystem survey, not tied to any specific game. Companion to psx-recomp.md; see also the project’s earlier PS3/ps3recomp research for the broader static-recompilation-wave context (N64: Recompiled, sm64ex, etc.).

1. CPU architecture: the Emotion Engine, and why VU1 is “the SPU problem” for PS2

The PS2’s Emotion Engine (EE) is a MIPS III/IV-derived 64-bit core (custom “R5900,” ~294 MHz) extended with 128-bit SIMD “MMI” instructions — already more complex than PS1’s plain R3000A, but still a conventional scalar/SIMD CPU a MIPS-lifting recompiler can approach the way N64 or PS1 tools do. The real complexity is the two attached Vector Units:

VU0 is tightly coupled to the EE and can run in “macro mode” much like a normal coprocessor (COP2) — instructions issued inline from the main EE stream, executing largely in lockstep with it. That makes VU0 comparatively tractable: close enough to “more coprocessor instructions embedded in the main program” that a recompiler translating the EE stream can plausibly translate VU0 macro-mode code the same literal, 1:1 way.
VU1 is the hard part, and PS2’s structural analog to PS3’s SPUs. It’s loosely coupled: separate instruction memory (micro-mem) and data memory, running independently once kicked off, typically fed vertex/geometry microprograms that the main EE program DMAs into micro-mem at runtime — sometimes generated or patched on the fly rather than existing as a fixed blob in the ELF. That combination (a separate DSP-like unit, its own instruction memory, code not fully known until runtime) is exactly what makes ahead-of-time static recompilation hard: a static recompiler wants to walk the whole binary once, at build time, and translate everything it will ever execute. If VU1 microprograms are streamed, composited, or self-modified by EE-side logic at runtime, there may be no single fixed “VU1 program” to find and translate in advance — the same fundamental headache PS3 research hit with SPU code (see the project’s earlier ps3recomp research), realized via DMA’d microcode instead of dynamically loaded SPU overlays.

2. Existing recompilation and decompilation prior art

OpenGOAL / jak-project — the flagship success, with a caveat

The single most successful, complete example of a PS2 game running natively on PC is OpenGOAL / jak-project, targeting Naughty Dog’s Jak and Daxter trilogy:

Scope: all retail PAL/NTSC/NTSC-J builds of The Precursor Legacy (long considered complete and polished), Jak II, and Jak 3 (both feature-complete and fully completable, “beta” mainly for residual audio/graphics bugs) are supported, per the FAQ and OC3D coverage. Early builds, demos, and PS3/4/5 re-releases are out of scope; users supply their own legitimate disc.
Why it worked: Naughty Dog didn’t ship a normal C/C++ binary — roughly 98% of the trilogy is written in GOAL (“Game Oriented Assembly Lisp”), their own proprietary Lisp-like language, compiled by their own lightly-optimizing in-house compiler. That left compiled output close enough to the original Lisp structure that OpenGOAL reconstructed ~99% of functions back into readable GOAL, aided by autogenerated debug metadata exposing type layouts and field offsets — unusually generous ground truth. The team wrote a modern GOAL compiler retargeting x86-64 plus asset tools, and recompiles reconstructed GOAL straight to native PC — no MIPS/VU binary translation in the shipped result.
Why it doesn’t generalize: the FAQ is explicit — “the work done on OpenGOAL will not be a big help for decompiling anything outside of the main Jak series.” It’s a source-level decompilation of one studio’s proprietary language runtime, not a general PS2 binary recompiler. Most PS2 games used conventional C/C++ + GCC toolchains, shipping ordinary optimized MIPS/VU code with none of GOAL’s structural regularity or debug generosity — for those, OpenGOAL’s method has nothing to transfer.

General-purpose binary-level static recompilers — early and incomplete

For the actual ps3recomp/N64:-Recompiled-style approach — translating an arbitrary PS2 ELF at the machine-code level — the main effort is PS2Recomp: statically recompiles PS2 ELFs to C++ via ps2xAnalyzer (ELF scan/config), ps2xRecomp (literal 1:1 R5900/MMI/VU0-macro → C++), ps2xRuntime (memory, function registration, syscalls), and ps2xIOP (IOP HLE, per-game profiles). Its README claims “PS2-specific MMI and VU0 macro support” but explicitly states VU1 microcode support is incomplete — precisely the loosely-coupled, runtime-DMA’d unit above. The Graphics Synthesizer and most hardware blocks still need external implementation, and stripped retail binaries need Ghidra-assisted analysis. It’s marked experimental: sizable community interest (thousands of stars, 100+ forks as of 2026) but no confirmed fully-working commercial game in the README, and forks in progress (e.g. EmotionRecomp) rather than one converged codebase. Press coverage (GIGAZINE, linuxadictos, ObsoleteSony) is consistently early-stage in framing — ObsoleteSony’s summary: “PS2 recompilation is game-specific, labor-intensive, and nowhere near ready… not a practical way to play PS2 games.”

Related forks/derivatives (ej-sanmartin/ps2recomp, and even an AI-agent “skill” wrapper, ps2-recomp-Agent-SKILL) show community interest but no independent mature competitor, unlike PSX’s brief two-project race. One adjacent, game-specific effort worth flagging: reo, recompiling Resident Evil Outbreak with a reported “SSE/AVX SIMD + custom microcode translator” for VU0/VU1 — a hand-tuned, single-game attack on the VU1 problem rather than a general solution.

Tooling crossover

splat, the N64/PSX-decomp-born binary splitter, lists PS2 as a supported target, so groundwork tooling exists for PS2 source-level decompilation in principle. In practice, PS2’s larger and more varied middleware/engine landscape (vs. PS1’s PsyQ-dominated era) means no comparable wave of general “game X decompilation” projects exists for ordinary C/C++ PS2 titles — OpenGOAL stands out precisely because it had unusually favorable conditions most PS2 titles don’t share.

3. PCSX2 as the reference implementation

PCSX2 is the mature, JIT dynamic-recompilation PS2 emulator, and plays the same reference role for PS2 that RPCS3 plays for PS3: two decades of accumulated EE/IOP/VU/GS hardware-behavior knowledge, JIT recompilers for both the Emotion Engine and Vector Units, and broad, full-speed compatibility across nearly the entire commercial library. Its correctness is proven by running thousands of titles for years, and any static recompiler is implicitly leaning on the same community-derived hardware knowledge PCSX2’s JIT encodes — even though the execution strategy (translate-once-ahead-of-time vs. translate-and-cache-at-runtime) differs fundamentally. As with PSX/PS3, PCSX2 doesn’t solve static recompilation by itself, but is the ground-truth behavioral reference every PS2 recompilation effort checks against.

4. Honest state assessment: PS2 vs. PSX vs. PS3

Vs. PSX: PS2 general recompilation is markedly less mature. PSX has two independently developed static recompilers already producing partial-but-running results on real commercial games, atop a large, genuinely mature source-decompilation ecosystem. PS2’s general recompiler (PS2Recomp) is earlier-stage, has no confirmed fully-working commercial game, and is explicitly blocked on VU1 — a harder structural issue than anything PSX’s single-core, fixed-function-GTE architecture presents.
Vs. PS3: PS2 is more mature in outcome, but for an idiosyncratic reason — OpenGOAL is a real, shipped, playable, actively-maintained native port of an entire AAA trilogy, and nothing on PS3 has reached that bar. But this is somewhat apples-to-oranges: OpenGOAL’s success is a one-off consequence of Naughty Dog’s unusual GOAL toolchain, not evidence that general PS2 binary recompilation (the actual PS3-comparable technique) is ahead. On that narrower, apples-to-apples axis — arbitrary-binary, engine-agnostic recompilation of ordinary C/C++ game code — PS2 (PS2Recomp, VU1-incomplete, no confirmed working game) and PS3 (ps3recomp, PPU/VMX+RSX research-stage) sit in roughly the same early/experimental tier, each blocked on its console’s “hard secondary processor” problem: VU1’s runtime-DMA’d microprograms for PS2, SPU code and RSX/Cell coherency for PS3.
Overall: “is this solved” has two different honest answers for PS2. For a GOAL-based Naughty Dog game, essentially yes (OpenGOAL, uniquely). For an ordinary C/C++-toolchain PS2 game — the vast majority of the library — no: still nascent, one early-stage general recompiler with an acknowledged unsolved VU1 gap, and no decompilation wave comparable to PSX’s or N64’s.