The GP32 is always going to hold a special place in my collection for being the machine that introduced me to homebrew in the first place.

I got mine just as the machine was opened up properly to be able to do it, and a flurry of devs jumped on it to produce all sorts of things. It was great as there was always something new appearing every other day, and it certainly wasnt any slouch of a machine at the time either! But it was the fact that this was an actual hand held console that you could get a compiler and SDK for, and could make your own stuff on it that attracted me to it, and got me into this whole thing to begin with. So, my beloved GP32, this is for you!

I was asked recently to help port something over to the humble GP32, and nostalgia being the rose-tinted maiden that it is, I thought “oh it’ll just be a quick recompile after I dust off my toolchain again!”  This wasn’t quite the case, especially as said toolchain hadn’t been touched since 2004 and didn’t quite work any more.
So, I thought I’d go use the excellent devkitARM which supports a few of the Nintendo hand held consoles as well. However, this also hit problems as most of the libraries I could find weren’t EABI version as devkitARM was, and as I didn’t have a great deal of free time to go poking at it too much, I sadly had to drop it and try another route. I’ll probably come back to doing it “properly” with devkitARM as I much prefer their setup, but for now, method two will do.

Method two involved building my own arm-elf tool chain, using the rather succinct instructions over on cobbleware http://www.cobbleware.com/gp32/gp32toolchain.html which got me up and running pretty quickly. I did substitute GCC 3.3.6 for 3.3.2, however, and had to pull down 3.4 on my Debian box in order to compile it. I did get it compiling both on my 64bit desktop, and a 32bit laptop without issue, though, so it’s certainly still feasible these days to build tool chains for older platforms as needed. I did attempt to substitute higher versions of binutils, GCC and newlib, but they died during compilation and again, lack of time to do it properly meant I just wanted something that worked. Once I had the compiler though, my problems weren’t over yet.

It seems that everyone built their own tool chain setup back on the GP32 and all manner of libraries and strange things floated about. In general though, people either wrote their own low level SDK, used the excellent Mr Mirko’s SDK, or the wonderful Chui’s SDL port. The devkitARM tool chain comes with Mr Mirko’s SDK so if I only needed that, I’d have kept with it. I needed SDL support, however! and I had two options open to me; cobbleware’s version and SDL4GP32 - http://sdl-gp32.sourceforge.net/ . As said, everyone seemed to do their own SDK setup, and both of these sets of libraries overload a bit more than they probably should. The cobbleware version overloads stdio which caused some interesting errors in stderr and stdout not really being available, and though I got these fixed and the project compiling, I couldn’t get it to work no matter how much I prodded it. The SDL4GP32 version required a bit more poking, but it did manage to work, and with a few hours remembering that the GP32 uses SMC card, which has an 8.3 filename restriction, I managed to get the project up and running with minimal changes at between 20-30fps out of 60. Not bad for a few hours work, I think!

Of course, the GP32 being the old and odd beastie that it is, most games are just not written for it these days. It’s not a huge fan of large textures, and passing textures back and forth across the memory bus probably isn’t going to help it much so to get that framerate up further there’d probably need to be a bit more re-organisation of the sprites and assets than I was really wanting to do. Not out of laziness, but more out of not fiddling with someone else’s project! I just wanted to show them how to get it up and running on the GP32 as quick as possible, and let them sort out the issues in a way that works for them.

Anyway, this means that the first part of The GP32 Quest has been done - the tool chain. You can find a quickly written guide over on the left.

Now, if only I was brave enough to attempt a screen replacement on my little ‘ol Non-Lit GP32!

I’ve been having a rake through my hard drives recently to clean them up a bit.

It’s quite scary the amount of junk I have just sitting about, as well as how many duplicates of the same things that are not just on separate hard drives, but are usually on the same hard drive in different folders named “backup” and “stuff” and so on… though when I used to backup my code to CD, I’d just label them “Backup 25” and so on - making that just as useless!

Anyway, I’ve found some useful little code snippets that I’ll be sticking up here under the Tutorials & Guides category.

Some of them are a bit cleaner and more usable than others, whereas some need a bit of explanation as to what on earth is going on.

One of them is really clean and is in effect a fully working example in it’s own right, so I’ve already put this up - A Simple C State Machine. It’s pretty obvious what it’s doing, but sometimes you just need a bit of a poke in the right direction to remember how things should be laid out, etc… so I’m posting it up as a reminder to myself, and to anyone else that may find it useful! You can find it here: Simple C State Machine Gist

Right, back to sifting through this mess…

Yesterday morning, I got my Gameduino in the post. Not bad considering it was shipped on the 31st May from over in California.

I won’t be able to have a good look into it for a few days to a week yet, but I did boot it up and have a fiddle with the pre-loaded Asteroids game, which led me to the conclusion that this thing’s going to be fun to play with! Looks pretty much like a nice little 8bit console type thing, and looking forward to doing a nice little game for it.

So, I’m adding it onto The Quest.

Speaking of which, I haven’t had much time to fiddle with Core 24 on the Pandora. Nor fiddle with my engine in general.

Work stuff has been progressing nicely, I’d say, but it’s been eating up a lot of time, as it’s rather critical to get things right first time - or at least before anyone actually starts using it properly. So lots of extra work and thinking to ensure it all gels together properly.

I’m also currently collecting development environments for my hardware at the moment, anyway.. the older and newer machines are relatively easy to get compilers for, but it’s some of the ones in the middle - Dreamcast and Saturn in particular - which are a bit painful to find. I have messed with KalistOS before for the Dreamcast, so I’ll probably use that again - assuming I can find it. I also haven’t seen the Playstation compiler I used for quite a while either, and I imagine that’s going to be a right pain to find as well. At any rate, part of the reason for The Quest is to accumulate all these development bits and bobs in one place ( assuming they are pure homebrew and not leaked naughtiness of course! no badness here! ) so that I can remember where they are, if nothing else.

I’ve also still got some unfilled pages hanging around here that I’ve still to fix!

Oh well.. they’ll all get done at some point…