I like programming. It’s creative, and it’s good exercise for the brain. A friend once compared it to doing a crossword except that you end up with something useful when you’ve finished instead of a bit more recycling.

Every now and again, when I’m between projects, or when I’m in the middle of a project but have finished the fun part, I like to wander the web looking for inspiration.

I believe it was on one of these trawls that I found the Team POKEME website, the hub of the Pokemon Mini homebrew scene, and I was intrigued. The Pokemon Mini is a Nintendo handheld, released some years ago with no fanfare and to widespread indifference from the games community because it was aimed at kids and branded with Pokemon. Just a bit of merchandising tat, it disappeared as quietly as it came.

These guys would have helped out surely?

Then along came the clever people with too much time on their hands, and gradually managed to bring the PM back as a homebrew device: reverse-engineering it; figuring out the CPU instructions, the BIOS; designing flash carts; writing assemblers and emulators. This had all been done and nicely organised into websites when I came along, and I liked what I found.

Once you can see past the Pokemon branding, the machine itself is really quite nice. It has a tiny 96x64 screen supporting only 2 colours, although it is possible to get one extra shade of grey by flickering pixels on and off. It has 3 fire buttons, infra-red, a rumble motor and a shock sensor. It uses a custom 8-bit CPU running at 4MHz, and takes tiny cartridges of up to 512k. It also has built-in support for tilemaps (3 configurations of 8x8 tiles) and sprites (24 16x16 sprites).

Getting to the heart of the matter.

I have long had a slow-burning plan to port the same game across a number of handheld formats, and I decided I was going to make the Pokemon Mini the first of them, even though it was the one format I did not have a flash cart for. No matter, I thought, I’ll teach myself electronics and make my own. (This is still in parts. There is a small technical problem, but mostly it’s because I don’t have sufficient faith in my soldering ability.)

So I started work on Cortex, a port of my own Sokoban-derived puzzle game written for cellphones last year (under the somewhat crappier name Sortomatic). It was my first venture into 8-bit Assembly, but there were no other options, so I plugged away and it started to make sense after a while. I was able to reuse my binary level data from the phone version, but I decided to make things difficult for myself by using a non-standard tile size.

I decided that the best compromise between being able to see the map and being able to see what you were doing was to use 12x12 tiles. The native tiles are 8x8, so these were 1.5x1.5 hardware tiles in size. I also "cleverly" used a floor pattern that did not tile in 8x8, and thus I needed a set of routines to translate the 12x12 tiles into 8x8 tiles, and all the combinations of part-tiles that might fall in each 8x8 block had to be catered for. The solution was to process the map in blocks of 2x2, which translated into 3x3 hardware tiles, with the middle one being the most complex, containing the corners of all 4 map tiles. That’s the main reason there’s only one type of floor tile in this version of the game, otherwise the number of combinations skyrockets. With the constraint that there will always be walls around the floored sections - there will never be walls in space, and there will never be floors with no wall - the number of possible 8x8 chunks of 12x12 tiles was kept manageable. The hardware buffer holds just enough of the map to scroll one tile in any direction, and then the game has to perform the conversion again to build the next buffer-load.

Tiling can be a tricky business.

There were other problems: problems with the third colour trick interfering with the scrolling; problems with keeping the sprites in line with the background; and so on. They were all solved eventually, with the usual uneven progress of a game project: get masses done in one evening, then get stuck for two days on a stupid little bug.

Cortex reached a playable state a few months ago. It isn’t finished - I’d like to add a level selection screen, some music and sound (not correctly emulated), and save the progress and records to the built-in eeprom (not completely understood) - but it works quite nicely, and I am pleased with it. I hope, someday soon, to embark on a much more complex project for the Pokemon Mini, just as soon as the last few unknowns about the hardware are cleared up, and maybe when I finally get a flash cart and can test the games on real hardware. I also hope to embark on the next version of Cortex before too long, when I cease to be fed up of it again. I’m thinking WonderSwan.

There is something much more satisfying, to me, to be fighting serious constraints than to have a blank canvas. It is far more fun to make something simple do something complex than it is to make something complex do something simple.

February 2006

Comments