Improve formatting, update LLE info, fix spelling, add links.

Cxbx-Reloaded-overview.md

@@ -4,41 +4,74 @@ Here some technical details on how Cxbx-Reloaded works.
 Cxbx-Reloaded is a single executable which operates in two different modes:
 
 1. If launched normally (without any command-line arguments), it will show a user-interface.
-2. To emulate Xbox software, Cxbx-Reloaded re-launches itself (with the path to the Xbox executable to run on the command-line). The emulated Xbox screen is put over the user-interface. At the end of emulation, the second instance terminates and the user-interface re-appears.
+2. To emulate Xbox software, Cxbx-Reloaded relaunches itself (with the path to the Xbox executable to run on the command-line).
+The emulated Xbox screen is then put over the user-interface.
+At the end of emulation, the second instance terminates and the user-interface reappears.
 
-If another process launches Cxbx-Reloaded (for instance, a user starts a short-cut via Windows Explorer) with a command-line argument, there's no parent process, so when emulation ends in this scenario, the Cxbx-Reloaded process terminates entirely.
+If another process launches Cxbx-Reloaded (for instance, a user starts a shortcut via Windows Explorer) with a command-line argument, there's no parent process, so when emulation ends in this scenario, the Cxbx-Reloaded process terminates entirely.
 
 # Emulation aspects
 
 ## Operating System
-Cxbx-Reloaded currently runs on 64-bit Windows 7 and up. (More on this later, under 'Xbox Kernel')
+Cxbx-Reloaded currently runs on 64-bit Windows 7 and up.
+
+(More on this later, under _[Xbox Kernel](#xbox-kernel-bios)_)
 
 ## CPU 'emulation'
-Cxbx-Reloaded emulates the Xbox using direct code execution. This means most of the CPU instructions the Xbox would execute, are executed directly on the host machine, without any modification or interpretation. _This restricts running Cxbx-Reloaded to CPU's that are compatible with the Xbox Pentium 3 Coppermine CPU!_
+Cxbx-Reloaded emulates the Xbox using direct code execution.
 
-The advantage of this approach is, that Cxbx doesn't need to emulate the CPU at all, and offers native, 'faster-than-real-hardware' emulation speeds. Admittedly, executing Xbox code as-is does bring with it a few complexities;
+This means most of the CPU instructions the Xbox would execute, are executed directly on the host machine, without any modification or interpretation.
+
+_This restricts running Cxbx-Reloaded to CPU's that are compatible with the Xbox Pentium 3 Coppermine CPU!_
+
+The advantage of this approach is that Cxbx doesn't need to emulate the CPU at all, and offers native, 'faster-than-real-hardware' emulation speeds.
+
+Admittedly, executing Xbox code as-is does bring with it a few complexities:
 * some opcodes are prohibited to be executed in user-mode on Windows
 * IN/OUT opcodes must be emulated
 * CPU-specific opcodes (like CPUID) still need to be emulated
 * the FS segment layout differs between Xbox and Windows
-* mapping physical to virtual addresses (using the MMU) isn't allowed (More on this later, under 'Hardware accesses' and 'Contiguous memory'.)
+* mapping physical to virtual addresses (using the MMU) isn't allowed
+(More on this later, under _[Hardware accesses](#hardware-accesses)_ and _[Contiguous memory](#contiguous-memory)_.)
 
 ## 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.
-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.
-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.
+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.
+
+In the future, more APIs will be replaced with an implementation that doesn't rely on Windows anymore, and will be built on top of an abstraction-layer, removing much of the dependency on Windows.
 
 ## 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 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,
+Cxbx-Reloaded historically emulates Xbox software by patching a huge set of functions present in the Xbox executable, and replacing these with an implementation that can run on the host.
 
-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').
-For now, Cxbx-Reloaded only reliably supports HLE. Don't expect LLE to do anything (really, it won't).
+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 the 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.
+
+Cxbx-Reloaded in it's current form, is slowly migrating towards LLE, and offers an experimental flag to enable LLE of the GPU.
+
+APU and JIT LLE are disabled due to being unimplemented.
+
+For now, Cxbx-Reloaded only reliably supports HLE and LLE GPU.
 
 ## Emulating Xbox memory layout
-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:
 * ImageBase is set to memory address 0x00010000 (the lowest possible virtual memory address on both Xbox and Windows).
@@ -48,27 +81,62 @@ Furthermore, to be able to run Xbox code on the same virtual addresses as on rea
 * All emulation code is moved 64 MiB upwards, by reserving an empty-initialized virtual memory placeholder **as the very first thing** (before any code appears in the Cxbx-Reloaded `.text` section).
 * This placeholder is used for all Xbox virtual memory operations.
 
-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.
+
+Expect swapping when the host has less than 1 GiB of physical memory installed.
 
 ## 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 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.
+Most Xbox hardware is mapped from 0xF0000000 to 0xFFFFFFFF.
 
-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.
+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).
 
-However, when it happens, exception handling is slow, as it incurs a context-switch (storing and restoring the entire state of a thread) and has to figure out which address needs which handling. Therefore, there are plans to dynamically replace all Xbox instructions that access hardware registers with a small patch that will handle the hardware access directly. (More on this later, under 'JIT').
+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.
+
+However, when it happens, exception handling is slow, as it incurs a context-switch (storing and restoring the entire state of a thread) and has to figure out which address needs which handling.
+
+Therefore, there are plans to dynamically replace all Xbox instructions that access hardware registers with a small patch that will handle the hardware access directly.
+
+(More on this later, under _[JIT](#jit)_.)
 
 
 ## Contiguous memory
-In addition to the hardware memory range, the Xbox has a memory range that's shared between the CPU and the GPU, called 'Contiguous memory'. For the CPU, this memory is mapped to addresses 0x80000000 to 0x84000000. For the GPU, this memory is addressable from 0x00000000 to 0x04000000.
+In addition to the hardware memory range, the Xbox has a memory range that's shared between the CPU and the GPU, called 'Contiguous memory.'
+
+For the CPU, this memory is mapped to addresses 0x80000000 to 0x84000000.
+
+For the GPU, this memory is addressable from 0x00000000 to 0x04000000.
+
 Since we emulate the GPU, we can access this memory solely in the CPU memory-mapped space, which we reserve at startup.
 
 ## Tiled memory
-Tiled memory is not yet fully researched for Cxbx-Reloaded. Currently, Cxbx-Reloaded just maps the same memory in use for 'Contiguous memory' towards the tiled memory region (0xF0000000 to 0xF4000000). _This is probably not sufficient and will need more research and emulation._
+Tiled memory is not yet fully researched for Cxbx-Reloaded.
+
+Currently, Cxbx-Reloaded just maps the same memory in use for 'Contiguous memory' towards the tiled memory region (0xF0000000 to 0xF4000000).
+
+_This is probably not sufficient and will need more research and emulation._
 
 ## JIT
 **TODO**
 
 ## Rendering
-Xbox renders using the Nvidia NV2A GPU. Most software written for the Xbox was developed with some version of the official "Xbox Development Kit" (XDK for short), which offered Direct3D 8 like features. Therefor, Cxbx-Reloaded uses Direct3D 8.1 as rendering API, although it's planned to port to Direct3D 9 (for HLE) and OpenGL (for LLE). Vulkan is currently not under consideration.
+Xbox renders using the Nvidia NV2A GPU.
 
-Some features the NV2A offered are not available on Direct3D 8 (not even on 9), so for those Cxbx-Reloaded tries to convert it to host-compatible rendering. For example, some texture-formats (like P8, R8B8 and others) are not available on host Direct3D, and are thus converted into ARGB (the most widely supported texture format). Vertex coordinates undergo a similair conversion.
+Most software written for the Xbox was developed with some version of the official "Xbox Development Kit" (XDK for short), which offered Direct3D 8 like features.
+
+Therefore, Cxbx-Reloaded uses Direct3D 8.1 as its rendering API, although it's planned to port to Direct3D 9 (for HLE) and OpenGL (for LLE).
+
+Vulkan is currently not under consideration.
+
+Some features the NV2A offered are unavailable on Direct3D 8 or even 9, so for those Cxbx-Reloaded tries to convert it to be host-compatible.
+
+For example, some texture-formats like P8, R8B8 and others are not available on host Direct3D, and are thus converted into ARGB, the most widely supported texture format.
+
+Vertex coordinates undergo a similar conversion.