diff --git a/src/OAM_Corruption_Bug.md b/src/OAM_Corruption_Bug.md index d7f04a0b..c36e4226 100644 --- a/src/OAM_Corruption_Bug.md +++ b/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. diff --git a/src/Rendering.md b/src/Rendering.md index 2ff10100..281f9f52 100644 --- a/src/Rendering.md +++ b/src/Rendering.md @@ -1,4 +1,3 @@ - # Rendering Overview The Game Boy outputs graphics to a 160x144 pixel LCD, using a quite complex @@ -6,9 +5,9 @@ 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.