Taipan! on the Arduino(s). Part 4.

June 27th, 2012

Well, it is 99.9% done! I finally got all the code in, all the graphics done and the game is now running in it’s entirety minus a few bleeps and bloops.  I still need to test everything (it’s about 70% tested now) and fiddle with the formatting and when to clear things off the screen as well as add in some of the missing sound effects. They were quite tricky to do as I need to play the original Apple 2 version, listen for the sounds then recreate them by hand in code on the Arduino. Not perfect but I have them close. So far I have identified five different bleepy noises. I need to make sure I have the right beeps in the right places in the game still but most of them are there now.

Memory use on the main unit: Binary sketch size: 31,030 bytes (of a 32,256 byte maximum)

On the display: Binary sketch size: 15,510 bytes (of a 32,256 byte maximum)

And for the string writer: Binary sketch size: 11,306 bytes (of a 32,256 byte maximum

So the main code just squeaked in! It needs a lot more play testing now to make sure it is correct and that it flows like the original game. There are lots of pauses and waiting for key presses I want to get as correct as I can. I left in the negative debt bug (if it was really a bug) but removed a bug in the original Apple version where the screen would corrupt if you entered too long a firm name.

In the original game when you are attacked by pirates you could issue orders quickly and you got to shoot first. My version behaves the same. If you are too slow it prompts you to enter orders but then the pirates shoot first. The browser and C version don’t behave this way and you always get to shoot first.

I did have some trouble with the ship sinking graphics. Originally I did this by drawing the bitmap one line lower each time in a loop and blanking out above and below it with black rectangles. That caused issues if your ships were at the bottom of the screen. I ended up drawing outside the screen buffer and bad things happened!

My next thought was to take a copy of the bitmap, manipulate it then redraw it in the same place. That wouldn’t work either  since I don’t have enough memory to take a copy on the display unit (most memory being taken up by the screen buffer).  So I started looking at the TVOut code to see if I could hack that. Turns out I didn’t need to. The bitmap drawing routine has some handy, totally undocumented, features. Looking in the source TVout.cpp file we find this:

/* place a bitmap at x,y where the bitmap is defined as {width,height,imagedata....}
 * Arguments:
 *    x:
 *        The x coordinate of the upper left corner.
 *    y:
 *        The y coordinate of the upper left corner.
 *    bmp:
 *        The bitmap data to print.
 *    i:
 *        The offset into the image data to start at.  This is mainly used for fonts.
 *        default    =0
 *    width:
 *        Override the bitmap width. This is mainly used for fonts.
 *        default =0 (do not override)
 *    height:
 *        Override the bitmap height. This is mainly used for fonts.
 *        default    =0 (do not override)
void TVout::bitmap(uint8_t x, uint8_t y, const unsigned char * bmp,
                   uint16_t i, uint8_t width, uint8_t lines) {


It turns out that the code has some overrides but into it. These are used when it is printing characters using the font data. By specifying an index and a new height and width you can override the data bitmap you are drawing. This isn’t documented on the TVOut wiki and it does say not to override these things but it does work. All I did was set the index to 2 to bypass the first two bytes of the bitmap data (the width and height) and specified a new width and height.

TV.bitmap( bm_x, bm_y + bm_p, Ship0, 2, width, height - bm_p );


By reducing the height you only end up drawing the top part of the bitmap. To make the ship sink I just reduce the height by X amount and draw the bitmap X pixels lower. I do this one line at a time till the ship is gone. It works very well. Once I am totally finished I will upload some films of the actual game play to show this.

The next step will be to finish off my tweaking and then make the housing for the game in the book I bought. I also picked up something interesting from the bargain in the local Warehouse. I got a keychain picture frame for only $5. I’ve been meaning to grab one for a while to see if they were usable for parts. They are usually used for carrying around tiny pictures of your car or cat or beloved I guess.

IMG_2527_1 Keychain picture frame.

It turns out, despite being pink(!), this particular unit contains a very nice little screen. It’s an LPH9135. This is a 128 by 128 LCD supporting 65536 colours. It seems to be the same one mentioned here as a shield kit for the Arduino. There is probably enough data there for me to get it working. At 128 by 128 it is actually higher resolution that what I am using at the moment (128 x 96). All I would need to do is write a new display module to talk to the new screen. The main game could remain unchanged. If that worked I could make a much smaller version of the game hardware as this screen is only 1 inch across. perhaps a Taipan! portable version. As a test I uploaded my splash screen as an image to it.

IMG_2519_1 Splash screen on keychain.

It’s bloody tiny but it would work! The keychain as it is doesn’t work too well as a picture frame to be honest. After it auto powers itself off you need to hit the (internal) reset button to get it to come back on again! So I don’t mind hacking it. Might even get more!

Anyway, here are some pictures of the TV out version of the game as it is now showing some of the screens. I really need to try it out on my 32 inch TV to see how it looks on there. The housed version will have an option to plug in a full sized video display.

IMG_2529_1 IMG_2532_1 IMG_2526_1

IMG_2522_1 IMG_2523_1 IMG_2524_1

When complete I will release my source code. More for peoples interest. I can’t imagine anyone wanting to make one of these themselves!

Comments are closed.