I thought I might share a few thoughts while developing my Z80 Game Engine for the VZ200/VZ300 computers (aka VTech Laser 200 / Salora Fellow / Seltron 200 / etc). These computers have a Zilog Z80 CPU and a Motorola 6847 graphics chip.
I recently started using the Z88DK devkit which allows you to code Z80 applications using C and you can also use Z80 Assembly either inline or as addon files.
The VZ200 (as I’ll refer to this set of computers from now on) is a special-case computer. The graphics modes it uses via the 6847 graphics chip are unique and do not seem to be used at all on any other computer platform. Each single byte of data in screen memory represents FOUR PIXELS. Thus, it makes things difficult if you want to move a game ‘sprite’ around the screen one pixel left or right. There’s a lot of Rotating bits in bytes, ORing and ANDing to try to move one pixel in the X axis and if you want to NOT destroy any ‘background’ image data and all of these are very time and cpu-expensive instructions in Assembly. I have not been able to find any other platform — even ones using the same graphics chip — which draws to screen memory in this way.
Hence a lot of games for the VZ200 either move a game ‘sprite’ 4 pixels left/right at a time, or use a method Dubois used in some of his games whereby a game ‘sprite’ would be defined with 6 pixels in the left of the X-axis and the next animation would be the right-side 6 of 8 pixels. The sprite has not moved but it gives the illusion of movement.
You can have a maximum of 4 colours and the highest supported resolution is 128 pixels across by 64 pixels down. The 6847 graphics chip has other higher-resolution modes, in particular a monochrome hires mode which would have been very useful — if limited — but was disabled on the VZ200 due to the amount of RAM it would have used. (At least, this is what we guess).
I type ‘sprite’ in quotes because there is no such concept on this platform, but it makes it easier to think of as a sprite as opposed to ‘pixels-drawn-character’ or something like that. Unfortunately, there is also no concept of transparency. So you cannot draw non-destructive sprites.
As you can tell, this makes for some glitchy games. There’s not much you can do about this. There’s no layers to speak of and no actual sprites — hardware or otherwise. Games like Ladder Challenge above have to keep redrawing the background and then the foreground sprites on top. This is also CPU-intensive.
Another issue is all games draw directly to screen memory. This creates a hashing or glitch in the output as image data changes while the raster is scanning down the screen.
The VZEm emulator created by Guy Thomason does not normally exhibit this glitching, but he has added it in for full compatibility as an optional switch. It’s not quite so noticeable on an actual CRT screen — particularly when they were only about 10-14 inches in size.
So, one of my ideas for my Game Engine is to write a small Z80 routine to save the background image data before you draw your game sprite over the top and erase bits of it, then provide a way to quickly redraw the background data back again when the sprite moves.
Now: collisions. There are no hardware registers to detect or change due to sprite collisions. There’s no sprites, therefore no sprite collisions. Most games, I expect, use a simple AABB bounding box collision based on the sprites’ X,Y location and Width and Height. I have programmed this into my Game Engine as a simple C function.
I am guessing the simplest and most-likely used method for game sprites was:
Draw background, draw sprite, delete sprite, draw background, draw sprite, repeat. You will see all games have flickering sprites due to no layers nor hardware sprites. This is the way.
Sound. The VZ200 has a tiny piezo speaker inside and the only way to get sound out of it is to toggle bits 5 and 0 of a memory location. That is, when bit 5 is ON, bit 0 must be OFF and vice versa. Games only have a plip-plop type sound effect. The Spectrum has a similar way of making 1 bit audio sound and on both platforms the Z80 CPU has to do all the work to make sound happen. Hence, only wanting short blippy sound effects in games or it will take precious CPU time away from the rest of the game.
So the Z80 CPU has to not only calculate game information, it also has to manipulate data in the screen memory and toggle a memory location to make sound. What Dubois managed to come up with is quite amazing.
I’ve spent many, many hours recently trying to get one of the Spectrum 1-bit audio music engines to work on the VZ200 (as has a friend of mine called Dave whom first started doing so) but unfortunately none of the 1-bit audio engines with Trackers will work on a real VZ200 computer. Dave has managed to get a few working but those are extracted from Spectrum games and you only have one set of game data and can only write new music by hand by typing in values without being able to hear them.
I only know of two current trackers for this: Beepola and 1Tracker. Utz is working on Bintracker but it has not had the first version released yet and will primarily be for the Spectrum, though he is programming in plugin-support so it may be possible to write something which will help it work on a VZ200.