Software Archaeology

Just over 21 years ago I took a summer job between university courses. Looking back at it now I find it surprising that I was doing contract work. These days I tend to think that I'm not really cut out for that kind of thing but, when you're young, you tend to think you can do anything. Maybe it's just a case of having enough confidence, even if that can get you into trouble sometimes.

The software itself was called Zig Zag - Ancient Greeks and was written for the Acorn RISC OS platform that, in 1996, was still widely used in schools. Acorn had dominated the education market since the introduction of the BBC Micro in the early 1980s but the perception of the PC, particularly in its Windows incarnation, as an "industry standard" continuously undermined Acorn's position with decision-makers in education. Although Acorn released the RiscPC in 1994 with better-than-ever PC compatibility, it wasn't enough to halt the decline of the platform and, despite a boost from the launch of a StrongARM CPU upgrade in 1996, the original lifespan of the platform ended in 1998.

The history of the platform isn't really very relevant, except that Acorn's relentless focus on the education market, while potentially lucrative for the company, made RISC OS software seem a bit uncool to aspiring students and graduates. Perhaps that might explain why I didn't seem to face much competition when I applied for a summer job writing an educational game.

Back to BASICs

This article isn't about the design of the software, or the process of making it, though maybe I should try and make an effort to dig through the sources a bit more. Indeed, because the game was written in a dialect of BBC BASIC called ARM BASIC which was the standard BASIC on the Archimedes series of computers, and fortunately wasn't obfuscated, it's still possible to look at it today. Today, the idea of writing a multi-component, multi-tasking educational experience in BASIC makes me slightly nervous. However, at that time in my life, I was very comfortable writing non-trivial BASIC programs and, although a project of this scope and complexity wasn't something I'd done before, it just seemed more of a challenge than anything else.

Apart from some time spent in the Logotron office at the beginning and end of the project, most of the work was done from home with floppy disks and documents being sent back and forth between Nicola Bradley, the coordinator, and myself. I would be told what should happen in each activity, implement it, send it back, and get feedback on what needed changing. Despite mostly happening remotely and offline, it all got done fairly quickly. It wasn't really any more efficient when I was in Cambridge working in the office.

Everything you need to make olive oil.

The other people involved in the project were also working remotely, so being in the office didn't mean that I would be working alongside them. I only met the artist, Howard Taylor, when Nicola and I went to discuss some work with him. I didn't meet Peter Oxley, the historian responsible for the themes and accuracy of the software, at all. In some ways, apart from the ongoing discussion with Nicola about each revision of the activities, it was Howard with whom I was working most closely. The graphics he created are very much of their time - for a screen of 640 by 256 pixels with 16 colours - but still charming today.

One of the limitations that we encountered was that the software needed to fit onto two 800K floppy disks. Given that all the artwork had been created and tested for each individual activity, and we couldn't do much about the code to implement the behaviour of the activities, that required some kind of compression. I wanted to use the Squash tool that Acorn supplied with their operating system but this apparently wasn't an option. Perhaps Acorn couldn't sublicense its distribution - it was based around the LZW algorithm which was presumably affected by patents in the UK. We ended up using a tool with a fairly vague, permissive license to compress the images and shipped the corresponding decompression code with the software. I believe that the algorithm used was Lempel-Ziv with Huffman coding, though I would have to disassemble the code to find out because it was only supplied in binary form.

As you can see above, I have a way of viewing these images today. As the author of the software, I had the original images but I wanted to view the ones that had been compressed for the release version of the software. This required the use of the RPCEmu emulator to execute a few system calls to get the original images out of the compressed data. However, once extracted, how can we view images stored in an old, proprietary file format?

Worlds Collide

Fortunately, I prepared the ground for handling images in this format a long time ago. My Spritefile Python module was created many years ago so that I could access images I wanted to keep from my teenage years. I've used it in other projects, too, so that I could view more complex files that used this format to store bitmapped images.

In keeping with my more recent activities, I wanted to see if I could create a application for Android that allows the user to browse the contents of any spritefiles that they might still have. Since I'm stubborn and have my own toolchain for writing applications on Android, this meant writing it in a Python-like language, but that worked to my advantage since the Spritefile module is written in Python. It just meant that I would have to fix it up so that it fit into the constraints imposed by the runtime environment on Android.

Blessed are the cheesemakers.

However, things are never quite that simple, though it has to be said that ensuring that the core algorithms ran on Android was a lot easier than getting the application's GUI to behave nicely, and certainly easier than getting the application to run when the user tries to open a file with the appropriate file extension. Free Software desktops are so much more advanced than Android in this regard, and even old RISC OS has better support for mapping between MIME types and file extensions!

I've put the source code for the Sprite Viewer application up in a Mercurial repository. Maybe I'll create a binary package for it at some point. Maybe someone else will find it useful, or perhaps it will bring back fond memories of 1990s educational computing.

This document is licensed under the Creative Commons Attribution-NonCommercial-NoDerivatives 4.0 International license.