Game Boy Architecture

Architecture of Consoles: A Practical Analysis, Volume 2

Rodrigo Copetti

Published by Rodrigo Copetti, 2019.

While every precaution has been taken in the preparation of this book, the publisher assumes no responsibility for errors or omissions, or for damages resulting from the use of the information contained herein.

GAME BOY ARCHITECTURE

First edition. February 21, 2019.

Copyright © 2019 Rodrigo Copetti.

ISBN: 979-8201836016

Written by Rodrigo Copetti.

10 9 8 7 6 5 4 3 2 1

Also by Rodrigo Copetti

Architecture of Consoles: A Practical Analysis

NES Architecture

Game Boy Architecture

Mega Drive Architecture

SNES Architecture

Sega Saturn Architecture

PlayStation Architecture

Game Boy Advance Architecture

Nintendo 64 Architecture

Dreamcast Architecture

GameCube Architecture

Wii Architecture

PlayStation 2 Architecture

Xbox Architecture

Nintendo DS Architecture

Master System Architecture

PC Engine / TurboGrafx-16 Architecture

Virtual Boy Architecture

PSP Architecture

PlayStation 3 Architecture

Xbox 360 Architecture

Wii U Architecture

Game Boy Architecture

Simple and portable

Rodrigo Copetti

2019-02-21

© 2022 Rodrigo Copetti, CC BY-NC 4.0

1 About this edition

This edition originates from the article initially published on my personal website, it’s been re-styled to take advantage of the capabilities of PDF/eBook documents.

While identical content-wise, interactive widgets have been simplified to work with a static environment - in other words, anything that physical pages allow us, though these will offer a link to the original article in case the reader wants to try the ‘full version’. Please keep this in mind when you see references to interactivity throughout the writings.

As always, the original manuscript of the articles is available on Github to enable readers to report mistakes or propose changes. There’s also a supporting reading list available to help understand the series. The author also accepts donations to help improve the quality of current articles and upcoming ones.

1.1 Open to feedback

Last but not least, for any comments and/or issues regarding this edition of the article, please get in touch using the links provided on the About page.

2 A quick introduction

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.

3 Suporting Imagery

3.1 Model

Figure 3.1: The original Game Boy. Released on 21/04/1989 in Japan, 31/07/1989 in America and 28/09/1990 in Europe [1]

3.2 Motherboard

Figure 3.2: Motherboard. Showing revision ‘04’. Note that ‘DMG’ is the identifier of the original Game Boy model. [1]

Figure 3.3: Motherboard with important parts labelled.

3.3 Diagram

Figure 3.4: Main architecture diagram.

4 CPU

Instead of placing many off-the-shelf chips on the motherboard, Nintendo opted for a single chip to house (and hide) most of the components, including the CPU. This type of chip is called ‘System On Chip’ (SoC) and the one found on the GameBoy is referred to as DMG-CPU or Sharp LR35902 [2].

Having said that, the main processor is a Sharp SM83 [3] and it’s a mix between the Z80 and the Intel 8080. It runs at ~4.19 MHz.

The Z80 is itself a superset of the 8080, so what does the SM83 actually has and has not from those two? [4]

Neither Z80’s IX and IY registers nor 8080’s IN or OUT instructions 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 [5].

Only 8080’s set of registers are implemented.

Includes Z80’s extended instruction set. Although, only bit manipulation instructions are found.

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.

4.1 Memory available

Nintendo fitted 8 KB of RAM for general purpose use (which they call Work RAM or ‘WRAM’) [6]. Notice that this is four times larger than what the NES included.

4.2 Hardware access

The SM83 keeps an 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 [7]:

Cartridge space.

WRAM and Display RAM.

I/O (joypad, audio, graphics and LCD)

Interrupt controls.

5 Graphics

All graphics calculations are done by the CPU, and 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 on 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.

5.1 Organising the content

Figure 5.1: Memory architecture of the PPU.

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. The remaining bits will be stored inside the PPU instead, 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 registers so the game can instruct the PPU on how that data is organised (there are many rules, though).

5.2 Constructing the frame

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 an example:

5.2.1 Tiles

Figure 5.2: Multiple tiles.

Figure 5.3: Multiple tiles separated with a grid.

Figure 5.4: A single tile.

Figures: Tiles found in the Pattern Table.

The PPU uses tiles as a basic ingredient for rendering graphics, specifically, sprites and backgrounds [8].

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 a 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.

5.2.2 Background Layer

Figure 5.5: Allocated Background map in VRAM.

Figure 5.6: Selected area of the Background map. Notice the selected part includes one portion of the top, this will be overlapped by the Window layer.

Figure 5.7: Displayed Background map.

Figures: Background map rendering process.

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.

5.2.3 Window

Figure 5.8: Allocated Window map.

Figure 5.9: Displayed Window map. The game activates it during the last scan-lines. Hence, only the first rows are rendered at the bottom of the screen.

Figures: Window map rendering process.

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 it 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, scores and other ‘always-on’ information.

5.2.4 Sprites

Figure 5.10: Rendered Sprite layer.

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 to 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, the DMA 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.

5.2.5 Result

Figure 5.11: Final result. Tada!

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.

5.3 Secrets and Limitations

The inclusion of the Window layer and extra interrupts allowed for new types of content and effects.

5.3.1 Wobble effect

Figure 5.12: The Legend of Zelda: Link’s Awakening (1993). Spoilers! Interactive viewer available in the website edition.

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 shifted at different paces.

This achieved a Wobbling effect (I’m not sure that’s the official name of it).

6 Audio

The audio system is carried out by the Audio Processing Unit (APU), a PSG chip with four channels [9].

6.1 Functionality

Each channel is reserved for a type of wave-form:

6.1.1 Pulse

Figure 6.1: Oscilloscope view of the pulse 1 channel. Interactive viewer available in the website edition.

Figure 6.2: Oscilloscope view of the pulse 2 channel. Interactive viewer available in the website edition.

Figure 6.3: Oscilloscope view of all audio channels. Interactive viewer available in the website edition.

Figures: Pokemon Red/Blue (1996).

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 their 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.

6.1.2 Noise

Figure 6.4: Oscilloscope view of the noise channel. Interactive viewer available in the website edition.

Figure 6.5: Oscilloscope view of all audio channels. Interactive viewer available in the website edition.

Figures: Pokemon Red/Blue (1996).

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.

6.1.3 Wave

Figure 6.6: Oscilloscope view of the wave channel. Interactive viewer available in the website edition.

Figure 6.7: Oscilloscope view of all channels. Interactive viewer available in the website edition.

Figures: Pokemon Red/Blue (1996).

The APU allows defining 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 controlling its frequency (enabling it to produce different musical notes from the same entry) and volume.

6.2 Secrets and Limitations

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.

7 Games

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.

7.1 External communications

For the first time, games can communicate with other Game Boys using of a Game Boy Link cable, which provides multiplayer functionality. The interface relies on a very primitive type of serial connection.

8 Anti-piracy

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 [10], 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 [11]:

After the console is switched on, the CPU starts reading at address 0x00 (Gameboy’s ROM location).

RAM and Sound are initialised.

Nintendo logo is copied from the cartridge ROM to Display RAM, and then it’s drawn at the top edge of the screen. If there is no cartridge inserted, the logo will contain garbage tiles. The same may happen if it’s badly inserted.

The logo is scrolled down and the famous po-ling sound is played.

The game’s Nintendo logo is matched against the one stored in the console’s ROM, if the check fails the console freezes.

A quick checksum is done on the cartridge’s ROM header to make sure the cartridge is correctly inserted, if the check fails the console freezes.

The console’s ROM is removed from the memory map.

CPU starts executing the game.

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.

Figure 8.1: 20y, a homebrew demo that fiddles with the logo. Interactive viewer available in the website edition.

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.

9 That’s all folks

10 Support

If you enjoyed what you read and would like to help out, please consider donating. Your contribution will be used to fund the purchase of tools and resources that will help me to improve the quality of existing articles and upcoming ones.

You can go to the donation page to find out more.

Along with the donation you can leave a note stating which article in particular you want me to invest in. As a token of gratitude, your name will be included in the credits section of the next article or your nominated one, unless you state otherwise.

10.1 Other ways of contributing

Alternatively, you can help out by suggesting changes on the Github repository and/or adding translations on the Crowdin page.

10.2 Acknowledgments

I want to give a big thanks to the following people for their past donation since the website launched at the start of 2019:

Adam Obenauf

Adrian Burgess

Alberto Cordeddu

Alberto Massidda

Alexander Perepechko

Alí El wahsh

Andreas Kotes

Andrew Woods

Antonio Bellotta

Antonio Vivace

BBQ Inc

Ben Morris

Bitmap Bureau

Brenden Kromhout

Carlos Díaz Navarro

Chiang Yi-Ta

Christopher Henderson

Christopher Starke

Cirilla Rose

Colin Szechy

Daniel Cassidy

David Bradbury

David Portillo

David Sawatzke

Dominic Wehrmann

Dudeastic

Duncan Bayne

Dávid Major

Eli Lipsitz

Elizabeth Parks

Eric Haskins

eurasianwolf

Gerald Mueller-Bruhnke

Grady Haynes

Guillermo Angeris

Ifeanyi Oraelosi

Izsak Barnette

Jack Wakefield

Jacob Almoyan

Jaerder Sousa

James Kilner

James Knowler

James Montgomerie

James Osborne

James William Jones

Jan Straßenburg

Jason Strothmann

Jerre van der Hulst

Joe Pugh

Johannes Baiter

John Mcgonagle

Josh Enders

Julius Hofmann

ltlollo

Luke Wren

Manish Sinha

Matthew Butch

MCE

Michael Chi

Michal Borsuk

Nathan Castle

Neil Moore

Nick T.

Oleg Andreev

Olivier Cahagne

Owen Christensen

Parker Thomas

Paul Adamson

Payam Ghoreishi

petey893

Phil Stevenson

Piergiorgio Arrigoni

Racri

rocky

Roger Bolsius

Samuel Shieh

Sanqui

Shoaib Meenai

Simon Pichette

Stephen Molyneaux

Stuart Hicks

Sébastien Lethuaire

Thomas Finch

Thomas Lanner

Thomas Peter Berntsen

Tim Cox

Ulrich Bogensperger

11 Licensing

Just like the contents on the website, all of my writings and multimedia assets authored by me are available under a permissive Creative Commons license. This edition in particular, however, is available under the Creative Commons Attribution-NonCommercial 4.0 International (I had to make it ‘non-commercial’ in order to protect this document from being sold without my authorisation).

The chosen license also means you can use my content for your own work, what I ask is that you reference my work properly. Please pay attention when you quote or paraphrase my work, as you need to explicitly state when you do either. Unfortunately, throughout my time writing the articles, I’ve come upon derivative works that didn’t respect these simple steps (i.e. they don’t specify when they quote me or they don’t provide the complete URL of the article). To be fair, sometimes this is involuntarily but others are the result of lack of care, so I find myself dedicating more text explaining this. On the other side, there are derivative works which have surprised me (in the positive way) with their way of referencing my articles, providing beyond of what the CC license asks for.

Anyway, if you have any doubts, you can check this referencing guide made by the University of Leeds.

12 Changelog

It’s always nice to keep a record of changes.

2021-05-16

Renamed CPU from ‘LR35902’ to ‘SM83’, as ‘Game Boy: Complete Technical Reference’ by Joonas Javanainen (gekkio) suggests it’s a more accurate name for the CPU itself (distinguished from the SoC)

Improved ‘Sources’ structure

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

13 Sources

The contents of this document could not have been possible without the research and expertise provided by the works listed here. Some are carried out for commercial purposes while others are entirely volunteer-driven.

[1]

E. Amos, “The vanamo online game museum.” [Online]. Available: https://commons.wikimedia.org/wiki/User:Evan-Amos

[2]

RealBoy, “Emulating the core.” [Online]. Available: https://realboyemulator.wordpress.com/posts/

[3]

J. J. (gekkio), Game boy: Complete technical reference. [Online]. Available: https://gekkio.fi/files/gb-docs/gbctr.pdf

[4]

M. Steil, “The ultimate game boy talk.” 33c3, Youtube [Online]. Available: https://www.youtube.com/watch?v=HyzD8pNlpwI

[5]

M. Fayzullin, “Programming info.” [Online]. Available: https://fms.komkon.org/GameBoy/Tech/Software.html

[6]

Nintendo, Gameboy programming manual - version 1.1. [Online]. Available: https://archive.org/details/GameBoyProgManVer1.1

[7]

R. Mongenel, “GameBoy memory map.” [Online]. Available: http://gameboy.mongenel.com/dmg/asmmemmap.html

[8]

codeslinger.co.uk, “Graphics emulation.” [Online]. Available: https://web.archive.org/web/20181011213834/http://www.codeslinger.co.uk/pages/projects/gameboy/graphics.html

[9]

Gameboy Development Wiki, “Gameboy sound hardware.” [Online]. Available: https://gbdev.gg8.se/wiki/articles/Gameboy_sound_hardware

[10]

Dhole, “Booting the GameBoy with a custom logo.” [Online]. Available: https://dhole.github.io/post/gameboy_custom_logo/

[11]

RealBoy, “A look at the game boy bootstrap: Let the fun begin!” [Online]. Available: https://realboyemulator.wordpress.com/2013/01/03/a-look-at-the-game-boy-bootstrap-let-the-fun-begin/

Also by Rodrigo Copetti

Architecture of Consoles: A Practical Analysis

NES Architecture

Game Boy Architecture

Mega Drive Architecture

SNES Architecture

Sega Saturn Architecture

PlayStation Architecture

Game Boy Advance Architecture

Nintendo 64 Architecture

Dreamcast Architecture

GameCube Architecture

Wii Architecture

PlayStation 2 Architecture

Xbox Architecture

Nintendo DS Architecture

Master System Architecture

PC Engine / TurboGrafx-16 Architecture

Virtual Boy Architecture

PSP Architecture

PlayStation 3 Architecture

Xbox 360 Architecture

Wii U Architecture