A 1970s School 'Computer'

Programming at school in the decade before the microcomputer revolution

In around 1973 or '74, at Wellsway School in Keynsham, our Maths class was introduced by our wonderful teacher, Mr. Grace, to programming. The machine we used was shared between three schools in the area, one term at a time. While it was referred to as a 'computer', it was really a desktop calculator with some programming capability. We had taken Maths O-level a year early (a reflection of the SMP syllabus) and in the fifth form we had a little more time on our hands for such things. Programming was a new experience for us. Indeed, when we were first introduced to the machine, using a calculator would have been quite novel, with pocket calculators being a quite recent development and still somewhat expensive to buy.

Programs were worked out in advance and written down by hand on paper. Then, quite laboriously, they were punched onto paper tape, one instruction at a time by the user, using a separate tape punch machine. When that was completed, the paper tape was taken out of the punch device, and then loaded onto the computer via a connected tape reader which clicked away reading the tape, converting the punched holes on it into instructions the computer could understand. All being well, our programs would run as intended. More often than not though, a bug would be present, either in the original program as written down, or as a punching error, and the process of punching, loading and running the program would have to be repeated, perhaps several times. This was a shared machine, so this could be quite time-consuming to complete successfully and I remember getting up early on more than one occasion to get time on it! *

For some reason, I recall quite clearly that programs comprised up to 100 programming steps, contained in 10 program registers of 10 steps** each. If you needed to continue after 10 steps, you would go to the next program register. I think we could implement subroutines***, but perhaps without using that term, using these program registers. In addition, there were maybe 10 registers available for storing numbers. It was possible to repeat steps by jumping back to the beginning of a section of code and - crucially - to execute code depending on some condition being met. This last features provided the ability to extend programming beyond being simply a series of automated steps on the calculator (keystroke programming).

As to the device itself, I had long forgotten the name. However,  I did recall the distinctive symbols used for sending and retrieving data to and from registers, like this  -  V  - for one such operation and the same symbol but upside down for the other operation.  After a lot of searching, I found that these symbols seem to be unique to German manufacturer Diehl, and thanks to information about the range of their calculators on the very extensive CALCUSEUM site, I think our machine was either the Combitron-S, shown in  the centre of the picture above, or a similar machine, the Combitronic, these devices being limited to 10 program registers of 10 steps each. However, neither the manufacturer's name nor the names of the machines sound at all familiar, so I wonder if it could have been re-badged with a different company's name? 

(BTW, the tape puncher at the left in the above picture seems to have been an automatic one that punched as you typed on the main machine. I don't recall using one like that - the manual tape puncher was likely this one here).

We were tasked with writing programs that included:

• getting the user to input the radius of a sphere say and then calculating and printing out the volume.  I'm almost certain there was no hard-coded value for 'pi' so we would have had to assign the value for it to one of the registers ourselves! Such programs would have been relatively simple examples of keystroke programming only. Any complexity would have been in the commands for calculation - as a calculator it would have been far less easy to use than even a basic electronic pocket calculator from the era! ****

• playing a version of the game of Nim against the computer involving, taking it in turns to take 1, 2 or 3 imaginary counters from a heap, the loser being whoever took the last counter. If you got to go first and knew the winning strategy, you could beat the computer!  Games need rules and that means constructing conditional statements, which was something our 'computer' could do, even if somewhat primitively!

• a computer model of the Tower of Hanoi puzzle, with rings of different widths stacked in order of decreasing size on one of 3 posts. A ring can be moved from the top of one post to the top of another provided there is not already a smaller ring on the target post. The aim is to move all rings from one of the posts to another one, moving one ring at a time. After all this time, naturally my recollection is hazy, but given the limitations of the machine, the program likely provided just a simple model of the real thing that the user could manipulate to solve the puzzle, rather than having the machine do it.

After completing these exercises, I decided to set my own challenge by using an approximation method to determine the square root of a number. Never mind that the 'computer' came with its own, much faster, square root function, nor that there were likely many more suitable candidates for calculating a function! It was great fun and quite satisfying to do. The program looped to determine successive approximations of the root and was supposed to stop when they were the same. However, sometimes it continued to run with the printed approximations oscillating between two values and the program had to be stopped manually.

An enterprising fellow pupil used the machine to generate artillery tables and these were displayed in a chart along with the relevant equation at a stand at an evening event for parents of prospective pupils. Trigonometric functions would have been needed, so either the machine we used was a variation on the one shown above (which had no trig. functions) or this person coded their own using Taylor series!  Some thoughts on the feasibility of this here.

As for my programs, they were stored for a while in a round tobacco tin (my grandfather having been a pipe man) but are now long gone sadly, so as a bit of fun, I've tried to re-create a couple.

First, my square root program  here. For reference, I used program samples for the Combitron-S, which the owner of the CALCUSEUM site, Serge Devidts, kindly let me have.  Overall, the syntax seems pretty consistent with my now much faded memories, with one exception. The 'language' is low-level and you have to move data between registers as you perform calculations, something that is hidden from the user in even the most humble pocket calculator.  That much I remember. However, the conditional jumps are far more cumbersome to perform than I had recalled. So, if you want to see if two numbers are equal, having saved them first, you need to subtract one from the other and then, as conditional jumps are implemented when the content of the central unit is greater than or equal to 0, you have to do some jiggery-pokery involving subtracting a 1 and possibly changing the sign and then reversing these steps after the comparison has been made - what a faff! I managed to get the program to fit into 6 of the 10 available registers, so it was do-able, however.

I then tried my hand at the Nim program. My work in progress is here. It currently uses 13 program registers, which is far too many for the Combitron-S and Combitronic! It should be possible to cut back on the validation of the user's input to get it to fit, but that leaves a nagging doubt as to the identity of our machine. Were we really tasked with an exercise that would have highlighted the limitations of the device? Perhaps we had a more advanced model, one with a better implementation of conditional jumps? In fact the Algotronic, as well as having more program registers, had 3 jump keys marked 'J<', 'J=' and 'J>', suggesting just this extra capability (maybe testing when the content of the central unit is less than, equal to, or greater than 0?). If not for the greater number of program registers, this model could well have been the machine we used. Perhaps I have mis-remembered, or we were misinformed or we used an as yet unidentified model? In any case, with the more advanced conditional jumps provided by the Algotronic, I suspect the program would have fitted easily into 10 program registers and we may never have come up against this possibly notional limit.

By the time I left the school in 1976, the machine seemed very dated (it had been created ~ 1968). My own pocket calculator, while not programmable, had functions that weren't available on the Diehl machine. Not that I was aware at the time, but Diehl had been active in updating their range  - the Alphatronic from 1973 was much more powerful, could be connected to peripherals with magnetic media, had alphabetic keys (presumably so that text messages could now be displayed in programs), and 'proper' programming, including keys for GOTO, GOSUB and LABEL. Later models were even referred to as computers by Diehl. 

However, the writing must have been on the wall for this type of device, as relatively inexpensive programmable pocket calculators were becoming available. Also, while Diehl, and  no doubt others, were trying to develop their machines into desktop computers, they were going to have to compete with newcomers in the emerging personal computer market place.  

In the late 1970s,  Diehl released a mini computer range, the DS2000 and DS3000, with integrated CRT display, aimed at the technical and scientific market, but it seems they exited the business soon afterwards.

It would be great to see one of these machines working again. And I wonder - how difficult would it be to create an emulator?

(Almost) finally - if any fellow ex-pupils (or ex-staff!) at Wellsway remember this machine, I'd be delighted to hear from you! Similarly, if you used this machine at another school in the area, please do get in touch!

Foot notes

* on reflection, I think it more likely that we would have each had a session on the machine, keyed in our programs directly, got them to work (hopefully) and then committed them to paper tape afterwards. Coding errors identified during these sessions would be corrected by entering an updated version of the relevant program register, rather than an entire program. Even so, it would still have been a laborious process.

** actually it's just 10 characters per program register, so even more limited than I had remembered!

*** I think I must have been wrong about subroutines, if our machine was indeed a Combitron-S or Combitronic. Having reviewed the sample programs (see below), it seems that while you can jump between program registers, there is no hierarchy and you cannot return control to a calling program register.

**** coding involved moving numbers in and out of the central unit, to and from registers. While cumbersome, it was however a great introduction to programming in machine language for me (specifically z80 Assembly Language for the Sinclair Spectrum some ten+ years later).

More information

• For sample programs for a similar model, albeit with with less powerful programming capability, the Diehl Deltronic P, see the links to the brochure pages (in German) here

• To make sense of the syntax used to perform calculations, it may help to view this schematic (in French) for the Diehl Sigmatronic calculator (not programmable as far as I can tell, but the calculator part seems to be the same). In particular, note that there are separate registers for addition/subtraction, multiplication/division (as well as for accumulation). 

• For more information on the range of Diehl electronic calculators, see here and this document (in German) here

• For a closer look at one of the sample programs above, and the calculator syntax, see this document for some comments I have added

• Summary of symbols used by Diehl electronic calculators (focus on Combitron-S, Combitronic)

• An attempt to understand the format of the punched paper tape. (If I had kept my programs then it should have been possible to decipher them simply by looking at the locations of the punched holes!)