As I've done a beta release of a pure text game, I thought I'd put the engine code away for a bit and try and do the graphics. I'd already written BASIC to draw these (shown in a mock-up a few entries ago), but I needed to get it down in assembler so I could assess the ultimate size of code.

I'm starting with the Mysterious Adventures graphics as I decoded these around 12 years ago and they're the simplest to implement. As they're also based around line draws and fills, they can also scale to different resolutions. These graphics were used for three platforms (that I've seen):

• ZX Spectrum (the reference platform)

• C64

• Oric (only two colours are used for graphics)

As the graphics were originally made for the Spectrum we have to look at the differences with screen implementation. The Spectrum has a resolution of 256x192 pixels with a choice of 15 colours (8 primary colours and a brightness flag; bright black is the same as dull black!). But, my saving grace is the Spectrum assigns colours only in 8x8 blocks (which is why attribute clash was so bad on many Spectrum games), for this reason only four colours are actually used in the graphics - so that this clash can be minimised.

This means I can reproduce the graphics pretty much perfectly; in fact slightly better (as there's no attribute clash) in mode 1. I'll have to use an interrupt to redefine the palette between the graphics and the text so as to leave the text in a consistent colour. This still leaves a problem of palette: as the Spectrum can display 15 colours simultaneously, it doesn't need a VDU 19 equivalent and I only know 2 colours (foreground and background) at the start. For the other 2 colours I have to wait until I see a fill and then define my colours appropriately, this may mean that the screen can start drawing in one colour, then mysteriously change to the final colour.

In terms of pixel sizes, mode 1 (320x256) makes a nice looking rendering of the graphics with enough space so that I can perform screen reduction, to only use a 16K mode 1 (256x256). Rendering in mode 5 (160x256) is possible, though it looks chunky and some of the fills don't quite work and an interrupt or alternative font will be needed to place the text in mode 4. Of course, to maximise memory I could shrink to an 8K mode 5/4 (96x256), which would still look okay, but give me an extra 8 pages (2K) of memory.

The final option is to use the graphic data from the Oric (only two colours) and use mode 4 (or mode 0).

The final problem is the size of the graphics data, for The Golden Baton, they are around 13K, which could just about be squeezed in on mode 5/4; but has no chance on even a 16K mode 1. One solution to this is to read them in a page at a time from disc. There is very limited scope for compressing these.

The image on the right shows the possibilities and other version in order. First we have my rendered BBC screens in Mode 0, 1 and 5. These have just been programmatically redrawn. Then we have the Spectrum image, which shows up the attribute clash, followed by the C64 version with its better colours and for some reason it emulates the attribute clash! Finally we have the two colour Oric version.

The size of the graphics, plus my impatience to get a full release out means that I've made a decision about platforms; so, I will be releasing 2 versions.

The first will be designed for a Master (or anything with &E00 DFS and Shadow memory, so potentially a B+ or an expanded Electron). This will make use of PAGE at &E00 and shadow memory to produce a full mode 1 screen and hold all the graphics data in memory. The end result will probably be like the mock-up I did earlier. This could be quite quick to release as I can abuse the expanded plot codes on the Master to do fills for me.

The second will be designed for a &1900 DFS Beeb, so will be neutered in some way, this may mean its in mode 5/4 with graphics read from disc. The most difficult part of this will be writing a BBC Micro safe flood fill algorithm.

There's still scope to do a language ROM, which will free up enough memory on the Beeb to do a mode 1 screen, but this isn't a priority; I just need to make sure I define my work areas as separate from the code areas.