GBA Assembly — 9. From examples to Tower Defense

If you followed the examples, you have written colors to video memory, followed display timing, read buttons, and organized position and state in RAM. We now have the foundation for the main Game Boy Advance Tower Defense tutorial.

First, let's distinguish a build error, a hardware-access error, and a game-rule error. That makes an investigation much smaller than asking why the entire game does not work. The series index lets you return to any experiment.

Your route through this chapter

1. Open your last working mini-game and confirm movement, victory, and restart. If it fails, return to that checkpoint before adding Tower Defense rules.
2. Follow the file and build checks below first. Then use the symbol-inspection commands to connect names such as hero_x to addresses. You do not need to configure a debugger to complete the course.
3. Explain the sequence in your own words: read buttons, update RAM, choose a color and position, write pixels, repeat with display timing.
4. Use the comparison table below to find each familiar idea in the main tutorial. Start with its first teaching stage, which draws the scene, and check each stage before enabling the next one.

Checkpoint: you can rebuild the mini-game, describe why it wins, and recover after a failed build by fixing the first reported error. You can now approach Tower Defense one system at a time. The final hardware-feature table is a list of future topics, not another prerequisite.

Start from the last known working result

The six examples in the package are independent. If the mini-game fails, open the movement ROM. If movement fails, check the button example. If nothing appears, return to the first static screen.

You can also work forward: start with the smallest passing program and add one change at a time. That tells you where behavior first changed.

Check which file you are running before debugging

The four build commands produce different files. If the assembler fails and you keep opening an old .gba, the emulator may still be running the previous version.

Stop at the first failed command. Read its message and indicated line. After a successful complete build, check the path used to open the ROM. rom.py prints the final SHA-256, which helps identify whether two copies are identical.

A syntax error, undefined symbol, or ARM7TDMI-incompatible instruction occurs in your computer's tools. Changing the emulator configuration will not fix it.

Using ELF to inspect names

Consult build and inspection tools and the LDR pseudoinstruction with an equals sign to interpret the output.

The .gba is the byte sequence used as a cartridge. The .elf also preserves section and symbol information. With the tools installed in chapter 3, inspect it using:

arm-none-eabi-nm -n minijogo.elf
arm-none-eabi-objdump -h minijogo.elf
arm-none-eabi-objdump -d minijogo.elf

The first command lists names and addresses. Find hero_x, hero_y, and game_state: they should be in the RAM region starting at 0x02000000. Find boot and main_loop: they should be in ROM starting at 0x08000000.

The second command shows sections. The third disassembles instructions from bytes. The pseudoinstruction ldr r0, =constant may look different because the assembler chooses how to implement it. A textual difference does not necessarily indicate an assembly error.

In a debugger with memory inspection, the addresses from nm let you follow variables. Interface features and commands differ across mGBA distributions; the ELF and these concepts remain useful without depending on a particular menu name.

Inspect the boundary that should have changed

The reference helps distinguish addressing, flags, and conditions while investigating a failure.

If A does not change the color, inspect this chain in order:

1. Does the window receive keyboard input, and is the key mapped to GBA A?
2. Does the corresponding KEYINPUT bit change?
3. Is bit 0 set in normalized keys?
4. Does color selection use keys and mask 1?
5. Does fill_rect receive the right color and write to the expected area?

If position changes in RAM but the image stays still, input has already worked. Investigate drawing next. If the square moves but does not win, inspect the coordinates used for the target comparison.

The same reasoning applies to visual failures. A trail often means the old image was not restored. Movement turning into a strip suggests a wrong row offset. An access with the wrong width or alignment concerns communication with memory before any game rule.

Know what has been verified

All six examples were assembled with GNU Binutils and executed using the mGBA 0.10.5 core through a test interface. Checks covered the center pixel, rectangle edges, alternating colors, new and held button presses, all four movement boundaries, victory, and restart. Gameplay actions used controller input without writing directly to state to force an outcome.

That execution verifies the examples' described behavior. It is not a physical-console test and does not prove a future change respects every hardware timing limit. Validation commands and reports are in the website repository at docs/gba-assembly-series.md and docs/evidence/gba-assembly-series.json.

Now move on to Tower Defense

The main article uses these foundations for a round with a road, a hero, a building pad, and four enemies. Read it with these questions in mind:

An enemy becomes another position that changes over time. A tower tests conditions and changes enemy health. Coins are another RAM word. Complexity grows through relationships between rules; the basic operations remain recognizable.

You do not need to understand the complete ten-map campaign to follow the first small round. Start with the teaching version in the article and check one behavior at a time.

The next hardware features

The examples use Mode 3 to make the relationship between an address and a color visible. Once you understand that, other paths open up:

Each deserves another isolated example. DMA does not understand a request such as “load my map,” and OAM does not replace collision rules. They are hardware interfaces with formats and restrictions the program must follow.

Tonc organizes references for these subjects. The immediate next step, however, is to apply what we already learned: build the first Tower Defense round in assembly.

Previous: your first mini-game. Continue: the main Tower Defense article.