I sometimes get asked whether requiring a PC in a vintage computing project such as OqtaDrive isn’t pushing it too far. Even the use of a RaspberryPi Zero as in the standalone setup, occasionally gets frowned upon. Here’s an attempt at explaining the motives behind my approach:

The Pi is rather arbitrary. The core of OqtaDrive is the Arduino running the adapter firmware. This is acting as a protocol converter. It communicates with a daemon process that’s doing the heavy lifting. Where that daemon process runs is up to the user. When I started OqtaDrive, I really just thought about my PC as the target, since I rarely use my Spectrum and QL without it nearby, so it’s there anyway. It seems that these days the all-in-one solution with the RaspberryPi Zero is quite popular, but it’s just one of many possible configurations. And by the way, the Pi Zero does not represent the minimum system requirements for OqtaDrive. Have a look at the Linino setup, which is much more constrained than a RaspberryPi Zero 1, but still can run OqtaDrive.

So a few words about the design criteria behind OqtaDrive. While small may be better, I did not want to put too much focus on optimizing for space. Most important for me is flexibility, hence the split into adapter and daemon. It gives the user many setups to play with. Another point is developer efficiency and fast iteration cycles. I wanted to limit the C code base to the adapter firmware. This part matured early on and hasn’t seen many changes since then. Most of the new features can be done on the daemon side and I rarely need to touch the firmware.

The daemon is implemented in Go. It’s been my main language for the past few years and I use it for my day job as well. It’s an awesome language and I find it so easy to write what I need. The core libraries are great too, and networking and concurrency is all built into the language. Another advantage is that you can easily cross-compile. I currently release the daemon binary for Linux, MacOS, and Windows for several architectures, all from the same code base without any variants. Fun fact: Ken Thompson and Rob Pike of C & UNIX fame played a major part in designing Go. So not a bad choice for a vintage computing project.

Now I know, this approach precludes running everything on something as small and lean as an ESP32 micro-controller. And having a fully-fledged OS inside a stand-alone OqtaDrive, that might just as well emulate the complete Spectrum or QL, may be an unbearable thought for the purist. I grok that. But from my point of view, the speed at which I can develop new features, and –even more important– the kind of features this setup enables in the first place, by far make up for that. And I do want features such as searching in large local and remote cartridge collections, loading from the web and tying in remote content, a REST API for integrations, and a modern web UI you can use with pretty much any device.

Now it may be possible to do all this with just a micro-controller, but I dare claim that you’d have to compromise on extent and performance of these features, as well as pay a price in the form of greatly increased development effort and complexity. And my time budget for working on a project such as this one is limited. But above all, I love to augment the hardware I used when I started to learn programming with technology I have available today, decades later. Look at it this way: making a modern device that’s magnitudes more powerful serve a vintage machine is a bow of reverence, acknowledging the role that machine has played in computing history. Remember the past, live in the present. I guess we all set the dials differently here, and who’d want to be the judge of that.

Happy hacking!