Fix some typos on OAM and Rendering articles

src/OAM_Corruption_Bug.md

@@ -1,6 +1,6 @@
 # OAM Corruption Bug
 
-There is a flaw in the Game Boy hardware that causes trash to be written
+There is a flaw in the Game Boy hardware that causes rubbish data to be written
 to OAM RAM if the following instructions are used while their 16-bit content
 (before the operation) is in the range $FE00–$FEFF and the PPU is in mode 2:
 
@@ -64,20 +64,20 @@ operations are on 16-bit words.
 
 ### Write Corruption
 
-A write corruption corrupts the currently access row in the following
+A "write corruption" corrupts the currently access row in the following
 manner, as long as it's not the first row (containing the first two
 sprites):
 
--   The first word in the row is replaced with this bitwise expression:
-    `((a ^ c) & (b ^ c)) ^ c`, where `a` is the original value of that
-    word, `b` is the first word in the preceding row, and `c` is the
-    third word in the preceding row.
--   The last three words are copied from the last three words in the
-    preceding row.
+- The first word in the row is replaced with this bitwise expression:
+  `((a ^ c) & (b ^ c)) ^ c`, where `a` is the original value of that
+  word, `b` is the first word in the preceding row, and `c` is the
+  third word in the preceding row.
+- The last three words are copied from the last three words in the
+  preceding row.
 
 ### Read Corruption
 
-A read corruption works similarly to a write corruption, except the
+A "read corruption" works similarly to a write corruption, except the
 bitwise expression is `b | (a & c)`.
 
 ### Write During Increase/Decrease
@@ -92,18 +92,17 @@ If a register is increased or decreased in the same M-cycle of a write,
 this will effectively trigger both a read **and** a write in a single
 M-cycle, resulting in a more complex corruption pattern:
 
--   This corruption will not happen if the accessed row is one of the
-    first four, as well as if it's the last row:
-    -   The first word in the row preceding the currently accessed row
-        is replaced with the following bitwise expression:
-        `(b & (a | c | d)) | (a & c & d)` where `a` is the first word
-        two rows before the currently accessed row, `b` is the first
-        word in the preceding row (the word being corrupted), `c` is the
-        first word in the currently accessed row, and `d` is the third
-        word in the preceding row.
-    -   The contents of the preceding row is copied (after the
-        corruption of the first word in it) both to the currently
-        accessed row and to two rows before the currently accessed row
--   Regardless of wether the previous corruption occurred or not, a
-    normal read corruption is then applied.
-
+- This corruption will not happen if the accessed row is one of the
+  first four, as well as if it's the last row:
+  - The first word in the row preceding the currently accessed row
+    is replaced with the following bitwise expression:
+    `(b & (a | c | d)) | (a & c & d)` where `a` is the first word
+    two rows before the currently accessed row, `b` is the first
+    word in the preceding row (the word being corrupted), `c` is the
+    first word in the currently accessed row, and `d` is the third
+    word in the preceding row.
+  - The contents of the preceding row is copied (after the
+    corruption of the first word in it) both to the currently
+    accessed row and to two rows before the currently accessed row
+- Regardless of whether the previous corruption occurred or not, a
+  normal read corruption is then applied.

src/Rendering.md

@@ -1,14 +1,13 @@
-
 # Rendering Overview
 
 The Game Boy outputs graphics to a 160x144 pixel LCD, using a quite complex
 mechanism to facilitate rendering.
 
 ::: warning Terminology
 
-Sprites/graphics terminology can vary a lot among different platforms, consoles, 
+Sprites/graphics terminology can vary a lot among different platforms, consoles,
 users and communities. You may be familiar with slightly different definitions.
-Keep also in mind that some of the definitions refers to lower (hardware) tools
+Keep also in mind that some definitions refer to lower (hardware) tools
 and some others to higher abstractions concepts.
 
 :::
@@ -17,13 +16,13 @@ and some others to higher abstractions concepts.
 
 Similarly to other retro systems, pixels are not manipulated
 individually, as this would be expensive CPU-wise. Instead, pixels are grouped
-in 8x8 squares, called *tiles* (or sometimes "patterns"), often considered as
+in 8x8 squares, called _tiles_ (or sometimes "patterns"), often considered as
 the base unit in Game Boy graphics.
 
 A tile does not encode color information. Instead, a tile assigns a
-*color ID* to each of its pixels, ranging from 0 to 3. For this reason,
-Game Boy graphics are also called *2bpp* (2 bits per pixel). When a tile is used
-in the Background or Window, these color IDs are associated with a *palette*. When
+_color ID_ to each of its pixels, ranging from 0 to 3. For this reason,
+Game Boy graphics are also called _2bpp_ (2 bits per pixel). When a tile is used
+in the Background or Window, these color IDs are associated with a _palette_. When
 a tile is used in an OBJ, the IDs 1 to 3 are associated with a palette, but
 ID 0 means transparent.
 
@@ -43,11 +42,11 @@ but it works for the most part.
 
 ### Background
 
-The background is composed of a *tilemap*. A tilemap is a
+The background is composed of a _tilemap_. A tilemap is a
 large grid of tiles. However, tiles aren't directly written to tilemaps,
 they merely contain references to the tiles.
 This makes reusing tiles very cheap, both in CPU time and in
-required memory space, and it is the main mechanism that helps working around the
+required memory space, and it is the main mechanism that helps work around the
 paltry 8 KiB of video RAM.
 
 The background can be made to scroll as a whole, writing to two
@@ -60,19 +59,19 @@ It is fairly limited: it has no transparency, it's always a
 rectangle and only the position of the top-left pixel can be controlled.
 
 Possible usage include a fixed status bar in an otherwise scrolling game (e.g.
-*Super Mario Bros. 3*).
+_Super Mario Bros. 3_).
 
 ### Objects
 
 The background layer is useful for elements scrolling as a whole, but
 it's impractical for objects that need to move separately, such as the player.
 
-The *objects* layer is designed to fill this gap: *objects* are made of 1 or 2 stacked tiles (8x8 or 8x16 pixels)
+The _objects_ layer is designed to fill this gap: _objects_ are made of 1 or 2 stacked tiles (8x8 or 8x16 pixels)
 and can be displayed anywhere on the screen.
 
 ::: tip NOTE
 
-Several objects can be combined (they can be called *metasprites*) to draw
+Several objects can be combined (they can be called _metasprites_) to draw
 a larger graphical element, usually called "sprite". Originally, the term "sprites"
 referred to fixed-sized objects composited together, by hardware, with a background.
 Use of the term has since become more general.
@@ -83,4 +82,4 @@ To summarise:
 
 - **Tile**, an 8x8-pixel chunk of graphics.
 - **Object**, an entry in object attribute memory, composed of 1 or 2
-tiles. Independent from the background.
+  tiles. Independent of the background.