PS4 Static Recompilation — State of the Art

A general survey of native-code reconstruction (in the N64: Recompiled / Zelda 64: Recompiled sense) for the PlayStation 4, independent of any specific game. Companion docs: ps3-recomp.md, ps2-recomp.md, psx-recomp.md, amiga-recomp.md.

1. CPU/GPU architecture: a different kind of problem entirely

PS4 is a hard break from every platform surveyed so far. The CPU is an 8-core AMD Jaguar APU — a conventional, in-order-ish, low-power x86-64 design (AMD64/x86-64-v2 ISA, SSE4.1/4.2, AES, AVX-adjacent extensions) clocked around 1.8GHz, originally built for notebooks/tablets (Engadget spec announcement, wccftech analysis). The GPU is AMD GCN (Graphics Core Next, the “Liverpool” GPU) — the same architecture family AMD shipped in contemporaneous Radeon desktop cards.

This matters enormously for the recompilation framing used elsewhere in this survey series. Translating MIPS (N64), PowerPC/Cell (PS3), MIPS/VU (PS2), or m68k (Amiga) to a host architecture is genuine cross-ISA lifting — decode foreign instructions, build an IR, emit native code. Translating x86-64 to x86-64 is not that problem at all: a PS4 game’s CPU-side machine code, once decrypted, is already the exact instruction stream an x86-64 PC’s CPU can execute — no lifting required in principle. The GPU side is similar in kind: PS4 games emit PM4 command-buffer packets (AMD’s own hardware submission format, version 3) to the GCN command processor, and GCN’s shader ISA/command format is the same hardware family AMD’s own Linux stack — the amdgpu kernel driver and Mesa’s RADV Vulkan driver — already targets and publicly documents. Opposite situation from PS3’s proprietary, undocumented RSX.

So the “hard problem” for PS4 is not instruction translation — it’s the OS/API layer sitting below the game’s own code: Orbis OS, Sony’s FreeBSD 9.0-derived proprietary kernel plus userland (Unixmen writeup), which sandboxes every game process inside a FreeBSD jail (cturt’s “Hacking the PS4” series, PS4 Developer Wiki syscalls) and exposes hundreds of PS4-specific syscalls layered on top of (and sometimes replacing) standard FreeBSD ones, plus Sony’s proprietary graphics API pair — low-level GNM and higher-level GNMX (roughly analogous to D3D12 vs. D3D11) — which games call to construct those PM4 packets in the first place. Reconstructing a working implementation of Orbis’s kernel modules, libSceGnmDriver, and dozens of adjacent system libraries is the actual engineering mountain, not decoding x86-64 opcodes.

2. Existing prior art: a static recompiler is notably absent

Unlike PS3 (ps3recomp), no PS4-targeting static/AOT recompilation project turned up searching GitHub’s static-recompilation and ps4 topics or general search. No public statement from the N64Recomp author (“Wiseguy”) or ps3recomp’s author (sp00nznet) explaining a decision to skip PS4 was found either — community threads exist asking essentially this question (e.g. a PSX-Place thread titled “n64recomp (ps3 and ps4??)”), but no substantive technical answer from those specific authors could be confirmed. What is confirmed: the team behind RPCS3 (a separate project from ps3recomp) started RPCSX, targeting PS4/PS5 — but RPCSX is a conventional HLE emulator, not a recompiler, per 80.lv and wccftech (booting Sonic Mania and Bloodborne in recent progress reports). GNM/PM4-translation tooling independent of full-game efforts does exist, but again as emulator infrastructure, not a standalone lifter: GPCS4 tries to reconstruct original GNM API calls from PM4 packets before retranslating to Vulkan, while shadPS4 (below) skips that reconstruction and translates PM4 directly, per its own graphics-system docs.

3. PS4 emulation as the reference implementation

shadPS4 (started by George Moralis, a PCSX/PCSX2 veteran, October 2022; first release July 2024) is the dominant project and plays the role RPCS3/PCSX2 play elsewhere: HLE reimplementation of Orbis syscalls and GNM driver calls, with PM4 packets translated directly to Vulkan via a “Liverpool” GPU command-processor emulation layer. Maturity has moved fast for a project this young — compatibility snapshots through 2026 show rapid growth, from roughly 109 titles playable in March to 117–150 by June to reports of 300+ “in-game” and ~180 fully “playable” by November (v0.17.0 shipped July 30, 2026) — but by the project’s own framing it remains meaningfully behind RPCS3/PCSX2’s decade-plus-deep compatibility (emulation.gametechwiki). Orbital (AlexAltea), the earliest effort, is largely stalled at a research stage — boots the Orbis kernel and some homebrew but not commercial games (GitHub). fpPS4 is a smaller, actively-developed Free Pascal project notable for framing itself around syscall translation rather than full hardware emulation (GitHub). GPCS4 remains an early, largely unplayable proof-of-concept (GitHub). All are markedly aided by GCN being open, documented silicon compared to RSX — none needed to reverse-engineer the shader ISA or command format from scratch.

4. Compatibility-shim vs. instruction lifting

This is the one platform in the series where the user’s Wine/Proton intuition largely holds, though what’s actually been built is still emulator-shaped rather than a lightweight OS-level shim. No project loads a decrypted PS4 ELF into a real FreeBSD or Linux process and patches only the syscall table — every working project (shadPS4, RPCSX, GPCS4, fpPS4) runs the original game’s x86-64 machine code essentially unmodified inside an emulator process that reimplements Orbis’s kernel surface and GNM driver in userspace, rather than lifting or recompiling CPU instructions at all. fpPS4’s own description — “translating PS4 system calls instead of full hardware emulation” (Softonic, GitHub) — is the closest thing to the Proton framing found, and homebrew tooling like OpenOrbis (an LLVM/Clang toolchain compiling native ELFs directly against Orbis’s ABI, no Sony SDK required) confirms the userland ABI is tractable enough for outside developers to target directly. But a true “Proton for PS4” — retail SELF binaries decrypted per PS4 Developer Wiki-documented methods, then run with only a syscall shim atop a real host OS — was not found as a shipped or attempted project; SELF decryption is the same kind of plumbing PS3 requires, and everyone doing PS4 preservation work has judged it easier to build a self-contained emulator process than to fight the host OS’s own security model into hosting foreign syscalls directly.

5. Honest maturity assessment

PS4 doesn’t fit anywhere on the recompiler-maturity spectrum this series has been building, because “recompilation” is arguably the wrong frame for it altogether. PS3 has an early-but-real general static recompiler (ps3recomp); PS2 has a mature but franchise-specific bytecode port (OpenGOAL, ps2-recomp.md); PSX has a mature per-title source-decompilation scene with no general tool (psx-recomp.md); Amiga has essentially nothing started (amiga-recomp.md). PS4 has zero static recompilation projects, and that absence is not a gap waiting to be filled the way Amiga’s is — it reflects that the CPU/GPU-translation problem those other four platforms exist to solve is close to moot on PS4, since the original code is already native to the target architecture. The real preservation effort has instead converged, independently, on OS/driver-layer HLE emulation — shadPS4 chief among them — which is a mature-ish and clearly production-trending approach (hundreds of playable titles, rapid 2026 growth) but categorically different in shape from a CPU recompiler: it’s an operating-system compatibility problem wearing an emulator’s clothes, closer in spirit to Wine than to N64: Recompiled.

Case study: Bloodborne

Bloodborne (FromSoftware, 2015) is the field’s most-requested PS4-exclusive with no official PC release, which makes it a useful test of what this doc’s thesis predicts in practice: no recompiler, no binary-level port, action concentrated at the HLE-emulation layer. As of August 2026 that prediction holds, with one genuinely interesting wrinkle.

Official status: unchanged. Sony has never announced a PC port, remaster, or PS5 patch — the game is still 30fps-locked, PS4-only. Miyazaki has said he’d “love” more players to reach it, but the IP is Sony’s to greenlight, not FromSoftware’s (Kotaku). A June 2026 wave of “Bloodborne officially returns” headlines is not a game release at all — it’s a Laced Records vinyl reissue of the soundtrack made with Sony’s licensing cooperation (CBR), a good reminder to discount clickbait framing in this space.

shadPS4: not a showcase title. Bloodborne runs on shadPS4, but EmuRank’s aggregated 2026 reports rate it only “Ingame,” with 0% of recent reports reaching “Playable or better” as of shadPS4 0.15.0 (EmuRank) — this is squarely the HLE-emulator technique §3/§4 describe, immature, not the flagship compatibility win press coverage implies. Popular “Bloodborne 60fps on PC” stories (gamingbible) are shadPS4 plus community mod stacks (FPS unlock, texture downscale, cloth-physics removal) layered on top of the emulator, not a separate achievement. The most visible of these, modder “fromsoftserve”’s “BB PC Remaster” (Nexus, v0.99.57), is explicitly a shadPS4-hosted texture/lighting/gparam overhaul — AI-upscaled textures, reworked shadows and dynamic lighting — that still requires shadPS4 underneath to run at all (DSOGaming, DSOGaming (texture pack)). Outlets calling it a “PC port” or “PC remaster” are describing an emulator skin, not a native build.

A real third technique: rehosting on a sibling in-house-engine PC build. This is the interesting find. Bloodborne’s engine is a direct descendant of Dark Souls 1’s, sharing enough of its internal formats (FLVER models, MSB maps, TPF textures, param tables) that the community’s Souls-modding toolchain — katalash/dstools and its successor DSMapStudio — targets Demon’s Souls, DS1/2/3, Bloodborne, Sekiro, and Elden Ring as one family, and openborne/bbtools exists specifically to extract/convert Bloodborne’s proprietary asset formats. That shared lineage has enabled exactly the engine-based-porting move engine-based-porting.md describes — except the “host engine” is FromSoftware’s own PC-native Dark Souls III build rather than Unreal/Unity. A reverse engineer documented actually importing real Bloodborne map geometry into Dark Souls III on PC (Steam Community thread), and a substantial Nexus Mods ecosystem now ports genuine ripped Bloodborne weapon, armor, and enemy-item models into DS3’s engine — Bloodborne Weapons, Bloodborne Armors Plus, Bloodborne Enemy Items, and “Hunter’s Combat” (functional trick-weapon transformations) among them (Dread Central). This is real and working, but at mod scale — individual weapons, armor sets, and isolated maps dropped into DS3, not a full-game rehost. (Separately, the well-known “Graceborne” Elden Ring mod is often described in the press as “the closest thing to Bloodborne on PC,” but it’s a thematic overhaul built substantially from Elden Ring’s own asset base, not an asset-import project — worth distinguishing from the DS3 efforts above.)

No native binary port or decompilation. Searching specifically for a Bloodborne reverse-engineer or native-compatibility figure (CookiePLMonster was the obvious name to check) turned up no connection — their public work doesn’t include Bloodborne (CookiePLMonster/Silent’s Blog). No decompilation project or binary-level PC port exists, consistent with this doc’s core claim: x86-64-to-x86-64 isn’t a problem anyone needs to solve here, so effort has gone entirely into OS-layer emulation and, more surprisingly, into a genuine sibling-engine asset-rehosting scene that this series hadn’t named until now.