Inspired by the N64: Recompiled project, XenonRecomp does something similar, except for the PowerPC-equipped Microsoft Xbox 360 game console. Based around the triple-core IBM CPU codenamed ‘Xenon‘, the Xbox 360 was released in 2005 and generally quite successful over its lifespan despite its Red Ring of Death issues. Although the current Xbox Series X supports running a number of Xbox 360 games, this is done via emulation and only 632 games out of 2,155 are supported.
This is where XenonRecomp not only promises turning the games into native (x86) software, but also allowing for a range of graphical improvements. Best of all, it allows for Xbox 360 games to be preserved instead of linked to an obsolete console. That said, much like with N64Recomp, it’s not a simple matter of running a tool over the PPC binary. You’re expected to have in-depth systems knowledge, with the tools in XenonRecomp assisting with the decompilation (into C++) and the recompilation into x86 binaries, but support for PPC instructions, VMX (vector instructions) and aspects like jump table conversion and (currently missing) MMIO support are likely to present an enterprising developer with hours of fun to implement and debug when issues arise.
After recompilation into an x86 binary, the required assets are then expected to be copied in from a (legal) copy of the original game. As a proof of concept the game Sonic Unleashed has been ported in this manner, with [Modern Vintage Gamer] running through this port and the improvements made over the original game, as well as some issues you may encounter:
Last month I decided to take on the easy task of using Ghidra to port “Tanks” from Pegasus (Terminator) to Xbox 360. Because, you know, why not challenge myself with a project that’s clearly meant to be a walk in the park? After what felt like an eternity of failing and reloading the game executable into Ghidra, I was ready start work. How hard could it be to translate some 8-bit woofery into a proper PowerPC code? Spoiler: very hard. Apparently, the original developers had a flair for obfuscation. I spent hours trying to make sense of the code only to realize that Ghidra “user-friendly” interface is about as intuitive as a bondage rack when you’re looking for a toilet in the dark. I thought I’d be able to whip up a quick port, but instead, I found myself knee-deep in a labyrinth of functions that seemed fail at random. In the end, I didn’t even get close to a working version. But hey, at least I got to enjoy the delightful experience of Ghidra as promoted by MVG. Maybe I’ll just stick to playing the original on the Pegasus… at least it doesn’t require a PhD in cryptography to enjoy.
Ghidra is definitely an absolute nightmare to use, but it was also intended primarily as a decompiler rather than a straight-up disassembler. For disassembling and reverse-engineering code – and being able to see code running “live” – I stick purely with the MAME debugger.
And yes, MVG is a total hack.
This has “How hard can art be? I should just be able to pick up a chisel and a rock and produce a copy of Michelangelo’s David” energy.
Complex tasks require tools, skills, knowledge, and practice. Assuming that the tool will do all the hard work for you is setting yourself up for instant failure.
And there’s not much reason for the coders of a NES game (I think the game you’re referring to is actually “Battle City” for the NES, as the Pegasus is a NES clone?) to deliberately obfuscate things… that’s just what you get when you hand-code assembly for a small platform with quirky hardware. You don’t have the luxuries of a standard library or a flat memory space or an OS (or a compiler from a high-level language!) Everything is custom.
Just being “8-bit” doesn’t mean it’s easy to reverse engineer – often it can mean the opposite. Ghidra can certainly manage to some extent but most of the people working on it are targetting much more modern platforms with a much more convenient execution environment.
The biggest difficulty I found when I tried similar was the lack of a clear source of good info for getting up to speed. Things like how to extract assets to separate them from code and get started in general.
Another issue I had was I tried a few decomp projects and couldn’t get them to work despite taking the docker option so all the dependencies should’ve been handled.
I absolutely understand that it’s not easy but it feels like the documentation might be lacking so if you aren’t already in the groups working on these things, you will have to bootstrap everything besides the game too.
This is where I am with most modern tools, I “grew up” with 6502, 805x and PIC ASM so the tools were very simple, easy to learn, then C came along and the tools have become so complex that most of my life is spent working out (not always successfully) how to get them to work.
Ghidra is undoubtedly useful but so very complex that I’m never quite sure I’ve got sensible results from it, which in turn makes it less likely to be a tool I will use and learn.
However, I did find the Hackaday series of videos (Ghidraninja I think?) very useful..
Maybe change the title of the article? The project seems to be named XenonRecomp, but the title says XenonDecomp.
Thanks!
Man I hope someone can make a decompiled version of blitz 2, there’s no good way to play it even with emulators