Me and the creator of Apache Canyon – a new game for the venerable Acorn Electron – have a few things in common. Not only are we Brits of a similar vintage, we’ve got the same surname and paternal grandparents.
Playable in beta form currently and with a boxed RetroSoftware version on the way, my cousin Rob’s first release for the BBC Micro’s baby brother, is a hectic vertical shoot-em-up in which you fly an AH-64 up a scrolling gorge, downing alien invaders and destroying force-field towers as you go.
The final major feature, a boss UFO, was added to the WIP build this weekend, but you’ll need to be good to glimpse it.
My highest score thus far is an ‘above average’ (according to the game’s borrowed ranking system) 29375. In order to break the 30K barrier, I’m going to need to dodge incoming fire and collect power-ups more deftly, and treat force-fields with more respect. Getting too close to the latter, is a sure way to squander shield bars.
As Rob explains in the eye-opening Q&A below, because the Electron isn’t exactly well-endowed in the chips department, programming fast, furious games like Apache Canyon is far from straightforward.
Tim: What are the particular challenges of coding for the Acorn Electron?
Rob: The challenges of writing for any 8bit old hardware is lack of memory and lack of processor cycles. The Electron only has 32k of memory to start, the screen mode I use takes up 10k of that and then because I want a 50fps experience I need a second screen (for double buffering) which leaves only 12k for all the game code, graphics and sound!
I wrote the game entirely in assembly language, which for the Electron means 6502 assembly. My day job involves writing in a high level language (mostly JavaScript) so switching back to 6502 low level code was a fun challenge. The 6502 CPU runs at 1MHz in the Electron, so for a 50fps game I get precisely 20000 processor cycles to do everything the game needs. This sounds like a lot but each processor instruction takes on average 3 cycles, so that’s around 7000 instructions I can run every 50th of a second. With that I have to draw all the sprites, draw the scrolling canyon, read the keyboard and run all the game logic – running out of cycles is very easy and is why you only see 5 enemies on screen at a time.
To be able to use all of the available memory and processor cycles I’ve had to take over the whole machine, this means I’ve thrown out the operating system so have to do everything it would normally handle such as reading keys, playing sounds and writing text.
All of the above are challenges, but also why writing the game has been such an interesting experience.
Tim: Which aspect of Apache Canyon caused the most headaches?
Rob: The sprite drawing routines – I have multiple routines (to optimise for speed at the price of using more memory – another challenge!). Moving a block of pixels around the screen 1 or 2 pixels at a time is quite expensive in terms of processor cycles as you have to:
1. Remove each sprite before redrawing it – this is complicated by double buffering as each sprite can appear at 2 slightly different screen locations so you have to remember both and make sure you are removing the right one!
2. Pick the correctly pre-shifted (horizontal) sprite, I store multiple copies of each sprite each one shifted right by 2 pixels. For an 8 pixel wide sprite this means 4 copies (and an actual sprite width of 16 pixels) so that I don’t have to do the horizontal shifting in software which is very expensive in terms of CPU cycles.
3. Pick the correct frame of animation, the enemy sprites have 4 animation states, the player sprite has 5 – these take up a lot of memory but as I’m using a monochrome screen mode I had to make up for a lack of colours by having nice animations.
4. Draw the sprite at the correct location on screen making sure that if it’s in the same location as something else (e.g. the canyon “background”) that the sprite is “merged” nicely with the existing screen content. Handling vertical pixel locations involves some calculations as I can’t pre-shift for vertical (I’m already doing this for horizontal and don’t have the memory for both) but vertical shifting is slightly cheaper in terms of CPU cycles.
Getting all of above to work probably took the most time and involved a lot of learning and trial & error.
Tim: Which Acorn Electron game do you have the fondest memories of, and which, in your opinion, exhibits the cleverest coding?
Rob: Fondest memories are AcornSoft Elite which was a technical masterpiece at the time, getting a whole 3D universe working on such limited hardware was a huge achievement. If anyone is interested in looking at the code involved then I can thoroughly recommend Mark Moxon’s amazing site.
Tim: Thank you for your time