The current plan is that Kobold has a bitmapped, multicolor display. It has 640 visible pixels per line, with 256 colors per pixel.
But we want more.
Suppose we want to program a game, where the hero (let's call him Mario) has to move in front of a background picture. Making the hero move involves a lot of software actions:
- to remove him from the current position, redraw the background at the hero position
- the hero is represented by a rectangular bitmap where several positions have 'transparent' color. The transparent positions must be filled with correct background pixels of the new position
- the result of step 2 must be copied to the screen memory at the new position.
The early video games had a nice solution to this. At the positions that the hero could reach, the background was mostly black. This makes it really easy to remove the hero (just overwrite with zeros) and to place it at a new position. To make this realistic, the games were in a dark setting (in a cave or in outer space). Examples are:
- Nodes of Yesod
- Prince of Persia (Apple II 6502 source code available on the www)
For Kobold, we want to move Mario in front of a real background, without too many software actions.
This can be done with Sprites (Wikipedia), objects that can be shown on screen, appearing in front of the background. They can be moved without a lot of software work.
The spirit of the Kobold project does not allow to use a TMS9918 or other special video control chip. Simple TTL chips should be used. But real sprites will need a lot of TTL, also against the Kobold philosophy.
A solution (or call it compromise) has been found. There will be two modes (The mode can be set differently for each scan line):
- Hires mode, 640 pixels per line. Each memory word in video memory has two consecutive 8-bit (256 color) pixels.
- Dual layer mode, 320 pixels per line. Each memory word in video memory has two 8-bit pixels, one for the background layer and one for the foreground layer.
In dual layer mode, there will be a special bit or bit combination in the foreground pixel byte meaning 'transparent'. If a foreground pixel is transparent, the corresponding background pixel will be shown. If it is not transparent, the foreground pixel will be shown.
Although moving the foreground objects still involves software, moving Mario is simply painting a rectangle at old foreground position with 'transparent', and copying the hero's bitmap to the new foreground position.
Perhaps only a single extra TTL chip is needed for this dual layer mode. But I also have to increase the number of available control signals... I found space in the microinstructions to control 8 more output bits, now having 24 of them, and updated the description of the microinstructions.
Writing pixels to video memory will be quite fast because it will be supported by special microcode.