Re: [stella] Boulderdash - musings and screen demos

Subject: Re: [stella] Boulderdash - musings and screen demos
From: Christopher Tumber <christophertumber@xxxxxxxxxx>
Date: Wed, 02 Apr 2003 23:41:29 -0500
Andrew wrote:

>The only real issue, then, is one of how to store the data for the playfield
>in what little RAM is available.  If there were just a little more RAM, then
>this would be a fairly straightforward project, I think.  Perhaps we should
>just bite the bullet and specify/use a 3F bankswitching RAM format.  The
>ICC(TM) system proposed above would basically need 24 bytes for the drawing,
>leaving just 100 for the actual playing area - not enough.

This is similar enough to the issues II've been dealing wih in my rewrite of Big Dig that I thought I'd chime in.

In it's simplest form, your playfield data can be expressed in two bytes, assuming the player's position is not involved (ie The player's X,Y gets it's own variable)

00 - Blank
01 - Dirt
10 - Boulder
11 - Diamond

The display screen is 10x6 which could be stored 1 byte per space for 60 bytes. Or you can pack it in at 2 bits per square giving you 15 bytes. Assuming you want a larger, virtual screen that's 2x2 display screens, that'd be 60 bytes. 2x3 or 3x2 is 90 bytes which is possible though it's going to be really cramped.

Packing the data in like this adds an extra level of complexity to you game calcs but it's not all that horrific. You're just dealing with bit shifting and/or masking in order to 
pack and unpack data. Being able unpack the data "only the fly" in order to draw the screen could be a real problem though. 

So how about this:

Use a big 60 byte buffer for the screen that's being displayed. This data is in an intermediate state,  with a 1:1 byte to game square correlation but not the actual offset data that the display kernal will use to draw the screen. Rather the display kernal will use this data to unpack into a small buffer (see below) on the fly as you a row by row basis.

This unpack buffer is 15 bytes - Actually 12 bytes (6 pointers per line) with 3 bytes unused. The reason for 15 bytes will be explained shortly.

There are three 15 byte buffers, these contain packed data for the 3 quadrants of the game screen which are not being displayed. That is, if the upper-left hand quadrant of the virtual screen is on display, then it's data is in the 60 byte buffer above and the data from the upper-right, lower-left and lower-right quadrants are in their own 15 byte buffers.

Unfortunately the screen can't be scrolled on a line by line or row by row basis, it has to be flipped from one quadrant to another. When the page is flipped, the 60 byte buffer is temporaily packed into the 15 byte temporary (unpack) buffer. Then the new visible quadrant is unpacked into the 60 byte buffer. The old visible quadrant is then moved from the temporary buffer into a regular 15 byte buffer.

Memory is a little tight. The 60 byte and three 15 byte buffers are permanent and require 105 bytes. The 15 byte temporary/unpack buffer can be used, but only outside the display kernal and when the display page is not being changed (ie: it can hold some temporary, loop type variables, your stack if you're carefull but not much else...). That only leaves 8 bytes RAM for permanent storage (score, level player X,Y). Kinda tight but hey....


Archives (includes files) at
Unsub & more at

Current Thread