Super Mario 64 Has Arrived on PlayStation 1, But It Took Thousands of Builds to Get There

Off a CRT television, the footage captures Mario mid-jump in Bob-omb Battlefield. The camera follows him across familiar terrain. No emulator sits between the console and the screen. This moment marks real hardware execution after roughly 3000 separate builds and months of relentless iteration by one dedicated developer. The project began as a fork of earlier work by malucard, who first adapted the open-source Super Mario 64 decompilation for PlayStation 1 targets.

Early versions showed some promise, but they were rough around the edges, with trees floating around, animations stalling or breaking, and the camera refusing to act properly. In several instances, performance was sluggish. Still, these early builds demonstrated that the concept could be made to work, even if it wasn’t remotely playable on a console; however, that’s where Eyepatch Entertainment stepped in, and they decided to take on the challenge of getting it stable and running smoothly on a PlayStation’s far-from-generous 2MB of RAM.

Super Mario 64, of course, was initially intended for the Nintendo 64, which had more memory and rasterization processors. In contrast, the PlayStation ran a different CPU, had a simpler graphics system, and used a disc rather than a cartridge. Every image, procedure, and byte of data had to be rethought to function inside the PlayStation’s limited memory space to prevent the game from crashing all the time.

The first round of work was focused on getting the game to boot properly and not run out of memory. That’s a significant issue, and levels like Bob-omb Battlefield were practically impossible to work on owing to allocation concerns. The game occasionally crashed, and when it did, it was limited to a few frames per second. You have to fix the CD image handling to remedy the sector alignment and controller mode issues that were causing texture corruption. It was difficult to debug at first, simply comparing screenshots to what we expected to happen, but after he got GDB and backtracing using the PCSX-Redux emulator, things improved significantly.

Then, in a big breakthrough, he successfully got the game to run on an actual PlayStation. Now, I understand that sounds simple, but getting it to do anything close to what we saw in the emulator was a huge feat. Of course, it wasn’t all smooth sailing; a few additional concerns surfaced. For example, because of the way the framebuffer was flipped, Mario’s model was allowing in light from behind, causing the game to drop frames and freeze. So he fixed that and a few other bugs, and the game began to take shape. He changed the topography to just build the necessary level detail and simplified elements of the 3D models, such as Mario’s legs. This made a big impact in memory and performance.

Audio, oh boy, was a whole other ballgame. On an actual PlayStation, he would occasionally hear stillness or a lot of crackling. The music was encoded as 8-bit ADPCM, which worked flawlessly on the emulator, however the real device required 4-bit XA-ADPCM. We had to re-encode the entire audio. We changed the sector interleaving so that the PlayStation could read it properly, and we even included additional automated checks to ensure that the same issue did not occur again.

The good news is that the most recent builds are beginning to resemble what he envisioned. The skybox, with its flowing clouds and ocean backdrop, is operating perfectly. The Peach sequence is playing out exactly how he had imagined. After very rigorous tuning, Bob-omb Battlefield now runs at a consistent 20 to 28 frames per second. The Chain Chomp is loading properly, animating correctly, and even demolishing its gate on time. Even the door and painting transitions function without crashing the game, and the castle interior runs nicely once we set the frame rate to 30 FPS to avoid timing difficulties.