|Resurrection Home||Previous issue||Next issue||View Original Cover|
The Journal of the Computer Conservation Society
| God Save the King |
An Early Musical program on the Ferranti Mark 1
|Cleaning the Elliott 401 Computer||Dominique Russell|
|Dennis Blackwell – a Life||Susan Colley|
|A Chilton Atlas Ghost Story||Chrissy Norris|
|The Tony Sale Award 2016||Martin Campbell-Kelly and others|
|Book Review : Archeology of Algorithmic Artefacts||Doron Swade|
|50 Years Ago .... From the Pages of Computer Weekly||Brian Aldous|
|Committee of the Society|
|Aims and Objectives|
EDSAC Replica — Andrew Herbert
We continue to progress step-by-step through systems integration.
We have demonstrated main control successfully going through the order fetch / decode / execute cycle with the arithmetic unit.
The coincidence and store access circuits remain in place and commissioned: they will be integrated with main control once it has been shown to be fully functional.
The arithmetic unit is in Cambridge ready for transfer for TNMoC. It is substantially complete, undergoing final testing of the corner cases of the multiplication circuits.
After a long period of experimentation we have arrived at a solution for driving the nickel delay line stores from the storage recirculation units that would seem to give us reasonable operating characteristics — the main issue has been improving the signal to noise ratio on the output from the delay line back to the regeneration unit to minimise breakthrough from the input side. We have some suspicion our decision to put an isolated 0V rail on every chassis may well be exacerbating our problems, and of course our EDSAC lives in an electrically noisier environment than its predecessor.
Ducting and 1.5km of cabling has been installed to connect the delay lines to the recirculation units.
Next steps are to continue with the systems integration, design and build the the initial orders loading system, complete the input-output system and devices, build an operator’s desk and design and build a clock monitor.
David Allen, David Hartley and I have visited another lady EDSAC operator to gather more information on what it was like to work with EDSAC in the early days and some of the associated personalities.
A full EDSAC volunteer’s meeting took place on 1st October. On the following day we hosted the surviving EDSAC operators (all ladies) to show them progress so far and pick their brains on how the machine was operated day to day.
ICL 2966 — Delwyn Holroyd
The system continues to operate reliably. The only problems worth noting have been ongoing issues with the EHT power supplies of the two 7181 VDUs, which are caused by the crimped internal connections. Whilst the terminals are both still serviceable, some more work will be required in the near future.
Our Computer Heritage — Simon Lavington & Rod Brown
OCH contains the beginnings of a write-up of the Modular One computer — see: www.ourcomputerheritage.org/Modular_One_Version_1.pdf. We now need a volunteer who is interested in adding material to this section about the Modular One’s register-level architecture, instruction set, etc. Anyone with fond memories of a Modular One and an interest in writing technical descriptions is asked to get in touch with Simon Lavington.
Bombe — John Harper
We started the Bombe Rebuild Project over 20 years ago and have had it fully working and have regularly demonstrated it for almost ten years. It is now time to consider succession planning. Many of the original team are ‘not as young as they were’ and it is time to develop the team with younger blood.
Therefore we are looking for new recruits. When we say younger; it might be unrealistic to consider, but not rule out, those in work with younger families and other personal commitments: so likely candidates would be in their mid to late 50s, retired with a personal income, with basic professional engineering background but also with a ‘hands on’ experience and a talent to make things work without a significant support network. Electro-mechanical skills would be most appropriate but this should not rule out other backgrounds.
If you are interested please contact me using my details shown elsewhere in Resurrection.
Appeal for Help
The National Railway Museum is researching Total Operations Processing System (usually known as TOPS) the 1970s IBM 370 computer system for keeping track of British Railways’ rolling stock.
Were you a TOPS developer or user? Did you write TOPSTRANS software for British Railways, or help implement the scheme on the ground? Do you have knowledge of the pre-history of TOPS in the USA and its origins in IBM and Southern Pacific Railroads? Are you familiar with the origins of the IBM software in the US defence sector (SAGE)? If so, or would be keen to hear from you.
Further details at www.computerconservationsociety.org/news/tops.pdf.
ICT/ICL 1900 — Delwyn Holroyd, Brian Spoor, Bill Gallagher
A new issue tape has been created for version 6A using source recovered over the last couple of years from the MGS binary system. A clean install, compiling from this tape, binary compares with the MGS binary. We know there are potential source errors still in the source (absolute addresses instead of labels, etc.) so that different configurations to MGS give problems. A lot of these errors have been cleared during the create process, but it would be unrealistic to hope that they have all been corrected. A lot of testing now required.
The CPU module appears to be working, as does the EDS30/60 module. Disc DCPs and OLTs can be loaded and run. The DDE module (1900 interface) still has to be completed.
Work has been paused in favour of the 7930 scanner implementation for the 1904S emulator, which will also be used for the PF56 communications module. It is easier to debug the 7930 against a 1900 Executive for which we have a compilation listing rather than the binary only EZ5A communications DCP.
Some useful information was obtained at the Punch Card Reunion at Stevenage in October, where the main topic was the PF56.
Running reliably, current work is to add a 7930 Scanner (see above). This is proving frustrating due to lack of documentation, but seems to work with teletypes and 7020 RJE terminals under E6RM, but fails miserably under GEORGE 3.
The 1974 magnetic tape rewind/unload problem has been resolved.
On long term hold, works with E1HS, but fails with E1DS fixed, overlays missing.
Further work is required on bug clearance, but a basic system is running. It is nowhere near release standard yet.
We are running Executives created from the ‘cleaned’ source, but have identified further ELWRO updates which will need to be removed.
Testing of the 7930 Scanner has led to the discovery of ELWRO amendments which need to be investigated and removed.
Building of a database of available programs continues. We have also written several short manuals on various utilities for which no documentation appears to exist, having ascertained a way to drive them (correctly or not) out of necessity.
We already have copies of the most common 1900 manuals, so it’s unusual to come across new ones. This month copies of Care and Handling of Recording Media and 1901 Console Operating (without Console Typewriter) were donated to TNMoC, the latter an ICT first edition from 1966.
Argus 700/Bloodhound — Peter Harry
We welcomed CCS members to RAF Cosford on September 24th for a visit that included a presentation on restoring our Argus 700 and to see the computer in use as part of the Bloodhound missile simulator. The simulator, part of the UK’s cold war heritage, is the focus of our restoration work, it just happens to use Ferranti’s Argus 700. CCS members could see at first hand the work undertaken to restore the Argus 700 in what can be described as basic facilities. During the presentation, a brief explanation was given regarding one of the main obstacles overcome, replacement of the Argus 700’s obsolete disc drives. It is hoped that a full description of the Argus 700’s restoration will be available for inclusion in a future edition of Resurrection.
The Argus 700 now runs reliably, as does the Bloodhound simulator, so what next? The next is a change of focus, a move from being hardware orientated to one of software and program writing. Not an insignificant change as we started the restoration project with no previous Argus 700 knowledge, or experience. Help though is always at hand as over the years we have received advice and support from several ex-Ferranti engineers. Essential support when it came to understanding software error messages and converting the disc system on the Argus 700. Over the past four years of the restoration it was a case of getting the Argus 700 to run with an existing and compiled software application. There was no need to understand how to write a program as the Argus 700 just had to run and if it didn’t, it was a hardware problem. So what next? Learn how to program the Argus 700!
One obvious question is, why bother learning to program the Argus 700? The simulator runs and there is no need to modify the application software in any way. The answer is, we need to create test routines to exercise parts of the simulator system and the Argus 700 hardware. One goal is to write programs that can be used to test individual Argus 700 boards. A steep learning curve is now needed over the next few months but we do have the means to succeed. We can work at the bit and byte level using Ferranti’s Control and Monitor Panel (ME159), a unit that enables the monitoring of instructions as they execute by displaying the contents of the processor’s accumulator and registers as well as memory locations. At the other end of the software scale is the operating system (OSC245) and a Coral 66 compiler (OSX150). A start has been made in gaining some knowledge of how to use the Control and Monitor Panel but there is a long way to go. Help is always appreciated so if there are any ex Ferranti Argus 700 software engineers reading this who can share their knowledge, please get in touch.
CCS Website Information
The Society has its own website, which is located at www.computerconservationsociety.org. It contains news items, details of forthcoming events, and also electronic copies of all past issues of Resurrection, in both HTML and PDF formats, which can be downloaded for printing. At www.computerconservationsociety.org/software/software-index.htm, can be found emulators for historic machines together with associated software and related documents all of which may be downloaded. Note that this part of our website is under development. Further material will be added in due course.
Software — David Holdsworth
Volume IV of the Leo Manual has now been decorated with hot links and can be seen at: leo.settle.dtdns.net/LeoMan/Manuals.htm
I have very recently received a very positive response from Jim Austin about borrowing tapes from him.
There has been much activity. Our re-engineering of the missing brick 20 is still making good progress. Brian Wichmann continues to explore the archives at Blythe House, and has recently discovered a hand-written copy of the missing brick. David Huxtable has been in contact with its original author who believes it to be close to that which was issued. We have not abandoned our re-engineered version, and are still considering whether it is worth copy-typing.
It is my intention that these documents (primarily design documents and flow diagrams) will eventually form part of the on-line presence of our preserved compiler system. Find an initial stab at incorporating such documents at kdf9.settle.dtdns.net/KDF9/kalgol/DavidHo/KAB22.htm.
Harwell Dekatron/WITCH — Delwyn Holroyd
This Halloween saw a special program of activities around the museum and the annual excuse for themed decoration of the WITCH area!
The artist John Yeadon recently visited the museum. Readers may remember the appeal earlier this year to find his 1983 work “Portrait of a Dead WITCH”, which was eventually located in a Manchester café bar. It was the first time John had seen the machine since he painted it at the Birmingham Museum of Science and Industry.
Operation has been generally trouble free with the exception of a couple of incidents. One of these was suspected to have been caused by dirt in a relay contact and cleared itself. The second unfortunately caused a day of downtime on a Saturday, however visitors did get a rare chance to witness the process of fault-finding on a 1950s computer. The symptom of the issue was seemingly random corruption of store locations during operation.
The problem was eventually traced to an intermittent partial short in a pulse generator valve which confusingly didn’t affect the output of the valve in question, but instead caused another circuit to malfunction due to the increased load on the input signal to the faulty valve. The unusual and intermittent nature of the fault caused more than the usual amount of head scratching amongst the team!
IBM Group — Peter Short
We have made good progress in creating information cards for those displays where they were missing. Each card can take quite a while to produce if we don’t already have the product information. After trawling our own documentation then the web, we can end up with little information or huge amounts. Either way, we update the online database first, and then create a summary on the card. In addition if there’s enough information online we create a QR code pointing at the web page.
Two Hursley departments have been having a major clearout and invited us to take what we wanted. One area yielded a lot of miscellaneous hardware, software and documentation. The other, the Storage Systems Development group, yielded a quantity of SSA disc adapter cards and hard discs. We also found a prototype for the Redwing hard disc, which had two actuators , whereas the finished disc only used one.
An IBM retiree has donated a set of framed IBM advertisements from the 1950s, extolling the lightning fast computing power of electro-mechanical machines and valve-powered computers. These now hang behind the Royal Army Pay Corps 705 console.
After the loss of an artefact out on loan that we reported earlier in the year, we have implemented more regular checks on loans and the people responsible. Unfortunately this revealed that our 011 electric hand punch, on loan to us from the Army, and loaned out to a Hursley department, has disappeared. The responsible manager had moved on, and we’ve not been able to find anyone who knows what happened. This was our only example of this punch, so our loans policy has been further revised to only lend items where we have at least two and preferably more.
Elsewhere in this edition, you will read about Strachey’s program for the Ferranti Mark 1 which played God Save the King on the hooter.
By co-incidence, that very subject came up in an edition of BBC Radio 4’s Today programme on the 1st of October 2016. Jack Copeland, a noted authority on Alan Turing, managed to get all the way through a long interview without mentioning Strachey at all, but discussed Turing at length giving the unfortunate impression that the latter was entirely responsible for the feat! Happily, the BBC’s web page at tinyurl.com/z5v2a3m gives a more balanced view. There you will also find links to the interview and to a recently cleaned-up version of the 1951 BBC recording of God Save the King, and other tunes. Do note however, that the implication that Turing built the Mark 1 computer all by himself should not be taken seriously.
Our ever-active friends in the LEO Society have been at it again. On 29th November, 65 years to the day after LEO I became the first computer in the world to be applied to business, rather than scientific problems, a plaque has been unveiled in Lyons Walk, Hammersmith a short distance from the site of that momentous and pioneering event.
In “Brexit” news, the Chancellor of the Exchequer has indicated that highly skilled workers may be exempt from the government’s planned immigration controls. Philip Hammond said he could not see why firms should be restricted from recruiting “high level” workers. The public was not concerned about controls on “computer programmers, brain surgeons, bankers”, he said (BBC News website).
This is the first time my social and economic status has been equated with that of a brain surgeon. Less pleased about the bankers though.
Starting in February 2017, the Science Museum’s new exhibition is all about robots. The centrepiece of the event is “Eric” a newbuild replica of a 1920s humanoid robot which seems to have disappeared once the novelty wore off. Externally, the Eric replica is a faithful re-creation of the original but its mechanisms are modern and it is computer-controlled. The Science Museum’s web page tinyurl.com/zndc4yx has details and a short video.
“George”, Tony Sale’s similar 1950s creation (see Resurrection 53) on loan from TNMoC, is also part of the exhibition but is pretty much original. The exhibition will run until September.
Readers might recall our Resurrection 71 article on the rather handsome STC Executel discovered at the National Trust property The Homewood. It turns out that it had been discarded in a skip at the house until somebody noticed that it fitted the space created for it in the office desk and retrieved it. Until we recently made contact (don’t ask) it was thought to be a telephone exchange rather than a telephone-cum-computer. Delighted to be of service!
Peter Cunningham has set up a website (www.inputicenter.com) to give researchers and historians access to work produced by the INPUT organisation from 1975 to 2000. The collection contains research and materials specific to IT Software and Services Industry markets — more than 3,000 collection items
The service is offered free to students and researchers with a .edu or .ac.uk email address and available free for a trial period to all visitors.
The current website presents the results of the “Phase One” of our digitization effort — the scanning of all highest-priority INPUT deliverable items.
God Save the KingDavid Link
In September 1951, the school teacher Christopher Strachey showed up in the computing laboratory of Manchester University with an algorithm of enormous length. After a couple of errors were fixed, the program ran straight through and finished by playing God Save the King on the built-in hooter (loudspeaker) of the Ferranti Mark 1 computer, which had been installed there in February.
This was only the second time a universal machine has been employed to play music the Australian CSIRAC having achieved the same feat in August 1951. On the 2nd of October 1951, the mathematician in charge of the lab, M.H.A. Newman, congratulated Strachey on his achievement of the melodic program in a letter, which allows a relatively precise dating of the event and is preserved in Bodleian library, Oxford.
A short time later, also in autumn 1951, a team from the BBC Children’s Hour recorded how the very early computer played God Save the King, Baa Baa Black Sheep and In the Mood, so by that time, the musical repertoire had already evolved. One of the engineers from the lab, Frank Cooper, asked for his own copy of the recording and the BBC team cut a second acetate disc for him, which survives in the possession of Christopher P. Burton.
Until now, it was completely unknown how Christopher Strachey programmed the machine to play music. But the author has unearthed the first God Save the King algorithm in Bodleian library (Strachey papers, CSAC 71.1.80 C.53), and a detailed description of it is given here.The musical programs were made possible by a technical device of the Mark 1, the so-called hooter — a simple loudspeaker. The corresponding hoot instruction in the command set of the machine, /V, sent an electrical pulse to the speaker, which became “distinctly audible as something between a tap, a click, and a thump”, as Turing’s Handbook wrote. The order could be integrated into a cycle, e.g.
FS NS/V CS FS/P
where the first sent the pulse to the speaker, and the second jumped back into the first line. Both instructions had a duration of four basic machine beats of 0.24 milliseconds length, so the period of both commands was 8 x 0.24 = 1.92 milliseconds and hence the frequency of the sound generated, 1000 / 1.92 = 521 Hertz, about C5. Since this was the smallest loop possible, the tone was the highest one the computer could emit. By calling /V “repeatedly and rhythmically”, wrote the handbook, “a steady note, rich in harmonics, can be produced.”. By constructing different loops, other tones could be programmed.
The hooter already existed on the Manchester Mark 1, the precursor of the Ferranti Mark 1, which developed organically out of the Small-Scale Experimental Machine SSEM, or “Manchester Baby” for short, from August 1948 on. In October 1950, Audrey Bates wrote a thesis On the Mechanical Solution of a Problem in Church’s Lambda-calculus, incorporating programs on the Manchester Mark 1, and reported that in the “Code of Instructions” decimal 1 or teleprinter E was the “Hooter operator”. Also in Turing’s first edition of the handbook from March 1951, there is an appendix on the “Pilot Machine (Manchester Computer Mark 1)” with a list of Computer Function Characters, where 15 or K meant “Hooter operates”. The code for the loudspeaker apparently changed several times.
The hoot function was put to use in several different ways. The handbook specified the following scenario for the above-mentioned simple loop: “This is used to enable the operator to be called to attend to the machine in some way. The simplest case is where the whole of a job is completed and it is required to clear the electronic stores and start something different.” Usage was so common that the so-called hoot stop was incorporated into “PERM”, two pages that contained the powers of two and the routine-changing sequence and were kept constantly available in the electronic store at the side of every program. In Christopher Strachey’s software for the game of draughts from 1951/2, the algorithm also entered the hoot stop if the user took too long to reply to the machine. According to Martin Campbell-Kelly, usage of this feature declined after a dramatic event had taken place: “[A] new user ran a programme that terminated on a hoot stop, with the volume full on. He looked for a switch to turn off the hooter and the only one that seemed possible was labelled HT. Unfortunately it was the high tension power supply; the machine took several days to repair!”
In the instruction sheet for the draughts program, Strachey described a more subtle way of tone-driven interaction with the software: “The machine gives a ‘pip-pip’ signal when it requires attention. It should always be restarted by operating KAC after it has been set appropriately.” So every time the algorithm had digested the user’s input, for example part of a move sequence, it was emitting a sound and passing control over to him, until he hit a key called KAC to indicate his input was complete. This procedure organised the whole flow of human interaction with the program.
A third function of the hooter was useful in debugging. The handbook wrote: “By putting hoot instructions into programmes [sic] at suitable points one is enabled to listen in to the progress of the routine. Some indication of what is going on is given by the rhythm of the clicks that are heard.” Dietrich G. Prinz, an early programmer on the Mark 1, remembered he was once congratulated on the “musical quality” of his software. Many of these diagnostic clicks can also be found in the source code of Strachey’s draughts program.
The musical algorithm that played God Save the King was part of an interpretive trace routine which was 20 programming pages long and which Strachey had developed in parallel to his draughts on the suggestion of Turing. Its name was CHECKSHEET and on page 19, the melodic software was located. It was one of two ways to terminate the algorithm, hence the page was called ROUTINE CHECKSHEET EXIT2. Strachey had scribbled on the top right of the page “The King” to indicate the tune it played.
In the bottom half of the right column E, the frequency of the notes is found in teletype characters and written backwards from bottom to top. Hence the first tone values are in rows £E, VE, XE, etc. Only the first two characters are used and the first line, @/@/, is decremented by one to E/@/ before it is employed, so the 16 numbers for note frequencies are 1 1 2 0 1 2, 3 3 4 3 2 1, 2 1 0 1 (rows £E to TE). Above the tone values, also in the right column and again backwards from bottom to top, the note durations are located, numbers in Baudot code between 1024 and 4128.
The actual program producing the music is found in the left column, rows // to P/. Its main function was to define loops mixing arithmetic five-beat instructions and non-arithmetic four-beat instructions. This is because by using only orders of one duration to define the frequency, there is no way that a good enough musical scale can be produced. It is essential to have finer control of the length of the loop. Using suitable mixtures of four- and five-beat instructions allowed increments of 0.24 milliseconds and that enabled a reasonable scale to be produced. We take the first note generated as an example.
In row W/, B-tube 7 is set to one of the values for the note durations in rows KE to /E, in our example to KE = S/@/. Two lines below, in row Y/, B-tube 6 is set to one of the values for the note frequency in rows £E to TE, in our example to E/@/, the content of line £E decremented by one in the preceding rows T/ to L/. After that, in line P/, command S/IP is found, an unconditional jump. Before it is obeyed, the content of B-tube 6 is added to it, in our example the first two signs of E/@/. This modifies the address the operation jumps to, the final command now being I//P, and in row I/, the first two characters are :/. The algorithm thus jumps to this line and continues execution at the beginning of loop 8 (L8, cf. Figure 1), in row S/. The addresses of the five possible loops are found in the first two signs of lines S/ to D/ and have been framed in Figure 1.They are selected in the way just described by addition of B-tube 6 to the control transfer instruction.
Loop 8 in rows S/ to N/ begins with what is called a “dummy command”, an order with an operation code T£ that has not been assigned a function. It takes four basic beats of the machine, and hence has a duration of 4 × 0.24 = 0.96 milliseconds. The following four commands with operation code T: repeatedly clear the accumulator of the computer and as arithmetic instructions each take five beats, 1.2 milliseconds. After that the hoot order proper, /V, is found, which takes another four beats, then a four-beat command that decrements B-tube 7 holding the note duration by 32 and finally a four-beat instruction that jumps back to the beginning of the loop if B-tube 7 is still positive. The total length of loop 8 is therefore 4 + 5 + 5 + 5 + 5 + 4 + 4 + 4 = 36 beats, and its period 36 × 0.24 = 8.64 milliseconds. That means the frequency produced in this loop is 1000 / 8.64 = 115.7 Hertz, slightly below B♭2 (116.54 Hz).
To determine the duration of the note, the software sets B-tube 7 to one of the values in rows KE to /E. At the end of the loop, as we just saw, the B-tube is decremented by 32 and loop 8 repeated if the result is still positive. The duration of the first note is found in row KE, S/@/, which is 2053 converted to decimal notation. If we divide this value by its decrement, 32, we get 2053 / 32 = 64, hence the loop is repeated 64 times. This results in a note duration of 64 × 8.64 = 553 milliseconds, approximately half a second. In a similar fashion, all note frequencies and durations can be determined, and they are found for the complete tune in the following tables, first the frequencies, then the durations.