Fixed spelling errors

Overview-of-the-project-&-Glossary-of-terms.md

@@ -5,51 +5,51 @@
    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 intent to keep that speed (mainly contributed
-   by the fact we run code on the native CPU) and improve compatability by using Hybrid emulation of
-   various XBox hardware components.
+   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 behaviour and state of the emulated hardware.
+   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 acceses
+   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 is 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 replate their
-   behaviour using native hardware using OpenGL for graphics (and possibly something like OpenAL for
+   It won't be complete LLE, as we're planning to interpret hardware accesses and replace their
+   behavior using native hardware using OpenGL for graphics (and possibly something like OpenAL for
    audio and OpenIO for input/output).
 
-## XBox emulation
-   Emulation of the Microsoft XBox console platform. In contrast with many other platforms,
-   there are not many succesfull XBox emulators. The first one was made by Microsoft themselves,
-   for the XBox 360. Others are xqemu and the XBox/Chihiro driver in MAME, which are both quite
+## Xbox emulation
+   Emulation of the Microsoft Xbox console platform. In contrast with many other platforms,
+   there are not many successful Xbox emulators. The first one was made by Microsoft themselves,
+   for the Xbox 360. Others are xqemu and the Xbox/Chihiro driver in MAME, which are both quite
    complete, since they both use LLE, but as a result both are also quite slow.
   
-## XBox hardware
-   The main XBox hardware components are: a 733MHz Pentium 3 CPU, a NV2A GPU, and an MCPX APU.
+## Xbox hardware
+   The main Xbox hardware components are: a 733MHz Pentium 3 CPU, a NV2A GPU, and an MCPX APU.
 
-## XBox Kernel (BIOS)
-   Normally present in the BIOS of the XBox, the kernel offers more than 360 basic system functions.
+## 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' enviroment, so it's native code execution doesn't escape
+   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 resouces (documentation, tools, source code, etc.) as once distributed by Microsoft to XBox developers.
+## 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.
+## 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 a XDK or an Open Source alternative (like OpenXDK).
 
 ## Library
@@ -58,7 +58,7 @@
    Later XDK's used only one Version for all it's contained Libraries.
 
 ## Version
-   A four-digit number, indicating the release number of a Library (thus, also of all Symbols orginating from it)
+   A four-digit number, indicating the release number of a Library (thus, also of all Symbols originating from it)
 
 ## Location
    A unique memory address with contents of an XBE loaded into memory, ready for execution or read/write access
@@ -67,10 +67,10 @@
    A unique label, indicating either a Global or a Function.
 
 ## Global
-   A piece of data, uniquely indentified by a Symbol (thus, Globals are a subset of all Symbols)
+   A piece of data, uniquely identified by a Symbol (thus, Globals are a subset of all Symbols)
 
 ## Function
-   A piece of code, uniquely indentified by a Symbol (thus, Functions are a subset of all Symbols)
+   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 
@@ -86,11 +86,11 @@
    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).
    Patch are written over the found Function Locations, so a wrongly detected Location
-   will result in incorrecly placed Patches, resulting in incorrect emulation behaviour and
+   will result in incorrectly placed Patches, resulting in incorrect emulation behavior and
    potential crashes. Also, the implementation of a Patch greatly influences the level of
    accurateness of emulation. Some Patches don't do anything, whilst others try to mimic the
-   behaviour of the original Function as closely as possible. The end result is sometimes
-   very noticable (beeps & pops, graphics artifacts, etc) and sometimes you can't tell
+   behavior of the original Function as closely as possible. The end result is sometimes
+   very noticeable (beeps & pops, graphics artifacts, etc) and sometimes you can't tell
    the difference.
 
 ## AliasOovpa