Game Boy Advance Architecture

A practical analysis by Rodrigo Copetti

Classic edition - Last updated: August 12, 2023

Languages available: 🇬🇧 - English, 🇵🇱 - Polski, 🇷🇺 - Русский, 👋 - Add translation

About this edition

The ‘classic’ edition is an alternative version to the ‘modern’ counterpart. It doesn‘t require Javascript, state-of-the-art CSS or convoluted HTML to work, which makes it ideal for readers who use accessibility tools or legacy internet browsers. On the other hand, eBook users can now check the eBook edition.

This edition is identical content-wise. However, interactive widgets have been simplified to work with pure HTML, though these will offer an link to the original article in case the reader wants to try the ‘full version’.

As always, this article 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.

Table of Contents

  1. Supporting imagery
  2. A quick introduction
  3. CPU
    1. What’s new?
    2. Memory locations
    3. Becoming a Game Boy Color
  4. Graphics
    1. Organising the content
    2. Constructing the frame
      1. Tiles
      2. Backgrounds
      3. Sprites
      4. Result
    3. Beyond Tiles
  5. Audio
    1. Functionality
      1. PCM
      2. PSG
      3. Combined
    2. Best of both worlds
  6. Operating System
  7. Games
    1. Accessing cartridge data
    2. Cartridge RAM space
    3. Accessories
  8. Anti-Piracy & Homebrew
    1. Flashcarts
  9. That’s all folks
  10. Copyright and permissions
  11. Sources / Keep Reading
  12. Contributing
  13. Changelog

Supporting imagery


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 audio amplifier are on the back.
Motherboard with important parts labelled


Main architecture diagram
Each data bus is labelled with its width.
The layout shown of the AGB Game Pak doesn't include a mapper (as the new CPU is able to address significantly more memory), although games with a large ROM may still bundle one.

A quick introduction

The internal design of the Game Boy Advance is quite impressive for 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 British company that will surge in popularity in the years to come.


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

Note that 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 (currently “Arm”) became incredibly popular in the smartphone world, they licensed their CPU designs to power Acorn’s computers, Apple’s Newton, Nokia’s phones and the Panasonic 3DO. Nintendo’s chosen CPU, the ARM7TDMI, is based on the earlier ARM710 design and includes [1]:

Moreover, this core contains some extensions referenced in its name (TDMI):

Memory locations

The inclusion of Thumb in particular had a strong influence on 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.

Memory architecture of this system.

Usable memory is distributed across the following locations (ordered from fastest to slowest) [3]:

Although this console was marketed as a 32-bit system, the majority of its memory is only accessible through a 16-bit bus, meaning games will mostly use the Thumb instruction set to avoid spending two cycles per instruction fetch. Only in very exceptional circumstances (i.e. need to use instructions not found on Thumb while storing them in IWRAM), programmers will benefit from the ARM instruction set.

Becoming a Game Boy Color

Apart from the inclusion of GBC hardware (Sharp SM83, original BIOS, audio and video modes, compatible cartridge slot and so forth), there are two extra functions required to make backwards compatibility work.

From the hardware side, the console relies on switches to detect if a Game Boy or Game Boy Color cartridge is inserted. A shape detector in the cartridge slot effectively identifies the type of cartridge and allows the CPU to read its state. It is assumed that some component of CPU AGB reads that value and automatically powers off the hardware not needed in GBC mode.

From the software side, there is a special 16-bit register called REG_DISPCNT which can alter many properties of the display, but one of its bits sets the console to ‘GBC mode’ [5]. At first, I struggled to understand exactly when the GBA tries to update this register. Luckily, some developers helped to clarify this:

I think what happens during GBC boot is that it checks the switch (readable at REG_WAITCNT 0x4000204), does the fade (a very fast fade, hard to notice), then finally switches to GBC mode (BIOS writes to REG_DISPCNT 0x4000000), stopping the ARM7.

The only missing piece of the puzzle is what would happen if you were to remove a portion of the GBC cartridge shell so the switch isn’t pressed anymore, then did a software mode-switch to GBC mode. Multi-boot mode could help here. I’m not sure if the switch needs to be pressed down for the GBC cartridge bus to work properly, or if it just works. I’m willing to guess that the switch is necessary for the bus to function, but that’s just a guess.

Dan Weiss (aka Dwedit, current maintainer of PocketNES and Goomba Color)


Before we begin, you’ll find the system a mix between the SNES and the Game Boy, the graphics 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.

Compared to previous Game Boys we now have a colour LCD screen that can display up to 32,768 colours (15-bit). It has a resolution of 240x160 pixels and a refresh rate of ~60Hz.

Organising the content

Memory architecture of the PPU.

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

Constructing the frame

If you’ve read the previous articles you’ll find the GBA familiar, although there is additional functionality that may surprise you, and 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.


These two blocks are made of 4 bpp Tiles.
You may notice some weird vertical patterns in here, these are not graphics but ‘Tile Maps’ (see next section).
These two blocks are reserved for sprites.
Pairs of charblocks found in VRAM.

GBA’s tiles are strictly 8x8 pixel bitmaps, they can use 16 colours (4 bpp) or 256 colours (8 bpp). 4 bpp tiles consume 32 bytes, while 8 bpp ones take 64 bytes.

Tiles can be stored anywhere in VRAM, however, the PPU wants them grouped into charblocks: A region of 16 KB. Each block is reserved for a specific type of layer (background and sprites) and programmers decide where each charblock starts. This can result in some overlapping which, as a consequence, enables two charblocks to share the same tiles.

Due to the size of a charblock, up to 256 8 bpp tiles or 512 4 bpp tiles can be stored per block. Up to six charblocks are allowed, which combined require 96 KB of memory: The exact amount of VRAM this console has.

Only four charblocks can be used for backgrounds and two can be used for sprites.


Background Layer 0 (BG0).
Background Layer 2 (BG2).
Background Layer 3 (BG3).
This particular layer will be shifted horizontally at certain scan-lines to simulate water effects.
Static background layers in use.

The background layer of this system has improved significantly since the Game Boy Color. It finally includes some features found in the Super Nintendo (remember the affine transformations?).

The PPU can draw up to four background layers. The capabilities of each one will depend on the selected mode of operation [6]:

Each layer has a dimension of up to 512x512 pixels. If it’s an affine one then it will be up to 1024x1024 pixels.

The piece of data that defines the background layer is called Tile Map. To implement this in a way that the PPU understands it, programmers use screenblocks, a structure that defines portions of the background layer (32x32 tiles). A screenblock occupies just 2 KB, but more than one will be needed to construct the whole layer. Programmers may place them anywhere inside the background charblocks, this means that not all tiles entries will contain graphics!


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 into two groups:


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:

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

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 96 KB of VRAM which is enough to allocate a bitmap with the dimensions of our LCD screen.

The good news is that the PPU actually implemented this functionality by including three extra modes, these are called bitmap modes [7]:

The reason for having two bitmaps is to enable page-flipping: Drawing over a displayed bitmap can expose some weird artefacts during the process. If we instead manipulate another one then 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.

Super Monkey Ball Jr. (2002).
Bitmap mode allowed the CPU to provide some rudimentary 3D graphics for the scenery.
Foreground objects are sprites (separate layer).
Tonc’s demo.
Rendered bitmap with some primitives.
Notice the screen doesn’t show significant patterns produced by tile engines.
Nickelodeon’s SpongeBob SquarePants.
Episode distributed as a GBA Video cartridge (it suffered a lot of compression, of course).
Examples of programs using bitmap modes.

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 as a single background layer, which means no more individual affine transformations, layering or effects unless the CPU computes them. Also, the frame-buffer occupies 80 KB of memory, so only 16 KB (half) are available to store sprite tiles.

For this reason, these modes are used exceptionally, such as for playing motion video (Game Boy Advance Video completely relied on this) or rendering 3D geometry with the CPU.


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


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


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 a higher rate means a larger 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-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 Game Boy. I’ve previously written 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.



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

Even though the GBA has just two PCM channels, some games can magically play more than two concurrent samples. How is this possible? Well, while only having two channels may seem a bit weak on paper, the main CPU can use some of its cycles to provide both audio sequencing and mixing [8] (that should give you an idea of how powerful the ARM7 is!). Furthermore, in the ‘Operating System’ section, you’ll find out that the BIOS ROM included an audio sequencer!

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.

Operating System

ARM7’s reset vector is at 0x00000000, which points to a 16 KB BIOS ROM. That means the Game Boy Advance first boots from the BIOS, which in turn shows the iconic splash screen and then decides whether to load the game or not.

That ROM also stores software routines that games may call to simplify certain operations and reduce cartridge size [9]. These include:

The BIOS is connected through a 32-bit bus and it’s implemented using a combination of Arm and Thumb instructions, though the latter is the most prominent.

Also, remember that all of this will only run on the ARM7. In other words, there isn’t any hardware acceleration available to speed up these operations. Hence, Nintendo provided all of this functionality through software.


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!

Programs are mostly written in C with performance-critical sections in assembly (ARM and Thumb) to save cycles. Nintendo provided an SDK with libraries and compilers.

Games are distributed in a new proprietary cartridge called Game Pak.

Accessing cartridge data

While the ARM7 has a 32-bit address bus, there are only 24 address lines connected to the cartridge. This should mean that up to 16 MB can be accessed on the cartridge without needing a mapper, however, the official docs state that 32 MB of cartridge data are mapped in memory. So what’s happening here? The truth is, the Gamepak uses 25-bit addresses (which explains that 32 MB block) but its bottommost bit is fixed at zero, so the only 24 remaining bits are set. This is how Gamepak addressing works.

Now, does this mean that data located at odd addresses (with its least significant bit at ‘1’) will be inaccessible? No, because the data bus is 16-bit: For every transfer, the CPU/DMA will fetch the located byte plus the next one, allowing to read both even and odd addresses. As you can see, this is just another work of engineering that makes full use of hardware capabilities while reducing costs.

Cartridge RAM space

To hold saves, Game Paks could either include [10]:


The famous Game Boy Link Cable provided multi-playing capabilities. Additionally, the 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 Game Boy.


As solid-state storage became more affordable, a new type of cartridge appeared on the market. Flashcarts looked like ordinary Game Paks but had the addition of a re-writable memory or a card slot that enabled to run game ROMs. The concept is not new actually, developers have internally used similar tools to test their games on a real console (and manufacturers provided the hardware to enable this).

Earlier solutions included a burnable NOR Flash memory (not exceeding the 32 MB) and some battery-backed SRAM. To upload binaries to the cartridge, the cart came with a Link-to-USB cable that was used with a GBA and a PC running Windows XP. With the use of a proprietary flasher software and drivers, the computer uploaded a multi-boot program to the GBA, which in turn was used to transfer a game binary from the PC to the Flashcart inserted in the GBA. Overall, the whole task of uploading a game was deemed sluggish. Later Flashcarts (like the ‘EZ-Flash’) offered larger storage and the ability to be programmed without requiring the GBA as an intermediate [11]. The last ones relied on removable storage (SD, MiniSD, MicroSD or whatever).

Commercial availability of these cards proved to be a grey area: Nintendo condemned its usage due to enabling piracy whereas some users defended that it was the only method for running Homebrew (programs made outside game studios and consequently without the approval of Nintendo). Nintendo’s argument was backed by the fact flashers like the EZ-Writer assisted users to patch game ROMs so they can run in EZ-Flash carts without problems. After Nintendo’s legal attempts, these cartridges were banned in some countries (like in the UK). Nonetheless, they persisted worldwide.

That’s all folks

My GBA and a couple of games.
Too bad it doesn’t have a backlight!


This article is part of the Architecture of Consoles series. If you found it interesting then 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.

Donate with PayPal
Become a Patreon

You can also buy the eBook edition in English. I treat profits as donations.


A list of desirable tools and latest acquisitions for this article are tracked in here:

Interesting hardware to get (ordered by priority)

Acquired tools used

Alternatively, you can help out by suggesting changes and/or adding translations.

Copyright and permissions

This work is licensed under a Creative Commons Attribution 4.0 International License. You may use it for your work at no cost, even for commercial purposes. But you have to respect the license and reference the article properly. Please take a look at the following guidelines and permissions:

Article information and referencing

For any referencing style, you can use the following information:

For instance, to use with BibTeX:

    url = {},
    title = {Game Boy Advance Architecture - A Practical Analysis},
    author = {Rodrigo Copetti},
    year = {2019}

or a IEEE style citation:

[1]R. Copetti, "Game Boy Advance Architecture - A Practical Analysis",, 2019. [Online]. Available: [Accessed: day- month- year].

Special use in multimedia (Youtube, Twitch, etc)

I only ask that you at least state the author’s name, the title of the article and the URL of the article, using any style of choice.

You don’t have to include all the information in the same place if it’s not feasible. For instance, if you use the article’s imagery in a Youtube video, you may state either the author’s name or URL of the article at the bottom of the image, and then include the complete reference in the video description. In other words, for any resource used from this website, let your viewers know where it originates from.

This is a very nice example because the channel shows this website directly and their viewers know where to find it. In fact, I was so impressed with their content and commentary that I gave them an interview 🙂.

Appreciated additions

If this article has significantly contributed to your work, I would appreciate it if you could dedicate an acknowledgement section, just like I do with the people and communities that helped me.

This is of course optional and beyond the requirements of the CC license, but I think it’s a nice detail that makes us, the random authors on the net, feel part of something bigger.

Third-party publishing

If you are interested in publishing this article on a third-party website, please get in touch.

If you have translated an article and wish to publish it on a third-party website, I tend to be open about it, but please contact me first.

Sources / Keep Reading






Operating System



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