Tatsh Network

Guess what, there isn't one and there won't be for a while. If you want an idea of how long this will take, take a look at the DEAD project PearPC which runs Mac OS X on x86 processors (I can't get it to compile for x86-64 for anything but that's because of very specific assembly written for x86 not compatible with AMD64).

PearPC in 2010: While feature-filled enough to run OS X (at least up to 10.4 Tiger), it's still VERY slow in comparison to the real machine (I own a G3 so I know).

The very problem is PPC->x86 code translation, something that nobody has really researched or figured out in a way that is practical (at least not within public research). Strangely enough, x86->PPC translation (old emulators that ran Mac OS and OS X; Connectix mainly) was practical enough to run at least Windows 98. I doubt XP would do any good on them but that's probably because PPC's MHz measurement really is NOT equivalent in any way to x86. The PPC architecture also lacks numerous features found within x86 CPUs that makes them faster in terms of things you can do vs MHz.

The only good thing about 360 is that like the Nintendo 64, any developer could try HLE (high-level emulation), just ilke with UltraHLE the Nintendo 64 SDK C calls were emulated instead (and still are for the most part), attempting to avoid ALL CPU translation. Today, CPUs are fast enough to go from N64's RISC->x86 without too much of an issue. UltraHLE you must remember was only compatible with < 10? games when it was released. Still was a huge deal. I'm sure many can remember buying a Voodoo card perhaps just to run UltraHLE and see it in action with their own eyes (there was no YouTube back then).

And in that sense, that is how Cxbx works (a somewhat active in development Xbox emulator). It works by translating the function calls (and luckily XBEs are x86 so no need for CPU translation whatsoever). The developer is making great progress but what he has found is that with Xbox and running XBEs as if they are EXEs (since there will be no recompilation because they are the same instruction set), it depends HEAVILY on knowing what SDK version the developers used. Some were leaked, some were not. This could be the case with the Xbox 360 ALONGSIDE CPU translation since all the code must be translated somewhere along the line from PPC64 to x86/x86-64 (what 99% of PCs are using).

There are a few ways to emulate Xbox 360. The MESS project would accept only one approach and this would mean slowness until there is a CPU that is maybe 500x faster than the Xbox 360 CPU + GPU combined before you could 'game' with it. That method is code translation, from PPC64 to whatever target machine their is. They have a very nice API for doing this abstractly, but regardless it will be slow. They also will not accept that XEXs have to be in a decrypted form before running, or even that the ISOs generated by Xbox Backup Creator have ANY modifications whatsoever. The goal is to emulate the entire machine perfectly with files as perfectly copied as they can be and it does not matter if it is for practical use (like gaming or even making demos/homebrew/etc).

The other way to emulate the Xbox 360 is through HLE. This involves:

• Implement ALL function calls AND specific versions of them that may have changed between SDK versions.
• Emulator must be able to tell which SDK was used and switch to the proper mode (the same way Cxbx does).
• A CPU translation to be used minimally should be created (to translate PPC64 to x86 and x86-64 at minimum).
• JIT compiler/dynamic recompiler?
• Map DX9 calls to the same ones on Windows (and for other platforms, use something like wined3d).
• This will require a few not so legal things: NAND copy (you can get it legally from your own machine though), and if you want, a game (you can legally back up your own copies).

So I wish luck to anyone who starts such an endeavour. Please make it run for Linux too natively.