School Computing, 1960s Style

As a teenager I was fascinated by computers. This was the mid-1960s, when a typical computer had a whole building to itself, replete with whirring magnetic tapes. The personal computer was still two decades away. My local library had a huge selection of books on the subject, as it did on even the most arcane topic. Why, remains a mystery. So I had read all the then-famous books by Daniel D McCracken on each of the programming languages of the time - Fortran, Cobol, IBM 360 Assembler, and Algol 60.

But my learning was strictly theoretical. Only huge companies and a few well-endowed universities owned them, and access for a working class lad was out of the question. Like the Poles, who at that time did magnificent work on the theory of computing simply because the real thing wasn't available to them, all my computing was done in my head.

My dreams were given unexpected reality thanks to a certain Bill Broderick, at the Royal Liberty School a few miles away in Gidea Park. He was the first person in the country to see that schools needed computers. Somehow he raised the money to buy one of the first minicomputers, an Elliott 903, which was installed there and available to all the schools in the area. The term "minicomputer" is strictly relative. This one was the size of a large chest freezer and with its anciliary equipment still took up a good sized room - but not a whole building.

I was about 14 when one of my teachers asked me if I was interested in using it. Normally that was a privilege reserved for sixth-formers (16 upwards). Of course I said yes.

Timesharing had yet to be invented, so each school had a scheduled session of a couple of hours with hands-on access to the machine. Ours was at 4pm on Fridays. Half a dozen of us would go down there, usually in our maths teachers' cars, to run and debug our little programs.

The only input/output for the machine was paper tape. No printer, no terminals, not even flashing lights. Programs were laboriously written out longhand on special sheets, one box per character, then prepared offline by unseen typists. In theory we would take along our programs, run them, get the result on paper tape, print it, and there we were, successful programmers. In practice it never worked like this. When mistakes were found, there was no editor. Programs were corrected using the venerable ASR33 teletype, copying the tape and stopping it where needed to make changes. The ability to sight-read paper tape was essential.

All student programming was done in Algol 60, or at least the 903's subset of it. It was a miracle to have a compiler that would run on such a tiny machine. Several tricky language features were omitted, such as call-by-name and recursion. Even so running a program involved two passes. In the first, the compiler was loaded from a spool of paper tape about four inches across. Now the program tape could be loaded. If all went well, an object tape was produced. If not, the output tape contained error messages. Or rather, error numbers - there wasn't room in the machine for verbose text. Meanwhile, there was time to hand-rewind several hundred feet of tape ready for the next user.

If things went well, the next step was to load the run-time interpreter, another substantial spool of tape. Then the object tape could be loaded, and now the program would run. If it worked, it would produce its output, again on paper tape, which could be proudly printed on one of the ASR33s. If not - well, time to figure out why not.

Our programs were very simple - print the prime numbers under 100, print the first few Fibonacci numbers, that kind of thing. Just as well, because there were absolutely no debugging aids. With no interactive terminals, interactive debugging was unthinkable. What a luxury it seemed when I could use ODT (Octal Debugging Tool) on the PDP-8 at university!

The computer had a loudspeaker, wired to some internal signal which caused it to emit a tone that depended on what the computer was doing. There was a program that made it play simple tunes. Often you could tell how it was doing with a calculation by the noise it was making. One of my programming adventures was to code the highly recursive Ackermann's function (which involved some ingenuity to get around the lack of recursion in Elliott Algol). It made a very distinctive whoop-whoop noise which changed as it went up and down the recursion stack. You could even get it to play music with very careful tuning of instruction times.

The computer lab also had one of the very first electronic calculators, a Sumlock Anita. This was a wonder to behold. It could multiply and divide as well as add and subtract. It displayed its output on a row of Nixie tubes. Its internals were a very clever vacuum-tube arrangement using very few components to achieve all that it did.

The 903 had an 18-bit word, quite common before everything aligned around 8-bit bytes. There were 8192 of them, using core memory where every bit was represented by a little ferrite doughnut. Inside the cabinet, each of the 18 bits was implemented by a singe large board. When things weren't quite working, standard practice was to open it up and run a hand down the boards, reseating them.

It was a classic von Neumann architecture. There was a single register (the accumulator). An instruction used 4 bits for the opcode, 1 to mark indexing, and 13 for the operand address in memory. The memory access time was 6µS, and instructions generally took about 25µS. That included the time to read the instruction pointer and the accumulator, which were both stored in core memory to reduce the amount of expensive transistor memory required. There was hardware multiply and divide, taking about 75µS each, but no hardware floating point. If you needed that, there was a software library called QF that did about 1000 floating operations per second.

The Elliott 903 instruction set, including timings. The handwritten figures
to the right are for the new Elliott 905.

There was an assembly language called SIR, which was a classic assembler. Its one oddity was that there were no acronyms for instructions. You had to remember that 4 was "load accumulator", 5 was "store accumulator", and 14 others. I guess it wasn't hard, since I can still remember them 50 years later. It was rare for students to use assembler, I may even have been the only one. 

Bill Broderick had somehow persuaded Elliotts to give him paper listings of the Algol compiler and interpreter, all written in Assembler. It was a masterpiece to get a compiler into the available memory. It was also the first compiler implementation I saw. I spent a lot of time studying it, and I learned a lot from it. This was long before there were books about how compilers worked - though I do still have my copy of Gries from my student days.

Knowing both the assembler and the language internals led to an interesting adventure. In 1971 our town was twinned with Ludwigshafen in Germany. As part of the general junketing that accompanied it, the two respective police forces decided to organise some kind of car rally from one place to the other. To show what an advanced place Romford was, all of the associated calculations were to be undertaken using the school computer. Information was passed back and forth using the Telex network.

There was just one problem with this magnificent demonstration of 20th century technology. The telex network uses an ancient 5-bit code called Baudot, which was designed to minimize physical wear and tear on the mechanical internals of teleprinter machines. The order of character codes had nothing at all to do with alphabetical order. Our computer used wider tape and the ASCII 8-bit code, in which letters are arranged in the obvious order. How to convert from one to the other?

Somehow my name came up, and so I got to write library routines for the Algol system, in SIR, that would convert back and forth between the two character sets. Fortunately it was easy to adapt the paper tape readers and punches to work on the narrower 5-bit tape. This was my first taste ever of system programming, and I thoroughly enjoyed it. Maybe it was what encouraged me, a few years later in my first job at DEC, to develop a complete driver for 64 timesharing terminals and numerous different pieces of incompatible hardware for the PDP-11.

I spent the day at the operational headquarters of the rally. I forget the details, but I suppose they must have moved the computer there since there was certainly no remote access to it. It was my first, and I'm pleased to say so far only, close contact with the police.

Somewhere along the line our Elliot 903 was replaced by a newer machine, the 905. This had hardware registers for the assembler and instruction pointer, and faster core memory, bringing the typical instruction time down to about 3µS. Around the time I left school this was in turn replaced by one of the first HP computers. I don't know why they did this, but it seemed a bad idea. HP, being a US company, didn't have an Algol compiler. To satisfy the European market they had cobbled something together which was essentially Fortran using Algol syntax. I took one look at it and decided not to bother - I was off to university shortly afterwards anyway.

There are still several operational Elliott 903s, including one at the National Computer Museum in Bletchley, England. If you go when it is being demonstrated, you can listen to it play tunes, exactly as in 1966.