RAM, RAM, glorious RAM :)

Pacman in a UDG system

The question is at root, do we have 1k RAM or 2k RAM to work with.

We have certain requirements

• Each square on the screen needs a byte to itself.
• Each square on the screen needs a nibble or byte for colour (optional background colour)
• We need some space for RAM based UDGs.

RAM based UDGs allow smooth movement. The ghosts and pacman in the picture are built up from two adjacent squares, if moving along a cell line, or 4 if moving arbitrarily (see the diagram - the A can be moved anywher by just redefining those graphics). For Pacman it actually can use ROM UDGs because the objects move only horizontally or vertically in the maze.

If you look through videos of Vic Games it is usually fairly clear which use this sprite approach, and which just write in a specific cell ; the jumps between cells are clearly visible. Some games (e.g. Gridrunner) covert his up partially by being quick.

So I've come up with the following solutions for consideration. I have no idea what the real one(s) were.

In each "solution" I assume that UDGs are split between RAM and ROM, maybe with 128 UDGs in RAM and 128 in ROM. Note that this does not mean 128 are available, just possible.

I also don't allow for coders requiring some storage, which can be acquired either by sacrificing RAM UDGs or by setting the colour to the same as the background and using the character space.

I also didn't consider partial solutions like, for example, having larger areas all the same colour, a bit like the attribute clash problem in the Spectrum.

Solution 1 (1k)

This actually doesn't pass the requirements as above. I came up with a scenario where the upper 2 bits of the character ID, combined with the border setting, create a varying palette of 4 characters, e.g. a byte is 8 bytes of character ID *and* 2 bytes of colour ID mixed. Also, it has an additional option to make the visible border area black irrespective of what the border colour is set to. The table would be at $8000

This is somewhat messy because colours are all over the place, but does sort of work. I would imagine such has a CGA look to it. 

The advantage is that in 1k it allows a 32x24 character array (768 bytes) and 32 RAM based UDGs (256 bytes). The disadvantage is the messiness and the unpredictable display of the colours. It would give you colour, but not always the colour you wanted.

Solution 2 (1k)

This passes the requirements but only by reducing the screen size to 32x20. This gives 640 bytes for the character array and 320 for the attribute (colour) array by using nibbles for colour (e.g. a monocolour background). This only leaves space for 8 UDG (64 bytes) though. 

This allows a full screen with a tiny number of UDGs. The downside is that full screen is 2/3 of the original and would look a bit small.  One could reduce it further and scale it to fit into the line space in NTSC (smaller than PAL) and have a 32x16 Grid occupying 256 scanlines. This would work but would give rather tall looking characters I suspect.

The character map would be at $8000, the attribute at  $8280 with some tweaking to the address (invert bits 7 and 8) to make the addressing work.

Solution 3 (2k)

This is by far the simplest. A 32x24 screen, 768 bytes for Character, 768 bytes for Attribute (could use Nibbles which would halve it) and 64 RAM UDGs. It

I would put the character table at $8000 and the attribute table at $8400 leaving two 256 byte windows $8300-FF $8700-FF, as this would making mapping between the two tables fairly straightforward.

Option 3 is clearly the best, and considering the small extra cost would be well worth it. It would extend the complexity of the games that could be design considerably ; the other two designs are workable but have too many compromises.