I wrote 2 games for the Gameboy/Gameboy Advance back in the day (Hot Wheels Stunt Track Driver and Matchbox Emergency Patrol) and it was an awesome experience. There's nothing like being able to hold the entire machine in your head and have every line of code executing being written by you.
If you're interested in development I suggest using the No Cash GB/GBA emulator; it's spot on and only had one glitch that Nintendo found in testing due to something about switching off the screen at the wrong time. I did almost all of my professional development in it and only had to burn to a Bung cartridge (used to be available from HK for cheap) for final testing infrequently. Much cheaper and probably better than the official dev kits available (but I wouldn't know, I never used one).
What led you to using No$, and not having an official dev kit? I have no idea what the relationship would have been like with Nintendo...but did they wonder how you'd written the game if they'd never issued an official dev kit?
I used no$ because it was simply the best emulator available back then (circa 1999), plus the company didn't feel a need to actually buy a dev kit since I was fully capable of building my own, and actually preferred to use, using open source tools (assembler, linker, make, etc) and no$gba.
We were publishing through Mattel for those games as a 3rd party developer, so they handled all the dealings with Nintendo and I assume they had an in house dev kit or two, or at least it was just a 2 gorrila relationship.
I have long thought that the GBA would be an excellent teaching platform for low-level programming if only Nintendo would allow it.
It has the feature that 100% of it's functionality is controlled through memory-mapped structs. You can define the whole hardware API in a single c header of struct/address pairs. To do anything, you write to those addresses and stuff happens. No magic, black-box libraries required (I guess there is the BIOS...)
It's also incredibly underpowered. You get a low number of clock cycles per frame to do everything. The lack of power, lack of cache and simple instruction set makes it an actually really good target for self-modifying code.
And, not least of all: it's literally a device built for having fun!
Hacking on the GBA gave me the motivation to learn embedded programming in C. You need to know how to handle memory-mapped registers, create C structs with proper alignment to interface with the hardware sprite/tile acceleration, direct memory access, and how to manipulate GCC to do things like override functions with BIOS functions or build freestanding binaries with custom chunks of boot assembler. This sounds intimidating as hell, but it is a fantastic motivator to learn these things to see your own little animation on actual game hardware.
Around 2006-2007, I TAed a course at Cornell (CS212 I think?) that did exactly this. Three other TAs and I basically got to fork the course. We did a bunch of R&D into tooling and taught a small group of interested and motivated students how to build a non-trivial piece of software from start to finish. I think it worked out very well.
You could easily teach a course on it. Have the students purchase a GBA flash linker and GBA and then teach the course. The students can flash their GBA games into the flash linkers, and you make the term project a completed game.
I went to a university where my direction was programming/game development. We had a course in, I can't remember for sure, C perhaps, and it included making a game for the GBA. It was some time ago but I remember it was quite interesting.
Many years ago, I spent a little bit of time trying to apply my undergrad coursework to making a game for my TI-89 calculator. There was a simple IDE somebody had made and I was able to test in an emulator and then on real hardware.
I got so far as having some sprites moving around the screen and shooting and had to put it all to rest before I got around to implementing collision detection but I learned an incredible amount from it.
The most interesting thing is that the solutions I came up with (and thought were very clever) I found out later were often the "way" things were actually done in the commercial world. Like screen buffering, how to define a sprite as data, sprite composition, the game loop, etc. I probably had to tackle and figure out a couple dozen challenges and most of them turned out to be reasonable solutions to the problem.
The hardware target being very simple also forced me to think about optimization and compute cost in ways I hadn't thought of before.
I wish it had been a formal course in Uni. Everbody had a TI calculator of some sort anyways, and a semester of building a simple game would have been tremendously educational.
The graphics modes are fun to program for too. You can start with a simple mode 4 that is a bunch of pixels, and eventually advance to "mode 7" with pseudo 3d made with tricks in hblank, and a custom vram tile allocator to support larger-than-vram scenes.
Yep! The fact that the GBA has many quality, free emulators is a big bonus. It allows people with no access to hardware to participate. At least one (no$gba ?) even has a built-in debugging interface and can be debugged with gdb!
I did my tiny experiments in homebrew dev on an emulator. A year later, I bought a flash cart, booted up my old program on a real device and it worked! :D
I'd love to see more new games on old platforms like this. I even think people would pay a small amount if someone could get with EmulationStation or something like that and setup and install the emulators along with games. I also really wish that getting rights to distribute abandonware were reasonably possible.
I have a retropie set up for my son. Even though he's been exposed to all sorts of fancy stuff you can get on an Android, as well as Don't Starve Together, and Minecraft and a few other games on the Steam platform, he still really loves playing some of the older console games; especially stuff from the Megaman and Sonic franchises. I've also recently found Zelda for snes, which I never played as a kid. If anyone has any other old games to recommend for children on the SNES, NES, GBA, Genesis, etc. please reply.
The SNES, for instance, is commonly held to be the 2D (J)RPG console par excellence. Chrono Trigger, Secret of Mana, Earthbound, Super Mario RPG and the Final Fantasy games should take 100s of hours of your time.
Still for the SNES, I recommend Yoshi's Island, one of the best 2D platformers I've ever played. And of course, don't skip classics like The Legend of Zelda: A Link to the Past and Super Metroid.
Hahah I have literally every one of those games in cartridge form (only had FFVI not FFV). One of the few treasures I have saved from my childhood. Riding my bike to Funcoland every weekend hunting a used copy of earthbound took like a year of searching, but many it was awesome when I finally got it.
Here's some games that seem to have either aged pretty well (I still go back and replay them) or provided a pretty unique experience that you don't see much of nowadays that were on SNES:
Uniracers, Metal Warriors, Yoshi's Island, Tetris Attack, Chrono Trigger, Zombies Ate My Neighbors, E.V.O. Search for Eden, Wildsnake, Donkey Kong Country 2, Ka-Blooey, King Arthur's World, King of Dragons, Lemmings, Lost Vikings, Rock n Roll Racing, Secret of Mana, NBA Jam Tournament Edition, Pocky & Rocky, SimAnt, Super Buster Bros.
I just so happen to have a list of great NES games:
Ice Hockey,
Megaman 2,
Super Mario Bros. 3,
Solstice,
Ninja Gaiden,
Blaster Master,
Ghosts n Goblins,
Teenage Mutant Ninja Turtles,
Bayou Billy,
The Battle of Olympus,
Legend of Zelda + Adventure of Link,
Battletoads,
Bump n’ Jump,
Castlevania 1/2/3 (2 is really hard and different, but good),
Chip n’ Dale: Rescue Rangers,
Clash at Demonhead,
Contra,
Crystalis,
Double Dragon 1/2/3,
Dr. Chaos,
Dr. Mario,
Dragon Warrior 1/2/3 (2 and 3 are better on the gameboy),
Ducktales 1 and 2,
Final Fantasy 1,
Galaga,
Gauntlet (all of them),
Kick Master,
Kirby’s Adventure,
Kung Fu Heroes,
Legendary Wings,
Metroid,
Mike Tyson’s Punch-Out,
Power Blade,
River City Ransom,
Silver Surfer,
Street Fighter 2010,
Shatterhand,
StarTropics,
Time Lord,
1942/1943,
Xexyz
Shining Force and Shining Force II are a couple of my absolute favorite Genesis games. There's also a very good VBA remake of Shining Force that's got some nice improvements. Also BattleToads, even with the infuriating speeder bike sequence.
So many weekend hanging out with friends in grade school playing through Shining Force.
It's an interesting thing to try out. Especially to see what memory pre-allocation and limited resources can do to your way of modern thinking. It's also a nice exercise in C. You can do it via emulator, but linkers are rather cheap for GBA. There's something insanely satisfying seeing your crap run on mystical hardware of ye old(er) days.
In 2006 I was off work for 6 weeks recovering from an injury. Just before my surgery I learned about the Atari 2600 homebrew scene - and was fascinated by the tricks you had to do to get something game-looking on the screen (I mean, the scanlines on the TV directly map to code cycles: so if you use too many instructions while the beam is in the visible section of the television, the whole game goes skewed!)
My recovery time was completely lost in following the AtariAge forums and tutorials, and I ended up with this "game": https://github.com/mrspeaker/plops - you can test it out by grabbing the .bin file and dropping in the online emulator.
Not the most polished game ever, but was such a learning experience!
Doing homebrew programming on older game consoles is lots of fun. It's quite a twist to start thinking of rendering in terms of the hardware's object APIs instead of a simple framebuffer. Even "API" is a bit of stretch: you're really just poking your data to the right spot in memory and the hardware takes care of the rest. And if you've got the right hardware, you can even run your games on the console itself!
Last year I got back into GBA dev except this time I had a degree in computer science so I knew a bit more this time. It was fascinating to play around at such a low level. Directly referencing registers and setting bytes of memory to get them on the screen. I used a old gba link cable soldered to a parralel port to send my demos to the GBA. It was a fun learning tool. I didn't make a game though. Maybe one day :)
I also gave a talk at my uni to young kids learning to program about homebrewing on the gba. Which they surprisingly found quite cool for a game console they had never even heard of :3
It would be interesting for the author to get a flashcart, load his rom on it, and add some video of it playing on physical GBA hardware. Then you can really find out if any quirks of the system would prevent it from running, or add any slowdown.
One of the easiest ways to get code running on the GBA is via the multiboot protocol over the link port. This was the primary way I ran code on the GBA circa 2003ish using a link cable spliced into a parallel port plug.
Unfortunately, parallel ports are exceedingly uncommon these days. However, it looks like this can be done easyly enough using something like a Teensy [0] or Arduino [1].
Oh, interesting! For those of you not versed in the intricacies of playground GBA link cable gaming, this protocol was used to link multiple GBAs, where one would have a cartridge and the others would not, and they would receive the game over the link cable. These single-cart multiplayer experiences were almost always very rudimentary, because as Torgo says, you're loading the entire payload in memory.
Apparently most bootleg GBA cartridges (usually Pokemon titles) ship with the "write enable" pin connected, so they can be re-flashed. I haven't done it myself though.
GBA is probably the last device made that acts like an old classic console like the NES. It hardware-accelerates tiles and sprites, which are loaded from memory-mapped locations that you set (typically) with structs made in C. You can tweak x-y orientation through bitmaps, etc and scroll the tilemap around the screen by setting the values in memory-mapped registers.
Since there's only a fixed number of sprites the hardware acceleration can reference from memory to display on screen, it was really an eye-opener to debug commercial games and see how they worked around these limitations. In Wario Land, the Wario character onscreen had tons of animations, which would seem to break this limitation. By debugging the game, I was able to find the way they did it was by setting aside just a few sprite slots for Wario, loading all his animations into a different segment of RAM, then DMA'ing the frames into his sprite slot on a timer to do the animation.
Also, even though it's an LCD screen, the hardware simulated a CRT vertical and horizontal blank. I guess this was because this is the paradigm that console game-programmers were used to, as you'd do your game logic there between animation frames.
If you're interested in development I suggest using the No Cash GB/GBA emulator; it's spot on and only had one glitch that Nintendo found in testing due to something about switching off the screen at the wrong time. I did almost all of my professional development in it and only had to burn to a Bung cartridge (used to be available from HK for cheap) for final testing infrequently. Much cheaper and probably better than the official dev kits available (but I wouldn't know, I never used one).