Starting GBA development?

03/08/2023

Recently I was made aware of the GBA Winter Game Jam for 2023. Sadly, I only found out about it in the last two days it was running. I figured it would be worthwhile to try to submit something to it, given that the theme was title screens, which is relatively small in scope. I poked at some of the libgba sample programs that came with devkitPro and started working from there. As it turns out, the GBA differs from the DS in more ways than I really realized.

The first major thing that stuck out to me was that, since there was no 3D engine, of course there's no need to allocate VRAM banks to 3D engine textures and palettes. And since there's no extended palettes either, there's also no need to allocate VRAM to extended palette slots. What I took for granted, the second screen of the DS, simply does not exist on the GBA, so of course there doesn't need to be any VRAM for that. What's left is actually no VRAM banks at all, which I first found slightly disorienting. It kind of makes sense though, there's really no need for such a thing. It really just serves to make things easier in the end, since VRAM locations are easier to know. The main downside is that, since there's not as much VRAM as on the DS, I have to actually be efficient somewhat in my resource management. So far this hasn't proven particularly difficult, since making use of 4bpp modes and good character compression seems to keep this down fairly well for normal BG sizes.

The next thing that struck me was the fact that GBA games can run straight off the cartridge. Unlike the DS, the GBA cartridge is small enough that it can be mapped wholly into memory and read directly as if it were RAM. Though this also means that, unless code is copied to RAM, it will run a bit slower.

Speaking of memory, there's only 256KB of EWRAM and 32KB of IWRAM. This definitely seems like a downgrade coming from the DS's 4MB of main memory. Though in practice, this amount is lesser since the game code has to exist alongside dynamic allocations and such. In the end, 256KB should be plenty enough for general use, and 32KB IWRAM for especially hot routines and data. To me, the IWRAM kind of looks similar to TCM on the DS.

Quite majorly, there is also only one CPU in the GBA. On one hand, this means that one CPU can interface with all of the hardware and do what it wants. On the other hand, this also means that you can't call to a slave CPU perform execute asynchronous work. This may prove difficult when it comes time to handle audio.

One thing that I took for granted and almost didn't even see didn't exist were the math coprocessors. There is no circuitry for performing square roots and divisions on the GBA, so I guess that'll have to be software implemented. Ugh.

Aside from all this, the two systems seem quite similar. The BG and OBJ system, aside from some of the DS specific features, are the same. This allowed knowledge to transfer quite smoothly, no relearning required.

My general impression overall is that the system is quite nice to work with, in some ways easier than on a SD. This is to be seen though, as I work more with it and my impressions change. I hope to do more with it in the future.

I started on a simple library for myself that I'll be using to simplify some of the development process. As of now, I've implemented a filesystem (and program to pack it), an arena, heap, fixed point routines, sine/cosine lookup table, graphics routines, and scene manager. The next program I write for GBA will be making use of this library that I'm tentatively calling SAL. I'm sure you can figure out what it stands for, lack of imagination abound.