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.
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.
Turns out that I’m better at writing code than writing about code. Though that’s not too surprising if I’m honest. Documentation is always a chore and my past low tech attempts at chronicling events can be found in various unfinished diaries.
So to start 2019 with slightly better intentions – and yes, I’m aware it’s already mid February – let’s begin with some details on my latest release for the venerable ZX Spectrum, Your crackers, m’lord!
Towards the end of October last year, R-Tape took his special ceremonial horn off the wall, put it to his lips and let out a clarion call for submissions to the second edition of the Woot! Christmas tape magazine . I had an idea for something to do but couldn’t get it together in time as I was struck down with a chronic bout of level designer’s block. With the December deadline rapidly approaching, I went back to the drawing board.
So what to do in a short amount of time? I still wanted to knock a simple game together. I tend to favour writing puzzle games as they can be easier to implement in a short amount of time – especially if the main mechanic isn’t too complicated. Then, it’s just a matter of going through and adding all the levels.
By chance, I stumbled across a Scratch remake of Kiragames’ ‘Unblock Me’ by griffpatch. The aim of the game is to slide the pieces of wood vertically or horizontally to let you move the red block across the screen to the hole on the right hand side. The red block can only slide horizontally and the others can only slide in the direction they are oriented. It had a small level set, was challenging and the cleanly designed graphics would work well on the Spectrum.
griffpatch’s Scratch remake
Over the first weekend in December, I fired up my trusty text editor alongside with the z88dk C compiler and started work on my conversion. By Sunday afternoon, I had this garish prototype:
Crackers on acid!
It had a frontend (recycled from Thoroughly Modern Willy), 4 levels and the code to display the board – but you couldn’t move any of the crackers around or finish a level. Over the subsequent days, common sense prevailed and I settled on a more sedate set of cracker graphics. I also added the code to select a cracker (using the Spectrum’s BRIGHT attribute as an easy way to implement the selection cursor), move the cracker around the board vertically or horizontally and to detect when the red cracker was at the gap in the board which meant the level was finished.
The finished product.
With the game code sorted I set about playing the levels on the original to obtain the level data for the 28 remaining levels. These were pretty straightforward until the last 2, which had been sourced from a harder level of play. After some head scratching, I had the full level set and the skills to play test all the levels. For each level, I took screenshots of the game’s web page on starting and finishing a level so I could check I’d entered the level data in correctly and knew where I needed the crackers to end up to complete the level.
At this point, the only reference to Christmas was the cracker graphics. When you pull a cracker at Christmas, aside from the coloured paper crown you usually end up with a gift of dubious quality – usually a tiny notepad, some impossible joined metal loop puzzle or a red plastic fish with ‘psychic’ powers – and a piece of paper with a poor quality Christmas joke printed on it. I decided to source 32 cracker jokes, one for each level to display on completing a level. Fortunately the internet had my back with various web sites compiling lists of the best worst Christmas cracker jokes.
The main constraint for using a joke was whether I could fit the question and answer parts of the joke on one line. This proved challenging with an 8 x 8 pixel font, so I used Einar Saukas’ fzx font system support in z88dk to use a variable width font which let me squeeze more characters on to the line.
Just one of the 32 pieces of comedy gold strewn between the levels.
The name ‘Your crackers, m’lord’ comes from a sketch by the Two Ronnies (a popular UK comedy double act from the 1970s and 80s whose Christmas show was a big telly event back then). The sketch is in a similar vane to the classic ‘Fork handles / Four candles’ where the property of certain English phrases sounding identical to each other but meaning vastly different things is used to comic effect. In this case, the butler whilst serving courses of a meal to an aristocratic couple is saying nice things to his Lordship’s wife “Your sweet m’lady.” but is insulting to his Lordship “Your nuts m’lord.” “Your crackers m’lord”.
This sketch also gave me the bare bones of a story to hang the game off. The reason you’re having to go to all this trouble moving these other crackers around is to satisfy your aristocratic employer’s demand for a red cracker with his festive food stuffs. I’m sure this was one of the sub plots of a Christmas edition of Downton Abbey one year.
For a rush job I was happy with the overall result. I’d like to thank griffpatch for his original Scratch game which provided the inspiration and source material for my conversion and R-Tape for compiling another Woot! tape magazine.
Knockabout has been available in varying forms for about 3 months now. I’d received next to no feedback on the game after initially making it available on the ZX Spectrum Next forum back in August. Recently, a new forum opened at Spectrum Computing which I joined. It had a section for letting people know what projects you are currently working on. I posted a topic about Knockabout and within a couple of days got a much better response and some proper feedback.
One of the surprising things with the previous releases was the lack of reported bugs (one of the first versions had a typo in the level data which made it impossible to get past level 4). In software there are usually two reasons for this: 1 – the code is perfect and bug free or 2 – no one is using the code. I’m realistic enough to see the latter as the reason for the lack of bug reports. Maybe it will be the former one day. 🙂
Turns out there were some cosmetic glitches and some right howlers. From a rotating switch not being drawn correctly in a certain situation, player tiles being left behind after moving which would block your progress and the undo mechanism which – apart from working intermittently – would randomly corrupt memory.
I made a number of intermediate builds available on the forum to get to the bottom of the reported issues. After a hiatus of a month or so (I was working on contributions for the upcoming WOOT! ZXMAS 2017 tape magazine but, more on that to come…) I’ve picked up the code again and made a proper new build available.
Level 89 – “We’re gonna need a bigger block array…”
The following changes have been made in build 107:
Added levels 83-90.
Fixed switch graphics glitch when rotating a 2×2 switch anti-clockwise.
Logic fixes to undo system.
Undoing a move was corrupting memory.
Try and stop issue where a ‘stuck tile’ gets left behind on the level after moving.
My guess at the the number of levels – 136 – has been confirmed. I managed to find a newer version of the Nintendo DS game ‘PuzzleBoy’ – 1.10. rather than 1.04. This had a read me file which states the game has 136 levels and more usefully, the source of the additional levels. PuzzleBoy is a not a direct clone of Kwirk. While it uses the levels, they are interspersed with other levels that I assumed had been written by the author of the DS version. It turns out though that they are from Amazing Tater (a sequel to Kwirk on the Gameboy) and PuzzleBoy, a version of Kwirk for the PC Engine.
Hitting the wall(s) on Level 71 on the DS.
Level 71 on the Spectrum.
This proved rather helpful in getting me past level 71 which I had been stuck on for a while, as I found and downloaded walkthroughs for Amazing Tater and Puzzleboy. I then managed to track down which game the level was from and then used the solution to complete the level. I couldn’t figure out a way to auto convert the levels from the DS so I’ve been adding them in one at a time as I’ve been progressing through the game – which is why they’ve been added in spits and spurts.
The following changes have been made in build 106:
Added levels 71 to 82.
Swapped the Restart and Map options around in the break menu.
Made the code entry screen look similar to the level info screen.
Added support for blocks greater than 1 x 1 starting over a hole.
Needed for level 74. I think this is an enhancement from Amazing Tater as Kwirk doesn’t appear to have blocks or switches starting over holes.
Fixed a bug creating a block when you had two n x n blocks on the same y axis. Spotted on level 71.
The initial switch position on level 12 was incorrect.
