I'm building PSXRecompStudio, an open-source research project exploring static recompilation of PlayStation 1 software.
The long-term goal is to help authorized rights holders turn existing PS1 games into maintainable, rebuildable ports, even when their original source code and build tools are no longer available.
This is still research-stage work, not a way to recompile and play a complete commercial game today. But over the past few weeks, several parts of the project have become much easier to demonstrate and measure.
Seeing Persona's opening for the first time
One of the most encouraging milestones was getting visible opening imagery from Megami Ibunroku Persona (Revelations: Persona) through the OpenBIOS interpreter execution path.
I added screenshots captured at specific VBlank intervals rather than trying to reconstruct an earlier frame from the final state of video memory. The resulting captures show the ATLUS logo and opening text referencing Zhuangzi's butterfly dream.
That matters because the project had spent a long time making progress that was mostly visible in CPU traces, BIOS calls, and test output. Seeing recognizable frames is a different kind of feedback.
The qualification is important: this is interpreter execution, not a successfully recompiled version of Persona. Reaching the title screen, playing the game, and matching this behavior in the generated native host remain unproven.
How the VBlank capture was implemented (PR #754)
A tiny PS1 executable can go all the way through recompilation
There is also now a reproducible showcase for the actual recompilation pipeline.
Using the released v0.0.0-alpha.2 CLI, a script generates an original five-instruction PS-X EXE, then follows this path:
Synthetic PS-X EXE
|
v
MIPS analysis and lowering
|
v
Generated host code
|
v
Native artifact build
|
v
Execute and inspect output
The demo prints P to the terminal. Real console captures document the result on Windows, and an equivalent released-binary run was verified on Linux.
Five instructions do not demonstrate compatibility with an entire commercial game. They do demonstrate that analysis, code generation, building, and execution can work together end to end for a controlled input.
Demo verification and screenshots (PR #781)
The hard part: two execution paths, different results
The biggest open problem is less photogenic.
The interpreter can advance through Persona's opening, but the standalone AOT + interpreter-fallback runtime still produces a black screen in the investigated scenario.
AOT means ahead-of-time compilation: known PS1 instructions are translated into host code before execution. When the generated host encounters a path it cannot handle, an interpreter can take over.
I am comparing the two execution paths instead of assuming the GPU renderer is responsible.
At one shared checkpoint, the recorded CPU state, RAM, VRAM, GPU state, captured device registers, and guest-cycle count match. That is equality at one checkpoint, not a claim that all preceding execution was identical. Their subsequent instruction paths diverge, and the root cause has not yet been identified.
One useful outcome of this investigation was finding a misleading diagnostic: a run stopped by an explicit request could be reported as if it had exhausted its instruction budget. The diagnostic was corrected, but the underlying rendering divergence is still open.
Investigation and measured limits (draft PR #787)
A concrete runtime optimization
On October 16, I merged a smaller, measurable change to the generated-host runtime.
The runtime was spending a lot of time exchanging synchronous messages between generated code and the host. In particular, a guest-time report was often sent immediately before an MMIO access.
Combining that time report with the MMIO request into one message reduced IPC round trips per guest instruction from 0.106 to 0.071, approximately 33% fewer in the measured setup.
A separate throughput measurement had a higher median, but considerable host noise, so I'm treating the round-trip reduction as the more reliable result.
This improves communication overhead; it does not establish that Persona now boots further or that the black-screen divergence is fixed.
IPC optimization and measurements (PR #796)
Tests should say what they actually tested
Another recent change was deliberately unglamorous: integration tests requiring real CHD files now skip explicitly when their input is unavailable, instead of silently returning and appearing to pass.
With a lawful local fixture present, the relevant tests can run normally. Without it, the test report distinguishes missing evidence from successful execution.
I want the project's status reports to keep three things separate: what a synthetic input proves, what a locally supplied real disc proves, and what has not been verified.
Real-ROM test reporting fix (PR #791)
What's next?
The immediate priority is to identify the first meaningful behavioral difference between interpreter and generated-host execution, then extend the runtime only with evidence for the missing behavior.
There is still substantial work ahead in BIOS and device behavior, recompiler coverage, runtime integration, and independent validation. A working demo and recognizable screenshots are milestones, not compatibility guarantees.
But I'm happy to have moved from “the traces are changing” to a project with visible frames, a reproducible native-code demo, a precise unsolved divergence, and measurements that can guide performance work.
If you work on emulators, recompilers, MIPS, or retro-game preservation, I'd be interested in technical feedback—especially on differential execution testing.
Repository: https://github.com/mao2009/PSXRecompStudio
The project does not distribute commercial game images, BIOS files, or copyrighted game data. Persona screenshots document interoperability research; the game and its imagery belong to their respective rights holders. PSXRecompStudio is unaffiliated with ATLUS.
Top comments (0)