--CXBX PC EMULATOR--

08/27/03

Cxbx : PC XBox Emulator

Cxbx's Emulation Theory

The basic theory behind Cxbx is a tasty blend of HLE (High Level Emulation), and extremely efficient direct code execution. Since the Xbox uses an Intel Pentium processor, a large percentage of the code (most importantly, the code that tends to eat up the CPU) can be executed directly. This means there is no need for DynaRec (Dynamic Recompilation), which saves alot of CPU and RAM. Emulators such as UltraHLE and Project64 have proven that High Level Emulation is a really great way to achieve high performance. Cxbx takes this idea and, because of the Xbox's architecture, takes it to the next level by combining it with direct code execution. The result is speed and accuracy.

Here is a progress report I wrote a while back for my student project.

Goal Checklist

  Xbox Architecture Research

The first step to creating an Xbox Emulator was determining the hardware and software systems used by the Xbox. Since the Xbox is pretty much a PC dressed up like a console, the hardware component was easy enough. The software side was a bit more complicated. The Xbox uses a stripped down and partially modified Windows 2000 Kernel. The Xbox also only executes a single process at a time.

In order to emulate an Xbox game, it is necessary to simulate the game's environment. For the Xbox, this means making the game believe that it is running on a very specific set of PC hardware, running a very specific operating system. The operating system is simulated by intercepting kernel function calls, and wrapping them around existing NTDLL functions within Windows 2000 and Windows XP. The specific hardware is simulated by intercepting code that is known to touch the hardware at the lowest level possible. For Direct3D, this means simulating the Direct3D API by wrapping it around the windows Direct3D API.

  Xbe to Exe Conversion

In order to give an Xbox game the chance to execute, it must first be loaded as a new process, with specific environmental requirements. This task was accomplished by analyzing the XBE (Xbox Executable) file format, and finding a suitable conversion to the PE (Windows Exe) file format. During the time this conversion was being programmed, the XBE File Format was documented.

It is also necessary to prepend crucial initialization code at the beginning of the converted executable, in order to analyze the loaded XBE file and hijack all necessary functions. This is done by appending a special section to the executable, and altering the entry point.

  Thread Local Storage

Typically, a multi-threaded environment will provide some way for the programmer to access thread-specific data. In x86 Win32, this is done using the FS segment selector register. Unfortunately, the Xbox and Win32 do this just a tad bit differently. The idea is the same, but the structures are a little bit different. After banging my head against a few walls, and brute force hacking my way around to figure out exactly how the Xbox does it's TLS, I was able to stabilize a very efficient method for handling the differences. TLS is actually not used very heavily in games. It is, however, used by the CRT and must be emulated correctly.

  Kernel Hijacking

The basic purpose of the Xbox operating system is to provide Xbox games with a stable and efficient environment to run inside of. Typically, the closest an Xbox game programmer will get to the hardware is through the Xbox Kernel's API interface. Cxbx takes over this interface, and mimics the expected behavior of the Xbox operating system. Much of the API is wrapped almost directly around the Win2k/XP NTDLL interface. This is very efficient, and leaves very little overhead.

  High Level Function Interception

In addition to the Xbox Kernel API interface, Xbox games use statically linked libraries that directly access the NVidia chip and other hardware components. In order to allow an Xbox game to run on a PC, these libraries must be located, intercepted, and emulated and/or wrapped around existing Windows API. If you are familiar with IDAPro, the concept of FLIRT libraries is very similar to the technique used by Cxbx. Taking advantage of the fact that even relocatable libraries have distinguishing characteristics, Direct3D and other APIs can be located inside of the virtual address space of a loaded XBE file, hooked, and emulated.

  Complete Direct3D Interception/Emulation

Direct3D is a complex system in itself. In addition to this complexity is the added optimizations provided on the Xbox system. Since it is safe for the developer to assume a very specific set of hardware, many pieces of code are literally removed by an optimizing compiler. Other pieces of code have changed in significant ways from Windows Direct3D. There are also many Xbox specific features which must be emulated, including hardware specific precompiled texture formats, vertex and pixel shaders, CPU optimized routines, texture swizzling, special alpha ops, etc. In order for a game to not only run but look good, these features must be accurated emulated.

  Sound and Network Support

The depth of the Cxbx project is significant enough that certain aspects were basically ignored for the time being. Relatively speaking, sound and network support are non-crucial features that can be implemented after retail games become playable. For the time being, there is no support for these two components. In the big picture, these features are relatively easy to add

Screenshots

.