1.
GBA Hardware

1.1.
Meet the GBA

The Nintendo GameBoy Advance (GBA) is a portable games console.
As if you didn't know already. The CPU is a 32-bit ARM7tdmi chip
running at 16.78 MHz. It has a number of distinct memory areas
(like work RAM, IO and video memory) which we will look into shortly.
The games are stored on Game Paks, consisting of ROM for
code and data, and fairly often some RAM for saving game info. The
GBA has a 240x160 LCD screen capable of displaying 32768 colors
(15 bits). Unfortunately, the screen is not back-lit, which made a
lot of people very angry and has generally been regarded as a bad
move. So, in 2003 Nintendo launched the GBA SP, a sort of GBA 2.0,
which features a fold-up screen reminiscent of the old Game & Watch
games (remember those? You do? Boy, you are old! (For the
record, I still have mine too :) )). Then in came the
final GBA version, the GBA micro, a very, very small GBA which easily
fits in everyone's pockets. The differences the GBA, GBA-SP and Micro
are mainly cosmetic, though, they're the same thing from a programming
point of view.

The original GameBoy which took the world by storm in 1989. Not bad
for a monochrome handheld console, eh? Later the GameBoy Color was
released which finally put some color on the aging machine, but it
was still very much a simple GameBoy. The true successor was the GBA,
released in 2002. The GBA is backward compatible with the GameBoy,
so you can play all the old GB games as well.

In terms of capabilities the GBA is a lot like the Super NES (SNES):
15bit color, multiple background layers and hardware rotation and
scaling. And shoulder buttons, of course. A cynic might look at the
enormous amount of SNES ports and say that the GBA is a
SNES, only portable. This is true, but you can hardly call that a
bad thing.

Fig 1.1: original GBA.

Fig 1.2: GBA-SP.

1.2.
GBA specs and capabilities

Below is a list of the specifications and capabilities of the GBA. This
not a full list, but these are the most important things you need to know.

Video

240x160 pixel, 15bit color LCD screen. The original GBA screen was not
backlit, but the SP's and Micro's are.

Optional infrared, solar and gyroscopic interfaces. Other interfaces have
also been made by some.

Main programming platforms: C/C++ and assembly, though there are tools for
Pascal, Forth, LUA and others as well. Easy to start with, yet hard to truly
master.

From a programming point of view, the GBA (or any other console
for that matter) is totally different from a PC. There is no
operating system, no messing with drivers and hardware
incompatibilities; it's bits as far as the eye can see. Well,
PCs are also just bits, but that's several layers down; on consoles
it's just you, the CPU and memory. Basically, it's the Real
Programmer's dream.

To get anything done, you use memory-mapped IO. Specific areas
of memory are mapped directly to hardware functions. In the first demo,
for example, we will write the number 0x0403 to memory
address 0400:0000h. This tells the GBA to enable
background 2 and set the graphics mode to 3. What this actually
means is, of course, what this tutorial is for :).

1.2.1.
CPU

As said, the GBA runs on a ARM7tdmi RISC chip at 16.78 MHz
(224 cycles/second). It is a 32bit chip that can run on
two different instruction sets. First, there's is ARM code,
which is a set of 32bit instructions.
Then there's THUMB,
which uses 16bit instructions. THUMB instructions are a subset of
the ARM instruction set; since the instructions are shorter, the
code can be smaller, but their power is also reduced. It is recommended
that normal code be THUMB code in ROM, and for time-critical code to
be ARM code and put in IWRAM. Since all tonc-demos are still rather
simple, most (but not all) code is THUMB code.

1.3.
Memory Sections

This section lists the various memory areas. It's basically
a summary of the GBATek
section on memory.

area

start

end

length

port-size

description

System ROM

0000:0000h

0000:3FFFh

16kb

32 bit

BIOS memory. You can execute it, but not read it (i.o.w, touch,
don't look).

EWRAM

0200:0000h

0203:FFFFh

256kb

16 bit

External work RAM. Is available for your code and data. If
you're using a multiboot cable, this is where the downloaded code
goes and execution starts (normally execution starts at ROM).
Due to the 16bit port, you want this section's code to be THUMB
code.

IWRAM

0300:0000h

0300:7FFFh

32kb

32 bit

This is also available for code and data. The 32-bit bus
and the fact that it's embedded in the CPU make this the fastest
memory section. The 32bit bus means that ARM instructions can
be loaded at once, so put your ARM code here.

IO RAM

0400:0000h

0400:03FFh

1kb

16 bit

Memory-mapped IO registers. These have nothing to do with the
CPU registers you use in assembly so the name can be a bit
confusing. Don't blame me for that. This section is where you
control graphics, sound, buttons and other features.

PAL RAM

0500:0000h

0500:03FFh

1kb

16 bit

Memory for two palettes containing 256 entries of 15-bit colors
each. The first is for backgrounds, the second for sprites.

VRAM

0600:0000h

0601:7FFFh

96kb

16 bit

Video RAM. This is where the data used for backgrounds and
sprites are stored. The interpretation of this data depends
on a number of things, including video mode and background and
sprite settings.

OAM

0700:0000h

0700:03FFh

1kb

32 bit

Object Attribute Memory. This is where you control the
sprites.

PAK ROM

0800:0000h

var

var

16 bit

Game Pak ROM. This is where the game is located and execution
starts, except when you're running from a multiboot cable.
The size is variable, but the limit is 32 MB. It's a 16bit bus,
so THUMB code is preferable over ARM code here.

Cart RAM

0E00:0000h

var

var

8 bit

This is where saved data is stored. Cart RAM can be in the
form of SRAM, Flash ROM or EEPROM. Programmatically they all
do the same thing: store data. The total size is variable,
but 64kb is a good indication.

The various RAM sections (apart from Cart RAM) are zeroed
at start-up by BIOS. The areas you will deal with them most are
IO, PAL, VRAM and OAM. For simple games and demos it will usually
suffice to load your graphics data into PAL and VRAM at the start
use IO and OAM to take care of the actual interaction. The layout of
these two sections is quite complex and almost impossible to
figure out on your own (almost, because emulator builders obviously
have done just that). With this in mind, reference sheets like the
GBATek and the
CowBite Spec are unmissable documents. In theory this is all
you need to get you started, but in practice using one or more
tutorials (such as this one) with example code will save a lot of
headaches.