On Lockdown Retro Computing and Aerosol Data Inversion

As a child of the 70s/80s, I was born into the "golden era of home computing" — which in the UK of the early 80s meant the likes of the Sinclair ZX Spectrum, Commodore 64 and BBC Micro. Way before actually getting my hands on some real hardware, I used to go the library and take books out from the Usborne Computer Books, my favourite being "Practical Things to do with a Microcomputer", of which I still have a well thumbed copy today:

My first home computer was the then new Commodore 16, onto which I duly entered some of the programs I had written out on paper. Literally the first program I ever entered was this:

Now the reason I even have that screenshot is that I have managed to keep all my home computers from the 80s, so when they shut the pubs and other leisure activities during this last year of COVID, it was time to dust them off. The Commodore had been dead for years, but after changing the 5 V voltage regulator and the (notoriously flaky) TED graphics chip, it fired up. It lasted about a week, before developing another fault that thus far I have been unable to track down.

The C16 was always a frustrating computer to me, not least because it had no [what would be described in the parlance of the modern Raspberry Pi as] General Purpose Input / Output (GPIO) port — so could not be interfaced to my own electronics projects. So by the time I got to 12, my parents managed to get me a second-hand BBC B Microcomputer (even by then, rather out-of-date). The BBC Micro, for those unfamiliar, was the result of a competition set up by the British Broadcasting Corporation to develop a new microcomputer which could be used as part of its computer literacy TV programming. The competition was won by the fledgling Cambridge based Acorn Computers. The BBC Micro was soon adopted across UK schools as the computer of choice, so I was very familiar with it by the time I got to actually own one. Like me, it inspired a whole generation, and was the inspiration behind my contemporary Eben Upton's development of the Raspberry Pi in order to inspire the next generation.

The BBC Micro was a very advanced machine for its time, not least because of the huge array of I/O ports it had for expansion. I got my "GPIO" port (the User Port) as well as an analogue to digital converter. Amongst many other ports, it had this mysterious one named "The Tube®", which it turned out allowed the BBC Micro to support a 2nd processor, which seemed like science fiction to me at the time. Not only that, but the second processor didn't even have to be the same type as the first (a MOS Technology 6502) — you could for example attach a Zilog Z80 coprocessor and run the CP/M operating system for "business" use. Anyway, this was all way beyond my pocket as a teenager.

Back to 2020. After the C16, I dust off the BBC B. It fires up first time, though after about 10 seconds it crackles and emits a puff of horrid smelling smoke characteristic of fried electrolytic capacitors. In testament to its "over-engineering" it keeps running though, and it's several months before I get around to replacing the "dried out" capacitors in the power supply. My first mission was to transfer all my floppy disks onto a neat little SD Card adapter you can now buy, lest the magnetic media fail. Amazingly, all the floppies were readable. Now what? The lure of Ebay and those exotic co-processors beckoned.

The obvious place to start was a 6502 co-processor (above, in the "cheesewedge box to the right of the BBC B). Got one — great things run a bit faster and there is more memory to use. Next I obtained a Z80, which was far more interesting as it allowed different software to be run. But I wanted more — which led me to search for the rather more elusive National Semiconductor 32016 co-processor. This was a (wow) 32 bit processor (contrasting with the 8 bits of most home computer processors at the time, including the 6502). It was sometimes marketed by Acorn as the Cambridge Co-processor and also formed the basis of Acorn's "Cambridge Workstation" computers, and was aimed at "serious" users, such as mathematicians and modellers. It was actually criticism of the limitations of the 32016 by Acorn's legendary Sophie Wilson which led Acorn down the path of developing their own 32-bit processor, the ARM architecture, and the rest is history as they say. Before you ask, yes Acorn did make a limited run of ARM co-processors for the BBC Micro, but I have never seen one come up for sale and suspect it would be very much out of my price range!

Anyway, eventually I found a 32016. The software suite comes with the rather esoteric Panos operating system (rumoured to be so-named after Acorn staff had night out at a Cambridge Greek restaurant) and large array of "serious" programming language such as C, Fortran 77, Lisp and Pascal. Whilst Panos can be run from floppies, is is much more convenient to run on a hard drive. Given the rarity and unreliability of the original "Winchester" hard drives for the BBC, in practice this means using a Compact Flash adapter kit which are readily available online. For some reason, I couldn't get the CF based HDD to work with my old BBC B, so I turned to a BBC Master which I had rescued from a skip whilst I was a student. Again, this needed a bit of attention electronics wise, but I soon had it up and working. Great, got into Panos, so now what?

This was a serious co-processor, so needed something serious to crunch. What piece of numerical computing was I most familiar with? Well, the obvious choice to me was the Cambustion DMS500 "data inversion" algorithm. The DMS500 is our fast particle sizer — basically it tells you the size of nanoparticles (e.g. soot) in the air in real-time. To do that, electrically charged particles are deflected onto a series of collection rings which then register a current:

The inversion algorithm takes the currents from those detectors and turns them into a spectrum of concentration versus size in nanometres, using the instrument's transfer function:

It's a nice piece of numerical computing because it involves matrix algebra and manipulation, so is ideally suited to Fortran, though the code doing the real-world job on the DMS is in C++. Now I'm just old enough to have been formally taught Fortran 90 as part of my physics degree, and had dabbled a bit in Fortran 77, so I had a go at getting it to work. There were a few hurdles along the way, not least a limitation on the width of file "records" which meant I had to "unroll" the instrument transfer function and data files first to get them read in. I also had to get enough of the BLAS and LAPACK libraries to compile on the 32016, which was a challenge in itself. However, I eventually got it to work with some data sampled from a gasoline engine:

It does take around 3 minutes to process each data line — as the data is taken at 10 Hz this would clearly not be practical, as the instrument needs to do this in real-time (I won't repeat my polemic on the difference between response time and data rate, but you can read it here). It even turns out that my 32016 is the faster 10 MHz variant (for which I fitted some much needed heat sinks!) It would certainly have little chance of running the DMS's Bayesian lognormal data fitting algorithm, which when I wrote it in 2005 was a struggle to get to run in real-time on the PCs of the day.

Now, of course you can get emulators for the BBC Micro, and someone has even emulated the 32016 on a Raspberry Pi — as a half-way house you can get a Pi-based co-processor for your BBC hardware with selectable architecture, including the elusive ARM evaluation system. However, I rather like the original hardware, which give or take the flash based HDD and the modern monitor, I've managed to use (see picture at top). Great hardware and software which was after all developed on Cherry Hinton Road in Cambridge, just like Cambustion's today.

Have a great 2021; let's hope, in the nicest possible way, that we all have a little less time for our indoor hobbies.