Game Boy Advance Architecture
The original Game Boy Advance. Released on 21/03/2001 in Japan, 11/06/2001 in America and 22/06/2001 in Europe
Showing revision '03'. Note that 'AGB' is the identifier of the Game Boy Advance model
Cartridge slot and amplifier are in the back
Game Boy Advance Architecture
Each data bus is labelled with its width.

A quick introduction

The internal design of the GameBoy Advance is quite impressive for being a portable console that runs on two AA batteries.

This console will carry on using Nintendo’s signature GPU, additionally it will introduce a relatively new CPU from a UK company that will surge in popularity in years to come.


CPU

Most of the components are compressed in a single package called CPU AGB. This package contains two completely different CPUs:

Both CPUs will never run at the same time or do any fancy co-processing, the only reason for including the very old Sharp is for backwards compatibility.

What’s new

Before ARM Holdings became incredibly popular in the smartphone world, they actually licensed their CPU designs to power Acorn’s computers, Nokia’s phones and some of Nintendo’s consoles. Their new design, the ARM7TDMI, is based on the old ARM710 with very distinct features:

Additionally, this core contains some extensions referenced in its name:

Memory locations

The inclusion of Thumb in particular had a strong influence in the final design of this console, Nintendo mixed 16-bit and 32-bit buses between its different modules to reduce costs while providing programmers with the necessary resources to optimise their code. Usable memory is distributed across the following locations:

Albeit this console being marketed as a 32-bit system, the majority of the memory is only accessible through a 16-bit bus, games will mostly use the Thumb instruction set to avoid spending two cycles per instruction. Only critical sections will be using the ARM instruction set.

How do they maintain compatibility

You’ll be surprised that there is no software implemented to detect whether the cartridge inserted is a GB or GBA one. Instead, the console relies on hardware switches: A shape detector effectively identifies the type of cartridge and then only passes power through the required bus.


Graphics

Before we begin, you’ll find the system a mix between the SNES and the GameBoy, the graphic’s core is still the well-known 2D engine called PPU. I recommend reading those articles before continuing since I’ll be revisiting lots of previously-explained concepts.

In terms of screen, we now have a colour LCD screen that displays up to 32,768 colours (15-bit), it has a resolution of 240x160 pixels and a refresh rate of ~60Hz.

Organising the content

PPU Diagram
Memory architecture of the PPU

We have the following regions of memory used to distribute our graphics:

Constructing the frame

If you’ve been reading the previous articles you’ll find the GBA a no-stranger, be that as it may, there will be additional functionality that may surprise you (don’t forget that this console runs on two AA batteries).

I’m going to borrow the graphics of Sega’s Sonic Advance 3 to show how a frame is composed.

Tiles

4bpp Tiles found in VRAM
Last block is reserved for sprites

GBA’s tiles are strictly 8x8 pixels bitmaps, additionally they can use 16 colours (4bpp) or 256 colours (8bpp).

Considering the space available in VRAM, we can store up to 512 8bpp tiles or 256 4bpp tiles.

Tiles are grouped in charblocks, each block is reserved for a specific type of layer.

Backgrounds

Affine background layers in use
Layer 3 will be scaled to simulate water effects

The background layer of this system has improved significantly since the times of the Gameboy Color, it finally includes some features found in the Super Nintendo (remember the affine transformations?).

There are up four background layers available, the capabilities of each one will depend on the selected mode of operation:

  • Mode 0: Provides four static layers.
  • Mode 1: Only three layers are available, although one of them is affine (can be rotated and/or scaled).
  • Mode 2: Supplies two affine layers.

Each layer be up to 512x512 pixels wide, if it’s an affine one then it will be up to 1024x1024 pixels.

Sprites

Sprites
Rendered Sprite layer

The size of a sprite can be up to 64x64 pixels wide, yet for having such a small screen they will end up occupying a big part of it.

If that wasn’t enough, the PPU can now apply affine transformations to sprites!

Sprite entries are 32-bit wide and their values can be divided in two groups:

  • Attributes: Contains x/y position, h/v flipping, size, shape (square or rectangle), sprite type (affine or regular) and location of first tile.
  • Affine data: Only used if the sprite is affine, specify scaling and rotation.

Result

Sprites
All layers merged (Tada!)

As always, the PPU will combine all layers automatically, but it’s not over yet! The system has a couple of effects available to apply over these layers:

  • Mosaic: Makes tiles look more blocky.
  • Alpha blending: Combines colours of two overlapping layers resulting in transparency effects.
  • Windowing: Divides the screen into two different windows where each one can have its own separate graphics and effects, the outer zone of both windows can also be provided with tiles.

On the other side, in order to update the frame there are multiple options available:

  • Command the CPU during VBlank/HBlank: The traditional way.
  • Use the DMA Controller: DMA provides transfer rates ~10x faster and can be scheduled during VBlank and HBlank. This console provides 4 DMA channels (two reserved for sound, one for critical operations and the other for general purpose). Bear in mind that the controller will halt the CPU during the operation (although it may hardly notice it!).

Beyond Tiles

Sometimes we may want to compose a background from which the tile engine won’t be able to draw all required graphics. Now, modern consoles addressed this by implementing a frame-buffer architecture but this is not possible when there’s very little RAM… Well, the GBA happens to have 96KB of VRAM which is enough to allocate a bitmap with the dimensions of our LCD screen.

Good news is that the PPU actually implemented this functionality by including three extra modes, these are called bitmap modes:

The reason for having two bitmaps is to enable page flipping: Drawing over a displayed bitmap can expose some weird artifacts during the process, so if we manipulate another one instead, none of the glitches will be shown to the user. Once the second bitmap is finished, the PPU can be updated to point to the second one, effectively swapping the displayed frame.

Demo

Sprites
Tonc's demo
Rendered bitmap with some primitives
Notice the screen doesn't show significant patterns produced by tile engines

Video

Sprites
Nickelodeon's SpongeBob SquarePants
Episode distributed as a GBA Video cartridge (it suffered a lot of compression, of course)

Overall it sounds like a cutting-the-edge feature, however most games held on to the tile engine. Why? Because in practice it costs a lot of CPU resources.

You see, while using a tile engine the CPU can delegate most of the computations to the graphics chip. By contrast, the frame-buffer system that the PPU provides is limited to only displaying that segment of memory, that means no more affine transformations, layering or effects unless the CPU computes them.

For this reason these modes are used exceptionally, such as for playing motion video (Game Boy Advance Video completely relied on this).


Audio

The GBA features a 2-channel sample player which works in combination with the legacy GameBoy sound system.

Here is a breakdown of each audio component using Sonic Advance 2 as example:

PCM

PCM-only channels

The new sound system can now play PCM samples, it provides two channels called Direct Sound where it receives samples using a FIFO queue (implemented as a 16-byte buffer).

Samples are 8-bit and signed (encoded in values from -128 to 127). The default sampling rate is 32 kHz, although this depends on each game: Since more rate means bigger size and more CPU cycles, not every game will spend the same amount of resources to feed the audio chip.

DMA is essential to avoid clogging CPU cycles, timers are also available to keep in-sync with the queue.

PSG

PSG-only channels

While the Game Boy subsystem won’t share its CPU, it does give out access to its PSG. For compatibility reasons this is the same design found on the original GameBoy, I’ve previously wrote this article that goes into detail about each channel in particular.

The majority of GBA games used it for accompaniment or effects, later ones will optimise their music for PCM and leave the PSG unused.

Combined

Tada!

Finally, everything is automatically mixed together and outputted through the speaker/headphone jack.

The resulting quality has often been compared against the SNES sound system and, to be honest, it depends on the angle: As a sample player the GBA wins (mainly because the SNES can’t play PCM samples!), however, if it tries to replicate any SNES’ module then it will always result in disadvantage (the GBA can’t compete with 16-bit sounds).

Additionally, this analysis has been so far theoretical: The GBA included its own mono speaker while the SNES relied on whatever speaker our TV had.


Best of both worlds

Some games took the PCM-PSG duality further and ‘alternated’ the leading chip depending on the context.

In this game (Mother 3), the player can enter two different rooms, one relatively normal and the other with a nostalgic setting. Depending on the room the character is in, the same score will sound modern-ish or 8bit-ish.

Normal room, only uses PCM
Nostalgic room, PSG leads the tune

Games

Programming for the GBA was similar to the SNES with the addition of all the advantages of developing games in the early 2000s: Standardised high-level languages, better compilers, faster RISC CPUs, non-proprietary computers for development, comparatively better documentation and… Internet access!

Games are mostly written in C with critical section in assembly (ARM and Thumb) to save cycles. Nintendo provided a SDK with libraries and compilers. BIOS calls were available to simplify I/O access and reduce cartridge size.

Cartridge space

In terms of medium, while the ARM7 has a 32-bit address bus, there are only 24 address pins connected to the cartridge (called Game Pak), so games can hold up to 32 MB without needing a mapper.

In order to hold saves, Game Paks could either include:

Accessories

The famous Game Boy Link Cable was available to play online with other GBAs connected on the other end of the cable.

Additionally, this cable has a special feature internally known as Multi-boot: Another console (either GBA or GameCube) can send a functional game to the receiver’s EWRAM, then the latter would boot from there (instead of needing a cartridge).


Anti-Piracy & Homebrew

In general terms, the usage of proprietary cartridges was a big barrier compared to the constant cat-and-mouse game that other console manufacturers had to battle while using the CD-ROM.

To combat against bootleg cartridges (unauthorised reproductions), the GBA’s BIOS incorporated the same boot process found in the original GameBoy.

Flashcards

As solid state storage became more accessible, a new type of cartridge appeared on the market. Flashcards looked like ordinary Game Paks but had the addition of a card slot (SD, MiniSD, MicroSD or whatever) which enabled to run game ROMs. The concept is not new actually, developers have internally used similar tools in order to test their games on a real console (and manufacturers provided the hardware to enable this).

However, commercial availability of these cards proved to be a grey area: Nintendo condemned its usage due to enabling piracy where as some users defended that it was the only method for running Homebrew (programs made outside game studios and consequently without the approval of Nintendo). After Nintendo’s legal attempts, these cartridges were banned in some countries (like in the UK) nonetheless they still persisted worldwide.


That’s all folks

My GBA
My GBA and a couple of games
Too bad it doesn't have a backlit!

Sources / Keep Reading

General

CPU

Graphics

Audio

Games

Anti-Piracy

Photography


Contributing

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.

Paypal

Changelog

## 2019-10-03

- Improved Thumb explanation

## 2019-09-17

- Added a quick introduction

## 2019-09-01

- Added my GBA 🧐

## 2019-08-26

- Used better wording on some explanations

## 2019-08-19

- Corrected wee mistakes

## 2019-08-18

- Ready for publication

Rodrigo Copetti

Rodrigo Copetti

Hope you enjoyed the article! If you want to know more about the author tap here and if you'd like to support him tap here instead

rss facebook twitter reddit