ShuriZma
/
Cxbx-Reloaded
mirror of https://github.com/Cxbx-Reloaded/Cxbx-Reloaded.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity

Updated Cxbx Reloaded overview (markdown)

PatrickvL 2017-08-02 11:48:43 +02:00
parent 1b43b56b5b
commit 2941947833
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Cxbx-Reloaded-overview.md

@ -25,13 +25,13 @@ The advantage of this approach is, that Cxbx doesn't need to emulate the CPU at
## Xbox Kernel (BIOS) ## Xbox Kernel (BIOS)
Cxbx-Reloaded contains it's own implementation of the Xbox kernel, which means there's no need to acquire a dump from your Xbox. Cxbx-Reloaded contains it's own implementation of the Xbox kernel, which means there's no need to acquire a dump from your Xbox.
In it's currenty form, the Cxbx-Reloaded kernel forwards many of the 378 kernel API's towards the host Windows kernel API's. __This restricts running Cxbx-Reloaded to operating systems that contain the Win32 API's, so-far Windows only!__ In it's current form, the Cxbx-Reloaded kernel forwards many of the 378 kernel API's towards the host Windows kernel API's. __This restricts running Cxbx-Reloaded to operating systems that contain the Win32 API's, so-far Windows only!__
Because many of the kernel API's are just forwards, some aspects of the Xbox kernel are not emulated well enough. Timings will differ, thread switching works differently, thread local storage must be patched, etc. etc. Because many of the kernel API's are just forwards, some aspects of the Xbox kernel are not emulated well enough. Timings will differ, thread switching works differently, thread local storage must be patched, etc. etc.
In the future, more API's will be replaced with an implementation that doesn't rely on Windows anymore, but will be build on top of an abstraction-layer, removing much of the dependancy on Windows. In the future, more API's will be replaced with an implementation that doesn't rely on Windows anymore, but will be build on top of an abstraction-layer, removing much of the dependency on Windows.
## High Level Emulation (HLE) vs Low Level Emulation (LLE) ## High Level Emulation (HLE) vs Low Level Emulation (LLE)
Cxbx-Reloaded historically emulates Xbox software by means of patching a huge set of functions present in the Xbox executable, and replacing these with an implementation that can run on the host. This process is called 'High Level Emulation', or HLE for short. To be able to do this reliably, the functions that need to be replaced have to be pin-pointed accuratly. For this, caustik (the initial developer of Cxbx, the parent project of which Cxbx-Reloaded is a fork), introduced a datastructure (called OOVPA tables) and accompanying scanning code. Read more on this elsewhere in this Wiki, Cxbx-Reloaded historically emulates Xbox software by means of patching a huge set of functions present in the Xbox executable, and replacing these with an implementation that can run on the host. This process is called 'High Level Emulation', or HLE for short. To be able to do this reliably, the functions that need to be replaced have to be pin-pointed accurately. For this, caustik (the initial developer of Cxbx, the parent project of which Cxbx-Reloaded is a fork), introduced a data structure (called OOVPA tables) and accompanying scanning code. Read more on this elsewhere in this Wiki,
In contrast to this, another approach to emulate a machine like the Xbox is not to find and patch functions, but to emulate only the hardware that these functions access. This is called 'Low Level Emulation', or LLE for short. In contrast to this, another approach to emulate a machine like the Xbox is not to find and patch functions, but to emulate only the hardware that these functions access. This is called 'Low Level Emulation', or LLE for short.
Cxbx-Reloaded in it's current form, is slowly migrating towards LLE, and offers a few experimental flags to enable LLE of the APU and/or the GPU. (And additional flag, called 'JIT'. More on this later, under 'JIT'). Cxbx-Reloaded in it's current form, is slowly migrating towards LLE, and offers a few experimental flags to enable LLE of the APU and/or the GPU. (And additional flag, called 'JIT'. More on this later, under 'JIT').
@ -41,7 +41,7 @@ For now, Cxbx-Reloaded only reliably supports HLE. Don't expect LLE to do anythi
Cxbx-Reloaded emulates the Xbox memory layout using a trick that allows so-called 'fast path' memory access, by mimicking the memory layout of the Xbox on the host OS. This involves the following steps: Cxbx-Reloaded emulates the Xbox memory layout using a trick that allows so-called 'fast path' memory access, by mimicking the memory layout of the Xbox on the host OS. This involves the following steps:
First, we apply these linker options to the Cxbx-Reloaded executable: First, we apply these linker options to the Cxbx-Reloaded executable:
* ImageBase is set to memory addres 0x00010000 (the lowest possible virtual memory address on both Xbox and Windows). * ImageBase is set to memory address 0x00010000 (the lowest possible virtual memory address on both Xbox and Windows).
* Relocation information is stripped, so Windows is forbidden to relocate Cxbx-Reloaded to another address. * Relocation information is stripped, so Windows is forbidden to relocate Cxbx-Reloaded to another address.
Furthermore, to be able to run Xbox code on the same virtual addresses as on real hardware, we apply these tricks: Furthermore, to be able to run Xbox code on the same virtual addresses as on real hardware, we apply these tricks:
@ -51,7 +51,7 @@ Furthermore, to be able to run Xbox code on the same virtual addresses as on rea
The downside to this is that the Cxbx-Reloaded is quite big (more than 67 MiB currently), but once compressed it's less than 3 MiB. Since Cxbx-Reloaded launches itself a second time for actual emulation, memory-requirements on the host are doubled to at least 256 MiB of memory (but expect much swapping when the host has less than 1 GiB of physical memory installed). The downside to this is that the Cxbx-Reloaded is quite big (more than 67 MiB currently), but once compressed it's less than 3 MiB. Since Cxbx-Reloaded launches itself a second time for actual emulation, memory-requirements on the host are doubled to at least 256 MiB of memory (but expect much swapping when the host has less than 1 GiB of physical memory installed).
## Hardware accesses ## Hardware accesses
Most Xbox hardware is mapped from 0xF0000000 to 0xFFFFFFFF. Cxbx-Reloaded reserves this memory-region using so-called 'guard-pages' which guarantees this memory range isn't used for anything else, and causes so-called access violations (or more accuratly, guard-page exceptions). When Cxbx-Reloaded emulates an Xbox instruction that accesses a hardware component (reading or writing to one of the MMIO memory-addresses), this access is trapped using a so-called 'exception handler'. This allows us to capture and emulate hardware accesses that aren't present on the host. Most Xbox hardware is mapped from 0xF0000000 to 0xFFFFFFFF. Cxbx-Reloaded reserves this memory-region using so-called 'guard-pages' which guarantees this memory range isn't used for anything else, and causes so-called access violations (or more accurately, guard-page exceptions). When Cxbx-Reloaded emulates an Xbox instruction that accesses a hardware component (reading or writing to one of the MMIO memory-addresses), this access is trapped using a so-called 'exception handler'. This allows us to capture and emulate hardware accesses that aren't present on the host.
When Cxbx-Reloaded operates entirely in HLE mode (which is the current default), most (if not all) hardware accesses are prevented entirely. So normally, this is mostly a moot point and you won't see slow-down in emulation because of this. When Cxbx-Reloaded operates entirely in HLE mode (which is the current default), most (if not all) hardware accesses are prevented entirely. So normally, this is mostly a moot point and you won't see slow-down in emulation because of this.