The Game Boy can be imagined as a portable version of the NES with limited power, but you’ll see that it included very interesting new functionality.
The main processor is a Sharp LR35902, a mix between the Z80 and the Intel 8080 that runs at ~4.19 MHz.
The Z80 is itself a superset of the 8080, so what does the Sharp actually has and has not from those two?
All graphics calculations are done by the CPU, then the Picture Processing Unit renders them. The picture is displayed in an integrated LCD screen, it has a resolution of 160×144 pixels and supports 4 shades of grey (white, light grey, dark grey and black). In practice, however, since the original gameboy has a green LCD, graphics will look greenish.
In order to build the picture, the PPU first looks for tile references from a different set of tables stored in Display RAM which were previously populated by the game, each table is used to build a layer of the frame.
Each layer also allows to store a different colour palette: Even that the GameBoy only has 4 colours, palettes can create a different combination of those, allowing to alternate colours without having to store extra graphics.
For demonstration purposes, Super Mario Land 2 will be used as example to show the process of rendering the frame:
The PPU uses tiles as a basic ingredient for producing sprites and backgrounds.
The Game Boy defines tiles as basic 8x8 maps, these are stored in the Program ROM (cartridge) but, in order to access them, they have to be copied to Display RAM during specific events (these are discussed later).
In Display RAM tiles are organised in Pattern Tables and there’s enough space for two of them. Each one will be accessed by different layers.
The Background layer is a 256x256 map containing static tiles, however only 160x144 is viewable on the screen, so the game decides which part is selected for display. Games can also move the viewable area during gameplay, that’s how the Scrolling Effect is accomplished.
The Background Tile Table is used to store references of tiles to be displayed as background.
The Window is a 160x144 layer containing tiles that can be displayed on top of the background and sprites, it doesn’t scroll. Games normally use it to display player stats, score and other always-on information.
The Window Tile Table selects the tiles to be used in this layer, it has the same structure as the Background Table.
The Background and Window can be used concurrently with each one using different parts of the screen. This is accomplished by changing the LCDCONT register during specific scan-lines.
Sprites are tiles that can move around the screen. They can also overlap each other and appear behind the background, the viewable graphic will be decided based on its priority value.
Sprites have an extra colour available: Transparent. This also means that they only can display 3 different greys instead of 4. Luckily, this layer allows to store two palettes in order to use every colour.
The Object Attribute Memory (OAM) table specifies which tiles will be used as sprites. In addition to the tile index, each entry contains an (x,y) position and multiple attributes: Colour palette, a priority and flip flags (allows to rotate the tile).
The PPU is limited to ten sprites per scan-line and up to 40 per frame, overflowing this will result in sprites not being drawn.
Once the frame is finished, it’s time to move on to the next one! However, the CPU can’t modify the tables while the PPU is using them, so the system provides a set of interrupts triggered when the PPU is idle. This design is similar to the NES’ PPU, which was built for CRT displays.
When a single scan-line is complete, the Horizontal Blank interrupt is called, this allows to fiddle with the part of frame that has not yet drawn.
When all scan-lines are complete the Vertical Blank interrupt is called. The game can now update the graphics for the next frame.
There’s an extra state called OAM search that is triggered at the start of the scan-line, at this point the PPU is processing which sprites will be displayed in that scan-line, so the game can update any region except OAM.
The inclusion of the Window layer and extra interrupts allowed for new types of content and effects.
Horizontal interrupts allowed to alter the frame before being finished. This means that a different scrolling value could be applied at each line, resulting in each row of the frame being displaced differently.
This achieved a Wobbling effect.
The audio system is carried out by the Audio Processing Unit (APU), a PSG chip with four channels, each one reserved for a type of wave-form:
Pulse waves have a very distinct beep sound that is mainly used for melody or sound effects.
The APU reserves two channels for one pulse-wave each. These channels use one of four different tones constructed by varying its pulse width. The first channel has an exclusive Sweep control available.
Due to the limited number of channels, melody will often be interrupted when effects have to be played as part of the gameplay. This is very noticeable in games like Pokemon Red/Blue when, during a battle, the Pokemon’s cry will overlap all the channels used for music.
Noise is basically a set of random wave-forms that sound like white static. One channel is allocated for it.
Games use it for percussion or ambient effects.
This channel has only 2 tones available to use, one produces clean static and the other produces robotic static. Its frequency can also be controlled.
The APU allows to store 32 custom wave-forms to be played in its forth channel. Each wave is composed of a 4-bit sample that will be played repeatedly.
This channel also allows to control its frequency (enabling to produce different musical notes from the same sample) and volume.
The mixer outputs stereo sound, so the channels can be programmed on the left side or on the right one, this is only possible to hear from the headphones though! The speaker is mono.
The mixer chip is also connected to a specific pin of the cartridge, allowing to include an extra channel with the condition that the cartridge has to actually output the sound (only possible using extra hardware). No game in the market ended up using this feature.
Games have a maximum size of 32 KB, this is due to the limited address space available, but if the cartridge uses a Memory Bank Controller it can reach bigger sizes, the biggest cartridge found was 1 MB. They can include a real time clock and an external battery along with SRAM to hold saves.
For the first time games can also communicate with other consoles thanks to the Game Boy Link cable which provides multiplayer functionality.
This console contains a 256 Byte ROM stacked in the CPU that is used to bootstrap the cartridge’s ROM. It doesn’t run the game right away however, instead it executes a series of checks that prevented unauthorised cartridges from working and also made sure the cartridge was correctly inserted.
To be able to pass these checks, games had to include a copy of Nintendo’s logo (in the form of tiles) in its ROM header, this way Nintendo could make use of Copyright and Trademark laws to control the distribution, Clever huh?. The bootstrap ROM included a copy of this logo as well.
That being said, the boot process is as follows:
More anti-piracy measures can be implemented inside the games, like checking the SRAM size (is normally bigger in Bootlegs) and checksumming the ROM at random points of the game.
This article is part of the Architecture of Consoles series. If you found it interesting please consider donating, your contribution will be used to get more tools and resources that will help to improve the quality of current articles and upcoming ones.
A list of desirable tools and latest acquisitions for this article are tracked in here:
## Interesting hardware to get (ordered by priority) - An original Gameboy (~£30 ?) - A Dev cartridge (couldn't find one, yet)
Always nice to keep a record of changes.
## 2019-09-17 - Added a quick introduction ## 2019-07-22 - Improved Anti-Piracy content ## 2019-05-19 - Extended CPU section ## 2019-02-21 - Ready for publication