Video Display - Revision history

Nitro2k01 at 02:12, 5 April 2020

2020-04-05T02:12:45Z

PinoBatch: Why is LCDC address missing?

2020-02-20T22:52:45Z

Why is LCDC address missing?

ISSOtm: /* VRAM Tile Data */ Add link to ShantyTown's explanation of the graphics format

2019-10-12T19:52:46Z

‎VRAM Tile Data: Add link to ShantyTown's explanation of the graphics format

Mattcurrie: /* FF44 - LY - LCDC Y-Coordinate (R) */ Writing to LY does not reset the counter. Verified by test ROM.

2019-07-26T05:12:36Z

‎FF44 - LY - LCDC Y-Coordinate (R): Writing to LY does not reset the counter. Verified by test ROM.

PinoBatch: /* Sprite Priorities and Conflicts */ "regardless" should work better here

2019-02-14T14:48:01Z

‎Sprite Priorities and Conflicts: "regardless" should work better here

PinoBatch: /* Sprite Priorities and Conflicts */ DMG X sorting is only within the 10 sprites appearing first in OAM

2019-02-14T14:42:59Z

‎Sprite Priorities and Conflicts: DMG X sorting is only within the 10 sprites appearing first in OAM

PinoBatch: /* FF41 - STAT - LCDC Status (R/W) */ LIJI32 told me I forgot SCX mod 8

2019-02-14T14:27:02Z

‎FF41 - STAT - LCDC Status (R/W): LIJI32 told me I forgot SCX mod 8

PinoBatch: Move comment about fitting 8 bytes into mode 0+2 down from hardware description section to programming advice section

2019-02-14T05:03:46Z

Move comment about fitting 8 bytes into mode 0+2 down from hardware description section to programming advice section

PinoBatch: /* FF41 - STAT - LCDC Status (R/W) */ Reorganize modes as table; add sprite cost formula; "as if" description of STAT bug

2019-02-14T04:25:50Z

‎FF41 - STAT - LCDC Status (R/W): Reorganize modes as table; add sprite cost formula; "as if" description of STAT bug

ISSOtm: Move LCDC data to its own article. Needs to be done for the rest too, but that'll be later.

2019-02-02T23:30:51Z

Move LCDC data to its own article. Needs to be done for the rest too, but that'll be later.

← Older revision		Revision as of 02:12, 5 April 2020
Line 1:		Line 1:
−	{{Pandocs\|~~videodisplay~~}}	+	{{Pandocs\|video-display}}

	== LCD Control Register ==		== LCD Control Register ==

@@ Line 3: / Line 3: @@
 == LCD Control Register ==
 Detailed article: [[LCDC]]
+=== FF40 - LCDC - LCD Control (R/W) ===
    Bit 7 - LCD Display Enable             (0=Off, 1=On)
    Bit 6 - Window Tile Map Display Select (0=9800-9BFF, 1=9C00-9FFF)
@@ Line 87: / Line 87: @@
 === INT 48 - LCDC Status Interrupt ===
-There are various reasons for this interrupt to occur as described by the STAT register ($FF40). One very popular reason is to indicate to the user when the video hardware is about to redraw a given LCD line. This can be useful for dynamically controlling the SCX/SCY registers ($FF43/$FF42) to perform special video effects.
+There are various reasons for this interrupt to occur as described by the STAT register ($FF41). One very popular reason is to indicate to the user when the video hardware is about to redraw a given LCD line. This can be useful for dynamically controlling the SCX/SCY registers ($FF43/$FF42) to perform special video effects.
 Example application : set LYC to WY, enable LY=LYC interrupt, and have the handler disable sprites. This can be used if you use the window for a text box (at the bottom of the screen), and you want sprites to be hidden by the text box.

← Older revision		Revision as of 19:52, 12 October 2019
Line 273:		Line 273:

	For each line, the first byte defines the least significant bits of the color numbers for each pixel, and the second byte defines the upper bits of the color numbers. In either case, Bit 7 is the leftmost pixel, and Bit 0 the rightmost. For example : let's say you have $57 $36 (in this order in memory). To obtain the color index for the leftmost pixel, you take bit 7 of both bytes : 0, and 0. Thus the index is 00b = 0. For the second pixel, repeat with bit 6 : 1, and 0. Thus the index is 01b = 1 (remember to flip the order of the bits !). If you repeat the operation you'll find that the indexes for the 8 pixels are 0 1 2 3 0 3 3 1.		For each line, the first byte defines the least significant bits of the color numbers for each pixel, and the second byte defines the upper bits of the color numbers. In either case, Bit 7 is the leftmost pixel, and Bit 0 the rightmost. For example : let's say you have $57 $36 (in this order in memory). To obtain the color index for the leftmost pixel, you take bit 7 of both bytes : 0, and 0. Thus the index is 00b = 0. For the second pixel, repeat with bit 6 : 1, and 0. Thus the index is 01b = 1 (remember to flip the order of the bits !). If you repeat the operation you'll find that the indexes for the 8 pixels are 0 1 2 3 0 3 3 1.
		+
		+	A more visual explanation can be found [https://www.huderlem.com/demos/gameboy2bpp.html here].

	So, each pixel is having a color number in range from 0-3. The color numbers are translated into real colors (or gray shades) depending on the current palettes. The palettes are defined through registers [[#FF47_-_BGP_-_BG_Palette_Data_.28R.2FW.29_-_Non_CGB_Mode_Only\|BGP]], [[#FF48_-_OBP0_-_Object_Palette_0_Data_.28R.2FW.29_-_Non_CGB_Mode_Only\|OBP0]] and [[#FF49_-_OBP1_-_Object_Palette_1_Data_.28R.2FW.29_-_Non_CGB_Mode_Only\|OBP1]] (Non CGB Mode), and [[#FF68_-_BCPS.2FBGPI_-_CGB_Mode_Only_-_Background_Palette_Index\|BCPS/BGPI]], [[#FF69_-_BCPD.2FBGPD_-_CGB_Mode_Only_-_Background_Palette_Data\|BCPD/BGPD]], [[#FF6A_-_OCPS.2FOBPI_-_CGB_Mode_Only_-_Sprite_Palette_Index.2C_FF6B_-_OCPD.2FOBPD_-_CGB_Mode_Only_-_Sprite_Palette_Data\|OCPS/OBPI and OCPD/OBPD]] (CGB Mode).		So, each pixel is having a color number in range from 0-3. The color numbers are translated into real colors (or gray shades) depending on the current palettes. The palettes are defined through registers [[#FF47_-_BGP_-_BG_Palette_Data_.28R.2FW.29_-_Non_CGB_Mode_Only\|BGP]], [[#FF48_-_OBP0_-_Object_Palette_0_Data_.28R.2FW.29_-_Non_CGB_Mode_Only\|OBP0]] and [[#FF49_-_OBP1_-_Object_Palette_1_Data_.28R.2FW.29_-_Non_CGB_Mode_Only\|OBP1]] (Non CGB Mode), and [[#FF68_-_BCPS.2FBGPI_-_CGB_Mode_Only_-_Background_Palette_Index\|BCPS/BGPI]], [[#FF69_-_BCPD.2FBGPD_-_CGB_Mode_Only_-_Background_Palette_Data\|BCPD/BGPD]], [[#FF6A_-_OCPS.2FOBPI_-_CGB_Mode_Only_-_Sprite_Palette_Index.2C_FF6B_-_OCPD.2FOBPD_-_CGB_Mode_Only_-_Sprite_Palette_Data\|OCPS/OBPI and OCPD/OBPD]] (CGB Mode).

@@ Line 102: / Line 102: @@
 === FF44 - LY - LCDC Y-Coordinate (R) ===
-The LY indicates the vertical line to which the present data is transferred to the LCD Driver. The LY can take on any value between 0 through 153. The values between 144 and 153 indicate the V-Blank period. Writing will reset the counter.
+The LY indicates the vertical line to which the present data is transferred to the LCD Driver. The LY can take on any value between 0 through 153. The values between 144 and 153 indicate the V-Blank period.
 === FF45 - LYC - LY Compare (R/W) ===

@@ Line 347: / Line 347: @@
 === Sprite Priorities and Conflicts ===
-During each scanline's OAM scan, the LCD controller compares LY to each sprite's Y position to find the 10 sprites on that line that appear first in OAM ($FE00-$FE03 being the first). It discards the rest, allowing only 10 sprites to be displayed on any one line. When this limit is exceeded, sprites appearing later in OAM won't be displayed. To keep unused sprites from affecting onscreen sprites, set their Y coordinate to Y = 0 or Y => 160 (144 + 16) (Note : Y <= 8 also works if sprite size is set to 8x8). Just setting the X coordinate to X = 0 or X => 168 (160 + 8) on a sprite will hide it, but it will still affect other sprites sharing the same lines.
+During each scanline's OAM scan, the LCD controller compares LY to each sprite's Y position to find the 10 sprites on that line that appear first in OAM ($FE00-$FE03 being the first). It discards the rest, allowing only 10 sprites to be displayed on any one line. When this limit is exceeded, sprites appearing later in OAM won't be displayed. To keep unused sprites from affecting onscreen sprites, set their Y coordinate to Y = 0 or Y >= 160 (144 + 16) (Note : Y <= 8 also works if sprite size is set to 8x8). Just setting the X coordinate to X = 0 or X >= 168 (160 + 8) on a sprite will hide it, but it will still affect other sprites sharing the same lines.
 If using [[BGB]], in the VRAM viewer - OAM tab, hover your mouse over the small screen to highlight the sprites on a line. Sprites hidden due to the limitation will be highlighted in red.
@@ Line 353: / Line 353: @@
 When these 10 sprites overlap, the highest priority one will appear above all others, etc. (Thus, no Z-fighting.) In CGB mode, the first sprite in OAM ($FE00-$FE03) has the highest priority, and so on. In Non-CGB mode, the smaller the X coordinate, the higher the priority. The tie breaker (same X coordinates) is the same priority as in CGB mode.
-The priority calculation between sprites disregards OBJ-to-BG Priority (attribute bit 7). Only the highest-priority sprite is compared against the background. Thus if a sprite with a higher priority (based on OAM index) but with OBJ-to-BG Priority turned on overlaps a sprite with a lower priority and a nonzero background pixel, the background pixel is displayed even if the lower-priority sprite's OBJ-to-BG Priority is on.
+The priority calculation between sprites disregards OBJ-to-BG Priority (attribute bit 7). Only the highest-priority nonzero sprite pixel at any given point is compared against the background. Thus if a sprite with a higher priority (based on OAM index) but with OBJ-to-BG Priority turned on overlaps a sprite with a lower priority and a nonzero background pixel, the background pixel is displayed regardless of the lower-priority sprite's OBJ-to-BG Priority.
 === Writing Data to OAM Memory ===

@@ Line 66: / Line 66: @@
 |}
-Unlike most game consoles, the Game Boy can pause the dot clock briefly. It routinely takes a 6 to 11 dot break to fetch sprite patterns between background tile pattern fetches. On DMG and GBC in DMG mode, mid-scanline writes to <code>BGP</code> allow observing this behavior, as a sprite delay shifts the effect of a write to the left by that many dots.
+Unlike most game consoles, the Game Boy can pause the dot clock briefly, adding dots to mode 3's duration. It routinely takes a 6 to 11 dot break to fetch sprite patterns between background tile pattern fetches. On DMG and GBC in DMG mode, mid-scanline writes to <code>BGP</code> allow observing this behavior, as a sprite delay shifts the effect of a write to the left by that many dots.
-Each sprite usually adds <code>11 - min(5, (x + SCX) % 8)</code> dots to mode 3. Because sprite fetch waits for background fetch to finish, a sprite's cost depends on its position relative to left side of the background tile under it. It's greater if a sprite is directly aligned over the background tile, less if the sprite is to the right. If the sprite's left side is over the window, use <code>255 - WX</code> for <code>SCX</code> in the formula. An active window also adds at least 6 dots to mode 3, as the background fetching mechanism starts over at the left side of the window.
+Three things are known to pause the dot clock:
-'''Not fully understood:''' The exact timing for window start is not confirmed; it may have the same background fetch finish delay as a sprite. If two sprites' left sides are over the same background or window tile, the second may take fewer cycles.
+'''Not fully understood:''' The exact pause duration for window start is not confirmed; it may have the same background fetch finish delay as a sprite. If two sprites' left sides are over the same background or window tile, the second may pause for fewer dots.
-A hardware bug in the monochrome Game Boy makes the LCD interrupt sometimes trigger when writing to STAT (including writing $00) during OAM scan, H-Blank, V-Blank, or LY=LYC. It behaves as if $FF were written for one cycle, and then the written value were written the next cycle. Because the GBC in DMG mode does not have this bug, two games that depend on this bug (Ocean's ''Road Rash'' and Vic Tokai's ''Xerd no Densetsu'') will not run on a GBC.
+A hardware quirk in the monochrome Game Boy makes the LCD interrupt sometimes trigger when writing to STAT (including writing $00) during OAM scan, H-Blank, V-Blank, or LY=LYC. It behaves as if $FF were written for one cycle, and then the written value were written the next cycle. Because the GBC in DMG mode does not have this quirk, two games that depend on this quirk (Ocean's ''Road Rash'' and Vic Tokai's ''Xerd no Densetsu'') will not run on a GBC.
 ==  LCD Interrupts ==

@@ Line 69: / Line 69: @@
 Each sprite usually adds <code>11 - min(5, (x + SCX) % 8)</code> dots to mode 3. Because sprite fetch waits for background fetch to finish, a sprite's cost depends on its position relative to left side of the background tile under it. It's greater if a sprite is directly aligned over the background tile, less if the sprite is to the right. If the sprite's left side is over the window, use <code>255 - WX</code> for <code>SCX</code> in the formula. An active window also adds at least 6 dots to mode 3, as the background fetching mechanism starts over at the left side of the window.
 '''Not fully understood:''' The exact timing for window start is not confirmed; it may have the same background fetch finish delay as a sprite. If two sprites' left sides are over the same background or window tile, the second may take fewer cycles.
@@ Line 370: / Line 368: @@
    jr   nz,@@wait    ;/
-Even if the procedure gets executed at the <end> of Mode 0 or 1, it is still proof to assume that VRAM can be accessed for a few more cycles because in either case the following period is Mode 2 which allows access to VRAM either. However, be careful about STAT LCD interrupts or other interrupts that could cause the LCD to be back in mode 3 by the time it returns.
+Even if the procedure gets executed at the ''end'' of Mode 0 or 1, it is still proof to assume that VRAM can be accessed for a few more cycles because in either case the following period is Mode 2 which allows access to VRAM either. However, be careful about STAT LCD interrupts or other interrupts that could cause the LCD to be back in mode 3 by the time it returns. In CGB Mode an alternate method to write data to VRAM is to use the HDMA Function (FF51-FF55).
 In CGB Mode an alternate method to write data to VRAM is to use the HDMA Function (FF51-FF55).
 === OAM (memory at FE00h-FE9Fh) is accessible during Mode 0-1 ===

@@ Line 28: / Line 28: @@
 The two lower STAT bits show the current status of the LCD controller.
-  Mode 0: The LCD controller is in the H-Blank period and
+The LCD controller operates on a 2<sup>22</sup> Hz = 4.194 MHz dot clock. An entire frame is 154 scanlines, 70224 dots, or 16.74 ms. On scanlines 0 through 143, the LCD controller cycles through modes 2, 3, and 0 once every 456 dots. Scanlines 144 through 153 are mode 1.
-          the CPU can access both the display RAM (8000h-9FFFh)
-          and OAM (FE00h-FE9Fh)
-−
-  Mode 1: The LCD controller is in the V-Blank period (or the
-          display is disabled) and the CPU can access both the
-          display RAM (8000h-9FFFh) and OAM (FE00h-FE9Fh)
-−
-  Mode 2: The LCD controller is reading from OAM memory.
-          The CPU <cannot> access OAM memory (FE00h-FE9Fh)
-          during this period.
-−
-  Mode 3: The LCD controller is reading from both OAM and VRAM,
-          The CPU <cannot> access OAM and VRAM during this period.
-          CGB Mode: Cannot access Palette Data (FF69,FF6B) either.
 The following are typical when the display is enabled:
@@ Line 50: / Line 36: @@
    Mode 1  ____________________________________11111111111111_____
-The Mode Flag goes through the values 0, 2, and 3 at a cycle of about 109 μS. 0 is present about 48.6 μS, 2 about 19 μS, and 3 about 41 μS. This is interrupted every 16.6ms by the VBlank (1). The mode flag stays set at 1 for about 1.08 ms.
+<!-- 2, 3, 0, 1 because that's their order in the frame -->
-A complete cycle through these states takes 456 tstates. Mode 2 is present for 80 tstates, mode 3 about 170-240 tstates depending on where exactly the sprites, window, and fine scroll (SCX modulo 8) are positioned, and mode 0 for the rest of the scanline (up to 200 tstates). VBlank lasts 10 scanlines, or 4560 tstates. A complete screen refresh occurs every 154 lines, or 70224 tstates.)
+Unlike most game consoles, the Game Boy can pause the dot clock briefly. It routinely takes a 6 to 11 dot break to fetch sprite patterns between background tile pattern fetches. On DMG and GBC in DMG mode, mid-scanline writes to <code>BGP</code> allow observing this behavior, as a sprite delay shifts the effect of a write to the left by that many dots.
-A hardware bug in the monochrome Game Boy makes the LCD interrupt sometimes trigger when writing to STAT (including writing $00) during a H-Blank or V-Blank period.
+Each sprite usually adds <code>11 - min(5, (x + SCX) % 8)</code> dots to mode 3. Because sprite fetch waits for background fetch to finish, a sprite's cost depends on its position relative to left side of the background tile under it. It's greater if a sprite is directly aligned over the background tile, less if the sprite is to the right. If the sprite's left side is over the window, use <code>255 - WX</code> for <code>SCX</code> in the formula. An active window also adds at least 6 dots to mode 3, as the background fetching mechanism starts over at the left side of the window.
 ==  LCD Interrupts ==

@@ Line 2: / Line 2: @@
 == LCD Control Register ==
-=== FF40 - LCDC - LCD Control (R/W) ===
+Detailed article: [[LCDC]]
-−
-LCDC is special, because it can be written to during Mode 3 (while graphics are being drawn), and '''will''' affect display during the scanline !
-−
-This could be used for very complex video effects, but they will probably fail to render properly on most emulators. (They could be pretty sick though)
    Bit 7 - LCD Display Enable             (0=Off, 1=On)
@@ Line 16: / Line 12: @@
    Bit 1 - OBJ (Sprite) Display Enable    (0=Off, 1=On)
    Bit 0 - BG/Window Display/Priority     (0=Off, 1=On)
 == LCD Status Register ==