The development environment for doing ZX81 games is the same as for the Spectrum, just that you need a ZX81 emulator to see the results on. You can still use whatever text-editor/project solution you are used to, and the same assembler – it’s just Z80 again after all. For the emulator I’d recommend using either EightyOne – which is very accurate – or No$ZX81 – which is much faster to boot, but not quite as exact. I personally use No$ZX81 for day-to-day development & testing, given it’s quick turnaround, and EightyOne for final testing.
I’ve been ask by a few people to write about my experiences with programming the ZX81, and with the grounding of using Z80 on the ZX Spectrum now largely covered it would seem the right time to step back a little in time to the Speccy’s predecessor…
With the Zeddy being based upon the ’81 most of the concepts are actually very similar, if not identical, between the two machines. Obviously, out of the box, it lacks sounds and colour (so that’s two less things to worry about straight off) but the main differences are really only how the display works, it’s relative lack of memory, and that it’s slower than it’s big brother. But if, like me, you stick to using the low-res ‘chunky pixel’ graphics that it’s known for then you actually need much less memory to store graphics, and because the screen takes less memory you can fill it faster, so it’s very much swings and roundabouts.
Finally! The mythical keyboard post!! Sorry it’s taken so long, but SokoBAArn was taking it’s time (along with a large & overgrown garden back in the real world). Anyway, we’re here now, woohoo!!
Back in the depths of time I did a short piece on how to detect if a key is pressed, which used the following code:
WAITFORKEY: ld a, 0 in a, (254) cpl and %00011111 jp z, WAITFORKEY
That’s actually the basis for all keyboard reading, and as complicated as it gets, just that we were doing a particular and simple case – testing for any key being pressed.
Now that SokoBAArn has been released, I’ll have a bit more time to devote to this blog, starting with that mythical keyboard handling post!
In case you haven’t seen SokoBAArn yet, take a look here…
Oops! I did actually have a piece written to post about reading the Kempston joystick, as a precursor to reading the keyboard, but just noticed that some months ago I did post exactly that. Promise I’ll wake up shortly and do that keyboard piece 🙂
Back in June Peter Jones (Hi Peter, hope you’re still reading?) asked after a machine-code version of the BASIC SCREEN$ command, to help him convert a BASIC program. At the time I briefly replied that it wasn’t the best way to do things in m/c, and now I’ll explain why, and what a better alternative is.
We now have the knowledge to draw sprites anywhere we want on the screen, and could try and draw as many of them as we like, but there’s a problem…
If we try to draw two of our ‘smiley faces’ next to each other, then one will overwrite the other, as below:
So which is best – storing your graphics already shifted into position, or shifting them in code? The answer is simple – which you choose is entirely up to you and the kind of game you are writing, there is no ‘best method’ for all cases.
So pre-shifted graphics are great to use in certain circumstances – objects which are constantly moving horizontally whilst animating, for example (think Manic Miner) – and are fast, but they also have their drawbacks – not the best use of memory for one. We could fix the memory issue by not having all those individual graphics, and just shift one copy into the required position when we need to. Continue reading
This post is about using pre-shifted graphics to produce the effect of smooth horizontal movement, as explained previously. This is the most straightforward of the two methods to produce smooth movement, but has it’s limitations – which I’ll come to at the end.