Programming the oldest working computer in the world
Our team recently organised an outing to The National Museum of Computing at Bletchley Park. On the same site but separate from the Bletchley Park Trust, The National Museum of Computing (TNMoc) has restored and displays a fascinating collection of early and more recent computers, including a rebuilt Colossus, the world’s first electronic computer.
During this visit, it was my immense privilege to have the opportunity to write and run a program on the Harwell Dekatron/WITCH, the oldest working computer in the world. It was originally built at Harwell around 1950 to automate mathematical calculations that had previously been done by hand, and was later moved to Wolverhampton as an educational tool, where it became known as as the Wolverhampton Instrument for the Teaching of Computation from Harwell (hence, “WITCH”).
Although different in some respects, I was surprised how similar it was to a modern computer. Store locations (memory addresses) can either hold a data word—8 decimal digits, stored in base-10—or an Order (instruction). So, a Von Neumann architecture just like nearly all the modern computers that we’re familar with.
The Accumulator, paper tape readers, tape printers and the Drain (equivalent to /dev/null) are memory-mapped to the first 10 memory addresses, which is more similar to modern CPUs than than some of the architectures that followed it.
There are no “carry” or “zero” flags automatically calculated, but there is a YES state, which can be explicitly calculated by testing data either for positive or negative value. Curiously there’s no test for zero, but this makes sense given the real-number (as opposed to integer) workload that the machine was designed to process.
There are of course some aspects of the design that are less familiar nowadays:
The 90 words of memory (Stores) are implemented with “Dekatrons” (hence the name of the machine). These are vacuum tube devices with multiple electrodes, between which a discharge (clearly visible, see photos) can reside, and can move monitonically between positions respresenting the values 0..9. It’s lovely that you can actually see the state of memory just by looking at the dekatrons; this isn’t merely a representation of the state, it is the state.
The gotcha that required me to do some debugging and modification to my original program was that writes to memory—for example to store instructions or variables—actually add (arithmetically) to the previous value, so it’s necessary to clear any previous value before writing a new one. This is done by using a “move” instruction, moving the previous value to the Drain, to clear it.
What struck me is that the hard part of programming for the Dekatron is similar to one of the challenges that we still face when programming a modern computer, albeit at a different scale; how to organise and structure a non-trivial program so that it’s both efficient and maintainable. You have only 90 words of memory, but can read from multiple paper tape readers and write to printers, and potentially read back from tape what you’ve printed earlier. You can seek forwards on each tape – there’s a specific tape code for a Block Marker. Instructions can be executed either from memory or tape, but they’re actually faster if executed from tape. I can only begin to imagine how you’d construct a non-trivial program, and I’m full of respect for the programmers who managed to use it—and even greater respect (or sympathy) for any programmer who’d have to maintain a program that someone else had written!
Many thanks to the engaged and interesting staff and volunteers of TNMoC who hosted and gave us a fascinating day out.
Footnote: what did my program do? It just counted down from 100 to 0 & stopped; about 20 instructions, written out on paper and converted to machine code by hand, and entered on the front panel. It terminated with a FINISH instruction – this was a novelty to me, but of course with no operating system you need your computer to stop at the end of the program.
6th January 2016