Game Boy Advance Architecture

Most of the building blocks of this console are combined into a single package called CPU AGB. This contains two entirely different CPUs:

• A Sharp SM83 running at either 8.4 or 4.2 MHz. If it isn't the same CPU found on the Game Boy! It's effectively used to run Game Boy (DMG) and Game Boy Color (CGB) titles. My previous article provides an overview of the predecessor.
• An ARM7TDMI running at 16.78 MHz: This is the new processor we will focus on; it most certainly runs Game Boy Advance games.

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.

With that in mind, let's dive into the ARM chip. However, since this is the first ARM CPU discussed in this series, let me start with the background history, I promise it will be worth it!

The Cambridge miracle

The story about the origins of the ARM CPU and its subsequent rise to fame is riveting. Here we find a combination of public investment, exponential growth, ill-fated decisions, and long-distance partnerships.

The rise of Acorn Computers

The BBC Micro (1981) with a box of 5¼ disks on top , the first disk features the game Elite (1984).

The ARM Evaluation Board (1986), a 'Tube' module carrying an ARM1 CPU. I found it at The Centre for Computing History (Cambridge, UK).

The late 70s were a tumultuous time for the United Kingdom populace. The interventionist economy once built under post-war ideals had reached its course, and the pendulum soon swung towards free-market reforms. Amid this storm, Cambridge-based ventures such as Acorn Computers, along with Sinclair and the like, were selling computer kits to laboratories and hobbyists. Similarly to American and Japanese enterprises, Acorn's computers relied on the 6502 CPU and a proprietary BASIC dialect.

Entering the 80s, ministerial interests within the new British government led to the creation of a project aimed at uplifting computer literacy in schools . Thanks to Acorn's upcoming 'Proton' home computer, the company was awarded the contract to build an affordable computer that would realise the government's vision. The result was the BBC Micro (nicknamed the Beeb), which enjoyed significant success among schools, teachers, and pupils. Inside the Micro, Acorn incorporated an avant-garde 'Tube' interface that could expand the computer with a second processor. This paved the way for Acorn's next big investment.

During the development of their next product, this time enterprise-focused, Acorn did not find a suitable CPU to succeed the 6502. Pressure to innovate in the face of Japanese and American competition, coupled with unfortunate planning, placed Acorn in a troubled financial state. Thus, a new division in Acorn was tasked to produce a compelling CPU. To work around Acorn's recent constraints, the CPU team based their architecture on the teachings of a research paper called The Case for the Reduced Instruction Set Computer and its prototype, the RISC CPU . Finally, in 1985, Acorn delivered the ARM1 CPU as a Tube module for the BBC Micro, although it was marketed solely for R&D purposes. It wouldn't be until 1987, with the introduction of the first Acorn Archimedes computer, that ARM chips (by then, the ARM2 CPU) would take a central role.

A new CPU venture

A late Newton model... after a few minutes playing with it.

During the commercialisation of the Acorn Archimedes, Apple became captivated by Acorn's energy-efficient CPUs, but the American company was still unconvinced that Acorn's latest ARM3 was suitable for Apple's new pet project, the Newton. However, rather than walking away (after all, Acorn was a competitor), both explored the possibility of evolving the ARM3 to meet Apple's requirements , namely flexible clock frequency, an integrated Memory Management Unit (MMU), and complete 32-bit addressing.

This collaboration soon turned into a partnership in which Acorn, Apple, and VLSI (ARM's chip manufacturer) set up a new company solely focused on developing ARM CPUs. Apple provided the investment (obtaining a 43% stake), Acorn shared its staff, and VLSI took care of manufacturing. In 1990, Advanced RISC Machines (ARM) Ltd came into existence, with Robin Saxby appointed as executive chairman.

Years after, Apple finally shipped the Newton MessagePad, powered by an ARM610 - one of the next-generation ARM chips shaped by Apple's input. Meanwhile, Acorn also released the RiscPC using the new CPUs.

Now, while Acorn and Apple lingered on the computer/handheld market, ARM devised a radical business model. Keeping away from manufacturing, Saxby's vision centred on licensing ARM's intellectual property, in the form of CPU designs and its instruction set . This granted ARM with clients beyond the computer realm, such as Texas Instruments , which later connected the company to the emerging mobile market (culminating in the Nokia 6110) and set-top boxes. The follow-up years would see ARM's technology being bundled in billions of mobile devices .

The Nintendo partnership

Back in Japan, and thanks to the Game Boy analysis, we have learnt that Nintendo's hardware strategy for portable systems favours a System-on-Chip (SoC) model. This has allowed the company to obfuscate affordable off-the-shelf technology and combine it with in-house developments. In doing so, the new console could be unique and competitive. Fortunately, ARM's licensing model fitted just right for those needs.

The CPU AGB chip, housing the ARM7TDMI CPU (among many other components).

Both companies had been in discussions since 1994 (a year before the Virtual Boy's launch), likely as part of 'Project Atlantis', during which Nintendo considered the ARM710 . However, nothing materialised until many years later , and the reason was simple: the Japanese found ARM's code density and the need for 32 data wires unfeasible (something the Virtual Boy's CPU had already managed to escape). Nevertheless, ARM's new CPU designer - Dave Jaggar - quickly answered with the ARM7TDMI, a new design that focused on maximising performance under power and storage constraints. This marked a turning point for ARM, as this new product not only pleased Nintendo, but also got the attention of Texas Instruments, Nokia, and other competitors in the cellphone arena.

Unsurprisingly, when Nintendo started working on the successor of the Game Boy Color, their CPU pick became the ARM7TDMI.

The ARM7TDMI

Let's now examine what this chip has to offer.

Commanding the CPU

To begin with, the ARM7TDMI implements the ARMv4 instruction set, the successor of the ARMv3. This implies:

• A RISC-based design: As explained before, ARM CPUs have been influenced by a paper from the University of California, Berkeley called 'The Case for the Reduced Instruction Set Computer' . Its research outlines a series of guidelines for scalable processor design and advocates the use of a load-store architecture, fixed instruction size, and a large register file. Many of these traits were absent from the crowded CPU market at the time (i.e. the Intel 8086, MOS 6502, Zilog Z80, and the Motorola 68000), but they would influence the design of new CPU lines throughout the 80s and 90s.
• Conditional execution: A peculiar feature of the ARM ISA. Essentially, almost every instruction embeds a condition that states whether it should be executed. Typically, other CPUs follow the 'compare and jump' process (also called 'branching') to control which instructions the CPU must execute. By contrast, ARM programmers may insert the condition in the instruction itself. This is possible due to the first four bits of ARM's opcodes are reserved for a condition (i.e. equal, not equal, etc). All in all, this reduces the complexity of ARM code, as conditional execution provides a cleaner design for routines, unlike branching and subroutine splitting. Additionally, this also serves as a workaround for control hazards (explained in more detail later).
• A flexible second operand, also known as 'Operand2' . Typically, operations are made of two operands (like add 2 and 2). However, ARM instructions also allow embedding an extra shift operation into the second operand. For example, you can compute shift 2 by four bits and then add it to 2 in a single instruction.
  • Bit shifting is also a cheap shortcut to perform division or multiplication with powers of 2, which leads to many optimisation techniques.
• 32-bit and 64-bit multiplication instructions: An addition in ARMv4. Furthermore, 64-bit operations output the result in two registers.

The package

Now that we know how developers talk to this chip, let's check what's inside the silicon.

The core

In terms of circuitry, the ARM7TDMI is a cut-down version of the ARM710 with interesting additions. The core includes :

• 16 general-purpose 32-bit registers: While it's a big step compared to the seven 8-bit registers of the SM83/Game Boy, it represents a compromise on the RISC guidelines, which stipulate thirty-two 32-bit registers. This is because ARM favoured maintaining a small silicon footprint .
• 32-bit data bus and Arithmetic Logic Unit (ALU): Meaning it can move and operate 32-bit values without consuming extra cycles.
• Clean 32-bit addressing: This is part of Apple's input. The first three ARM CPUs employed 26-bit memory addresses to optimise performance (allowing to store the Program Counter and Status Register in a single 32-bit word) in exchange for memory addressability (only up to 64 MB of memory could be accessed). The follow-up ARM6 series (with its ARMv3 ISA) introduced 32-bit addressing logic, but kept a backwards-compatible mode for legacy code. Now, the ARM7TDMI (being mobile-focused) scrapped the 26-bit mode and only houses logic for 32-bit addresses, thereby reducing the amount of silicon needed.
• No Memory Management Unit (MMU): Ever since the ARM1, ARM provided an MMU solution. First as the 'MEMC' co-processor, and then integrated with the ARM610. Now, the ARM7TDMI seems to be the only one in its series to provide none, potentially due to the lack of interest (as early mobile devices didn't require sophisticated virtual memory).
• No cache: Another cost-saving measure in this chip, as earlier ARM chips bundled some cache.

Finally, all of this can operate with a 3 Volt power supply . This is an evident step towards mobile computing, as earlier cores required a 5 V supply.

The pipeline

Since its first iteration, ARM has implemented a three-stage pipeline to run code. In other words, the execution of instructions is divided into three steps or stages. The CPU will fetch, decode and execute up to three instructions concurrently. This enables maximum use of the CPU's resources (which reduces idle silicon) while also increasing the number of instructions executed per unit of time.

Like two closely related contemporaries, ARM CPUs are susceptible to data hazards. Nevertheless, neither the programmer nor the compiler will notice them, as, in this case, the CPU automatically stalls the pipeline when necessary.

Control hazards are also present, but ARM tackled them with an efficient approach called conditional annulment: whenever a branch instruction reaches the second stage (Decode), the CPU evaluates the branch condition . Based on the result, if the branch is to be taken, the CPU automatically nullifies the follow-up instruction (turning it into a filler). Now, this may look inefficient when compared to MIPS' approach (as a MIPS compiler can insert useful instructions, not just fillers). Hence, apart from branching, ARM provides conditional execution. The latter turns this pipeline design into an advantage, since ARM can decode an instruction and calculate its embedded condition at the same stage. Thus, in this case, no fillers are added. This is why conditional execution is preferred over branching when programming for ARM CPUs .

Squeezing performance

One of the drawbacks of load-store architectures led to ARM's code being very sparse. Competitors like x86 could perform the same tasks using smaller amounts of code, requiring less storage. Consequently, when Nintendo took a look at ARM's latest design, the ARM7, they weren't pleased with it. The size of ARM's instructions meant that hypothetical gadgets comprised of 16-bit buses with limited memory and storage - all to save cost and energy - would make the CPU inefficient and bottlenecked. Luckily, Dave Jaggar had just finished designing the ARM7 and wouldn't give up yet. During his commute after meeting Nintendo, he came up with a solution: the Thumb instruction set .

Thumb is a separate instruction set that operates as an alternative mode within the CPU. It is comprised of a subset of the ARM instruction set, with instructions encoded into 16-bit words (as opposed to 32-bit) . Being 16-bit, Thumb instructions require half the bus width and occupy half the memory. To achieve this, it compromises in the following ways:

• Thumb doesn't offer conditional execution, relying on branching instead.
• Its data-processing opcodes adopt a two-address format (e.g. add R1 to R3), rather than a three-address format (e.g. add R1 and R2 and store the result in R3).
• It only has access to the lower half of the register file. Thus, only eight general-purpose registers are available.

All in all, since Thumb instructions offer only a functional subset of ARM, developers may have to write more instructions to achieve the same effect. In practice, Thumb uses 70% of the space of ARM code. For 16-bit wide memory, Thumb runs faster than ARM. If required, ARM and Thumb instructions can be mixed in the same program (called interworking) so developers can choose when and where to use each mode.

The extensions

The ARM7TDMI is, at its essence, an ARMv3-compliant core with extras. The latter is referenced in its name (TDMI), meaning:

• T -> Thumb: The inclusion of the Thumb instruction set.
• D -> Debug Extensions: Provide debugging capabilities using the Joint Test Action Group (JTAG) interface.
• M -> Enhanced Multiplier: Previous ARM cores required multiple cycles to compute full 32-bit multiplications, this enhancement reduces it to just a few.
• I -> EmbeddedICE macrocell: Enables hardware breakpoints, watchpoints, and allows the system to be halted while debugging code. This facilitates the development of programs for this CPU.

Overall, this made the ARM7TDMI an attractive solution for mobile and embedded devices.

Memory locations

The inclusion of Thumb in particular had a strong influence on the final design of the Game Boy Advance. Nintendo mixed 16-bit and 32-bit buses between its different modules to reduce costs, all while providing programmers with the necessary resources to optimise their code.

Memory architecture of this system.

The Game Boy Advance's usable memory is distributed across the following locations (ordered from fastest to slowest) :

• IWRAM (Internal WRAM), 32-bit with 32 KB: Useful for storing ARM instructions.
• VRAM (Video RAM), 16-bit with 96 KB: While this block is dedicated to graphics data (further explained in the next section), it also appears in the CPU's memory map. So, programmers can store other data here if IWRAM is not enough.
• EWRAM (External WRAM), 16-bit with 256 KB: A separate chip next to CPU AGB. It's optimal for storing Thumb-only instructions and small data chunks. On the other hand, the chip can be up to six times slower to access compared with IWRAM.
• Game PAK ROM, 16-bit with variable size: This is the place where the cartridge ROM is accessed. While one of the slowest sources, it is mirrored in the memory map to offer different access speeds. Additionally, Nintendo fitted a Prefetch Buffer that interfaces the cartridge to reduce stalling and compensate for the lack of CPU cache. This component independently caches continuous addresses when the CPU is not accessing the cartridge. It can hold up to eight 16-bit words.
  • In practice, however, the CPU rarely lets the Prefetch Buffer do its job. Since, by default, the CPU continuously fetches instructions from the cartridge to maintain execution . This is why IWRAM and EWRAM are so critical.
• Game PAK RAM, 8-bit with variable size: Used to access cartridge RAM (SRAM or Flash Memory).
  • This is strictly an 8-bit bus (the CPU will see 'garbage' in the unused bits).

In conclusion, even though this console was marketed as a 32-bit system, the majority of its memory is only accessible through a 16-bit bus, meaning games mostly use the Thumb instruction set to avoid spending two cycles per instruction fetch. Only in very exceptional circumstances (e.g. when using instructions not found on Thumb or when reading from IWRAM) programmers will benefit from the ARM instruction set.

Becoming a Game Boy Color

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

From the hardware side, the console relies on an electrical switch 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 ARM7 CPU to read its state and act accordingly. Furthermore, the voltage supply, along with the joypad, cartridge, and WRAM buses are physically redirected depending on the state of the switch.

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' . This prompts the system to put the SM83 CPU in charge and bootstrap the GBC BIOS. There's one restriction, however: setting REG_DISPCNT to GBC mode only works if the system is currently booting from the GBA BIOS, as it checks the value of the program counter (the PC register).

An interesting aspect reported in the Gbdev Wiki and GBATek is that all Game Boy Advance variants are technically capable of executing Game Boy code . This includes the Game Boy Micro, which lacks the legacy cartridge slot. This is because all variants bundled the same SoC and they don't strictly need the shape detector to enter GB mode. Additionally, by fiddling with other registers, the GB's verification routines can be bypassed. However, in the absence of a GB cartridge, the GB game must somehow reside in VRAM (since the CPU will be reading zeroes until reaching VRAM) and the joypad becomes unusable (as the shape detector must be switched to redirect the bus to the SM83) .