Goldfinch: an open software stack for mass storage on the Spectrum

Yep, another pet project of mine to compete with all the others I’ve started. But hey, if I didn’t get distracted by things like this I’d just get distracted by Youtube and sudoku instead…

Goldfinch1 is an attempt at remedying the “walled garden” syndrome in the world of ZX Spectrum mass storage – there are plenty of software projects doing exciting things with IDE and CompactFlash and ethernet on the Speccy, on top of multiple competing hardware interfaces, and for one reason or another they end up having ‘baggage’ that prevents the casual tinkerer from properly harnessing that existing work for their own stuff – so writing a program that reads ‘some file’ off ‘some disk’ is a bigger deal than it ought to be. The reasons for this might be technical (the disk access code is too tightly coupled to a Basic extension, or an emulation layer, or something else, and only one person in the world understands the whole package), legal (licencing problems prevent the source code from being released), or the entire project being locked away in perpetual vapourware hell (ahem).

So. The initial goal of the project is to create a set of libraries for C and Z80, in z88dk library format (because z88dk is the one project on the scene that solves the issue of code re-use), for accessing mass storage systems in a natural, device-independent way, at whatever level of abstraction is appropriate. It’s in a ridiculously early stage right now, but this is the sort of thing we’re talking about:

#include <stdio.h>
#include "include/divide.h"
#include "include/block_device.h"
int main() {
  unsigned char buffer[512];
  unsigned int x,y;
  BLOCK_DEVICE *device;
  /* Open the block device for the DivIDE master drive */
  device = divide_open_drive(DIVIDE_DRIVE_MASTER);
  /* Read block number 0 from it */
  read_block(device, (void *)buffer, 0L);
  for (y = 0; y < 256; y += 16) {
    for (x = 0; x < 16; x++) {
      printf("%02x ", buffer[y|x]);
  return 0;

Here we’re opening the attached DivIDE disk as a block_device, and reading and dumping the first sector from it. But beyond the first line, the same bit of code could equally work on a ZXCF-attached disk, or a .TRD image on a FAT16 filesystem, or an .MGT image that’s just been streamed over Spectranet… as all of those things will implement the block_device API. And likewise, there’ll be a standard API for accessing files, so that C programmers can do the familiar fopen() stuff without worrying about the underlying filesystem.

As for what this means for the end user – hopefully, by supporting all of these technologies (DivIDE, ZXCF, TRD, FAT…) through common standard mechanisms, we’ll get away from the situation where Fatware is “the DivIDE firmware that reads TAP files off FAT with a pretty menu” and ResiDOS is “the DivIDE+ / ZXCF / (your interface here) firmware with Basic extensions to read and write to FAT”, and into a bright new future where all of those capabilities will operate together, rather than having every lone genius reinventing their own bits of the wheel.

…And with a bit of luck, we’ll generally lower the barrier towards doing Interesting Things with mass storage on the Speccy, and end up with all sorts of applications that not even I’ve thought of yet. (I have my own ideas about how to take this further with dynamically loaded modules and things which kind of segue into a whole new operating system for the Spectrum, but let’s not get ahead of ourselves here.)

1 Not a particularly meaningful name, just that there was one in my garden on the day I happened to name the project.

7 Responses to “Goldfinch: an open software stack for mass storage on the Spectrum”

  1. yerzmyey says:

    …and for idiots – what does it do?

  2. yerzmyey says:

    …all systems in one? argh, this text is long as a Bible. ;)

  3. matt says:

    Basically – it helps people who want to write programs for DivIDE/ZXCF/whatever to share code. So, if someone wanted to make a program for playing WAV files off disk, with a file chooser just like FATware, they could do that without reinventing all of Baze’s work. And if someone else wanted to run the same program on their ZXCF interface, they could make a ZXCF version of the program with hardly any extra work.

  4. YERZMYEY says:

    Very enlightened idea, then.

  5. I had a glance at Goldfinch and it seems to me the lower level of abstraction is still missing, to make a program compile for ZXMMC I had to overlap the DivIDE code with something simulating the original calls.
    BTW it is a brillant idea, perhaps we should join efforts and add some sharpness directly to the discussion already in place.
    We are probably interested more in the FAT stuff, why won’t you join to the z88dk forum ?
    Code is always welcome !

  6. matt says:

    Hi Stefano,

    I probably won’t be doing much more work on the lower level code, as ESXDOS has really got there first – any future work I do here will probably be application-level code built on top of ESXDOS, but the API there is close enough to UNIX standard I/O that it’ll be reasonably portable to other disk systems (as well as anything else that needs filesystem-related applications, like the SIF and Spectranet…)

  7. hi
    ay chance of setting some mass storage standards?
    any chance of developing a single word processor
    maybe 128k one that allows us to read good ol 32 column text files
    64kb text files?
    spell checker – with as much space as the dictionary needs for expansion
    could it work on all mass storage systems please?
    cant eh dictionary be used as the basis of itu t v44+IPR=921600bps v92 modem hardware compression even though the pc wont let you use a hi speed serial port at this speed or modem at the speed it is designed to function at
    other european languages?
    programming manuals for basic
    code examples
    z80 assembler with programming examples of standard routines

Leave a Reply