In the world of Game Boy graphics, all calculations are done by the CPU, and then the separate Picture Processing Unit (PPU) renders them. This is another component found inside the DMG-CPU SoC, and could be described as an improved version of the predecessor's graphics chip (which, coincidentally, shares the same name).
Frame rendered by the PPU.
Frame displayed on the original Game Boy's LCD.
The picture is displayed on an integrated Liquid-Crystal Display (LCD) with a resolution of 160×144 pixels. In the case of the monochrome Game Boy, the LCD can only reflect 4 shades of grey (white, light grey, dark grey and black). However, due to the use of a green-tinted LCD, the picture will look slightly greenish.
A familiar model
If you've read the NES study, you may recall that the PPU was designed to leverage the behaviour of the CRT (especially how its beam worked). This may now seem incompatible when connected to an LCD. Although, the new display still requires to be refreshed. Thus, the new PPU uses this to provide CRT-based effects, similar to those that enabled NES developers to come up with imaginative content.
Additionally, unlike its home console counterpart, the Game Boy is not powered by the alternating current supplied through wall sockets - the very same that varies depending on the country or region. Consequently, the analogue circuitry is not tied to the region's electrical grid. What I mean to say is, while the NES had to be adapted to 60 Hz and 50 Hz configurations, the Game Boy operates on the same four AA batteries, regardless of geographical location. Therefore, all Game Boys share common CPU clock speeds and a refresh rate of 59.7 Hz - a standard that makes things more pleasant for developers (and, ultimately, users).
Organising the content
Memory architecture of the PPU.
The PPU is exclusively connected to 8 KB of Video RAM (also called 'VRAM', though some sources also refer to it as 'Display RAM'). Those 8 KB contain most of the data the PPU needs to render graphics. The remaining materials are stored within the PPU itself, as they require faster access rates.
The PPU also arbitrates CPU-to-VRAM access, and the game is in charge of populating the different areas with the correct types of data. Moreover, the PPU exposes registers that are used to define how the graphics data is organised. Nevertheless, there are many rules to follow (explained in the following sections).
Constructing the frame
The final frame that you see on the LCD screen is composed of three overlapping layers. Each is designed for a different type of use.
Let's see how the PPU manages to draw pixels on the screen. For demonstration purposes, Super Mario Land 2 is used as an example.
Tiles
A pattern table with multiple tiles squashed together.
A single tile.
The PPU uses tiles as a basic ingredient for rendering graphics, specifically, sprites and backgrounds .
Tiles are just 8x8-pixel bitmaps. Each occupies 16 bytes and is stored in VRAM, in a region called Tile set or 'Tile pattern table'. The colour of the pixels comes from one of the four available shades of grey, which is selected through a 'colour' palette. The use of palettes also allows colours to be alternated without having to modify the tile set.
The monochrome Game Boys house enough registers to define up to three palettes, yet their use is limited to the type of layer being rendered (explained in the next sections). As previously explained, there are only four colours/shades to choose from, so a single 8-bit register can accommodate a palette of four shades without issue.
Moving on, tiles are grouped into two pattern tables.
To build the picture, tiles are referenced in another type of table known as a Tile map. This data informs the PPU where to render each tile. Two maps are stored to build different layers of the frame.
The following sections explain how tile maps are used to assemble these layers.
Background Layer
Allocated background map in VRAM.
Selected area of the background map. Notice that the selection includes an unpopulated portion at the top. This is intentional and will be later overlapped by the Window layer.
Displayed background layer.
The background layer is a 256x256 pixel (32x32 tiles) map containing static tiles. However, remember only 160x144 pixels are visible on the screen. So, the game also decides which portion of the background layer is selected for display. Interestingly, games can also shift the viewable area during gameplay - this is how the scrolling effect is accomplished.
One of the two tile maps is used to construct the background layer. Moreover, only one palette is available for this layer.
Sprites
Rendered sprite layer.
Sprites, also known as 'Objects', are tiles that can move independently across the screen. They can also overlap one another and appear behind the background; the viewable graphic is determined by a priority attribute.
This layer also has an extra colour available: Transparent. At first, this means sprites can only display three shades of grey instead of four. On the other hand, this layer in particular offers the choice of two dedicated palettes.
The Object Attribute Memory (OAM) is a map stored within the PPU that specifies which tiles are used as sprites, its location makes it faster to access during rendering. For this reason, all sprites are defined in OAM (rather than a tile map within VRAM). Games typically fill this region by calling the OAM Direct Memory Access (DMA) unit located inside the chip; the DMA fetches data from main RAM or game ROM and transfers it to OAM. Now, while DMA is active, the CPU cannot access external memory - hence the importance of taking advantage of High RAM during that period.
In addition to the tile index, each OAM entry contains the following attributes: X-Y position, chosen palette, priority, and flip flags (allowing to mirror the tile vertically and horizontally).
The PPU is limited to rendering up to ten sprites per scan line and up to 40 per frame; overflowing this will result in sprites not being drawn.
Window
Allocated Window map.
Displayed Window map. This is because the game intentionally activates it during the final scan lines. Hence, only the first rows are rendered at the bottom of the screen.
The window layer is a 160x144 pixel map (covering the entire screen) that renders tiles on top of the background and sprites. Having said that, this layer does not scroll.
Only the remaining tile map can be assigned to the window layer, which also shares the same palette.
All in all, this may sound like a silly feature: considering the window lacks transparency and therefore completely obscures all underlying layers, you may wonder 'what is it useful for?'. Well, in combination with timed raster effects, the window can be used partially across different areas of the screen. Remember the complex and time-sensitive routines NES games went through to display player stats? The window is an answer to that, now automatically handled by the Game Boy's PPU.
Consequently, games normally use the window layer to draw life counters, scores, and other persistent information.
Result
Final result. Tada!
Once the frame is finished, it's time to move on to the next one! However, the CPU cannot modify the tables while the PPU is reading from VRAM, so the system provides a set of interrupts triggered when the PPU is idle. You may recall this behaviour from the NES era.
When a single scan line is complete, the Horizontal Blank period starts. This allows developers to fiddle with the part of the frame that has not yet been drawn.
When all scan lines are complete, the Vertical Blank period begins, and a dedicated interrupt is called. The game can then update the graphics for the next frame.
There's an extra state called OAM search that is initiated at the start of the scan line. At this point, the PPU is determining which sprites will be displayed on that scan line, so the game may update any region except OAM.
The Wobble effect
Super Mario Land 2: 6 Golden Coins (1992) plays with the X and Y scrolling controls mid-screen.
The inclusion of the window layer and extra interrupts allowed for unique content and effects. For instance, horizontal interrupts made it possible to alter the frame before it was fully drawn. This meant that a different scrolling value could be applied to each line, causing each row of the frame to shift at different rates .
This achieved an interesting wobble effect (I'm not sure whether that is its official name, but I find it distinctive enough).
The Color additions
So far, we've been focusing on the original Game Boy entry. Let's now examine the additions of the so-called 'Color' model.
Modes of operation
The Legend of Zelda: Link's Awakening DX (1998).
A hybrid Game Boy Color game running in CGB mode.
Super Mario Land 2, running in a Game Boy Color. The game executes in DMG mode, but the console applies a colourised palette nonetheless.
The Game Boy Color's PPU essentially behaves as a superset of the original. Yet, Nintendo wanted Color users to experience enhancements even with monochrome-only games. Thus, to maintain compatibility, the new PPU exhibits two modes of operation:
- CGB mode: An extended PPU mode offering all the visual improvements featured in Game Boy Color titles.
- DMG mode: A traditional mode with all the extras disabled. Nevertheless, you'll see in the 'Operating System' section that monochrome games are still upgraded with colour palettes.
Organising the (new) content
The CGB motherboard now houses 16 KB of VRAM, which is double the original VRAM amount. Due to the CPU's addressing limitations, this new arrangement is implemented in the form of two 8 KB banks, with a new register (VBK) acting as a switcher.
Meanwhile, the PPU can access the two banks at the same time. So, at the end of the day, programmers simply need to fill the VRAM banks with the help of VBK, and then specify in the tile map which bank the tile resides in, allowing the PPU to take care of the rest.
That being said, what can you do with the extra VRAM? Many things:
- Store twice as many tiles.
- Store additional palettes, which also offer a broader colour gamut.
- Extend the tile metadata space to encode more effects and reference extra palettes.
The visuals
Thanks to the new PPU, programmers can now define colour palettes with 32,768 colours to choose from.
Firstly, developers must populate a new area called Palette Memory, which stores up to sixteen colour palettes (half for the background and window, and half for sprites), each encoding four colours . Each entry fits in a 16-bit value (2 bytes), though only 15 bits are utilised. Palette Memory is not directly addressable by the CPU; instead, a new register serves as a buffer for writing to this memory (a methodology also found in the Super Nintendo). Overall, this is how coloured games define palettes.
Having said that, background and window tiles can reference any of the eight available palettes. The same applies to sprite tiles, except they are constrained to three-colour palettes, as one entry is still reserved for the 'transparent' colour.
The extra space
Moving on, tile sets are now twice as big, enabling programmers to store double the amount of tiles in VRAM. Background and window tile maps have been extended as well, resulting in extra meta-data being encoded. This expands the capabilities of these layers. For instance, background and window tiles can now be flipped horizontally and vertically, saving the need from storing duplicate graphics in VRAM (which, in turn, can be leveraged to render more unique content).
Furthermore, CPU CGB bundles one extra DMA unit, capable of copying data from the Game Pak or WRAM to VRAM. It operates in two modes :
- General-purpose DMA: Transfers can happen at any time, with the DMA taking priority over other memory accesses. So, programmers must carefully consider when to use this component (e.g. during or outside scanning) and how much data to copy, as misuse can lead to screen tearing (since VRAM access will be blocked during the transfer).
- Horizontal Blank (H-Blank) DMA: Transfers will only occur during H-Blank periods. This avoids screen artefacts, but limits transfers to batches of 16 Bytes, and pauses during LCD scanning.
Once again, this unit offers programmers new opportunities to deliver richer content, as it takes advantage of periods that would otherwise remain idle.