Table of Contents
Cxbx-Reloaded rationale
Cxbx has been around since 2002. It gained a spin-off with Dxbx in 2008-2011, but both attempts had a very low compatibility level.
Cxbx-Reloaded is an attempt to bring back life into the Cxbx codebase and improve it so it can support more software than ever before.
We believe Cxbx-Reloaded has a right to exist as a Hybrid emulator, covering the middle-ground between the LLE based emulators and the completely HLE based old Cxbx, which offered one remarkable feature:
Faster-than-original emulation speed.
We intend to keep that speed (mainly contributed by the fact we run code on the native CPU) and improve compatibility by using Hybrid emulation of various Xbox hardware components.
Glossary of terms used in this project:
LLE
Low Level Emulation, a technique in which an emulated piece of software is executed by way of emulating the original hardware.
This is done by a piece of code that replicates as close as possible the behavior and state of the emulated hardware.
HLE
High Level Emulation, a technique in which an emulated piece of software is executed without emulating the original hardware.
This can done when the emulated system and the host use comparable hardware.
In the case of Cxbx, the CPU code is executed as-is most of the time, and hardware accesses to the video, audio and input/output devices are bypassed using Patches over the original Functions.
Hybrid emulation
A mix of HLE and LLE, in which some parts are HLE'ed, while other parts are LLE'ed.
In the case of Cxbx, we're underway to emulate the graphics and sound hardware using a form of LLE.
It won't be complete LLE, as we're planning to interpret hardware accesses and replace their behavior using native hardware with OpenGL for graphics, something like OpenAL for audio, and OpenIO for input/output.
Xbox emulation
In contrast with other platforms, there are not many successful Xbox emulators.
The first one was made by Microsoft themselves for the Xbox 360.
They also made an emulator for the Xbox One, and Xbox One X.
Others such as xqemu and the Xbox/Chihiro driver in MAME are both quite complete and use LLE, but as a result are also quite slow.
Xbox hardware
The main Xbox hardware components are:
- 733MHz Pentium 3 CPU
- NV2A GPU
- MCPX APU
Xbox Kernel (BIOS)
Normally present in the BIOS of the Xbox, the kernel offers more than 360 basic system functions.
These functions deal with memory reservation, manage kernel objects (like hardware timers, mutexes, semaphores, storage devices, symbolic links, files, etc.) and accesses to hardware (like PCI, EEPROM, etc.).
Cxbx contains it's own implementation of the Kernel, as we need our emulator to create it's own sandbox environment so it's native code execution doesn't escape the sandbox and overloads, or otherwise wreaks havoc on the native system.
Xbox Development Kit (XDK)
A package full of resources (documentation, tools, source code, etc.) as once distributed by Microsoft to Xbox developers.
Xbox Executable (XBE)
A binary file containing all code for a piece of software that can be run on the Xbox.
An XBE file is generated using a compiler toolchain of either an XDK or an Open Source alternative (like OpenXDK).
Library
A binary object file distributed with an XDK, containing Symbols - code and data needed for specific tasks.
Libraries are linked (inserted) into XBE files.
Older XDKs contained Libraries with different versions.
Later XDKs used only one Version for all it's contained Libraries.
Version
A four-digit number, indicating the release number of a Library (also all of the Symbols originating from it)
Location
A unique memory address with contents of an XBE loaded into memory, ready for execution or read/write access.
Symbol
A unique label, indicating either a Global or a Function.
Global
A piece of data, uniquely identified by a Symbol. (thus, Globals are a subset of all Symbols)
Function
A piece of code, uniquely identified by a Symbol. (thus, Functions are a subset of all Symbols)
XRef
A cross-referenced Symbol Location from within a Function.
OOVPA
A data structure used as a 'thumbprint' for searching for the Location of a Function.
Symbol detection
A method that tries to find Symbol Locations in an XBE, in the case of Cxbx using OOVPA's.
Patch
A piece of emulation code, used as a replacement, written over the Location of a Function.
This original Function is found using an OOVPA, resulting in the Location of both Functions and in some cases also XRef-erenced Symbols (thus: either Functions or Globals).
Patches are written over the found Function Locations, so an incorrectly detected Location will lead to incorrectly placed Patches, resulting in incorrect emulation and potential crashes.
The implementation of a Patch greatly influences the accuracy of emulation.
Some Patches don't do anything, whilst others try to mimic the behavior of the original Function as closely as possible.
The end result is sometimes very noticeable (beeps & pops, graphical artifacts, etc) and other times you can't tell the difference.
AliasOovpa
An alternative OOVPA, used when a Patch may also be applied to another OOVPA 'thumbprint.'
This is mainly used for XBE's generated with LTCG which mangles Function contents somewhat.
LTCG
An optimizing linking technique sometimes used when compiling XBE's, resulting in faster code.
This results in slight deviations in the way Functions are represented in the XBE.
This makes Function detection unreliable, resulting in unused Patches, and emulation errors.
Name
A string used for debugging, associated with a combination of a Symbol (via an Oovpa) and Version.
In some cases expanded with additional information.
Home
Usage:
Development:
- Cxbx Reloaded overview
- Developer notes
- Child Process Debugging
- Developing Homebrew and test programs
- HLE v2 Database Method
- Maintaining OOVPAs for HLE function detection
- OOVPA sorting
- Updating a sub moduled Git repository
- Rebase Line Ending Fix
- Xbox D3D drawing via NV2A Kelvin
Other links: