The pitch is simple and the execution is not: take a PSP game's compiled MIPS machine code, translate it ahead of time into C++, compile that to WebAssembly, and run it in a browser tab against a from-scratch reimplementation of the PSP's operating system and graphics hardware. No interpreter loop, no JIT, no emulator binary. The game becomes a web page. The project, psp-web-recomp, uses PSPRecomp to analyze decrypted PSP executables, emit C++ in 16 KiB translation units, and link against a high-level emulation layer that answers system calls — cooperative threads, semaphores, file I/O via HTTP Range requests, audio mixing, save dialogs. The graphics pipeline decodes the PSP's GE display lists on the CPU (vertex formats, skinning, lighting, texture generation, clipping) and hands batched triangles to WebGL2 render targets keyed to VRAM addresses. Two threads mirror the PSP's own architecture: GE on a worker with OffscreenCanvas, game logic on main. God of War: Chains of Olympus and Ghost of Sparta are the proof-of-concept titles, both Ready at Dawn engine games. Chains of Olympus runs at 60fps in Chrome and Firefox at up to 4× the PSP's 480×272 native resolution, with music, speech, sound effects, and combat all functional. Ghost of Sparta followed with minimal additional work — a DRM decryption handler for one small PGD file, a lighting fix for ambient alpha, a handful of system calls — and hit 55-60fps at 3× resolution with zero performance tuning. The performance story is the most instructive part. The first playable build ran at 6fps. Most gains came not from renderer optimization but from diagnosing waste: God of War was drawing eight frames per vsync with no blanking hold (fixed by PPSSPP's double-swap trick), std::chrono calls through clockgettime cost a third of every frame via BigInt conversion in JS (replaced with performance.now()), Firefox's index buffer revalidation on a shared 4MB ring tanked to 3fps (fixed by per-draw small buffers), and stencil-alpha mirroring burned 60 million extra pixels per frame at 4× (reduced to 7 million by tracking dirty rectangles). The lesson: browser performance work is mostly archaeology. The toolchain is reproducible. You clone the repo, run setup.sh to pull PSPRecomp and Emscripten, point port.sh at a decrypted disc image you own, and get a web page in about four minutes on an 8-core laptop. No game data is distributed. The page requires SharedArrayBuffer and cross-origin isolation headers, with a fallback single-thread mode for browsers that can't draw WebGL2 on OffscreenCanvas. Phone support exists via on-screen touch controls. The honest limitation is scope: two games, both from the same engine, both from the same studio. The project makes no claim about generality. Another game will likely stop at an unimplemented system call or an unhandled GE feature. The README says as much, and docs/internals.md describes the debugging workflow. This is a proof of architecture, not a universal PSP player. What makes this worth attention is the method, not the game count. Static recompilation to WebAssembly with HLE is a fundamentally different preservation strategy than traditional emulation — it produces artifacts that run anywhere a browser runs, at native-code speed, with no runtime interpreter overhead. If the approach generalizes even modestly beyond Ready at Dawn's engine, it opens a new lane for game preservation that doesn't depend on platform-specific emulator binaries.
