The biggest update: pulling everything together to produce a complete Master version, with graphics and text, all in a fancy mode 1 screen. The graphics aren't 100% perfect though: as I cannot be guaranteed that I would have black and white to play with, for the sake of ease I decided that colours 0 and 3 would always be black and white respectively. This means that the colours of the rest of the screen don't change randomly.

Adding it together was relatively simple:

• A JSR drawscr to draw the picture

• Adding a redrawg file for only when you moved location

As I can use shadow RAM and PAGE at &E00 I actually had enough space to store the graphics in RAM on the Master. With the graphics coming up to (on average) 12K, this will not work with the BBC B. I'm planning to page a page of graphics information as it renders the images - I still have 4 unallocated pages under &E00.

I did perform some minor compression on the graphics data - most of this is limited by the design, so there isn't much scope. To start with, a simple description of the graphics data: there are a set of instructions to be performed on a screen of 255x191 pixels, with colours matching the ZX Spectrum palette. The instructions can either be:

• Start C (indicated by &ff)

• Draw Y X

• Move Y X (indicated by &c0)

• Fill C Y X (indicated by &c1)

After the instruction byte is usually the Y co-ordinate; as this has a limited, anything higher than it is a command. The data is in one block starting from the image for room 1 up until the image for room numrooms.

The first thing I did was to add a table of 16-bit start and end pointers. The Spectrum and Commodore version scan the whole graphics data from the start for each image, this seems particularly wasteful, so I'm going to use this bit of memory to make the search slightly less wasteful!

As the information is contiguous, why am I using end pointers, as the start pointer for the next image should be the end pointer? This is simply that usually at least one image is duplicated in the graphics data; this way I can save myself around 300 bytes/duplicate image. I could potentially lessen this overhead by 1 byte/image by having two tables:

• One table to point to the image data

• One table to map rooms to images

But this would probably increase the code size to greater than the size of memory saved!

There are some other savings I can do to try and reduce size, I haven't implemented these yet, but they should save me about 5-6 bytes/image and will offset the size of the look-up table:

• Remove the &ff byte - as I know this byte will always be at the start of the image

• Change FILL from &c1 colour to &c1 + colour; e.g. colour 1 will be &c2.