This article welcomes anyone that wants to help with translations or contributions.
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 CPU is found in a package called DMG-CPU which also houses other components we’ll see later on.
The Z80 is itself a superset of the 8080, so what does the Sharp actually has and has not from those two?
IYregisters nor 8080’s
OUTinstructions are included: This means that I/O ports are not available. I’m not certain if that’s just a measure to reduce costs, but one thing for sure is that components will have to be completely memory-mapped.
Finally, they also added a few new instructions that are not present in either Z80 or 8080. I think explaining them one by one goes beyond the scope of this article, but the main idea is that they optimise certain operations conditioned by the way Nintendo/Sharp arranged the hardware.
Nintendo fitted 8 KB of RAM for general purpose use (which they call Work RAM or ‘WRAM’). Notice that this is four times larger than what the NES included.
The Sharp keeps a 8-bit data bus and a 16-bit address bus, so up to 64 KB of memory can be addressed. The memory map is composed of:
All graphics calculations are done by the CPU, then the Picture Processing Unit or ‘PPU’ renders them. This is another component found inside DMG-CPU and it’s actually based on the predecessor’s PPU.
The picture is displayed in an integrated LCD screen, it has a resolution of 160×144 pixels and shows 4 shades of grey (white, light grey, dark grey and black). But since the original gameboy has a green LCD, graphics will look greenish.
If you’ve read the NES article before, you may remember that the PPU was designed to follow the CRT beam. However (and for obvious reasons), we got an LCD screen in the Gameboy. Well, the new PPU doesn’t alter that part, since LCDs require to be refreshed too. In fact, some special effects achieved thanks to this behaviour will also be supported on the Gameboy.
The PPU has 8 KB of VRAM or ‘Display RAM’, which both PPU and CPU can access directly but not at the same time. Those 8 KB will contain most of the data the PPU will need to render graphics, other bits will be stored inside the PPU as they will require a faster access rate.
The game is in charge of populating the different areas with the correct type of data. Moreover, the PPU exposes some register so they game can instruct how to manage that data (there are many rules, though).
Let’s see now how the PPU manages to draw stuff on the screen. For demonstration purposes, Super Mario Land 2 will be used as example:
The PPU uses tiles as a basic ingredient for rendering graphics, specifically, sprites and backgrounds.
Tiles are just 8x8 bitmaps stored in VRAM in a region called Tile set or ‘Tile pattern table’, each pixel corresponds to one of the four shades of grey available. Finally, tiles are grouped into two pattern tables.
In order to build the picture, tiles are referenced in another type of table called Tile map. This information will tell the PPU where to render the tiles. Two maps are stored to construct different layers of the frame.
The next sections explain how tile maps are used to construct the layers.
The Background layer is a 256x256 pixel (32x32 tiles) map containing static tiles. However, remember that 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.
One of the two tile maps can be used to build the background layer.
The Window is a 160x144 pixel layer containing tiles displayed on top of the background and sprites. It doesn’t scroll.
The remaining tile map can be assigned to the window layer.
At first, this may sound like a silly feature. After all, the window layer overlaps everything else so what’s useful for? Well, both Background and Window can be used concurrently at different parts of the screen. This is accomplished by changing the
LCDCONT register during specific scan-lines.
Thus, games normally use it to display player stats, score and other ‘always-on’ information.
Sprites are tiles that can move independently around the screen. They can also overlap each other and appear behind the background, the viewable graphic will be decided based on a priority attribute.
They also have an extra colour available: Transparent. So, they can only display three different greys instead of four. Luckily, this layer allows defining two colour palettes make use of every colour.
The Object Attribute Memory or ‘OAM’ is a map stored inside the PPU which specifies the tiles that will be used as sprites. Games fill this region by calling the DMA unit found inside the chip, this fetches data from main RAM or game ROM to OAM.
Apart from the tile index, each entry contains the following attributes: X-Y position, colour palette, priority and flip flags (allowing to rotate 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.
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 reading from VRAM, so the system provides a set of interrupts triggered when the PPU is idle. You can recall this behaviour from the times of the NES.
When a single scan-line is complete, the Horizontal Blank interrupt is called. This allows to fiddle with the part of the frame that has not yet been 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 (I’m not sure that’s the official name of it).
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 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, the 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 define a custom wave-form to be heard from its fourth channel. The wave is composed of 32 4-bit samples which are stored in a wavetable.
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 assigned to the left side or on the right one, this is only possible to hear from the headphones though! The speaker is mono.
Furthermore, the mixer chip is also connected to a dedicated pin on the cartridge, allowing to stream an extra channel with the condition that the cartridge has to actually output the analogue sound (only possible with extra hardware). No game in the market ended up using this feature.
Games are written in assembly and they have a maximum size of 32 KB, this is due to the limited address space available. However, with the use of a Memory Bank Controller (mapper), games can reach bigger sizes. The biggest cartridge found in the market has a 1 MB ROM.
Cartridges can include a real-time clock and an external battery along with SRAM to hold saves.
For the first time, games can communicate with other consoles with the use of a Game Boy Link cable, which provides multiplayer functionality. The interface uses a very primitive type of serial connection.
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, it first executes a series of checks that prevent the execution of unauthorised cartridges and also makes sure the cartridge is 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 Gameboy ROM also embeds a copy of the logo to be able to compare it.
That being said, the boot process is as follows:
Interestingly enough, the Nintendo logo displayed on the screen is not cleared from VRAM, so games can apply some animation and effects to introduce their own logo.
More anti-piracy measures can be implemented inside games, like checking the SRAM size (it’s 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)
Alternatively, you can help out by suggesting changes and/or adding translations.
Always nice to keep a record of changes.
## 2020-11-28 - Corrected wave channel info (see https://github.com/flipacholas/Architecture-of-consoles/issues/15), thanks @lotrbuilders ## 2020-10-23 - Overall revamp ## 2020-10-21 - Updated diagram and marked motherboard photo ## 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