Back in the times when cassette inlay texts and cover artwork were doing a lot of the heavy lifting for what turned out to be a game written in BASIC, the above statement was used as an additional mark of quality – this game must be good as it’s written entirely in machine code. And as we all know, it’s impossible to write a bad game in machine code.
On Christmas Eve, I released version 1.00 of my esxDOS file browser. As the previous version was 0.24 there’s been a bit of a jump in the numbering but there is a reason for this.
Originally the browser was written using the z88dk C compiler. I write C/C++ code for a living so it was a good place to start, especially as my Z80 assembly was a bit lacking back in 2020. Over time, I swapped out bits of the C code for Z80 assembly equivalents where possible but the main part of the browser – the code that accesses the FAT16 / 32 file system – was still written in C.
This wasn’t terrible but there was an overhead in switching between the compiled C code and my hand written assembly. Assembly code can use the Z80 registers as it pleases, so the C compiler has to add some code around assembly functions to ensure everything is saved and restored correctly. After v0.24 was released, I decided to bite the bullet and rewrite this core code in assembly.
This took several months – breaking the code a number of times – but ended with an assembly code version of the FAT code. With this done, it wasn’t too much additional work to remove the final bits of C that were keeping things together and driving the main input loop of the browser. The browser was now fully written in assembly. As a kind of throwback to the 100% machine code boasts of the past, I decided to bump the version to 1.00.
Looking back, peak browse was reached in v0.15 at 12,908 bytes for the main BROWSE.BIN file. v0.24, the last of the C based browsers had gotten this down to 9194 bytes (over 3kb smaller) through a combination of partial assembly refactoring and moving functionality out into separate browser plugins. v1.00 got this down to 8039 – another 1kb shaved off.
As ever, v1.00 can be downloaded from here. The official support thread over at the Spectrum Computing forum can be used to report any issues, bugs or feature requests. Thanks to all those patient people who participated in testing and reporting bugs with the interim builds.
Today marks the 41st birthday of the ZX Spectrum, so I thought I’d mark the occasion by bringing some presents to the party.
Let’s start with a party game. Or more accurately the digital download of Winter Wonder Worm. This isn’t the complete version you get if you purchase the tape from TheFutureWas8Bit – but you do now get 4 levels to worm around in. You can download it from here.
In a bizarre coincidence, the first public release (v0.01) of my long filename browser the ZXUNO and DivMMC / DivIDE devices was also released on this day three years ago. To mark this anniversary, I’ve released v0.24 today as well. This includes some new features, obligatory bug fixes, speed ups and a full rewrite of the .brwscfg configuration program in assembly. You can see me previewing a development version of it in the following video:
And what’s a birthday party without jelly? I’ve got you covered there as well, especially if you lurrrvve green jelly. I did a mod of my Kempston joystick mod of Snake Pit for Rod Hull so the eggs were changed into green jellies. This probably makes more sense if you were watching certain TV programs on BBC2 back in the 1990s. You can avoid snakes and chow down on jelly here. Here’s a video of Rod playing my green jelly mod:
If that leaves you wanting for more worm turning action, the full game can be purchased on tape from TheFutureWas8Bit. This has 6 levels, speed settings and an extra game mode
A cut down digital release will be available here in the future.
Towards the end of October last year I took a break from my long filename esxDOS browser and started work on something different – a conversion of a homebrew game on the Gameboy Color, called Willy Wonderworm. This is a variant (or twist if you’ll forgive the pun) on the traditional snake game where you control a snake, moving around a screen eating food and getting larger and larger having to avoid collisions with the walls and your own tail. This version lets you twist and turn around in angles rather than restricting you to 90 degree turns.
If I’ve not explained that clearly, I’ve recorded a short YouTube video which shows me playing my version, Winter Wonder Worm and explaining the different game modes.
As I neared completion of the game, I sent a copy to Rod Hull, proprietor of the retro hardware and software website, TheFutureWas8Bit who certainly knows his snake games. He liked it and asked if I wanted to release the game as a cassette on his 699 cassette range.
I will be adding a digital download at some point in the future – however this won’t have all the features available on the cassette release. So for that full on worm rotating experience, head over to TheFutureWas8Bit to buy Winter Wonder Worm as an actual cassette tape! I’m also hoping to publish a longer blog on how the game came into existence, the challenges I faced and how it evolved into the version you see in the video.
Recently, I was watching Rod Hull lament about the lack of joystick control in Mike Singleton’s Snake Pit. Having seen keyboard patches for other Spectrum games which fix terrible controls in classics like Jet Pac (Q, W, E, R and T for goodness sake!) I wondered how difficult it would be to adapt the game to use the Kempton joystick interface provided by the divMMC Future.
Armed with a pen, my trusty notebook and a ZX Spectrum emulator – Fuse in my case as I’m on Linux – I started my investigations. After some initial dead ends, I tracked down the keyboard reading routine. I then wrote some new code which took input from the Kempston joystick (on loan from my esxDOS browser) and converted that to the keypresses the game was expecting, so the original game code would be none the wiser as to what was going on. I then patched the original routine to call my new code and crossed my fingers.
After managing to get Fuse to emulate a Kempston interface and mapping the keyboard to be the attached joystick, it did indeed work. I then made a patched version available and after getting Rod Hull’s seal of approval in his rather lovely follow up video I then went about tidying up the patch and doing a final release. This involved me modifying the game to start using the joystick and – more importantly – adding a little cracker-esque message screen at the start.
Not all blue screens are bad.
Snake Pit with Kempston joystick support is available here.
After getting this all set up, I decided to package up a couple of other patches and fixes I had kicking around. When I got my +2 up and running a few months back, I’d tried running a +2 timed version of deMarche’s Paralactika demo to see how the cool multicolour effects looked on real hardware. The .tap file I had promptly reset after loading. On power up, esxDOS forces a 128k machine into USR 0 mode (basically the 48k BASIC prompt but with access to all the memory pages) whereas the loader was expecting standard 128k mode and was doing the memory paging in a way that didn’t work in USR 0 mode. So, I rewrote the loader to take this into consideration and the demo loaded and started up correctly. Paralactika fixed for esxDOS / USR 0 mode is available here.
Finally, I’d come across a 128k mod of Manic Miner which played AY music in game and also included an in-game cheat menu. The original file was a .z80 snapshot and it was causing the full-screen preview code in my esxDOS browser to crash. After fixing that, I had a play around with it and noticed that the music code was hanging – playing the last note over and over again – when you turned the music off or ended up on the Game Over screen. The mod code was using an interrupt based music player for the 128k music and was just enabling and disabling interrupts to start and stop the music. They weren’t calling the ‘stop’ routine to silence the AY chip in the music player which is why the music was getting stuck. After patching the code to do this, I then extracted the code and made it into a .tap file with the original Manic Miner animated loading screen as I’m not a fan of snapshot files. Manic Miner 128k with fixed music playback is available here.
So about a year ago I started a You Tube channel to try and document my projects and showcase what I’m currently working on. From a literally shaky start – lots of wonky hand held mobile phone footage – over time I’ve embraced higher video production values which makes full use of Kdenlive and the Spectrum ROM font.
Over the Christmas holidays, I ported John Elliott’s ZXZVM – a Z machine interpreter for the ZX Spectrum which lets you play Infocom text adventures and newer interactive fiction titles – to esxDOS. You can find out more in the video below.
Spurred on by the recent one year anniversary of the release of v0.01 and the YouTube videos by Rod Hull (HE IS ROD HULL!) of TheFutureWas8Bit fame showcasing my long filename browser for esxDOS with his DivMMC Future device, I thought I’d post a small update.
v0.17 with custom colour scheme based on the standard esxDOS NMI browser
At the time of writing this, version 0.17 has just been released which contains a couple of important bug fixes to the code used by the NMI version of the browser. So, if you’re on an older version or running the No_MMC_Memory version on your divIDE device, I would strongly recommend updating to this version even if you’re just using it to launch your .tap and snapshot files and not using some of the more advanced functionality.
As always, you can get the latest version of the browser here and the forum thread at spectrumcomputing.co.uk is a good place to ask for advice, request features, report bugs and get the latest test versions of the browser before official releases.
If you’re a fan of videos with poor production quality, that use the Spectrum ROM font and feature shonky camera phone or video capture footage, then you may also be interested in my fledgling YouTube channel, where you can find videos highlighting new features in upcoming versions of the browser.
I’d like to say a big thank you to all the people who have reported bugs, made suggestions, given feedback and spread the word about my browser. Seeing where the browser is now, just a year on from the first release (which only worked with .tap files on FAT16 cards) is very satisfying!
Like many people during the months of April and May, I found myself with a lot more free time on my hands after being put on furlough whilst COVID-19 caused things to grind to a halt across the world. I’d been spending some of it playing around with the ZX-UNO I purchased a while back. This is an FPGA recreation of the Sinclair Spectrum family of computers which also has support for the Russian ‘Pentagon 128’ variant – and the ability to simulate other 8 bit micros like the BBC, C64 and Amstrad.
My ZX-UNO.
It uses an SD card to provide an emulated DivIDE/DivMMC interface. These are hardware that let you access an IDE drive, Compact Flash or SD Cards on a real Spectrum. The ‘OS’ these devices use is called ESXDOS. This gives you a command driven interface for accessing files on the disk as well as providing a hardware NMI (Non Maskable Interrupt) button which launches a file browser. This works like a freezer cartridge letting you break in at any point to save a snapshot of the currently running program. It can navigate the contents of the disk as well as letting you automatically load .tap files (virtual Spectrum tape images), .sna, .z80 (memory snapshots) and .trd files (virtual Spectrum disk images normally found on Pentagon machines).
For reference, here’s the standard ESXDOS NMI browser:
The standard ESXDOS NMI browser with a guest appearance from the ROM font.
You’ll notice it doesn’t handle long file names. ESXDOS supports FAT16 and FAT32 file systems but is limited to the old DOS 8.3 style filenames. The files are also listed in the order they appear on the disk – not in alphabetical order. After using this for a while and having forgotten the joys of dealing with an 8.3 filename world, I started to wonder whether it was possible to do a nicer file browser that could somehow support long filenames.
My first attempt was to write a Python script which took a folder on the SD card and read in all the long filenames and wrote them out to a binary file with a special filename in that folder. I then wrote a basic browser program in C that looked for this file and displayed the contents on the screen to show the long filenames. It then converted the long file name on the fly back to the 8.3 form and launched that through ESXDOS. This sort of worked but had several limitations.
Any time you deleted a file, created a folder, added a new file or renamed an existing one you needed to rebuild the special data file to keep everything in sync. I also ran into an issue during development (I’m primarily running Ubuntu these days. Life’s too short for Windows 10 hassle) where I couldn’t easily determine the 8.3 filename from the original long filename. Most of the time, this wasn’t an issue as the majority of the files all mapped to unique 8.3 filenames. The order of files I was getting in my Python script when enumerating a folder wasn’t quite the same as the order on the disk. So I couldn’t be a 100% sure when you had two filenames like ‘Jet Set Willy.tap’ and ‘Jet Set Willy 2.tap’ – which would appear in 8.3 format as JETSET~1.TAP and JETSET~2.TAP – which short filename related to which long filename.
I decided to start again, this time seeing whether I could access the information directly from the FAT file system. Using the supplied ESXDOS dot command .dskprobe (a low level disk utility) I saw it was possible to access the FAT boot sector which was the first step in getting the information I required. At this point, I switched to C and wrote a test console program that loaded in a disk image I had made of the 512MB FAT16 SD card I’d been using with the ZX-UNO.
After reading a few web pages on the FAT file system, a couple of trips to the hex editor to confer with my disk image and lots of trial and error I had located the root folder and could read the directory entries in it. Long filename support on FAT is rather convoluted due to maintaining backwards compatibility with existing software (it uses pseudo invalid 8.3 filename entries to store the additional information). After getting my head round that, I now had some test code which could list the files in a given directory and show long filenames where used.
The browser code I’d written during my first attempt was then modified to use a list of data structure supplied directly from the FAT rather than from the pre-populated binary file – so that wasn’t a complete waste. I had to do a spot of disassembly on the .dskprobe program as the parameters to the ESXDOS API call to access the disk were not particularly well documented. This wasn’t the only time I had to resort to disassembling ESXDOS components during development of the browser. Fortunately, z88dk has ESXDOS support so it’s includes and code filled in a lot of the blanks.
After a couple of days of hacking around with my FAT test program, I’d knocked up a prototype .dot command called .browse using z88dk. The C FAT code from my test program cross compiled without major issues in z88dk (most of the browser was written in C, except for some assembly graphics routines).
Here’s how the initial version 0.01 of .browse looked:
Long filenames abound!
It supported long file names and also sorted the filenames – directories first, then files in A-Z order. The colours were hardcoded so folders appeared in blue and files appeared in black. Launching .tap files was supported – the other formats – .sna, .z80 and .trd weren’t. It was also limited to FAT16. There was no support for FAT32. At this stage it was a bit rough around the edges and lacked some key features but was a good enough proof of concept.
My first go at FAT32 support was added in version 0.02, alongside some fixes to the existing FAT code to handle folders that spanned multiple clusters. I also fixed an issue from the first version where on launching .browse, you were always dumped into the root folder regardless of your current directory before hand. I added some code that took the current directory and located it in the FAT.
Those extra 10 characters make all the difference.
On the Spectrum, if you use 8×8 characters in your font you can fit 32 characters on a line. There have been a number of ways to workaround this limitation. Tasword Two, a word processor that shipped with certain editions of the Spectrum 48k+ used a custom font of 4 x 8 to fit 64 characters on to the line. This works but the characters can look poorly defined due to the halved width. A good compromise is custom font of 6 x 8 which gives you 42 characters. I’d seen this used to good effect having played the Adventure International adventure games like Spiderman or Buckaroo Banzai. I decided to go with this to give the browser a bit more space to show filenames. I wrote the 42 column text routine myself in assembly which was a bit of challenge due to the memory layout of the screen on the Spectrum.
Alongside the more compact display, very long filenames were now truncated to the screen width with a custom ellipsis character. I also got .trd files to auto start from the browser after disassembling the .vdisk dot command and ESXDOS NMI browser to see how this was achieved. This was released as v0.03 and was the point when I noticed I was starting to get traction with the project. I’d started a topic on the Spectrum Computing website forum and was getting replies and feedback. From this, I discovered that my FAT code had a number of issues. On some configurations the browser just showed a blank screen and failed to start or listed the root folder correctly but showed empty sub folders or folders full of garbage characters.
v0.04 had a fix for the FAT16 problem where empty or garbage folders were being displayed rather than the actual contents. I also added the ability to load .z80 and .sna files using the ESXDOS .snapload dot command.
Green screens was my delight.
A user asked for the ability to change the colour scheme so I wrote a separate configuration editor program to adjust the colours. I also added the ability to specify the ESXDOS device identifier to use for directly accessing the disk in the browser for configurations with multiple disks or partitions. This was released in version 0.05 alongside some more FAT fixes – I wasn’t handling FAT32 clusters correctly which meant that files on larger drives with clusters greater than 65536 were returning empty folders or garbage folder listings. To my knowledge the FAT code is now working correctly (famous last words).
The hopeful finalisation of the FAT code seems like a good point to pause the story of developing the browser. There’s a lot of other things to go through – replacing the NMI, hitting the limit of .dot commands and accessing the ZX-UNO turbo modes – but that’s for another post.
The latest version of my browser can always be downloaded from here. There’s also the browser topic at the Spectrum Computing forum which contains ongoing information and discussions.
I’ve always been a fan of Nintendo’s portable game devices, from the early Game and Watch units to the various editions of the Game Boy. Dr Mario on the original Game Boy is still one of my favourite games to this day. I’d go as far as saying it’s better than Tetris – I once played it for so long that when I went to sleep and closed my eyes I could still see small pills falling downwards.
I’d already helped Nintendo along by getting a Game Boy Color and Game Boy Advance (which I picked up on a holiday in Japan), so when the chunky metallic blue Nintendo DS came on sale I got one. The launch titles weren’t too bad and showed what the touch screen brought to the party. I initially thought the dual screens and stylus were seen just gimmicks but they did bring some genuine innovation to handheld games.
A family reunion.
I’d obtained flash cartridges for the DS’s ancestors. These let you put multiple dumps of ROM images on one cartridge – so you only needed one cartridge and didn’t have to carry all your games around with you. Apart from software piracy, they unlocked the world of home brew on these devices. The Game Boy Color and Game Boy Advance had a surprising amount of home brew software- I had versions of Jet Set Willy and Jet Pac for the Game Boy Color and a full Spectrum emulator for the Game Boy Advance. Outside of doing proper development work for Nintendo and having access to the official developer kits and hardware, flashcards were the only way for home brew developers to get their code running on the Game Boy and Game Boy Advance.
Who needs a Vega Plus?
The first DS flash card I got was called the GBA Movie Player. This fitted into the DS’s GBA cartridge slot (Slot 2). It had to go here as it was too large to fit inside the native DS cartridge slot (Slot 1). The card had a full sized SD card slot which you could copy files on to. Nintendo had also implemented some security on the DS where you could only run code from Slot 1 if the correct RSA security signature was present. All legitimate DS cartridges had this signature so they could run on the device.
To get round this, a second device called a Passkey had to be fitted into Slot 1, alongside with an actual DS game. The passkey then used the signature from the real game to get the code running from the Slot 2 device. While this worked, it wasn’t an ideal solution as the DS would no longer lay flat on a surface as the Passkey and donor game hung out of Slot 1. The situation would eventually be improved by the continual shrinking of flash memory technology. SD cards were superseded by Micro SD cards. The size of these cards easily fit inside the Slot 1 cartridge form factor.
One Slot 1 flashcard went on to become the standard, the google or photoshop if you will – the R4. I bought an original one from a computer fair for £30 pounds. As befitting for a device that enables piracy, the R4 was copied and cloned and various knock off versions flooded the market. The R4 removed the need for a Slot 2 device and also did away with the need for the Passkey.
The inevitable march of technology.
The R4 flashcard made piracy a lot easier on the device. I remember the guy who sold it to me at the computer fair telling me I could fill the Micro SD card with games and his genuine surprise when I told him that you could also run home brew titles like Lemmings DS or emulators on it too. Subsequent versions of the DS hardware and some games included more checks to stop games running if they were being played from one of these devices. Unsurprisingly newer cards were produced and in game protections were removed by the groups releasing game dumps for these devices.
It is fair to say that the original DS is not a looker. The chunky casing and styling was a nod back to the original dual screen Game and Watch devices. Nintendo released the much slinkier looking DS Lite. This was basically the original Nintendo DS put on a severe diet and taking styling pointers from Apple. I held out for a while before purchasing this as I was slightly miffed at buying the first version at full price only for this much improved version to turn up not much later. There is a lesson here – never buy the first version of a Nintendo product.
Sibling rivalry.
As I now had a chunky blue paperweight in my possession, I decided to perform some light surgery on it. Some clever people had managed to crack the security on the DS firmware so you could run Slot-1 code without the security signature. You just needed to re-flash the firmware. This involved removing the battery cover and jamming a metal screw into an innocuous hole inside the casing to short a connection – what could possibly go wrong? After a nervy few minutes, I ended up with a modded DS and not a chunky bricked blue paperweight.
Home brew development on the Nintendo DS was made possible by libnds – a subset of the devkitpro home brew development kit (this also supported other devices like the GP32 and Game Boy Advance). Installing this gave you a gcc style environment to compile C / C++ into the .nds file format that ran on the Nintendo DS. As this development kit was not officially sanctioned by Nintendo, accessing the features of the device had to be done from scratch and not using any copyrighted material. In earlier versions of libnds, the routines to handle and read locations from the stylus and touchscreen were not as accurate compared to that in commercial versions. As the developers unlocked the secrets of the device, these problems went away.
The first thing I managed to get running with the libnds development kit on my DS was a hacked up port of Quirky’s Chaos Advance. This itself was a port of the seminal ZX Spectrum game Chaosfor the Game Boy Advance. This utilised the larger screen of the DS so you no longer had to scroll the screen around to see the full game board – the Spectrum screen resolution of 256 x 192 pixels (minus the border) was the same as the DS. It also added it some basic touch screen input so you could enter player names with an on screen keyboard or select spells.
I did the bulk of the work using an emulator – Dualis originally, then no$gba once it added more Nintendo DS features – as the workflow was much faster than having to compile the code, take the SD card out of the flash card, write the new .nds file from the PC to the SD card, put it back into the flashcard, turn the DS on and then select the file from the loader menu. You couldn’t completely avoid using real hardware as the emulators were still quite early on in their development so you could end up in situations where the emulator crashed running your code, whereas the DS didn’t and vice versa.
While it’s all kicking off below, the upper screen is not being used to it’s full potential.
When I did encounter crashes or bugs either in the emulator I then had the fun or trying to track the problem down without a debugger. I’d been developing on Windows with Visual C++ for some years and had been spoiled rotten by it’s lovely debugger. I had to switch back to printf-ing debug output onto one of the screens with messages to see how far the code had gotten when the crash occurred – Got here, Got here1, Got here2 and so on. I used this as a divide and conquer mechanism to narrow down the section of code that was causing the issue.
Quirky eventually updated his GBA port to run on the Nintendo DS, negating the need for my hacked up version. This was not a wasted endeavour as it gave me a good grounding in developing homebrew on the Nintendo DS with libnds. I was now on the look out for a new project.
My Aunt and Uncle did not have children so when we used to go and visit them my brother and I would have to take something with us to keep us entertained. This all came to a halt in the late 80s after my Uncle, for reasons unknown to me – as he’d never shown any interest in the subject up to that point – decided to purchase a home computer. He’d bought a Commodore C64.
Doubling down on this with a disk drive, printer and freezer cartridge, he’d also managed to obtain a large box of copied disks from someone he worked with. If this wasn’t exciting enough for us, the disk drive and printer combination added an extra frisson. If you powered the C64, disk drive and printer in the wrong order, you could end up damaging the C64. Pocket money crippling woes aside, this new acquisition posed another problem. Although we now had something to do, we were technically sleeping with the enemy.
Back in the 1980s home computer wars, you picked a side and stuck to it. I’d bought myself a ZX Spectrum 48k+ in 1984 as I wanted in on the home computer craze. The C64 wasn’t even on my radar due to the sheer cost of the machine. The Spectrum held sway at my primary school. There were a couple of people with Amstrad CPC 464s and a few Commodores. A friend of my mother who went to a different local school had bought their child a BBC Micro which we got to play on when we went round to visit.
Parents did not buy the Beeb for games. It was for far nobler pursuits like education or running a small business from. Even the big ticket games for it like Elite (fiddly space based ship simulator with you having to run a business in space) or Revs (fiddly Earth based race car simulator) seemed to revel in being difficult for small kids to play and required you to memorise at least fifteen different keys. The lack of games for the Beeb saw it off as a rival. In our eyes, any machine that didn’t have a version of Ghostbusters was a spent force. This combined with the lack of a proper joystick – from memory, a weird non centring analogue contraption – sealed the fate of the Beeb as an also-ran in the playground games scene.
The C64 was a different proposition. It did have proper joysticks. It did have Ghostbusters and it played the music from the film all the way through the game. Coming from the ZX Spectrum, the first thing to note about the C64 is how loud and musical it is. This is thanks mainly to it’s SID chip. In game music on the Spectrum was do-able but was tricky. Manic Miner and Jet Set Willy play single note beeper music throughout the game but the full on musical riot of the soundtrack provided by Rob Hubbard to Thing On A Spring was in another league.
The disk drive, at the time was a revelation too. Yes, even the notoriously slow C64 disk drive seemed nippy after spending minutes loading (or not loading) game in from tapes. Full games loading in under a minute and not having to rewind or turn tapes over for multi event titles like World Games left a mark. The graphics were more colourful – if a little chunkier and browner in places – and didn’t clash.
These occasional forays into the C64 did not cause major problems. I managed to get a 3rd party disk drive for my Spectrum +2 (my original 48k Spectrum had met a grisly end having a Kempston joystick interface knocked out of it’s expansion port with the power on which spelt insta-electra-death to the internals) and all was well with the world. But not for much longer. A storm was coming.
As the 80s ticked into the 90s, the old guard of home computers was under attack. The 16 bit machines released in the mid to late 1980s were now becoming more affordable and were becoming the machines of choice. The move up to secondary school had widened the social circles I moved in and while there will still C64s, Amstrads and Spectrums there were other, more affluent kids who had Atari STs and Commodore Amigas.
My first experience of the 16 bit world was near Christmas 1990. Not in a computer shop but in a music lesson at secondary school. As it was the last lesson before Christmas, the music teacher had brought the Atari ST that lived in the ‘music studio’ opposite (a soundproofed broom cupboard with a MIDI keyboard) into the classroom as a treat. I got to play a conversion of Metrocross.
Sir, are you sure this is a legitimate games compilation?
Like that old magazine advert from FAST, the teacher was running copied software on the school’s Atari. The following Christmas, he was taking copies of disks that a classmate had bought in, including a James Pond & Lotus Esprit Turbo Challenge compact disk. I didn’t get much time on it as once you were killed, someone else was let on to have a go. But the future seemed certain. I’d be getting an Atari ST at some point as my next computer and I’d be able to swap games easily as there seemed to be groups of people chucking out disks full of games.
This was a revelation coming from a tape based machine like the Spectrum. Although there were ‘cracked’ versions of software available for it these tended to originate from outside the UK. Most of the time you could copy a game with a twin cassette deck or using a freezer interface to snapshot the entire game to tape or disk. Even my dad managed to circumvent the colour code protection on Jet Set Willy by writing out all the colour codes as numbers on an A4 piece of paper.
So as I started to plan how many future Christmases I’d have to mortgage to get an ST, fate intervened in the shape of my Uncle. Again, for reasons that were never massively clear, he’d bought a new computer to replace his C64 – the Commodore Amiga 500. I don’t think it was brand new new as again, it came with a disk box full of hand labelled games. Labels that read ‘Xenon II’, ‘R-Type’, ‘Stunt Car Racer’ and ‘Shadow Of The Beast’.
The hand that rocked the boat.
The white screen with the hand holding a floppy disk greeted us when my brother and I switched the Amiga on – fortunately a much simpler and less costly operation than the bomb disposal-esque startup routine of the C64. But where to start? Around this time in the Spectrum’s software life cycle it was trying to keep up with these new upstarts with various ports of popular 16 bit games back on to the 8 bit platforms. I’d heard of a game called Shadow Of The Beast from a preview in Your Sinclair magazine, so I popped that in the drive and the drive sprang into life.
I later found out that Shadow Of The Beast was often used by computer shops to draw the crowds in and to show off the Amiga’s music and sound capabilities. In both aspects it performed admirably. The music and graphics as the game loaded were amazing. Then the game started and the parallax scrolling kicked in. In hindsight Shadow Of The Beast is a poor game but my brother and I were suitably impressed punching and kicking waves of smoothly animated enemies.
After this we listened to the Amiga belt out a song from Bomb The Bass in the intro to Xenon II. An actual song, with samples. We hurtled round a roller coaster race track in Stunt Car Racer and winced when we heard the damage we had inflicted on the car. We enjoyed the novelty of playing Rick Dangerous in 1940s cinema serial black and white instead of the black and green we were used to on the Spectrum.
As if this wasn’t enough to take in, there was also the hand eye coordination challenge of using a mouse. This was the first time I’d used a mouse in anger – up until then I’d only ever seen them advertised as peripherals for the Spectrum or during Micro Live on the telly. This in combination with the icons and windows of the Amiga’s Workbench meant I was finally living the blue, white, black and orange WIMP dream!
And then it all came to a grinding halt. We’d gone to visit my Aunt and Uncle on a Sunday evening and tomorrow was a school day. Falling from the dizzying heights of cutting edge 16 bit technology to be dumped back into yesterday’s 8 bit future. What a come down! As the following days turned into weeks and months, I still liked my Spectrum – I even bought a mouse for it to try and recreate that buzz – but this brief foray into the future had been a wake up call.
I didn’t really have much choice but to make do with what I had, as the Amiga was more expensive than the Atari ST I had lined up to replace the Spectrum. My brother managed to save his money and got an Amiga A600 for Christmas some years later. A year or so after that, I managed to get the funds together to buy an Amiga 500 Plus. Ironically by the time I’d managed to jump on the 16 bit bandwagon, the Amiga and ST had been superseded by the Mega Drive and Super Nintendo and the PC was starting to get it’s act together too.
As everything changed in the great switch over from 8 to 16 bit, everything stayed the same. Spectrum vs Commodore C64 was now Atari ST vs Commodore Amiga and PC owners were the new Beeb owners. But for a couple of hours my brother and I travelled in time. And it was exhilarating.
