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.
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.
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.