IBM Museum — Peter Short

Current Activities

The 4691 Moonshine leisure/pub terminal is now on display in the Hursley Room. After 30 years in someone’s garage it was rather dirty, but has cleaned up rather nicely. Unfortunately it is not in working order, probably with power supply problems. The coasters were produced at the same time as the hardware development and show made-up pub signs.

360/40 Archive

Now that we have identified at least some of the content of the ‘top safe’, the question is what to do with 300+ boxes. We’ve decided to put the boxes we took out back with the rest, take some more photos, catalogue their existence and leave them in peace.

Donations

The latest donation is an ITR clocking-in machine with IBM UK serial plate/service phone numbers inside and a short history on the back. The clocking-in mechanism is completely seized, but with that disconnected the clock itself runs well.

Hursley 60^th

The Museum supported a final celebration event for IBM employees to commemorate the actual anniversary of IBM coming to Hursley in December 1958 by providing a display featuring a number of awards, artefacts and images charting the history of both the site itself and the achievements of its staff.

EDSAC Replica — Andrew Herbert

We held a team meeting on December 18^th 2018 to review current status and plans. There was much discussion about whether we need to make the main clock more thermally stable or not. (The historical photographs show evidence of a Marconi frequency generator lurking behind the clock and digit pulse racks.)

A number of chassis have been taken home for rework – mostly monostable flip-flop to bistable flip-flop upgrades. Work continues away from the machine on initial orders electronics and clock monitor.

The priority remains commissioning main control. The main control team members feel they are now very close to, if not on the home straight for, reliable order fetch and decode.

A new volunteer, Simon Porter, has kindly agreed to go through all our schematics redrawing them to consistent standards.

Elliott 903 — Terry Froggatt

Locating a hard failure on the TNMoC Elliott 903 is sometimes very easy. We have a good selection of spare cards in the “scrap” 903, and we have an extra store unit which provides duplicates for the store cards in the main computer store. We almost have one spare of every type of card at TNMoC (although not in enough in quantity to make a second machine), and I have two working machines at home. So a hard fault can often be located by swapping cards, and the faulty transistor on a card can often be found with a simple multi-meter.

However, during 2018 the TNMoC 903 developed faults which we could not locate by card swapping. Sometimes, if it would read in program tapes at all, it would fail part-way through the day. So even if we swapped cards in groups, it would take many days on-site to locate the culprit. The TNMoC Large Systems Gallery has been closed for two months over winter, whilst the roof is being refurbished, so I’ve taken advantage of this down time, by moving the whole 903 CPU rack, power supply, control panel and some cables to my home, where I can test everything thoroughly card by card in my own 903s.

Progress has been good. Starting with my own working “Warwick 903”, I’ve slowly swapped in groups of cards that were in use at TNMoC, subjecting each group to a day of X3 (the function test) and a day of X2 (the store test) from cold. I found that the A-EC3 Master Store Driver card M59 would fail after some time. This culprit is a very “analogue” card, and will not be easy to repair. However the equivalent spare card N59 appears to be OK. Now armed with a full set of working TNMoC cards, I then swapped them all back into TNMoC’s rack, with the TNMoC MCB24 power supply and the TNMoC control panel, now attached only to the Paper Tape Station of my Warwick system. Everything continued to work.

In the photograph, the TNMoC rack is at the back, under its control panel. The Warwick rack is to the right, under the Warwick tape reader. The photograph was taken through the doorway of my Computer Room, to which access is currently rather tricky!

Subsequently, I’ve tested most of the cards (from the TNMoC and spare 903s) which were not in use in the rack when I collected it, so that we know which spares are trustworthy. Whilst doing this, there was a new hard failure on the spare A-FL Manual Control Logic card N02, which I was able to locate and repair. The current score is that we have 53 good spares for 76 slots, whilst 7 of the TNMoC “M” cards and 12 of the spare “N” cards are currently suspect pending further (non-urgent) investigation. We currently have at least one good spare (if we include the extra store) for all but 3 logic card types (A-FH, A-FF, A-FS).

In the last two weeks a further fault has appeared. A program tape cannot be loaded by Initial Instructions for the first two or three minutes from power up in the morning (at below office temperature). This could be related to the problem as that often seen at TNMoC last year, when tapes would not load at all. Swapping readers makes no difference. It could be a fault in the cards currently in the TNMoC rack or in its power supply, or a new fault in the Warwick Paper Tape Station or in its power supply. Although we could probably tolerate this fault, I hope to be able to track it down, given a few more cold mornings.

Elliott 905 ML/I – A Correction

In Resurrection 84, we should have said that London University’s Queen Elizabeth College was spun off from King’s College in 1935 and was re-absorbed by them (not by Imperial) in 1985.

Our Computer Heritage — Simon Lavington

Fresh delivery information has come to hand about the following computers:

• EMI EMIDEC 1100
• EMI EMIDEC 2400
• Modular One
• English Electric DEUCE

When checking has been completed, the consequential updates will be submitted to Birkbeck for uploading to the OCH website.

Harwell Dekatron/WITCH — Delwyn Holroyd

At the end of November 2018 roof works commenced in the First Generation and Large Systems Galleries. The machine has been boxed in to keep it safe during this work, which is due to be completed by the end of February.

Software — David Holdsworth

KDF9 Programming Languages

Work is ongoing to regularise the representation of KDF9 source code across our four different programming language systems, viz: two Algol implementations, Whetstone and Kidsgrove, and our two assemblers, Usercode and KAL4. The two main aims are:

• The ability to type input to our preserved systems using only characters commonly found on keyboards.
• The display of source text should look as it would have done on a KDF9 Flexowriter, which is also the form used in the documentation.
• The current scheme and its rationale are described in sw.ccs.bcs.org/DAVID-H/KDF9/chars.htm. The text of the web pages for the on-line executions of the software has seen some updating, but there are still omissions, notably the hints pages.

Some time ago we received a scan of an end-user program, which included the source text of the Algol library routines. It has not yet been possible to turn these into executable code. Our makeshift implementation of Usercode by substituting the paper-tape compiler for the missing KAB84 results in serious size limitations which are challenged by the full-scale library routines.

Bombe Rebuild — John Harper

In my last report I mentioned that we now have a recently German-built, highly accurate reconstruction of a WWII three-wheel Enigma machine as part of our displays. This has received a considerable amount of attention and is very popular. Not only do our demonstrators include it in their presentations but other TNMoC volunteers demonstrate it as part of their tours. This is sometimes to small visiting groups but often to organised school visits.

We are now almost back to giving demonstrations every day of the week. Whereas before the move we often had to demonstrate to excessively large groups, it is now more satisfying, because smaller groups ask questions and show more interest so we are able to tailor our replies and subsequent demonstrations accordingly.

The machine is in a state to allow our team to give standard demonstrations but currently we would have problems if we were to attempt to break a new message. As I write, we have identified four high speed sense relays not operating correctly and these will have to be attended to.

In our gallery at TNMoC we have installed an extensive audio-visual installation. It is very flexible and we can display videos etc, on any or all four large monitors. This allows us, for example, to run a video of one of our demonstration whilst our demonstrators are not available. There is therefore something of interest for visitors to see whenever the museum is open. Currently what is being displayed is set manually.

We have just entered the last phase of this development where a small touch screen can be used to choose a topic of interest from a selection of up to 12. Demonstrators can use this to augment their presentation, but at other times visitors will be able to choose their own subject of interest. The first example is now working and further development will take place shortly, after which it will then be made available to all.

North West Group contact details

ICT/ICL 1900 — Delwyn Holroyd, Brian Spoor, Bill Gallagher

ICL 1904S/ICT 1905/ICL 1901A – Public Release

These three emulators finally escaped into the wild at the beginning of December; so far nobody who has downloaded them has managed to break anything (apart from Brian). For details see icl1900.co.uk/preserve (or follow @ICL1900).

PF50

The emulation of the PF50 range of CPUs has begun in earnest, if somewhat accidentally. PF50 was the name assigned to a range of CPUs from Stevenage, starting from the 1902A and 1903A, and followed by the 1902S/3S and finally the 1902T and 1901T. The emulated CPU is passing the first few of the available exec mode tests and is able to run the available executive and GELL. Current efforts are the creation of the required peripherals and getting the I/O hesitation mechanism first understood and then coded. As usual we would greatly appreciate hearing from anyone with knowledge or items relating to these machines.

E3NG/05B/F53 64K
     MANCHESTER GRAMMAR SCHOOL FB8653.


     READY
     FI 30 G3MK8D O.K.
     UNIT 30 :- NON STANDARD TAPE
      

As can be seen from this most recent run we are currently having problems getting MT I/O working. All tapes are reported as non-standard despite an apparently successful read of the label into store.

Brian’s Xmas Challenge

Since the release of the emulators we have had various questions about how programs are loaded/run and the various operating systems, so I excavated the source of a demonstration program that I wrote in PLAN some 10 years ago showing the basics of TP/PUC operation – the basis of how GEORGE 1 & 2 and MAXIMOP worked, which I called GEORGE 0. This implemented a subset of GEORGE 1 Job Description commands, needed to run under GEORGE 3 and took up 1.5KWords of store.

I decided to tidy this up a bit and to try and make it smaller and neater by overlaying, a bad mistake, it actually increased the size by 320 words. This then became a challenge to rewrite it using a decent programming language, GIN (opinions may vary on this), keeping the footprint of GEORGE 0 to just 320 words and able to run under E6RM. Bill later threw in his couple of cents (we are in Euroland) and suggested that it could also form a basis for a MicroMOP, just to make things a bit more interesting.

To date, I have GEORGE 0 running under E6RM within the target footprint of 320 words, with just a couple of JD features yet to implement. MicroMOP (supports a single terminal) is a whole 40% bigger at 448 words and also working. The complete source, about 95% of which is common, using selective compilation (#DEFINE/#SKIP) with the missing features added should come in at about 2,500 lines of code.

Why do this? Why not? It is an interesting little project and is designed to run as either version on the 1905 emulator, which at 32KWords is a bit tight for GEORGE 2 (even GEORGE 1) or MAXIMOP.

ICL 2966 — Delwyn Holroyd

At the end of November 2018 roof works commenced in the First Generation and Large Systems Galleries. The machine has been wrapped up and some parts boxed in to keep it safe during this work, which is due to be completed by the end of February.

Our first happy duty here is to congratulate our energetic friend Delwyn Holroyd on the award of an Emmy from the Television Academy, no less. What for? Well not for his untiring work on various computer restoration projects, (though it ought to be) but for his “day job”. For he and his team at Codex Digital have created innovations to digital video cameras described as “game-changing”.

www.fxguide.com/quicktakes/70th-engineering-emmy-awards is the place to look for detail (no, I don’t really understand it either, but I am awfully impressed). How does he find the time?

101010101

The BBC Television Series Icons in which the public were asked to vote for the most significant figure of the 20^th century was “won” by Alan Turing who, it was claimed “invented the computer”. It is not clear who was runner up, but other finalists included Nelson Mandela and Martin Luther King Jnr.

The public’s recognition of the history of computers continues to grow. But what next for Turing’s reputation? Is there still a vacancy on the new £20 note?

101010101

The 75^th anniversary of the first attack by the Colossus computer on a Second World War enemy Lorenz message has coincided with the discovery of a selection of original decrypts showing the nature of the intelligence that was intercepted. The decrypts are now being analysed by researchers for a special display in the Colossus Gallery at The National Museum of Computing in May to mark the 75^th anniversary of the arrival of Colossus Mk II in time for D-Day in 1944.

101010101

Once again, we have been contacted by our friend Herbert Bruderer whose quest for ancient calculating machines has uncovered the work of engineer Roberto A. Guatelli. Guatelli seems to have been engaged in constructing replicas of such machines in the 1950s, many for IBM which are now believed to be in the IBM Archive at Poughkeepsie, New York. Several other examples of his work can be found spread round the world, notably at Carnegie Mellon University. Originals by Leibniz, Pascal, Babbage and others were reproduced.

cacm.acm.org/blogs/blog-cacm/234005-more-replicas-of-historical-calculating-machines-found/fulltext is the place to go for more information.

Reproduction of Pascal’s “Pascaline” Machine

101010101

As usual it is my sad duty to report the passing of significant figures from the IT industry.

Conway Berners-Lee’s career with Ferranti, ICT and ICL spanned some 35 years. Chiefly famous for the Berners-Lee Algorithm, a method for randomising the location of data in disc files which he later claimed to have forgotten. A regular attender at CCS meetings. He was 97.

Mike Forrest has also passed away. A senior management figure in the development of ICL’s “New Range” (a.k.a. 2900 Series) in the 1970s, he had a fearsome reputation for working all hours, perhaps only rivalled by Sir (as he then wasn’t) Peter Gershon.

101010101

STAB1

STAB1 is a programming language invented by Prof Andrew J.T. Colin, formerly of Strathclyde University. Andrew died in September 2018 after a brief illness, having drafted only the first part of this article. It has been completed by Chris Maden, who worked with Andrew at Talent Computer Systems and programmed several commercial projects in STAB.

PART 1: Background

In 1970, well before the invention of personal computers, I became the first professor of Computer Science at Strathclyde University. The course we planned included hardware, logic design and computer architecture as well as programming.

The only computing facility available to students when I joined was an ICL 1905 with punched card input, and a turnaround time of more than 24 hours – hardly a suitable environment for aspiring computer students.

As a ‘welcome gift’ the University bought my department a small computer. We chose a PDP-11/20 because it was one of the few machines available at the time whose designers seemed to understand common programming techniques. There was no attempt to squeeze everything into a 16-bit instruction word: addresses could span the entire memory rather than being limited to 8 bits. The stack concept was taken seriously, and there were good features for handling subroutine entry and exit to any level of nesting.

Our machine had 8K of 16-bit memory and paper tape I/O. The only software supplied was a BASIC interpreter and a symbolic assembler but on the other hand the PDP-11 had 8-bit wide digital input and output ports, which several students made good use of to run a model railway, a lift emulator, and a free-standing robot that navigated by acoustic signals.

We needed to supply a high-level programming language to support our planned courses. Our first thought was BCPL. Its author, Martin Richards, was extremely helpful and sent us all the documentation as well as a paper tape of the compiler. Unfortunately, when we came to load the tape into our machine, the 8K of memory proved insufficient. We therefore decided to design and implement our own language, which would be cut to the absolute minimum consistent while offering all the features of a general language. The result was STAB1, so-called because it was our first try at such a project (although if I was asked, I’d justify the name by mentioning the computer pioneers Strachey, Turing, Ada and Babbage).

STAB1

STAB1 used 8- and 16-bit integers (no floating point). The stack concept played a key role in the design. Thus every expression would leave a result on the stack, and every store command (preceded by ->) would take its data from the top of the stack. This fact was reflected in the form of the assignment statement, which was written in the opposite order to the standard convention; thus:

STAB used procedures of two types: functions and routines. A function returned a value, but a routine did not. Procedures could not be nested; one consequence was that variables were either global or local to the current routine.

Local variables were automatically assigned the value 0.

STAB allowed declaration of vectors of integers and characters. Addresses were always byte-orientated, so that adjacent integers in a vector always had even addresses. Values were given as octal numbers, unless preceded by a dot. Strings were terminated with the code 377, and the escape code was * so that *c*l stood for (carriage return/line feed).

The only I/O standard functions were readch (read a character), printch (print a character), and halt.

The indexing operator was !. Statements in the same line were separated by semicolons. Statements could be grouped in square brackets [].

This is a STAB program to print prime numbers below 1000, neatly arranged six to a line.

        vec primes=2,3,5,7,.11,.13,.17,.19,.23,.29,.31
          // All the primes < sqrt(1000)
        routine str charvec x
          let q;
          while x!q#377 repeat [printch(x!q); 1+q->q]

        routine pr n // Print a number in decimal 
                     // Note the use of recursion
          if n=0 then
            exit
          else
            [pr(n/.10; printch (n rem .10+'0')]

        routine print n
          printch(' ')
          if n<.10 then str ("  ") else
            // Initial spaces if needed.

            // "  " is a string
            if n<.100 then printch(' ')
              // ' ' is a single character
          pr(n)

        routine prno	// List all primes from 2 to 1000
          let x,y,c;
          str("*c*l Primes up to 1000 are: *c*l")
          	[do x=2(1),1000
            [do y=0(2)11
              if x rem primes!y=0 and x#primes!y then
                goto stop
              print(x); 1+c->c;
              if c=6 then [str("*c*l");0->c]
            ]
            stop:
          ]
        halt(0)

        prno       // Initial call to prno
      

Initial Effects

In the autumn of 1970 we had a cohort of some 15 students starting on the second year of their studies. In their first year, they had been obliged to run their programs on the University’s mainframe machine, with all the frustration of long turn-around times, disordered packs of cards, and a relatively complex programming language. It was no surprise, therefore, that when STAB became available in the department, they took to it with enthusiasm. Now they could punch a tape on one of our Flexowriters, submit it to the computer and get the results straight away. The students quickly worked through the exercises we gave them, and many of them started work on various utilities – editors, syntax checkers, and programs that controlled various bits of hardware. The PDP-11 was busy all day and half the night. Academically, that cohort was strikingly successful, and was the basis for many spectacular careers in IT.

To implement STAB we adopted a divide and rule approach. We would define an abstract machine (called STAB12). Then we could simulate, or emulate the abstract machine on hardware.

An interesting project I undertook during a summer vacation was to build a STAB12 machine in hardware. The scheme was named The DREADNAUGHT. The machine was based on a conventional Von Neumann architecture. Physically, it consisted of several 8”×8” boards plugged into a backplane that provided power and all the inter-board connections.

I based the arithmetic unit on four 4-bit ALUs connected to form a 16-bit accumulator. The ALUs provided a wealth of elementary functions including addition, subtraction, and bitwise operations. Each ALU had a board of its own. The surrounding components were conventional logic chips of the era, including inverters, nand-gates and so on, to control the operation of the ALU.

I used the other boards for the main memory (based on 4k byte chips) and control, where I placed the control counter, a stack pointer and current instruction register. There was also an EPROM for microcode.

Each chip was seated in a holder with wire-wrap pins that protruded from the other side of the board. Wiring the boards was the most laborious part of the construction: it would take me about ten hours for each board. However, I discovered a way to lighten the task. At the time I used to make frequent train trips from Glasgow to London, taking some five hours each way. On these journeys, I’d equip myself with a large wiring diagram, a blank board, a reel of wire and a wire-wrapping tool. People passing me on the train would sometimes stop and look with interest. One gentleman asked:

PART 2: Chris Maden continues with a personal view of STAB:

I worked on two projects while employed by Andrew in Talent Computer Systems, a company he established in the early 1980s to take advantage of the boom in home computers.

By the time I arrived, the STAB12 abstract machine had been ported to a number of computers. Our main development environment was a WICAT, which ran UNIX on a 68000 processor. We wrote our STAB programs on the WICAT and compiled them to run on the STAB12 abstract machine – not the DREADNAUGHT but abstract machines that ran on the Sinclair Z80, BBC and various other home computers of the early 1980s. The STAB12 abstract machine produced very compact code, but was slow; we could break-out to native machine code where performance rather than RAM usage was paramount.

The implementation of the STAB12 abstract machine depended on the target architecture. The 68000’s architecture was essentially a PDP-11 on a chip, so many STAB12 commands were single 68000 instructions. The 6502, by contrast, had a very limited instruction set and few registers, so the STAB12 abstract machine was less compact and slower to execute. Andrew preferred the 6502, however, to the 6809 and Z80: one of his mantras was “there are only three good numbers in computing: zero, one and many” and the 6809 and Z80 were neither chalk nor cheese in that respect.

The result was the best cross-platform system I’ve worked on to this day. We had all the power and flexibility that comes with the UNIX development platform, yet turnaround times of a single-platform system. In the era when 32K was an unimaginably large amount of RAM, we could craft code to be compact where speed didn’t matter, and fast where it did.

This rapid-development came to the forefront when the company was given the task of developing a proof of concept for what would now be called a Fitbit. One of Andrew’s colleagues at Strathclyde had invented a polymer which changed resistance when stretched. The idea was to put a band of this polymer around a jogger’s chest and record his respiratory rate and pulse at rest and while running, and also his recovery time. The proof of concept had to be ready within two weeks.

We wire-wrapped – not on a train – a small motherboard with a 6502 microprocessor, 2K of RAM and a 16K EEPROM, the latter of which was re-programmed probably a hundred times in that fortnight. The EEPROM contained the STAB12 engine and whichever code we developed. The software relied on a Fast Fourier Transform, which Andrew had written in assembly for another project some time before (we chose the 6502 because the FFT had been developed for it); the STAB part of the code dealt with interfacing with various external peripherals.

The key issue in the software design concerned these peripherals. In addition to the polymer, the unit had an RS232/432 serial port, a keypad and a display. I favoured driving the peripherals with interrupts. For the FFT to work, the polymer had to be polled at 20 times the frequency of the maximum likely frequency – the wearer’s pulse rate. That amounted to 20*200 = 4,000 samples per minute. Today, this is trivial. In those days, that amounted to barely 15,000 CPU cycles per FFT – a tight squeeze. Andrew preferred polling: his view was that, given that we had two weeks to finish the job, and that it was only a proof of concept, not a production design, having code we could debug was far more important than having code that was perfect.

His view prevailed and I learned a lesson: we delivered with hours to spare, but in time for a major fund-raising effort by the client. I doubt to this day if my technically perfect solution would have enabled us to deliver.

Andrew’s pragmatism came to the fore once again when I was given a graphics package to develop, for the Commodore C64. STAB12’s syntax was very simple: names were local or global, and that was that. All function and routine names were global, and in a code fragment such as

        routine aroutine
        aglobal;
        [ ... /// code ]
      

the compiler took the declarations as occupying successive positions in memory: aroutine was a scaler, initialised as a pointer to the code, and aglobal was a 16-bit scaler, global in scope, initialised to zero.

If the code didn’t have any global variables between functions/routines, the pointers to the code would occupy successive slots in memory, so in

        routine aroutine1 [code]
        routine aroutine2 [code]
        routine aroutine3 [code]
      

the pointer to the code for aroutine1 would be in memory 0, that for aroutine2 in memory 2, aroutine3 in slot 4 and so on (they were in even-numbered slots because STAB12 used byte-wise addressing and both pointers and scalers were double-byte words). Preceding these with an empty vector,

    vec allroutines(0);
      

and combining it with the dereferencing operator, @, allowed constructs such as

    @(allroutines!4)(parameter1, parameter2)
      

which would call routine3 with parameters parameter1 and parameter2.

Once I’d worked out this approach, developing most of the functions turned out to be straightforward, and I soon had a package ready for demonstration.

The pragmatism came in, however, with ellipses. This was before the GPU took the fun out of writing graphics, and I attempted to modify the mid-point algorithm to draw ellipses. No matter what I did, however, I couldn’t make my modified algorithm converge in any but trivial cases. After three fruitless weeks with an otherwise completed package – I was by then enjoying the maths more than the programming – Andrew suggested I try an approximation based on polygons. After another fruitless week, I relented. I tried 4, 8, 16 and 32 vertices: an irregular triacontadigon was indistinguishable from an ellipse.

There is an old adage in hardware: cheap, fast or small: choose any two. STAB12 was quirky, for all practical purposes typeless and utterly un-debuggable. But STAB12 proved to be streets ahead of its time: when Sun Microsystems launched Java a decade after STAB’s retirement, they made much of p-code running on a Java Virtual Machine. Andrew had been there two decades earlier with the STAB12 abstract machine, which was cheap, fast and small: perhaps we can think of STAB as standing for Strachey, Turing, Andrew and Babbage.

Bringing Bletchley Park’s Colossus to an FPGA

The 75^th anniversary of the first successful decryption using the WW2 computer Colossus took place recently. This seems like a good moment to inform Resurrection readers about a partial re-implementation project I did to better understand the operation of Colossus.

Colossus

Colossus was a special-purpose computer built in WW2 to perform statistical attacks on high-importance encrypted German transmissions. It has a key place in the early history of electronic computing.

Colossus was built to help attack an encryption system which combined the plain-text message with a random-seeming key stream generated by twelve cam-edged wheels. A full brute-force search for the correct settings would be impossible, but the mathematician Bill Tutte realised that two of the wheels could be studied on their own, vastly cutting down the number of possibilities. Even with this insight, there were still far too many to test by hand.

A telephone engineer called Tommy Flowers designed a “computer” to automate the statistical part of the job: Colossus. Of course, very substantial human intelligence and hard work was required for the complete code-breaking task.

The starting point for the process was an intercepted message, and some incomplete knowledge about the key stream. Omitting the details, Colossus was then used as follows. It worked through the letters in the intercepted message, counting how often some chosen condition was true, under each possible setting for the two wheels involved. An unusually low or high number of places where the condition held meant that the tested possibility was likely to be correct. For those interested in the mathematics of this process, I have written out a worked example at redfrontdoor.org/Dickens-Teleprinter.

Today it is obvious that one could use a computer for this type of analysis. It is difficult to imagine the depth of vision needed to conceive of this idea, and bring it to reality, 75 years ago.

Field Programmable Gate Arrays

An FPGA is ‘programmable hardware’; it has a large number of simple logic elements, which can be configured by the programmer to implement special-purpose behaviour. An FPGA typically also has RAM, dedicated arithmetic logic, and so on.

As a self-teaching project, I thought it would be an interesting challenge to mimic enough of Colossus to perform the so-called ‘chi-wheel setting’ part of attacking an intercepted message, as outlined above. I chose XESS’s ‘XuLA2’ FPGA development board, based on its good documentation, and its free-software/open-source tool support. The host computer for the FPGA board was a Raspberry Pi.

The FPGA Colossus

The FPGA Colossus worked – it correctly performed the chi-wheel setting, using a design which I believe is close in spirit to the original. Source code is available at github.com/bennorth/fpga-colossus , where a more detailed description of the design can also be found.

The design included the following parts of Colossus: the punched paper tape, used as storage for the intercepted message; the cam wheels simulator, to perform the key-stream generation as in the originating encryption device; the stepping controller, to iterate through the candidate wheel settings; the Q panel, to describe the condition which Colossus looks for; the counters, for counting how often the condition holds; the comparator, to test whether the count is high (or low) enough to be ‘interesting’; and the printer, for recording promising settings.

I tried to mirror the original block-level design as closely as possible, as described in the General Report on Tunny. Of course, the FPGA has no physical punched tape or printer, and instead of switches and plugs, it has configuration settings which are sent to it by the host Raspberry Pi.

The actual logic (for example, testing for the chosen condition, or counting matches) was a fairly small part of the design. The scheduling, control, and synchronisation between the many components took some care; it would be very interesting to know the details of how the real Colossus did this.

The General Report on Tunny includes the following fact about how Colossus was developed: it was made a principle that the design of a new routine must include all the checks required, and in estimating the merits of a proposed routine the nature of the checks required had always to be taken into account. We see here that the importance of designing for testability was recognised right as electronic computers were being invented, certainly before software engineering was a discipline. I tried to heed this advice in the FPGA design, building in test facilities for all components.

In working on this project, I think I did get a tiny sense for the questions the original designers would have had to address. However, I was following established methods, building on reliable hardware; and I knew that the goal was possible. I had a modern computer and a comfortable working environment, and no lives depended on what I was doing. It is daunting to try to think about the magnitude of what was achieved by the original team.

Ben North Can be contacted at .

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.

Members of CCS who watched the ITV series “Grantchester” on Friday January 25^th 2019 were treated to a story of murder by mercury poisoning in the University of Cambridge Mathematical Laboratory, featuring as one of the key elements a fictional computer called “UNIAC”. If they watched through to the very end they would have seen a credit to myself and The National Museum of Computing (TNMoC).

Here’s the story behind the credit. The episode was written by John Jackson and produced by Richard Cookson of Kudos a major TV production company. Richard, who studied cybernetics at Reading University, was keen that the set for the Mathematical Laboratory and for the UNIAC be as authentic as possible to the 1956 setting. The Kudos art department contacted TNMoC in July 2018 asking if we could help them build a prop for UNIAC, borrowing equipment from our museum. We quickly explained that our machines from that period, EDSAC and WITCH, are too big to consider as loan items and invited them instead to come and visit.

Jason Carlin the Production Designer spent a morning at the museum inspecting EDSAC and WITCH and learning the operational aspects of such machines - paper tape input/output, teleprinters rather than screens and thermionic valves rather than transistors. Lots of photographs were taken, points of detail discussed and the history of the real Cambridge Maths Lab explored. Given the plot, EDSAC was the main focus and the engineering of the mercury delay lines in the original, since a leak from these was the source of the mercury that poisoned the victim. (A pedant might question how effective exposure to elemental mercury is as a murder weapon, but remember Grantchester is an entertainment not a documentary).

Overall the script was true to the 1956 setting, with mercury delay line memory as the murder weapon, but it was clear from discussion that there a few anachronisms and I was asked if I would be prepared to review the script to help improve authenticity. At this stage of the planning, UNIAC was described as a machine comprising “spinning cogs”, and “transistor boards” from which “an engineer covered in grease” would emerge at a key point. We resolved this by deciding UNIAC would be a hybrid computer comprising a war surplus Turing Bombe coupled to an EDSAC-like thermionic valve electronic computer and I lent a Pegasus circuit card as a prop. (As it turned out in the eventual episode the engineer remained clean, UNIAC became fully electronic and the prop wasn’t used). Like EDSAC, UNIAC read five-hole paper tape (through a mechanical reader built by Kudos’ props team, and output to a period Creed teleprinter).

Another challenge was the requirement for UNIAC to have a screen on which a love message from one of the protagonists to another could be displayed. EDSAC to the rescue – the production team adapted the concept of the Sandy Fraser’s noughts and crosses for EDSAC which displayed the game on the main store monitor CRTs and borrowing this concept UNIAC was able to display a graphic heart and short Latin text on a “screen”.

The set also featured blackboards covered in mathematical equations – the one that appears in close up is the Airy Integral, one of the first functions tabulated by EDSAC using a programme written by M.V. Wilkes.

There were several other nods to Cambridge and Maths Lab history in the plot. Those familiar with Cambridge Maths Lab history will have been pleased to see the fictional lab also had a green door, and the large department store featured in the episode is called Swinnerton’s, reminding us of Peter Swinnerton-Dyer a leading figure in Maths Lab history. And in addition to mathematical calculation, UNIAC was being used to run some “work for local businesses” specifically concerning “teashops” perhaps hinting at the relationship with the Lyons company and the genesis of LEO.

Another aspect of the plot revealed 1950’s attitudes to homosexuality – a tangled web of “modern relationships” provides the motive for the murder and several of the characters reveal the negative attitudes and discomfort people felt at the time about such. This of course echoes the fate of Alan Turing, who died in Manchester in 1954, two years before the Grantchester episode.

The episode was filmed in August 2018 and the production team kindly invited me to attend, but, unfortunately, I had to take my father for a medical appointment that day. The fictional Maths Lab was actually a disused BT telephone exchange in Hammersmith with large cabinets appropriately dressed with dials and switches as illustrated in the picture above. You’ll notice the art team decided to use images of WITCH dekatrons rather than EDSAC chassis for the valve bays. The love message was digitally painted on the orange screen during the post production stage.

In a curious connection, according to some of the staff in the building, they had been visited back in the 1950s by members of the Cambridge Maths Lab looking for spare parts they could use in the EDSAC machines. And, just a ten-minute walk down the road from the building is the site of the old Lyons Cadby Hall offices where a plaque states that LEO, developed from the EDSAC design and “the world’s first business computer” was put into use processing data more efficiently for the company.

The Granchester TV programmes draw on a series of novels by James Runcie, son of the late Archbishop of Canterbury. [ed.]

More on 1906S Extended Floating Point

Recent sleuthing by Bill Gallagher uncovered a new ICL document, TP4999. This has a good explanation of just how advanced the 1906S extended floating point system was when dealing with underflow. It also helped me remember what the 1906S hardware was getting wrong back in 1976!

Underflow is when an operation causes the exponent to go negative beyond the allowable range (-256 in 1900 terms). NOTE not just 1906S!

When underflow was detected a manufactured result floating point zero was returned.

The extended floating point unit provided a means of determining just how close to floating point zero the result was and, in this case, the set of additional nine bits is where this functionality was provided. They were not thought to be documented anywhere, but I knew they were used.

The design flaw in the 1906S hardware lost this functionality under certain rare conditions. It was easily fixed!

The mathematics of this functionality is very hard to understand unless you are a PHD and an actuary or a statistician!

The extended floating point unit hardware and software held data regarding this “almost floating point zero” result which then could be accessed, checked as to how close to zero the small resultant was, and action could then be taken by the programmer.

HM Tax Office used this to determine the standard deviation of vanishingly small numbers.

I suspect that modern technology which is a mix of software and hardware cannot delve so deeply into such small numbers and will happily deliver FPZero.

To test this, you need a supercomputer and a language like Mathematica.

Use this sort of program loop, z=x/y, make y larger by small amounts using DIFFICULT binary numbers and at some point, the result will be reported as zero.

A case of lost technology perhaps?

Unearthing LEO AND THE MANAGERS

Back in January 2017 I had an initial email discussion with Peter Byford on the possibility of formally re-printing, within the LEO Computers Society and the CCS Resurrection journal, the two diagrams of the LEO III master integrated strategic systems plan for the J. Lyons Company that John Simmons had developed for his 1962 book LEO AND THE MANAGERS, published by Macdonald, London. I had used them in my personal contribution to LEO Remembered, the memorial book for the later Peter Bird. Email discussions then followed for the remainder of the year with a number of colleagues across the BCS / LEO Computers Society / CCS Resurrection on the legal aspects of formally reprinting them, together with further full narrative extracts from John Simmons book, in the LEO Computers Society e-newsletter/website and the CCS Resurrection journal.

There was considerable debate, and differing points of view, about the legality of such an action. Peter Byford then attempted to trace the take-over history of Macdonald publishers and had “got lost” within the Hachette Group of companies in the USA! We both tried personal contacts in the States to follow through, but both of us got nowhere new.

Back in January 2018, not willing to be defeated in this quest, and having the time, energy and inclination to undertake the appropriate company heritage research on both sides of the Atlantic, I went back to basics and started again using forensic research techniques. Following being bounced electronically backwards and forwards many times across the Atlantic over a nine-month period with the USA Hachette Book Group (part of Hachette France) – I picked up a USA contact that led me to the UK based London offices of Little Brown publishers (a publishing company within Hachette UK – owned by Hachette France).

You can imagine my extreme surprise and great delight when I finally spoke to the Little Brown “Permissions Department” in London, and after explaining what I was seeking – I was advised that in their Little Brown company heritage records they were still holding the original contract from 1962 that the J. Lyons Company signed with Macdonald at the time the book was published. Whilst John Simmons held the copyright of the book, his employer the J. Lyons Company held the publishing rights, and it was these rights the LEO Computers Society were seeking.

So – another search commenced – and a “new” J. Lyons company was found – whose registration records went back to the original J. Lyons head office building address (Cadby Hall) which was the address on the original 1962 Little Macdonald (whose heritage contracts are now owned by Little Brown) publishing rights contract with the J. Lyons Company. Originally the purpose of this “new” J. Lyons Company was an investment holding company after the Allied Domecq acquisition in 2005, and finally a dormant company within the Pernod Ricard Group. Further heritage information on this new J. Lyons Company can be found at Companies House (beta.companieshouse.gov.uk/company/00040901).

In the Companies House records link above is a copy of the original J. Lyons Articles of Incorporation from the 10^th April 1894, along with copies of other heritage J. Lyons Company documents and annual accounts.

But – back to John Simmons’ book. Further investigative research identified a director of this dormant “J. Lyons Company” now a Pernod Ricard company – and also currently a director of Chivas Brothers – a Scottish distillery within the Pernod Ricard Group. Chivas Brothers has its headquarters in Paisley, near Glasgow, and operates 14 Scottish malt distilleries, all located in the Speyside area – apart from Scapa on Orkney – along with the Strathclyde Grain Distillery in Glasgow. It also owns gin distilleries in London and Plymouth, and blending, bottling and warehousing facilities at several sites across Scotland. In total the company employs 1,600 people at 34 locations. Contact was made, the transfer of the book’s publishing rights to the LEO Computers Society agreed, and the rest, as they say, is history.

There are two elements to the transfer of the book’s publishing rights and both of the transfer letters are now part of the LEO heritage with the LEO Computers Society formal records. The first is the transfer by Little Brown Publishing to the “new”, but now dormant, J. Lyons company – part of the Pernod Ricard group of companies, and the second is the onward transfer of the “Publishing Rights” from the dormant J. Lyons company to the LEO Computers Society.

More recently I have approached Little Brown Publishers and obtained a copy of the 1962 original publishing rights contract Macdonald Publishers had with J. Lyons for LEO AND THE MANAGERS to be deposited in the LEO Computers Society heritage archives.

A life in Computing

In 1958 Alan Sercombe joined a group of four or five young programmers at Armstrong Siddeley’s aero engine premises at Ansty near Coventry, where a Ferranti Mark I* had recently been installed. Here is Alan’s recruitment story, as he remembered it in 2016. [SL] –

The Mark 1* at Armstrong Siddley

I graduated in 1955 with an honours degree in Mathematics from Queen Mary College then, after a delay of some months, commenced two years National Service in December 1955. After training I spent 18 months in Singapore, returning home for demob at the end of November 1957. I spent my demob leave on job interviews. The most interesting offers were both as a computer programmer, one with Rolls Royce and the other with Armstrong Siddeley. The salaries were £12/5/0 and £15/5/0 per week respectively so I sent myself to Coventry!

I started in mid-January 1958 and the computer was fully operational at that time. It was located next to the Stress Office and the whole computer section reported to the Chief Stress Engineer [David Evans]. It was staffed by a Chief Programmer [David Atherley] and I made up a complement of four or five programmers. I think I was the last programmer to join the team. Also there were four maintenance engineers employed by the company not Ferranti. Eric Griffiths [the leading engineer] was a heavy smoker and the evidence of the late nights worked to keep the machine operational was the cigarette butts on the floor of the computer room in front of the cabinets they had worked on.

The computer had 13 Williams Tubes of main memory, five-hole paper tape input and output, a magnetic drum and a character printer (Teleprinter). Subsequently the Ferranti maintenance engineers installed three additional tubes of memory bringing it up to the maximum of 16 tubes. This was done to make it compatible with the Mark I* installed in the Royal Dutch Shell Group in Amsterdam.

As they weren’t ready to start my programmer training I was given a desk in the Stress Office to learn about calculating the stress profile of ‘vaned impellers’ of aero engines. The calculations were then being done on a manual comptometer and took a week. My first job was to replicate this with a computer program. I was also given a programming manual which I believe was written by another user, not Ferranti. Part of my training was to write and test subroutines to perform division and other mathematical functions including the trig functions. When I started there was a suite of such programs already installed which may have been imported from either Ferranti or another user or maybe written by David Atherley. My development was just a training exercise.

The programming room between the stress office and the computer room was along one side of the drawing office. As the programming room only held four, I was found a desk in front of the first row of draughtsmen. After moving there, I found developing the subroutines fairly straightforward but a complete program was more complicated. Handling input and output; transferring control within a program; absolute addresses; modifying a program, etc.

After finishing the program for the impeller stresses it took five minutes on the computer as opposed to one week manually. Even so, on one occasion when after several iterations the computer was not providing an acceptable stress profile, David Evans, definitely old school, sent it back for manual calculation – which was acceptable. Smiles all round in the stress office, but not from me. It took me a couple of weeks to point out the mistakes made by the manual operator, to get final agreement that the computer was correct. The only other program that I remember writing was to optimise the fuel mixture for the Black Knight rocket then being tested at Woomera [in South Australia].

It was some time in 1959 that it was announced that the Aero Engine Division of Armstrong Siddeley Motors was to be acquired by Bristol Aero Engines, with the likelihood that a move to Bristol would be on the cards. About the same time an advertisement for programmers for Standard Triumph’s LEO installation in Coventry caught my eye. I applied and was one of six who were successful. After four weeks LEO training, as the only one with previous programming experience, I was appointed senior programmer. That put an end to my time with the Mark 1*.

Taken from Simon Lavington’s forthcoming book Early Computing in Britain: Ferranti Ltd. and government funding, 1948 – 1958. which will tell the story of the Ferranti Mark 1* in great detail.

50 Years ago .... From the Pages of Computer Weekly

Computing to the Moon: Three American astronauts are now engaged high above the earth in the most complex series of manoeuvres ever carried out in space. In a period of ten days they will simulate, during the Apollo 9 mission, the major steps in space for a manned moon landing operation. The whole exercise will require the most intense collaboration of the astronauts, a massive ground support team, and a world-wide communications network. Computers will play a vital part in the process, both in the telemetry and communication of data, and in the computation of information vital to various aspects of the mission. (CW129 p8)

Printers now use PDP-8 for setting this paper: Readers probably haven’t noticed any difference in the way Computer Weekly has been printed during the last six months or so. We hope not, because during that period the type has been set and justified by computer. In August last year our printers, QB Ltd of Colchester, installed a small (4K) PDP-8. Within a week it was operational, and today the computer is used to produce more than half of the 250,000 lines of print that pour from QB every week. (CW130 p9)

Massive Concorde test project: The most elaborate computer controlled structural testing project ever developed is being prepared to test Concorde, and it is estimated that the Mintech will be spending about £600,000 on computers, monitoring equipment and systems and programming effort. Preparations for the project are well in hand at the Royal Aircraft Establishment, at Farnborough, and the ministry has reached agreement in principle with a consortium of three firms, Digital Equipment Corp, Kent Instruments Ltd, and Computer Analysts and Programmers Ltd, for hardware and software systems. (CW131 p1)

MRC PDP-9 to control scanning device: In transit from Santa Monica, California, and last heard of at Kennedy Airport, is a PDP-9 computer destined for the Medical Research Council in London. Research workers at the MRC will use the computer to control a device for scanning chromosome formations directly from microscope slides. The work makes use of sophisticated pattern recognition techniques developed over the past three years by Dr Denis Rutovitz, who up to now has been using a photograph scanning device known as FIDAC, linked with Imperial College’s IBM 7094 computer, which scans and digitises photographs taken through a microscope. (CW132 p24)

Tracing the Steps of the Ferranti Mark 1: One of the areas of computer research which has received considerable attention recently is the development of visual outputs which will provide a closer man/machine interface. There is nothing new even in this for one of the first computers developed in this country featured a visual display unit as its output. (CW134 p12)

Leo 1 – the story of a revolution in industry: In these days of micro-integrated circuitry and third generation computers with running speeds of less than one microsecond per byte, a machine composed of 7,000 thermionic valves and containing half a ton of mercury in its store is as far removed from a modern computer as a Model T Ford is from a present day Maserati. But although Leo 1 is now nothing more than a fond memory of its inventors and a collection of valves in the Science Museum its story, like that of the horseless carriage, is the story of a revolution. (CW136 p8)

DEC adds to PDP range: A new addition to its range of low-cost scientific computers is announced by DEC this week. Costing £8,300 for a basic system, the PDP-15 is a medium scale machine with an 18-bit word length and a memory cycle time of 800 nanoseconds in the high-speed memory version. The new computer is being offered in four basic configurations, each upwards expandable and complete with software and peripherals. Prices range from £8,300 for the PDP-15/10, with 4K store and teletype, up to £46,000 for the PDP-15/40. (CW137 p20)

Stock Exchange to opt for two 1904s: Instead of the twin ICL 1902A configuration, which was planned to be employed as two central processors back-to-back, the Stock Exchange Council is understood to be opting for two 1904A computers for its inter-company accounting service. This massive systems upgrading places the whole project on a much broader footing, with one of the 1904A computers operating in real time mode and the other, with a smaller core capacity, providing batch processing and a stand-by facility to the real time system. (CW138 p20)

Software conversion for Decimal Day: On D-day (Decimalisation Day), which is set for February 15, 1971, the United Kingdom starts its changeover to decimal coinage. The pound sterling will be divided into 100 new pence, instead of 20 shillings, each of 12 pence. Most computer installations in the country, if not all, will be affected by this change in currency. Although the computer manufacturers have been aware for some time of the problems involved in software conversion, apparently few users realise that there is little time left to plan for D-day and users will have a significant amount of work to do. (CW141 p10)

Forthcoming Events

London Seminar Programme

London meetings take place at the BCS in Southampton Street, Covent Garden starting at 14:30. Southampton Street is immediately south of (downhill from) Covent Garden market. The door can be found under an ornate Victorian clock.

You are strongly advised to use the BCS event booking service to reserve a place at CCS London seminars. Web links can be found at www.computerconservationsociety.org/lecture.htm .

For queries about London meetings please contact Roger Johnson at .

Manchester Seminar Programme

North West Group meetings take place take place at Manchester Metropolitan University: 17:00 for 17:30.

For queries about Manchester meetings please contact Alan Pickwick at

Details are subject to change. Members wishing to attend any meeting are advised to check the events page on the Society website at www.computerconservationsociety.org/lecture.htm.

Museums

SIM : Demonstrations of the replica Small-Scale Experimental Machine at the Science and Industry Musuem in Manchester are run every Tuesday, Wednesday, Thursday and Sunday between 12:00 and 14:00. Admission is free. See www.scienceandindustrymuseum.org.uk for more details.

Bletchley Park : daily. Exhibition of wartime code-breaking equipment and procedures, plus tours of the wartime buildings. Go to www.bletchleypark.org.uk to check details of times, admission charges and special events.

The National Museum of Computing Colossus Galleries open daily 10.30-17.00; full Museum open Thursday, Saturday and Sunday 12.00-17.00.

Situated on the Bletchley Park campus, TNMoC covers the development of computing from the “rebuilt” Turing Bombe and Colossus codebreaking machines via the Harwell Dekatron (the world’s oldest working computer) to the present day. From ICL mainframes to hand-held computers.

Please note that TNMoC is independent of Bletchley Park Trust and there is a separate admission charge. Visitors do not need to visit Bletchley Park Trust to visit TNMoC. See www.tnmoc.org for more details.

Science Museum : There is an excellent display of computing and mathematics machines on the second floor. The Information Age gallery explores “Six Networks which Changed the World” and includes a CDC 6600 computer and its Russian equivalent, the BESM-6 as well as Pilot ACE, arguably the world’s third oldest surviving computer.

The new Mathematics Gallery has the Elliott 401 and the Julius Totalisator, both of which were the subject of CCS projects in years past, and much else besides.

Other galleries include displays of ICT card-sorters and Cray supercomputers. Admission is free. See www.sciencemuseum.org.uk for more details.

Other Museums : At www.computerconservationsociety.org/museums.htm can be found brief descriptions of various UK computing museums which may be of interest to members.

Computer Conservation Society

Aims and objectives

The Computer Conservation Society (CCS) is a co-operative venture between BCS, The Chartered Institute for IT; the Science Museum of London; and the Museum of Science and Industry (MSI) in Manchester.

The CCS was constituted in September 1989 as a Specialist Group of the British Computer Society (BCS). It thus is covered by the Royal Charter and charitable status of BCS.

The aims of the CCS are to

• To promote the conservation of historic computers and to identify existing computers which may need to be archived in the future
• To develop awareness of the importance of historic computers
• To develop expertise in the conservation and restoration of historic computers,
• To represent the interests of Computer Conservation Society members with other bodies,
• To promote the study of historic computers, their use and the history of the computer industry,
• To publish information of relevance to these objectives for the information of Computer Conservation Society members and the wider public.

Membership is open to anyone interested in computer conservation and the history of computing.

The CCS is funded and supported by voluntary subscriptions from members, a grant from BCS, fees from corporate membership, donations, and by the free use of the facilities of our founding museums. Some charges may be made for publications and attendance at seminars and conferences.

There are a number of active Projects on specific computer restorations and early computer technologies and software. Younger people are especially encouraged to take part in order to achieve skills transfer.

The CCS also enjoys a close relationship with the National Museum of Computing.