A word on Game Boy Advance home brew development:
I recently stumbled across some really cool information about developing home brew games for the GBA, so I got started right away porting a silly little game I had written for Windows some time back, and was immediately hooked. It is like the meeting of two very geeky worlds. First, there is the modern C compiler (I use GCC which builds fairly tight code for the ARM7 CPU). Then there is the old style freedom (complete with thrill and danger) that comes from writing code that will run unaided (and unhindered) by the Operating System because there just isn't one.
The toolset is pretty mature, the compiler builds clean code and optimization doesn't seem to break anything. The documentation is decent, although it does to some extent all rely on the reader having some working knowledge of low level programming. There are also a decent number of different emulators kicking around out there on which you can test your game. I personally use VisualBoy Advance most of the time, and occasionally NO$GBA which is a slightly more accurate if less user friendly emulator.
Now emulation is all fine and good, but there is no substitute for the real McCoy, and to that end I actually bought a real Game Boy Advance SP (like the normal Game Boy Advance, but with a backlight and a rechargeable battery, plus it's a little smaller). The next step was to buy a flash cartridge. I picked up a relatively affordable Flash Advance II which allows me to write my game (or any other program I feel like writing) to the Flash ROM in the cartridge and then play it on the real hardware.
It is a sort of nostalgia writing code for this machine, it's like what game-writing used to be like under DOS for instance, where you had to do everything yourself, and squeeze every CPU cycle and byte of RAM, but in exchange for that effort, you get absolute control of the system. This is one step better for the Game Boy Advance than back in the DOS days because the hardware is standardized by Nintendo so that if it runs on one, it will run on all. One of the most frequent problems writing games that squeeze the hardware is that small variations in target platform configuration can be fatal, but with a standardized platform, that's not nearly such a problem.
As far as graphics go, the display is natively 15 bit RGB (five bits per channel). You have a few possible video modes to choose from:
- Flat frame buffer 240x160 pixels, 16 bits per pixel, 15 bit color.
- Flat frame buffer 240x160 pixels, 256 color paletted mode, but with enough VRAM for a backbuffer for page flipping (double buffering)
- Straight tiled mode, in which you have 4 separately scrollable layers of 8x8 pixel tile maps (with color key transparency)
- Rotated and Scaled tiled mode, in which you have two layers of scrollable tile maps which can be rotated and scaled.
You can also have up to 128 on screen
sprites in any of the modes. The first 32 of these on screen sprites can also be rotated and scaled by the video hardware. In the tiled modes, you can set the
Z order of the sprites relative the four tile maps. There are a few other neat tricks the video hardware can do, such as dividing the
screen into up to four
regions each one having its own settings for visibility and
color blending, etc. The graphics
accelerator reminds me a lot of the one present in the old
Amiga computers.
Sound is probably the trickiest part. The hardware does very little to help you out with sound. There are four rather limited synthesizer channels, and two digital audio channels. You are responsible for mixing any digital audio and providing buffers out of which the sound can be played via two semi-dedicated DMA channels. Most people seem to have an interrupt service routine to swap audio buffers and set up a new DMA transfer every vertical blank, and then when there are free cycles go and replenish the old buffer so it can be swapped in on the next interrupt. This leads to some latency in starting sounds, so the very brave (and willing to live with the overhead) may try and mix on horizontal blank interrupts, but I've never seen it done.
Input is simple, there is a memory location you read which contains 10 bits, four for the directional pad and one for each button.
There is a prepackaged (and certainly not Nintendo sanctioned) development kit available called DevkitPro which lives on (last I checked) SourceForge and the detailed hardware documentation can be found along with the emulators by poking around gbadev.org, which also has excellent forums for asking and answering questions, along with a whole repository of sample code in both C and Assembly Language. The SDL version of VisualBoy Advance will happily talk to GDB providing you with solid source-level debugging support.
So, if you're nostalgic for the old days of down-and-dirty game programming, aren't afraid of a little system-level hacking, get cracking, it's a lot of fun!