Pimp My IDE / garage dispatchBack to the garage
October 12, 2026 / static recompilation / WebAssembly

A boot screen is not a compatibility claim.

PS2 Web Recomp turns console machine code into C++ and WebAssembly. The hard part is proving what the translator found, what the runtime supplied, and what the browser actually rendered.

Static coverage finds code. Runtime evidence finds the paths the game took.

The browser is running translated console code.

PS2 Web Recomp says it reads a game's Emotion Engine executable, follows control flow, emits C++ in 16 KiB units, compiles that output to WebAssembly, and links it to a reimplementation of PS2 operating-system and hardware behavior.[1] The project does not ship game data. Its scripts expect a disc image supplied by the user.

The repository reports two working titles. Gran Turismo 4 reaches races. God of War II reaches combat. That is a strong engineering result. It is not evidence that arbitrary PS2 software will work.

Translation coverage and platform compatibility are different records.

Static discovery needs a runtime return route.

The project's port script uses static analysis to find functions, then runs the game headlessly to record targets that static analysis missed. It adds those addresses as entry points and rebuilds until an exploring run stops finding new ones.[1]

That loop is useful because indirect calls hide code from a simple control-flow walk. It also has a hard boundary. An exploring run only covers the menus, modes, timing, inputs, saves, and errors that the run reached. A clean pass means no new target appeared in that run. It does not mean every executable path is known.

The runtime is part of the port.

The generated WebAssembly is not the whole machine. The repository describes a small PS2 kernel, an interpreted I/O processor, reimplemented sound and movie hardware, WebGPU compute shaders for graphics, workers for parallel units, HTTP Range requests for disc data, and browser storage for a memory card.[1]

A second title found generic defects that the first never triggered. The project reports one recompiler branch-delay bug, one vector-unit timing bug, and missing I/O behavior. That is the right lesson to carry into any binary translation project. A new workload is an independent probe of the translator and every service around it.

The host contract can fail before the game starts.

The page uses shared memory for its worker layout. MDN documents that SharedArrayBuffer use depends on cross-origin isolation. The response needs Cross-Origin-Opener-Policy: same-origin and a compatible Cross-Origin-Embedder-Policy value.[2] Emscripten's pthread guide gives the same deployment warning and notes that a threaded and non-threaded build are separate outputs.[3]

WebGPU adds another host check. MDN marks the API as limited availability and secure-context only.[4] PS2 Web Recomp documents a software-renderer fallback, but describes it as too slow for 3D. The compatibility report therefore needs browser, operating system, GPU, driver, isolation headers, adapter result, renderer, and observed frame rate.

Publish the miss, not only the demo.

A useful port report names the exact revision and disc identity, then saves the discovered target set, missing syscall or library message, first bad frame, reference-renderer comparison, and browser contract. A screenshot proves that one frame existed. A replay, save, or long run tests more of the machine.

The project README is unusually direct about its boundary. It says that only two games have been brought up and that another title will probably stop at missing system or rendering behavior. Keep that honesty attached when the demo leaves the repository and enters a headline.

Interactive makeover / compatibility dyno

Load the four witnesses.

This replaces a single "it runs" badge with four independent checks. The carriage advances as the test plan gains structure. It does not inspect a game, run the toolchain, or approve distribution.

TranslateExerciseCompareHost

Witness bank

Select the evidence sections that the report will require. Each section still needs real output.

Evidence rail

Every gate is a required section, not a passed test.

0 of 4 sectionsCompatibility report
Four evidence sections are open.Select the report structure before collecting outputs.
Sources read / October 12, 2026

Source log

Open the evidence boundary
  1. snuri00/ps2-web-recomp at commit 780f869, read October 12, 2026. The repository documents the translation flow, native runtime, two tested games, observed defects, browser requirements, legal boundary, and expected gaps. The commit was current when read and was not signed.
  2. MDN, "Window: crossOriginIsolated property", last modified August 21 and read October 12, 2026. MDN documents the response headers and permission condition needed for cross-origin isolation and reduced restrictions on shared memory.
  3. Emscripten documentation, "Pthreads support", read October 12, 2026. The guide documents SharedArrayBuffer use, COOP and COEP deployment requirements, worker behavior, main-thread blocking risks, and the separate-build boundary for threaded and non-threaded output.
  4. MDN, "WebGPU API", last modified September 2 and read October 12, 2026. MDN describes secure-context requirements, limited availability, adapter and device discovery, compute pipelines, and asynchronous error behavior.
  5. Hacker News discussion 50052251, read October 12, 2026. The discussion led to the repository. It is a conversation source, not evidence for the implementation or performance claims.

Evidence boundary: this page read the pinned repository and platform documentation. It did not provide a game disc, run the port script, compile the project, inspect a generated WebAssembly file, or reproduce the reported frame rates. The dyno creates a report structure only. A fully selected structure does not mean a game passed.