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

Fixed headers

PatrickvL 2017-08-15 09:56:55 +02:00
parent 28cf986fff
commit 0f990888e2
1 changed files with 5 additions and 5 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

10
Maintaining-OOVPA's-for-HLE-function-detection.md

@ -1,9 +1,9 @@
#Introduction
# Introduction
Cxbx in it's current form, uses HLE (High Level Emulation). This roughly means, that code in an XBE ("XB"ox "E"xecutable) is executed as-is. However, any code that accesses Xbox hardware registers will cause problems, since this hardware is not present in the host system running Cxbx.
So, for HLE to work, Cxbx needs to prevent those hardware accesses. Cxbx does this by scanning for problematic pieces of code, and patches these with replacement code, that emulates the original behavior.
#Scanning
# Scanning
Cxbx scans the contents of an XBE using so-called OOVPA's. OOVPA stands for "Optimized (Offset, Value)-Pair Array".
It's a data-structure that was thought up by Aaron Robinson (also known as Caustik), the initiator of Cxbx back in 2003.
@ -22,12 +22,12 @@ Scanning for functions using OOVPA's goes roughly like this:
* If one or more values mismatch, it's a miss, and scanning continues through the rest of the address range.
* If the entire range is checked without finding a match, the OOVPA (or rather, the function it describes) is considered not present in the executable.
#Patches
# Patches
Together with the registration of an OOVPA in an OOVPATable, a replacement function, called a patch, can be mentioned. Registrations that don't mention a patch are not patched (obviously) but are still useful for scanning. (See the XRef description below).
If an OOVPA is matched to a location in the XBE, and the OOVPA is registered with a patch, that location is overwritten with a call to the patch, which emulates this function. Thus, the problem of hardware accesses is avoided and emulated instead.
#XRefs
# XRefs
Apart from OOVPA's, Cxbx contains a set of so-called XRef numbers (short for cross-reference numbers), which are unique ID's to identify a function by. Some OOVPA's are defined including one of these XRef numbers.
When there's a match found for an OOVPA that has an XRef, the matching location is written to a list, indexed by the XRef number. Once there's a location recorded for an XRef, it's final, meaning that Cxbx will skip a scan with any other OOVPA mentioning that same XRef number.
@ -36,7 +36,7 @@ Some OOVPA's contain an XRef that must be checked for, together with the (Offset
Checking for an XRef means comparing the recorded location to the 4 bytes that are present on the mentioned offset. This is compared as a direct (absolute) reference, and as an indirect (address-relative) reference - either way, if that matches the recorded location, the XRef check holds, and all other (Offset, Value) pairs are checked. If the XRef check fails, the rest of the OOVPA is not checked, it's deemed a miss, scanning continues with the next address.
#Maintaining OOVPA's
# Maintaining OOVPA's
Each OOVPA must be unique from all other OOVPA's, otherwise, the same location could be matched to more than one function, which would lead to incorrectly placed patches, which leads to unpredictable behavior, probably crashes.
An OOVPA is formed by choosing a few offsets in the machine code of that function, and writing down their byte values, in such a way that no other function is identifiable with these offsetted bytes.