This is cool but of course it's only going to be a small handful of titles that ever receive this kind of attention. But I have been blown away that now sub-$300 Android handhelds are more than capable of emulating the entire PS2 library, often with upscaling if you prefer.
Emulation is amazing for access right now. Recompilation is about making sure MGS2 or GT4 still runs in 2045 on whatever weird hardware we're using then
Of course I am spoiled by Dolphin and their meticulous work, and the leap in N64 emulation, and PS3 emulation is way farther than I thought it could ever be.
But PCSX2 is mediocre. It reports the vast majority of the library in "green" emulation state, but that usually means there are glaring issues that someone is choosing to overlook, like shadows that are broken.
The Ace Combat games for example are all broken with the hardware accelerated renderer. Things run like garbage in the software renderer for a lot of games. Multiplayer functionality is spotty and hard to set up and poorly documented.
The state of emulation of that console generation is not up to snuff, save for Dolphin. It's still very much in the "Shut up, it works fine for Super Mario 64 so it works" mindset it seems.
This is true even of official emulators! The Xbox emulator that ran on the Xbox 360 has many games that are "officially supported" with serious issues. Forza Motorsport 1 has weird slowdowns on key tracks. I understand the serious hardware difficulties but I still wish emulation accuracy was an option.
As far as I know, static recompilation is thwarted by self modifying code (primarily JITs) and the ability to jump to arbitrary code locations at runtime.
The latter means that even in the absence of a JIT, you would need to achieve 100% code coverage (akin to unit testing or fuzzing) to perform static recompilation, otherwise you need to compile code at runtime at which point you're back to state of the art emulation with a JIT. The only real downside of JITs is the added latency similar to the lag induced by shader compilation, but this could be addressed by having a smart code cache instead. That code cache realistically only needs to store a trace of potential starting locations, then the JIT can compile the code before starting the game.
I believe the main interest in recompilation is in using the recompiled source code as a base for modifications.
Otherwise, yeah, a normal emulator JIT basically points a recompiler at each jump target encountered at runtime, which avoids the static analysis problem. AFAIK translating small basic blocks and not the largest reachable set is actually desirable since you want frequent "stopping points" to support pausing, evaluating interrupts, save states, that kind of stuff, which you'd normally lose with a static recompiler.
On this topic of ports/recomps there's also OpenGOAL [1] which is a FOSS desktop native implementation of the GOAL (Game Oriented Assembly Lisp) interpreter [2] used by Naughty Dog to develop a number of their famous PS2 titles.
Since they were able to port the interpreter over they have been able to start rapidly start porting over these titles even with a small volunteer team.
90% of the PS2’s floating point throughput is in the two vector units, not the R5900 conducting them. Concentrating on that, as the article does, seems as futile as focussing on the 68000 rather than the Amiga PAD in a 16-bit context (ignoring the EE’s 16-bit RAMBUS bottleneck).
However that approach will probably suit the least-ambitious PC-ports to PS2 (by studios that didn’t appreciate the difference) - rather as an ST emulator was a short cut to run the simplest Amiga games.
Back in the day, I wrote a simulator for the PS2’s vector units because Sony did not furnish any debugger for them. A month after I got it working, a Sony 2nd party studio made their VU debugger available to everyone… Anyway…
The good news is that the VU processors are actually quite simple as far as processors go. Powerful. Complicated to use. But, not complicated to specify.
This is made much simpler by the fact that the only documentation Sony provided was written by the Japanese hardware engineers. It laid out the bit-by-bit details of the instruction set. And, the bitwise inputs, outputs, delays and side effects of each instruction.
No guidance on how to use it. But, awesome docs for writing a simulator (or recompiler).
See also: XenonRecomp, which does the same thing for Xbox 360, and N64:Recompiled which does the same thing for N64.
Note that this "recompilation" and the "decompilation" projects like the famous Super Mario 64 one are almost orthogonal approaches in a way that the article failed to understand; this approach turns the assembly into C++ macros and then compiles the C++ (so basically using the C++ compiler as a macro re-assembler / emulation recompiler in a very weird way). The famous Super Mario 64 decompilation (and openrct and so on) use the output from an actual decompiler which attempts to reconstruct C from assembly, and then modify that code accordingly (basically, converting the game's object code back into some semblance of its source code, which this approach does NOT do).
> So yes, currently playing PS2 games on PC via emulator is still absolutely fantastic, but native ports would be the holy grail of game preservation.
I would think that emulation of the original game as closely as possible would be the gold standard of preservation, and native ports would be a cool alternative. As described in the article, native ports are typically not faithful reproductions but enhanced to use the latest hardware.
> The PlayStation 2’s library is easily among the best of any console ever released, and even if you were to narrow down the list of games to the very best, you’d be left with dozens (more like hundreds) of incredible titles. But the PS2 hardware is getting a bit long in the tooth
Besides the library, the PS2 is the most successful video game console of all time in terms of number of units shipped, and it stayed on the market for over ten years, featured a DVD drive, and at one point was positioned by Sony not just as an entertainment appliance but as a personal computer, including their own official PS2 Linux distribution.
In a more perfect world, this would have:
(a) happened with a hypothetical hardware platform released after the PS2 but before the PS3, with specs lying in between the two: a smidge better than the former, but not quite as exotic as the latter (with its Cell CPU or the weird form factor; whereas the PS2's physical profile in comparison was perfect, whether in the original form or the Slim version), which could have:
(b) resulted in a sort of standardization in the industry like what happened to the IBM PC and its market of clones, with other vendors continuing to manufacture semi-compatible units even if/when Sony discontinued it themselves, periodically revving the platform (doubling the amount of memory here, providing a way to tap into higher clock speeds there) all while maintaining backwards compatibility such that you would be able to go out today and buy a brand new, $30 bargain-bin, commodity "PS2 clone" that can do basic computing tasks on it (in other words, not including the ability to run a modern Web browser or Electron apps), can play physical media, and supports all the original games and any other new games that explicitly target(ed) the same platform, or you could pay Steam Machine 2026 prices for the latest-gen "PS2" that retains native support for the original titles of the very first platform revision but unlocks also the ability to play those for every intermediate rev, too.
As owner of PS2 Linux distribution and related hardware, it was sort of ok.
Sony intended it to be the evolution of Playstation Yaroze, fostering indie development, instead people used it mostly to run emulators on the PS2, hence why the PS3 version lost access to accelerated hardware for graphics.
PS2 Linux had hardware acceleration, the only difference was that the OpenGL inspired API did not expose all the capabilities of a regular DevKit.
Community proved that the development effort wasn't worth it.
The XBox arcade and ID@XBox programs have also taken these lessons into account, which is why you only see everyone running emulators on rooted XBoxes, not the developer mode ones.
The market of IBM PC clones only happened because of an IBM mistake, that was never supposed to happen, and IBM tried with the PS2 / MCA to take their control back, but the Pandora box was already open, and Compaq was clever with the way they did reverse engineer the BIOS.
I’ve been meaning to start decompiling one of my favorite games of the era (Hulk Ultimate Destruction) after watching the decomp of other games. Perhaps this is a sign to start?
As a movie geek I'm personally offended when someone says "oh, it's from 2017, it's an old movie!", or "I don't want to see anything from 90s, yuck" - and that's pretty common.
Of course, "Nosferatu, eine Symphonie des Grauens" is not for everyone, but I firmly believe that you can watch the new Dune and Lawrence of Arabia back to back and have similarly enjoyable time.
Fallout 1 and 2 are miles ahead of Fallout 3 (mostly due to uncanny valley phenomenon). Sure, the medium has changed a lot and modern consumers are used to more streamlined experience - my favorite example is the endless stream of Baldurs Gate "modern reimplementations" or rehashes, like Pilars of Eterniety that were too close to the original source, and then, suddenly, someone came up with Divinity, basically a Baldurs clone but with modern UI and QoL improvements.
But consoles are different.
This can truly be a window for the next generation to look back in the past.
I've been working on decompiling Dance Central 3 with AI and it's been insane. It's an Xbox 360 game that leverages the Kinect to track your body as your dance. It's a great game, but even with an emulator, it's still dependent on the Kinect hardware which is proprietary and has limited supply.
Fortunately, a Debug build of this game was found on a dev unit (somehow), and that build does _not_ have crazy optimizations in place (Link-time Optimization) that make this feat impossible.
I am not somebody that is deep on low level assembly, but I love this game (and Rock Band 3 which uses the same engine), and I was curious to see how far I could get by building AI tools to help with this. A project of this magnitude is ... a gargantuan task. Maybe 50k hours of human effort? Could be 100k? Hard to say.
Anyway, I've been able to make significant progress by building tools for Claude Code to use and just letting Haiku rip. Honestly, it blows me away. Here is an example that is 100% decompiled now (they compile to the exact same code as in the binary the devs shipped).
My branch has added over 1k functions now and worked on them[0]. Some is slop, but I wrote a skill that's been able to get the code quite decent with another pass. I even implemented vmx128 (custom 360-specific CPU instructions) into Ghidra and m2c to allow it to decompile more code. Blows my mind that this is possible with just hours of effort now!
47 comments
[ 3.1 ms ] story [ 65.2 ms ] threadOf course I am spoiled by Dolphin and their meticulous work, and the leap in N64 emulation, and PS3 emulation is way farther than I thought it could ever be.
But PCSX2 is mediocre. It reports the vast majority of the library in "green" emulation state, but that usually means there are glaring issues that someone is choosing to overlook, like shadows that are broken.
The Ace Combat games for example are all broken with the hardware accelerated renderer. Things run like garbage in the software renderer for a lot of games. Multiplayer functionality is spotty and hard to set up and poorly documented.
The state of emulation of that console generation is not up to snuff, save for Dolphin. It's still very much in the "Shut up, it works fine for Super Mario 64 so it works" mindset it seems.
This is true even of official emulators! The Xbox emulator that ran on the Xbox 360 has many games that are "officially supported" with serious issues. Forza Motorsport 1 has weird slowdowns on key tracks. I understand the serious hardware difficulties but I still wish emulation accuracy was an option.
The latter means that even in the absence of a JIT, you would need to achieve 100% code coverage (akin to unit testing or fuzzing) to perform static recompilation, otherwise you need to compile code at runtime at which point you're back to state of the art emulation with a JIT. The only real downside of JITs is the added latency similar to the lag induced by shader compilation, but this could be addressed by having a smart code cache instead. That code cache realistically only needs to store a trace of potential starting locations, then the JIT can compile the code before starting the game.
Otherwise, yeah, a normal emulator JIT basically points a recompiler at each jump target encountered at runtime, which avoids the static analysis problem. AFAIK translating small basic blocks and not the largest reachable set is actually desirable since you want frequent "stopping points" to support pausing, evaluating interrupts, save states, that kind of stuff, which you'd normally lose with a static recompiler.
Since they were able to port the interpreter over they have been able to start rapidly start porting over these titles even with a small volunteer team.
1. https://opengoal.dev/
2. https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp
However that approach will probably suit the least-ambitious PC-ports to PS2 (by studios that didn’t appreciate the difference) - rather as an ST emulator was a short cut to run the simplest Amiga games.
Back in the day, I wrote a simulator for the PS2’s vector units because Sony did not furnish any debugger for them. A month after I got it working, a Sony 2nd party studio made their VU debugger available to everyone… Anyway…
The good news is that the VU processors are actually quite simple as far as processors go. Powerful. Complicated to use. But, not complicated to specify.
This is made much simpler by the fact that the only documentation Sony provided was written by the Japanese hardware engineers. It laid out the bit-by-bit details of the instruction set. And, the bitwise inputs, outputs, delays and side effects of each instruction.
No guidance on how to use it. But, awesome docs for writing a simulator (or recompiler).
Note that this "recompilation" and the "decompilation" projects like the famous Super Mario 64 one are almost orthogonal approaches in a way that the article failed to understand; this approach turns the assembly into C++ macros and then compiles the C++ (so basically using the C++ compiler as a macro re-assembler / emulation recompiler in a very weird way). The famous Super Mario 64 decompilation (and openrct and so on) use the output from an actual decompiler which attempts to reconstruct C from assembly, and then modify that code accordingly (basically, converting the game's object code back into some semblance of its source code, which this approach does NOT do).
I would think that emulation of the original game as closely as possible would be the gold standard of preservation, and native ports would be a cool alternative. As described in the article, native ports are typically not faithful reproductions but enhanced to use the latest hardware.
Besides the library, the PS2 is the most successful video game console of all time in terms of number of units shipped, and it stayed on the market for over ten years, featured a DVD drive, and at one point was positioned by Sony not just as an entertainment appliance but as a personal computer, including their own official PS2 Linux distribution.
In a more perfect world, this would have:
(a) happened with a hypothetical hardware platform released after the PS2 but before the PS3, with specs lying in between the two: a smidge better than the former, but not quite as exotic as the latter (with its Cell CPU or the weird form factor; whereas the PS2's physical profile in comparison was perfect, whether in the original form or the Slim version), which could have:
(b) resulted in a sort of standardization in the industry like what happened to the IBM PC and its market of clones, with other vendors continuing to manufacture semi-compatible units even if/when Sony discontinued it themselves, periodically revving the platform (doubling the amount of memory here, providing a way to tap into higher clock speeds there) all while maintaining backwards compatibility such that you would be able to go out today and buy a brand new, $30 bargain-bin, commodity "PS2 clone" that can do basic computing tasks on it (in other words, not including the ability to run a modern Web browser or Electron apps), can play physical media, and supports all the original games and any other new games that explicitly target(ed) the same platform, or you could pay Steam Machine 2026 prices for the latest-gen "PS2" that retains native support for the original titles of the very first platform revision but unlocks also the ability to play those for every intermediate rev, too.
Sony intended it to be the evolution of Playstation Yaroze, fostering indie development, instead people used it mostly to run emulators on the PS2, hence why the PS3 version lost access to accelerated hardware for graphics.
PS2 Linux had hardware acceleration, the only difference was that the OpenGL inspired API did not expose all the capabilities of a regular DevKit.
Community proved that the development effort wasn't worth it.
The XBox arcade and ID@XBox programs have also taken these lessons into account, which is why you only see everyone running emulators on rooted XBoxes, not the developer mode ones.
The market of IBM PC clones only happened because of an IBM mistake, that was never supposed to happen, and IBM tried with the PS2 / MCA to take their control back, but the Pandora box was already open, and Compaq was clever with the way they did reverse engineer the BIOS.
Wasn't it also among the cheapest DVD players on the market back then?
2 out of 4 links in the article are messed up, that's mind boggling... On a tech blog!
Is that how far deep we've sunk to assert it wasn't written by AI?
As a movie geek I'm personally offended when someone says "oh, it's from 2017, it's an old movie!", or "I don't want to see anything from 90s, yuck" - and that's pretty common.
Of course, "Nosferatu, eine Symphonie des Grauens" is not for everyone, but I firmly believe that you can watch the new Dune and Lawrence of Arabia back to back and have similarly enjoyable time.
Fallout 1 and 2 are miles ahead of Fallout 3 (mostly due to uncanny valley phenomenon). Sure, the medium has changed a lot and modern consumers are used to more streamlined experience - my favorite example is the endless stream of Baldurs Gate "modern reimplementations" or rehashes, like Pilars of Eterniety that were too close to the original source, and then, suddenly, someone came up with Divinity, basically a Baldurs clone but with modern UI and QoL improvements.
But consoles are different.
This can truly be a window for the next generation to look back in the past.
Fortunately, a Debug build of this game was found on a dev unit (somehow), and that build does _not_ have crazy optimizations in place (Link-time Optimization) that make this feat impossible.
I am not somebody that is deep on low level assembly, but I love this game (and Rock Band 3 which uses the same engine), and I was curious to see how far I could get by building AI tools to help with this. A project of this magnitude is ... a gargantuan task. Maybe 50k hours of human effort? Could be 100k? Hard to say.
Anyway, I've been able to make significant progress by building tools for Claude Code to use and just letting Haiku rip. Honestly, it blows me away. Here is an example that is 100% decompiled now (they compile to the exact same code as in the binary the devs shipped).
https://github.com/freeqaz/dc3-decomp/blob/test-objdiff-work...
My branch has added over 1k functions now and worked on them[0]. Some is slop, but I wrote a skill that's been able to get the code quite decent with another pass. I even implemented vmx128 (custom 360-specific CPU instructions) into Ghidra and m2c to allow it to decompile more code. Blows my mind that this is possible with just hours of effort now!
Anybody else played with this?
0: https://github.com/freeqaz/dc3-decomp/tree/test-objdiff-work...