GBA Programming with DevKit Advanceby Howard Wen
People interested in making their own games for the Nintendo Gameboy Advance will find the unofficial Gameboy Advance (GBA) software development kit (SDK) indispensable. Based on the GNU Compiler Collection (GCC), DevKit Advance runs on Windows, Linux, and Mac OS X; it comes compiled with the Socrates Gameboy Advance Development Environment (SGADE), a library of generic code for the GBA platform released under an open source license. The rest of the DevKit Advance code is released under the GNU General Public License.
Throw in a good GBA emulator (Boycott Advance is recommended) and, the DevKit Advance developers claim, you'll have the essential tools to make original games for the Nintendo gaming handheld that can rival the quality of commercial titles.
For Jason Wilkins, the creator of DevKit Advance, the project was partly borne out of a desire to create a version of GCC for the GBA better than Nintendo's. "In many cases, I felt that Nintendo's version of GCC fell short. For instance, Nintendo's link script did not map read/write variables to RAM. If you did not know this, then your program would silently fail because your variables were stored in ROM. I'm sure Nintendo has fixed this by now, but it is a demonstration that I often start new projects because I feel I can do something better," says the 26-year-old programmer from Jonesboro, Arkansas, USA.
He also wanted to make getting GCC up and running on the GBA easier, which requires a bit of knowledge and work to conform it to the GBA's technical requirements. Wilkins runs down the extensive list: "You need to know how to build GCC as a cross-compiler. You need to write and understand link scripts, which tell the compiler how to lay out the binary, which in this case will become a ROM image. You need to be able to write in two different assembly languages in order to create the startup code. You need to understand how to create relocatable code, so you can copy code from the ROM to the main memories for faster execution. You also need to be able to compile GCC so that it will create 4 different versions of the standard libraries; this is related to the fact that there are two different assembly languages."
Shane Celis, a 23-year-old software engineer in San Jose, California, USA, became involved in Wilkins' work when he was looking into porting a favorite game to the GBA. But first he needed a programming environment. GCC was available only for Windows and Linux at the time, but he was a Mac OS X developer. So he decided to gather together the best tools available for GBA development on the PC and make them available on Mac OS X.
"I rolled up my sleeves and had a go at making it work on OS X. I hadn't planned on releasing it, but, owing to the fact that OS X isn't a moving target like Linux where distributing binaries is a chore, I figured I'd save someone else the effort by distributing my results," says Celis.
GCC "Encapsulated" for the GBA
DevKit Advance is primarily developed in C and C++, but Wilkins says he has had to occasionally write some ARM (32-bit) and THUMB (16-bit) assembly language.
The vast majority of the code is the Free Software Foundation's GCC and binutils. Wilkins' work has mainly been in creating patches to build the compiler in such a way such that it will create GBA ROM images as easily as possible. This includes some bug fixes and lots of modifications of the makefiles. "Basically, I am trying to encapsulate the knowledge of how to build GCC for the GBA. So, in reality, the vast majority of the code was not written by me," Wilkins clarifies. "It is just that correctly building GCC in any configuration is such a chore that it is a whole project in and of itself."
Thus, DevKit Advance probably would not have been possible without building off of the GNU Compiler Collection and other Free Software tools. "DevKit Advance is really the GNU tool-chain with a few patches to make it work on the GBA in particular," Celis says.
The first release of DevKit Advance provided a limited compiler, but it was still difficult to program an actual game. Celis sought out a library to incorporate. While there were numerous libraries of varying scopes and licenses, one important criteria was that the license must make the source available. "I found the SGADE library and included it in the distribution because it was comprehensive, had a liberal license, and the best documentation I could find," says Celis. "Good documentation is worth its weight in gold."
The biggest technical challenge that Wilkins faced was building DevKit Advance's cross-compiler, which he describes as "a brain-bending exercise". A cross-compiler runs on one platform but produces binaries for another platform. "The real brain bender came from trying to compile the compiler, using Cygwin, to run on Linux and compile programs for the GBA. This is possible, but I failed to get it to work. It would be easier just to install Linux," concluded Wilkins.
He also found it interesting to work with a platform which has two different assembly languages and can switch them on the fly depending on the need. To get the most out of the GBA, Wilkins concluded that his cross-compiler needed to be configured to take full advantage of this. The details on how to do this were not documented anywhere, from what he could find, but with enough trial-and-error effort he managed to enable this feature.
Games to Inspire
For future versions of DevKit Advance, Wilkins wants to expand the list of features of the GBA and GCC that the user can access and use. This includes adding a basic library and documentation for accessing all the registers, BIOS function calls, and DMA. He also hopes to make it easier for a programmer to control exactly where everything goes in the GBA memory.
As a demonstration and testbed of the capabilities of DevKit Advance, Wilkins wants to add an original, fully playable game to the whole package. "I am currently designing a GBA game, and plan on making the code as reusable as possible," he says. "Such higher-level code does not belong in the core dev-kit, but I want to make it available anyway."
Yet a game made with this open source SDK is maybe what is exactly needed to inspire home-brew GBA game development.
"I wish I had something like DevKit Advance when I was a kid," says Celis. "Video games are what ultimately propelled me to become a programmer, but the prospect of actually creating one for a console system wasn't always infeasible until now."
Jason Wilkins and Shane Celis recently agreed to an interview with Howard Wen. Here's what they had to say.
O'Reilly Network: Could a home-brewed game that looks as polished as a commercially produced game be made with DevKit Advance?
Shane Celis: Certainly, but I think part of the reason behind that is games are actually a special case, because, unlike other software, there is a lot more freedom in the UI design of games. Your game shouldn't look like every other game, as is the case with desktop software. Because there isn't that conformity in games, it's much easier for independent developers to produce games that would easily be mistaken for commercial games.
Jason Wilkins: If the GBA was a 3D monster machine, I would say no because creating good-looking games for machines like the Xbox requires that you have lots of money and time. There is no way around it. However, the GBA is simple, easy to program, and 2D content does not require the same level of commitment to get good-looking results.
I was once helping out someone with a simple game project on IRC. I knew he was young because he was having a lot of problems with the trigonometry he needed to make things work, but I was floored to find out that this person was only 13-years-old. If a seventh grader can put together something basic, then someone in their dorm room should be able to produce something that looks and plays as good as anything else out there.
The limited nature and simplicity of the GBA is a great leveler. It only does so much, and what it can do is attainable by any above-average programmer, artist, musician, or game designer. You do not have to be a god to take full advantage of the system. The result is that what I can do and what Nintendo can do are a lot closer in quality than, for example, the difference there would be if we were talking about the GameCube. I would never dream of creating Metroid Prime, a GameCube game, but the version for the GBA, Metroid Fusion, is definitely within reach.
ORN: Can you hazard a guess as to how DevKit Advance compares to the official Gameboy Advance SDK?
SC: I would guess that the official SDK has better support for debugging. Other than that I couldn't say.
JW: When I first started, I would have said they were roughly equivalent, except that Nintendo's kit comes with a lot of examples but was a little trickier to set up and use. Along with the issue I mentioned above about read/write variables, I also do not think it could compile C into 32-bit code (ARM). I have not seen a recent version of their dev-kit, so I do not know if they have fixed these issues or not.
ORN: What are the unique challenges in figuring out the inner workings of the GBA in order to aid in game development for it?
JW: Not being able to read the official GameBoy Advance SDK documentation, without being an official developer, is the main hurdle. However, there are a lot of people who have written alternatives to this documentation, so I have not had to hack out any details of the GBA by myself.
SC: Finding good documentation was hard. I would find little pieces here and there, but trying to get a comprehensive view was very difficult when I started out. That's one reason why I was so impressed with the SGADE library. Not only was the code comprehensive, but they also published tutorials that gave a good foundation to start with.
All programmers employ discovery programming, that is, the programming you do when you're exploring a new API or new environment to reassure yourself that it'll behave according to the docs or your assumptions. Doing GBA programming, especially if you don't have a library like SGADE, can be very cumbersome at first, because you can't just add a printf and see what value was returned.
ORN: What sorts of contributions could your project use from outsiders willing to volunteer their skills?
JW: I could use all the help I can get. I need people who can track updates and bug fixes to GCC and incorporate them, as well as people who can write documentation. I have just started a [DevKit Advance] SourceForge.net project to gather everyone together who wishes to contribute.
SC: There's a tool provided with SGADE called SoConverter that hasn't been ported to OS X. It converts images from many different formats into something usable by your game. I haven't had any need for it. I guess, that's the downside of the 'itch-scratching phenomena' of open code developers: it just doesn't 'scratch my itch yet'. So anyone who has a need for it, or is looking to volunteer their skills, could start with that.
ORN: For you as a programmer, what have been some of the lessons you've personally learned as you worked on DevKit Advance?
JW: Do not let a project get more popular than you are willing to put the effort into. I am glad that so many people find the dev-kit to be useful, but I wish I was not so busy. Then I could update it more often and the dev-kit would be a lot better.
SC: Don't underestimate what you can contribute to a project, no matter how small you may perceive it to be. For instance, as far as contributions to this project go, mine is the smallest by far. I didn't write the patches for GCC nor did I write the SGADE library. I simply took those pieces that were readily available and made them work on OS X. Technically, it's not a very compelling feat. But for all the people who might not be able to accomplish that, it means the difference between being able to write their own GBA games and possibly not having that option.
Return to the Linux DevCenter.