# The Early Days of Computing, Part One

## A personal history

I started working with computers when computers started. Not quite but my first line of code was written in 1969 and loaded onto an Elliott 905 computer at Elliott Automation, Borehamwood. My last line of code was written last week. I had to add some functionality to a customer’s database. (I’m a whizz at Access and SQL databases.)

I’ve been associated with the computing business for nearly 50 years, off and on. As the kids sit around the campfire and ask in awe, “What was it like in those pioneering days, Uncle Lugosi” I begin with tearful eyes as I look back to the teletype and paper tape.

I had no desire to get to university, declined an offer to become an articled clerk and started work in a warehouse schlepping,  boxes and on a market sweet stall. Out of nowhere I decided I wanted to be a programmer but had no qualifications. I got books out of the library on computers and FORTRAN.  I taught myself to program without having a computer.

Elliott Automation took pity on me and my begging letter to be a programmer. They invited me to their Graduate Intake Programmers Test. I passed and they offered me a job.

Here’s an Elliott 905.

• A Teletype to write your program which punches the paper tape as you type. It is also where the program can output messages.
• On top of the processor is the tape reader to read your program tape or data. Usually there is a bin to catch the paper tape that is read quite fast by the reader.
• On top of the processor box is a high speed tape output box for results and making a high speed copy of the input tape.

When you make a program mistake you read the tape to the point of error and cut out the wrong code by snipping the tape. You then punch up the replacement code on a fresh segment of tape and literally splice it in the right place using sticky tape with holes that line up with the tape.

If you were unlucky the tape reader would sometimes hit the splice and ruin your tape. Hence the need to run a tape copy.

These computers were used in industrial processes. I remember working on one that controlled Water, Gas and Electricity for a small town in Italy.

I next worked on a Univac 418 on stock market applications. We produced a daily publication of the Stock Exchange Daily Offical List (SEDOL) as well as a list of Gilts and some private, individualised lists. I was there on Decimalisation Day. I wrote the conversion program, called “FEB15”, so I never forget the date of Decimalisation. I also wrote the program to produce the Gilts list which drove a printing press.

It was a huge, air-conditioned room run by computer operators. You can see the magnetic tape units and tape stores.

Storage was on huge drums.

They had glass windows so you could see that the drum was rotating and heads moving.

For output you wrote to magnetic tape and for print-out there was the chain-printer.

It was fast because there was a drum with one character per column.

Programming was done by typing instructions into 80 column cards, usually done by card-punch operators, although many of us learnt some keyboard skills and did it ourselves.

You always carried elastic bands to make sure you didn’t shuffle the cards. Drop them and it was a disaster. I seem to remember they had a sequence number printed on them to help you if you dropped them.

Remember “Hanging Chads” from the Bush/Dean election? Well a Chad was a piece of card that is meant to be a hole that didn’t quite punch correctly. Hanging chads screwed-up card readers. The floor was always littered with them like confetti.

Debugging programs was fun! You would submit your job with cards and instructions as to which tape to load for data. In the morning you either got back the result that the program finished or that it crashed. A crash meant you get a memory dump full of the contents and you had to work out from the binary which were instructions and which were data. The dump was 20-30 pages of numbers in a horizontal and vertical array. The dump register at the time of the crash gave you a clue as to which memory location contained the last instruction and address. From that you had to work out what went wrong by following the code backwards deciding if “0FE206D87” was data or instruction.

When you thought you had found the problem you go back to the print-out of your program and work out which punch cards to change to re-submit a corrected program. Because you could only manage one run a day then ten problems meant ten days of debugging.

After one year I said to my boss “I don’t think this programming lark is for me”. (46 years later I happen to have turned out be a most talented and creative programmer and top debugger – ahem!).

I took a job 300 yards away in Hatton Garden working for Pitney-Bowes. They made some of the first Point Of Sale systems installed in the UK, although known better for their office equipment. I worked on the Data General Nova 1200. (There is an excellent full description of the Nova 1200 here Data General Nova )

You could almost call it a table-top or bench-top computer. It started life in 1969 and cost $8,000 without peripherals. It was used mainly by labs and in universities to control equipment and was a contemporary of the PDP series. The front panel was most interesting. In order to do anything you obviously needed to load a program into memory and execute it. You did that by entering a five instruction bootstrap program into memory via the 16 panel switches. 1. Clear memory. 2. Clear Registers. 3. Select bootstrap device (tape or disk – a fixed head disk costing about$10,000)
4. Set up a pattern of switches for the first instruction and load into memory.
5. Repeat for the next four.
6. Set address of the first instruction in memory.

The bootstrap would start loading 16 bits per address location and then jump to the first instruction loaded. The bootstrap might tell you to load a program via paper tape. That could be the “Compiler” which would then instruct you to “Load program Tape and press return”. You would then load your program tape, it would be compiled and then run.

Programming was in assembler code although there was a Basic compiler that came along later. Here is a code example:-

A comprehensive explanation of the DG instruction set is here:- Data General Nova Class Instruction Set Description

It did some weird stuff. Here’s a description of what special memory locations can do for you:-

“While not overly reliant on dedicated memory locations and so- called “magic numbers”, the Nova does allocate some memory locations for special uses. Most notable of these are the locations between 20 and 37 (octal) and locations 0 and 1.

Locations 20 through 37 are special in that when they are accessed as part of an indirect operation, they increment or decrement their contents before the effective address is calculated. This makes them useful for traversing tables and large chunks of memory. The locations 20 through 27 are auto- increment locations which increment their contents by one before the value is used; locations 30 through 37 are auto- decrement in that they decrement their value by one before the value is taken. The locations behave normally for non- indirect accesses.

Locations 0 and 1 are used by the machine’s program interrupt facility. When an interrupt occurs, the continuation address (the PC before interrupt) is placed into location zero and the machine executes an indirect jump through location one. Hence, location 1 must contain the start address of the interrupt handler. When an interrupt happens, further interrupts are disabled until they are explicitly re-enabled. A return from the interrupt is performed by jumping indirectly through location zero”

By writing code that handled interrupts, register manipulation, jumping to memory locations, left or right shifts on bits in an accumulator and interfaced to a disk at very low level like addressing individual tracks and sectors I somehow managed to write a hash indexed file system for looking up customer accounts and assigning transactions to them. The installation was at Peter Jones, Sloane Square and involved early POS terminals controlled by microcode, hard-wired ROMS. The terminals were “dumb” but got their smarts from the dual controller box with magnetic tape cassette recording for backup. The DG system took the data from the controllers.

The ROMS were programmed by hard wiring each instruction. Mistakes were simply unwound from the pins and re-wired. I never got involved!

I made myself redundant because I worked out why the system didn’t work. The cassette tapes were so unreliable that due to re-tries the dual controllers could never be in sync and so the integrity of the system was compromised. Project abandoned. Job disappears.

Next Job? Another 300 yards away in Hatton Garden. “So you know the DG series and have Point-Of-Sale experiences? We have just the job for you”. I joined Litton-Sweda and ended-up designing the first price-lookup POS system installed in the UK at Boots The Chemists in Nottingham. The Queen even came to open it. Well, to be honest, it was a visit by the Queen to honour Nottingham that just happened to pass the store.

End of Part One