Game Boy Advance Architecture

Before we begin, you'll find the graphics capabilities to be a blend of Super Nintendo and Game Boy elements. In fact, the new graphics core is still called Picture Processing Unit (PPU). Thus, I recommend reading those articles first, as I will be revisiting many previously explained concepts.

Comparison of screen resolution and aspect ratio between the Game Boy and Game Boy Advance series.

Compared to previous Game Boys, we now have an LCD screen with a richer colour gamut, capable of displaying up to 32,768 colours (15-bit). It features a resolution of 240 x 160 pixels (giving games a 'wide-screen' look) and a refresh rate of ~60 Hz. I wonder if the new aspect ratio was directed towards benefiting platform games.

Organising the content

Memory architecture of the PPU.

Graphics data is distributed across these memory regions:

• 96 KB 16-bit VRAM (Video RAM): 64 KB store backgrounds and 32 KB store sprites.
• 1 KB 32-bit OAM (Object Attribute Memory): Houses up to 128 sprite entries (not the graphics, just the indices and attributes). As noted by its wide bus, OAM is exclusively optimised for fast access.
• 1 KB 16-bit PAL RAM (Palette RAM): Holds two big palettes, one for backgrounds and one for sprites. Each palette contains 256 entries of 15-bit colours each, where colour 0 means transparent.

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. Regardless, the fact the new system operates on just two AA batteries makes this study even more enthralling.

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

Tiles

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' (explained in the next section).

These two blocks are reserved for sprites.

GBA's tiles are still 8 x 8 pixel bitmaps, but they can now use either 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 expects them to be grouped into charblocks - continuous regions of 16 KB. Each charblock is reserved for a specific type of layer (either background or sprites), and programmers decide where each charblock begins. This can result in some overlapping, which in turn 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. Overall, up to six charblocks can be allocated, which combined require 96 KB of memory - the exact amount of VRAM this console has.

Finally, only four charblocks can be used for backgrounds, while two may be used for sprites.

Backgrounds

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.

The background layer of this system has seen significant improvements since the Game Boy Color. It finally incorporates some features previously found in the Super Nintendo (remember affine transformations?).

The PPU can draw up to four background layers. 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 (capable of rotation and/or scaling).
• Mode 2: Supplies two affine layers.

Each layer has a dimension of up to 512 x 512 pixels. For affine layers, this extends to a maximum of 1024 x 1024 pixels.

The piece of data that defines the background layer is still called Tile Map. That said, this information is now encoded in the form of screenblocks - structures that define portions of the background layer (32 x 32 tiles). A single screenblock occupies just 2 KB, though multiple are needed to construct the whole layer. Programmers may place screenblocks anywhere in VRAM, potentially overlapping background charblocks (where tiles reside). This means that not all tile entries contain graphics!

Sprites

Rendered sprite layer.

A sprite can be up to 64 x 64 pixels in size. Yet, considering the 240 x 160-pixel screen, sprites will end up occupying a significant part of it.

As if that weren't enough, the PPU can now apply affine transformations to sprites! Specifically, rotation and scaling.

Sprite entries are 32-bit wide and their properties are divided into two groups:

• Attributes: These include x/y position, horizontal and vertical flipping, size, shape (square or rectangle), sprite type (affine or regular), and the location of the first tile.
• Affine data: Only needed for affine sprites. This specifies scaling and rotation .
  • With scaling, sprites may instead occupy up to 128 x 128 pixels on the screen.

Result

All layers merged (Tada!).

As always, the PPU combines and outputs all layers automatically, but it's not over yet! The system provides plenty of effects to apply to these layers :

• Mosaic: Makes tiles look even more blocky.
• Colour blending: Combines the colours of two groups of overlapping layers. The opacity of each group can be controlled to achieve varying degrees of transparency. Alternatively, the second group can be set to solid black or white, resulting in fading effects.
• Windowing: Divides the screen into three separate rectangular areas (called 'windows'). These may overlap, and each hosts its own graphics and blending controls. Two windows have programmable positions, while the third is the complement of the first two (in other words, the remainder of the screen not covered by them).

I have to say, these are strongly reminiscent of the Super Nintendo era.

Similarly, to update the frame, there are multiple options available:

• Command the CPU: The processor now has full access to VRAM whenever it wants. However, it may produce unwanted artefacts if it alters data mid-frame, so waiting for VBlank/HBlank (traditional way) remains the safest option in most cases.
• Use the DMA Controller: Direct Memory Access (DMA) provides transfer rates around ten times faster and can be scheduled during VBlank and HBlank. This console offers four DMA channels (two reserved for sound, one for critical operations, and one for general use). Bear in mind that the controller halts the CPU during the operation, although if used properly, the CPU will hardly notice.

Beyond Tiles

Sometimes, game artists may design a background for which the tile engine can't draw all required graphics. Now, modern consoles addressed this by implementing a frame-buffer architecture, enabling programmers to arbitrarily alter each pixel individually. However, this is not possible when there's very little memory... Well, the GBA happens to house 96 KB of VRAM. This is enough to allocate a bitmap matching the dimensions of the LCD screen.

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

• Mode 3: Allocates a single fully-coloured frame (16 bpp/32,768 colours).
• Mode 4: Provides two frames, each with half the colour depth (8 bpp/256 colours).
• Mode 5: Offers two fully-coloured frames, each at half size (160 x 128 pixels).

The reason for offering two bitmaps is to enable page-flipping: drawing over a displayed bitmap can expose unwanted artefacts during the process. If the CPU instead manipulates a secondary bitmap, none of the glitches will be visible to the user. Once the second bitmap is finished, the PPU can be updated to point to it, effectively swapping the displayed frame.

Super Monkey Ball Jr. (2002). Bitmap mode allowed the CPU to render rudimentary 3D graphics for the scenery, while foreground objects were handled as sprites (a separate layer).

Tonc's bitmap demo (Homebrew). Notice that the screen doesn't show the typical patterns produced by tile engines.

Nickelodeon's SpongeBob SquarePants (distributed as a GBA Video cartridge). To fit the medium, it underwent heavy compression.

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

You see, the tile engine enables the CPU to delegate most computations to the graphics chip. By contrast, the frame-buffer system provided by the PPU 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. Additionally, the frame-buffer occupies 80 KB of memory, leaving only 16 KB (half) available to store sprite tiles.

For this reason, these new modes were predominantly useful in exceptional cases, such as playing motion video (the Game Boy Advance Video series relied completely on this) or displaying 3D geometry (rendered by the CPU). In any case, the results were undeniably impressive.

Hidden capabilities

That's as far as the official perks go, but in the undocumented realm, there are obscure controls left installed that suggest additional, perhaps at one point envisioned, capabilities of the Game Boy Advance:

• For instance, a flag inside the DISPCNT register (affecting the LCD controller) enables a so-called 'green swap' mode . Upon activation, the display controller swaps the green composition of contiguous pixel pairs. It's not clear why Nintendo implemented this.
• To make things more intriguing, enabling green swap also unlocks other flags in the background and sprite maps. These instruct the PPU to render only the odd or even columns of each map .

All in all, these appear to be pieces of a large puzzle, perhaps aimed at implementing a stereoscopic function that was abandoned halfway through. Be that as it may, a previous interview with Satoru Iwata suggests that the Game Boy Advance SP was originally planned to bundle a stereoscopic screen , but the loss in display resolution delayed the plan until the arrival of the Nintendo 3DS, eight years later.