Software — David Holdsworth

Kidsgrove Algol

There have been various improvements to David Huxtable’s brick 20 (the most indispensable missing component), and we can now compile quite a variety of ALGOL 60 programs. Not only that, we can also run them, using our rather rudimentary run-time system and library of standard functions.

A signifcant part of our development has relied on reverse engineering other missing material, especially the POST system’s PANACEA module which provides the API to magnetic tape and which is essential for the Kidsgrove compiler. This development has involved putting specifc facilities into my own emulator. This means that the compiler will not run on any other emulator. I have constructed equivalent facilities using KDF9 code, and we now have a version that will generate KDF9 Usercode and will run on any KDF9 emulator – or even a real KDF9. The plan is to use Bill Findlay’s emulator ee9, which we also use for our Whetstone Algol facility (settle.ddns.net). At present our code is proving to be quite a good test program for ee9.

We do not have brick 84, the Usercode compiler for use with POST. Hitherto we have used my own assembler for converting the compiler output to KDF9 binary code. A few months ago. Brian Wichmann discovered a listing of the Paper Tape Usercode Compiler in the Science Museum archives, and now we have this operational. It always had a flaky reputation (deserved).

It remains to produce a better engineered integration of this last phase of the compilation, and further experiments are necessary to determine the best way to do this. A further area of imperfection is our somewhat Heath-Robinson means for incorporating the library routines and the run-time system.

Brian Wichmann still has his ALGOL 60 test suite, and he is keen to try it with our resurrected Kidsgrove Compiler.

There is a little demonstration at: settle.ddns.net/KDF9/kalgol/DavidHo/demo.zip.

Analytical Engine — Doron Swade

Excellent progress on the database of the Babbage technical archive. Tim Robinson in the US has produced a searchable database of all catalogued material with related content fully cross-referenced. Each item links directly to the corresponding Science Museum catalogue entry and to the recently available (low resolution) online scans of the originals. This work covers all technical drawings and related Notations (there are some 2,200 Notations for the Analytical Engine). A small amount of material that is known to exist but is not yet in the Science Museum catalogue remains yet to be done.

Back in London I have completed a Quick Index of the 26 volumes of Babbage’s Scribbling Books – Babbage’s scratchpad daybooks. The Index identifies all material specifically relating to the Mechanical Notation, Babbage’s language of signs and symbols that he used to describe and specify his engines. The Scribbling Books comprise 8,100 folio sides each of which has been examined for relevant content. The Quick Index is a retrieval and navigation tool to support ongoing research into the notational language with a view to further decoding the Analytical Engine designs.

It is thought to be only the third time in history that the set of Scribbling Books has been gone through in their entirety. The only known precedents for this are the work of the late Bruce Collier and the late Allan Bromley in the 1960s and 70s.

The next step on the main database is to go systematically through the Scribbling Books, extract all cross references, tag subject content and transcribe significant material. This process is expected to be completed by the end of the year. Material already transcribed for the Notation Quick Index will be directly imported.

North West Group contact details

Chairman  Tom Hinchliffe:  Tel: 01663 765040.
Email:  
Secretary  Gordon Adshead  Tel: 01625 549770.
Email:  

EDSAC Replica – — Andrew Herbert

The major item to report is the adoption of a new design for flip-flop circuits in certain areas of the machine. These circuits have been problematic since the outset of the project. In the EDSAC Report there is a circuit diagram labelled “Flip-Flop” but it shows no values for the RC components, and finding a set of values that would give the behaviour of the modern understanding of a flip-flop eluded us. Eventually the penny dropped that the circuit is actually a monostable with a set/reset facility – the monostable being tuned in each situation to hold a value for as long as it is required by the logic to which it belongs. This interpretation of the circuit was later confirmed in the cache of EDSAC circuit diagrams donated to us by John Loker, a former Mathematical Laboratory engineer. In most places the monostable design has worked reasonably well. But in Main Control it has been a different story: this unit has to retain the bits of an order throughout its execution – and for I/O, shift and multiply this can be a very long time. Setting component values suitable for this period gives a circuit that is slow to set and reset and thus the flip-flop cannot be clocked at the rate of the fastest instructions, leading to errors. The main control team, James Barr, Tom Toth and Simon Kelley, have wrestled with this problem for almost 12 months and we have finally given up and decided to adopt a bistable circuit more like a modern flip-flop. We know from the Loker drawings that the EDSAC pioneers had moved to a bistable circuit later in the life of the machine, but we had assumed this was much later than our target of the 1949-51 EDSAC. However from some of the documentary sources and closer inspection of the photographs of the original machine we have convinced ourselves that they experienced the same issues as ourselves and put in bistables as early as 1951.

The other item of note is that we are now gradually introducing the nickel delay lines made by Peter Linington into the machine, replacing Nigel Bennée’s “Digital Tank Emulators” used up until now to simulate the delay line stores. So far just the Counter register (in the Coincidence Unit) has been connected to its (short) delay line and shown to be satisfactory. The remainder of the short delay lines will be connected as and when the coffin to hold them is ready to do so, and this is imminent. The large coffin was put in place at the back of the machine earlier this week and a start made by Peter Linington and Andrew Herbert installing the internal racking needed to hold the delay lines in their “pizza box” receptacle.

Progress has been made in other areas: Martin Evans has a working paper tape reader electronics chassis and all the Storage Regeneration Units (chassis 01) have been updated to the latest revision and thoroughly tested. Most of the coaxial cabling for connecting these units to the delay lines has been put in place. The entire arithmetic unit has been moved from Nigel Bennée’s laboratory in Cambridge to TNMoC and is being recommissioned ready for hooking up to Main Control.

Our hope is for a big step forward once the monostables in Main Control are replaced by bistables: we should be able to demonstrate a working order fetch, decode and execute cycle and from that test each of the 18 EDSAC orders in turn.

Items still to be completed include the electronics part of the Initial Orders unit, the Operators’ Desk, the Clock Monitor unit, the electronics part of the printer interface and three rack-mounted power units to support the new bistable design (which have hitherto been inexplicable in the photographs).

A project yet to be started is the design of a photoelectric reader to match that on the 1951 EDSAC. If there is a volunteer who wants to take this on the project manager would be very pleased to hear from them.

Turing Bombe — John Harper

The challenge from the Heinz Nixdorf Museum in Paderborn went off extremely well. We broke their messages after finding the key of the day in good time but after first having detected one error in the original transmission. Publicity of this activity and good results led to very wide media coverage in Germany.

We also intercepted their radio transmissions using WWII equipment at both ends. There were transmission difficulties that were to be expected with the airwaves so busy compared with the 1940s but later in the day we did recover a valid intercept. Because there was doubt over this radio reception we first worked on an intercept obtained by modern methods but had the day been longer we would have succeeded using an ‘over the air’ intercept.

This July will mark 10 years since our machine was officially switched on by HRH the Duke of Kent. We are currently forming up ideas as to how best to celebrate this.

Harwell Dekatron/WITCH — Delwyn Holroyd

The machine has settled down again after the various problems reported last time, and has been giving good service.

Some improvements have been made around the display area: additional emergency stop buttons have been fitted, the work lights behind the machine have been repaired, the media player has been replaced and is now powered from the same switched circuit as the rest of the AV equipment instead of the machine supply controlled by the contactor

ICL 2966 — Delwyn Holroyd

All the terminals are now working again after an extended period of problems.

The fault on the 7501’s original scan board was traced to a dry joint on a resistor mounted on the line output transformer. The fault manifested by the display image shaking violently left to right, but in a curious wavy pattern. The purpose of the RC circuit to which the resistor belongs is to damp unwanted harmonics, so now we know what those harmonics look like when undamped! Meanwhile, the scan board from the left hand SCP that had been in use in the 7501 also failed with a high-voltage electrolytic capacitor going up in smoke. I decided to replace several such capacitors on both scan boards pre-emptively to ward off further trouble. An unexpected bonus has been a marked improvement in horizontal scan stability. The left hand SCP has now been re-united with its scan board and adjusted.

The right hand SCP display has been getting progressively dimmer over the last few years, and is now only just visible. The problem is the CRT itself, but remarkably I have been able to obtain a new (old stock) one of the correct type. We will most likely wait until the display becomes unusable before fitting it.

One of the 7181 terminals has been suffering from an intermittent collapse of the jiggle scan (the up and down scan used to trace out the characters on each line, distinct from the main vertical step scan). There are not many components involved and a couple of solder joints in the area looked suspect so I cleaned and resoldered all the likely culprits. This seems to have cured the trouble.

Elliott 903 — Terry Froggatt

There are three 250 char/sec paper tape readers available for use on the Elliott 903 at TNMoC, but they have all had problems. I recently had the opportunity to fit one of my own tape readers to the 903, and to bring TNMoC’s three readers home for some TLC.

Reader 2697 is the one which came with the 903. When this was being cleaned up, shortly after it arrived at TNMoC, one of the fixed pegs which guide the tape was sheared, leaving a length of 8BA thread buried in the tape plate. The reader still worked, but the tape was prone to wander, causing misreads. I’d found a replacement peg some time ago, cannibalised from a scrap reader, but getting the sheared thread out of the tape plate presented me with a problem. Someone suggested spark erosion, so I asked about this at my local engineering firm, who told me that there was a very helpful firm in Woking with the right equipment. Arriving there without warning, with the tape plate in my hand, I said “I’m told you are very helpful, this is from a 50-year old computer at Bletchley Park, can you help?” and they did. So special thanks are due to DELEN Tooling near Woking, for well over an hour’s use of one of their spark erosion machines. Once home, I dismantled the adjustable guide pegs to get the cooling water out, then I fitted the fixed guide peg and a capstan guard cover from the scrap reader. There’s no wander in the tape now.

Reader 6273 is generally viewed as a spare reader. It lacks the base cover, the capstan guard, and a retaining nut on one of the switches, also it does not have a suppressor. I had to soak one adjustable tape guide in WD40 overnight before I could adjust it. But the main problem with this reader was lack of thrust: it was not gripping the tape very well. I noticed that the 240 volt motor wiring was in modern mains colours, of brown and blue, suggesting that this motor had been rewired. This would have involved removing the motor and disturbing the gap between the capstan (on the motor shaft) and the pinch roller (on the clutch solenoid). I adjusted the pinch roller to reduce the gap, which improved the grip to the extent that I then needed to tighten up the brake friction pad. Another problem with this reader was that the car fog lamp would occasionally briefly go out. It had been suggested that this was caused by the lamp top contact solder melting when it was hot, but I’ve seen the lamp go out whilst it was still quite cool. I think it more likely that a worn screw thread in the fibre post which supports the contact spring was limiting the contact pressure. I’ve replaced the contact spring by a wire soldered onto the lamp cap directly.

Reader 8137 is the one which came with the 905. The 905 itself is currently in store in Bilton Road. The reader was quite clean inside, but the tape moved as long as you pressed READ, instead of stopping on the next sprocket hole. Initially I suspected a broken microswitch or a faulty photocell, but the problem was actually a badly adjusted amplifier on the sprocket track. Luckily the amplifier still had enough adjustment left to bring it back into range.

So reader 2697 is now back on the TNMoC 903, reader 8137 is available for the TNMoC 905, reader 6273 is available as a spare with some missing bits, and all three are now working.

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

We are still progressing on multiple fronts, juggling different sub-projects. Since the last update we have continued with MAXIMOP (Brian), 1830 General Purpose Visual Display Unit (Bill) and ICL 1904S (Bill and Brian).

MAXIMOP

More testing still required along with further documentation.

PLASYD

Currently on hold, no further progress. The compiler as found works under E6RM executive and GEORGE3 and correctly emits semi-compiled for GEORGE 4 paged environment as appropriate. We do not have the original runtime library (S-PL), but it has been possible to use the compiler to create utility programs.

BCPL

Still awaiting investigation. It has been possible to compile some of the sources found on the same magnetic tape. We have source for the front end of the compiler and thanks to Dik, a BCPL manual is now available, but it is more a language teaching/reference manual and does not give any operational information.

ICT 1830 General Purpose Visual Display Unit

An emulation is under development, but still not working correctly. Lack of understanding of how this device worked, in particular the fraction modes being the main problem with creating an easily usable emulation. We still need information on this device.

ICL 1904S

The 1904S emulation has had some improvements to the operation of the basic peripherals, a set of Windows programs is now under final (we hope) test, providing a simple GUI based set of tools for the basic peripherals (TR, TP, LP, CR, CP and GP). This along with similar GUI tools for the EDS8 discs and ½” magnetic tape should, with time permitting, allow easier and more realistic use of the emulators.

IBM Group — Peter Short

An avid collector of all things IBM has donated a huge number of manuals, sales material, newspapers, magazines and company reports going back to the 1920s. A star of the manuals collection is a pristine 305 RAMAC manual that she says cost £500 on eBay some years ago! Also included in the donation is a battery driven scale model of the IBM 705 operators’ console and a tape drive. The original 1960s Ever Ready leak-proof batteries, long dead, really haven’t leaked. Fitted with new batteries the console lights flash.

The model was presented by IBM to General Lyman Lemnitzer in 1960, we believe as an acknowledgement of the hard work he put in to adopt the 705 into the US military. We also have photographs and books about General Lemnitzer. This will make an excellent addition to the RAPC display in the museum.

The same collector has also promised us some of her hardware, including PCs, PS/2s and a US 115v volt DisplayWriter system.

We have also received a selection of CE tools, a box of Selectric golf balls and a dictating machine.

CCS April Meeting in London

Apologies to members who were expecting to hear Rod Brown tell us all about the ICT 1301. With a week to go, Rod had to withdraw from the engagement. Our gallant events secretary Kevin Murrell, despite having a proper job to keep him busy, not to mention his role as a leading light at TNMoC, was quick off the mark and in less than 24 hours had lined up Ben Trethowan who, in the short time available, somehow managed to put together a fascinating presentation on the former London air traffic control system, now resident at TNMoC. Well done to both of them!

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.

New member Rodney Hills reminds us (to be fair, I didn’t actually know) that 2017 marks the 50^th anniversary of the first GCE A-Level in Computing. His alma mater, the Royal Liberty School in Essex claims to have been the first school in Europe to install an electronic computer (an Elliott 903) in 1965. Can anybody outbid him?

101010101

The CCS website editor has been remiss in failing to provide any facility whatsoever to allow members to update their details. Aside from the facility to join as a non-BCS member there has been nothing. Knuckles having been rapped, this deficiency has now been eliminated. At www.computerconservationsociety.org/membership/membership_general.htm you will find instructions and links to enable you to join the Society, change your details or resign (if you really must).

101010101

In June one of only five surviving examples of a Mircal N, the “first microcomputer marketed in the world” went up for auction at Artigny Castle in France. Launched in 1974 some two years before the Apple I and seven years before the IBM PC, it went for €50,000.

Programming the ENIAC and Electronic Analogue Computers

The Heinz Nixdorf MuseumsForum (HNF) in Paderborn (Germany) has made an ENIAC demonstration rack that allows the visitor to plug cables in order to get a feeling of programming the ENIAC. It has raised the question how programming the ENIAC by plugging cables compares to programming electronic analogue computers.

As I had been signifcantly involved in the design of the HNF’s ENIAC mockup (see rclab.de/rclab/eniac/), and have some working knowledge on electronic analogue computers, I’ll give my personal view on this question here.

Programming the ENIAC

The HNF’s ENIAC mockup is – with good reason – a drastically reduced model for the ENIAC. In particular, it just allows us to program the data path, which is the less complex upper part with the data buses, called digit trays. When presenting this object, it would be absolutely necessary to tell the visitor that reconnecting plugs during a calculation was not part of programming the ENIAC. The mockup was so designed that calculating the Fibonacci numbers as well as the other examples do not require changing plugs, even to set the initial values. Running the program just requires to operate the switches in a correct sequence. So here is an important message to the visitors: That the original ENIAC – in its lower part – had an extensive mechanism to electronically control the switches, and that this part has not been added to keep the device simple to use.

Moreover, the real complexity of programming the ENIAC is setting up the lower part, and the ENIAC is fairly useless without such an extensive control path. Note that the ENIAC basically used a token passing control, and was not a finite state machine. Moreover, it soon became clear that it would be a great enhancement if programming could be done without setting plugs. And thus the function generators were re-used as mPROM (manually Programmable Read-Only Memory) to contain instructions like in any other stored-program computer where the program memory cannot be changed while a program is executing. So it is essential to distinguish the data path and the control path, and that the latter was used in the ENIAC to change the data path dynamically, which is common to all digital computers. Thus, from a scientific point of view, the second proposal of mine (see drawing above) should have been selected, which contains a – still very rudimentary – control system.

Programming an electronic analogue computer

Demonstrating electronic analogue computing, as is done in at the National Museum Of Computing (TNMoC), starts by explaining that electric voltages can be used to calculate simple arithmetic, in particular to do an addition. (If the scales were labelled logarithmically like in the common slide rule, it could be used to multiply, but no longer to add.) If a demonstrator is provided with plugs to connect several computing amplifiers, more complex equations can be calculated. Again, this is the data path that is plugged, and no control path is used.

This changes slightly if integrating amplifiers are used to solve differential equations, because these have to be initialised, which is the basic control path for analogue computers. Most commercial analogue computers had additional control paths, in particular the input to a computing amplifier could be disabled. The most basic of such features can distinguish negative from positive voltages and accordingly switch inputs on or off Soon there were also hybrid species, that had a simple digital section with a few gates and flip-flops to control the computing elements.

Note that analogue computing is highly parallel, as all computing amplifiers work continuously, while digital computing in general advances by time-multiplexing basic elements.

A famous example that uses a control path is the frst interactive video game, Tennis for Two (a.k.a. Pong). Here, the control path is essential to change the configuration if a player acts. Note that reflecting a ball at a wall can be done both with data path only (provided that there are appropriate non-linear units), or with control path units. See also my examples atrclab.de/rclab/analogrechner/.

This said, an analogue computing demonstration could well be done without a control exceeding the initialisation of integration amplifiers, although more advanced examples require a simple control, but not even a finite state machine.

Conclusion

Any serious computing requires a means to dynamically change the data path; this is the essence of programming a computer.

It was evident very early that stored-program control was much more efficient to handle than a plugboard determined control path. (Even Babbage with his Analytical Engine planned a more flexible way to program his machine.) On the contrary, analogue computing never had a demand for an extensive and flexible control path, and thus stuck to the plugboard – which finally contributed to their final decline.

Rainer Glaschick is a senior volunteer at the Heinz Nixdorf MuseumsForum in Paderborn, Germany. He can be contacted at

Minature Bricks : CCS Visit to the Deutches Museum, Munich

It seems to be becoming an annual custom for a selection of CCS members to visit a faraway land; in search of museums to peruse for their computing collections and, perhaps, local restaurants to sample for their wares. This year’s destination was Munich, the capital of Bavaria, and home to the Deutsches Museum; one of the world’s oldest museums of science and technology. With some members arriving on a rather dismal Friday evening, only to discover that Munich International Airport is some 30 miles away from the city centre, we set off in search of our first priority. Supper!

Following a hasty check-in at hotels we headed straight for ‘Wirtshaus in der Au’; a Bavarian restaurant and supplier of our supper, beverages and entertainment for the evening. With the restaurant staff dressed in traditional Bavarian clothing, and steins of Weißbier having been distributed amongst our group, we indulged in an evening of social chatter interspersed with delicious food. A small group decided to order possibly the largest dessert platter known to man, so grand in fact that it required its own staff escort complete with tolling bell to warn of its approach. Anyway, I digress.

We awoke on Saturday to prepare for the main event, our visit to the Deutsches Museum. The building makes an impressive, if stark, first impression. With an exhibition space of 66,000 square metres, it is one of the largest science and technology museums in Europe. As a museum of national significance, it is supported financially by both the state and federal government and is currently undergoing an extensive refurbishment. Whilst this meant that we had to purchase our tickets from a smart Portakabin outside the building, there were not yet any noticeable impacts to the exhibitions themselves.

Once inside, we were met by our guide, Wolfram Wach. We were also delighted to be accompanied by the curator for computer science, mathematics and cryptology at the museum, Anja Teuner. Our first stop was Oceanography. Wolfram explained that whilst the museum has dedicated exhibitions of computing and microelectronics, they also like to demonstrate specific applications by placing relevant artefacts in other galleries. The artefact of interest here was an electromechanical analogue computer used for tidal prediction. Used from 1935 – 1939, it was a direct translation of a prediction algorithm into hardware, calculating the times of high and low tide mechanically.

We then moved on to the Machine Tools exhibition, a short walk away from Oceanography. Here, our focus was on modern machine tools and computer-controlled manufacturing. This large gallery space contained several modern CNC tools, as well as a small automated manufacturing line, all of which were connected to a gallery-wide power system. This implied that the artefacts were operable and Wolfram confirmed this, stating that it was museum policy to have artefacts in an operable state where possible, with demonstrations of many taking place regularly. We huddled around a Spinner SB-CNC Tool Making Machine, for a discussion on the development of 3D Printing and how such technology was making the bespoke production of everything, from shoes to mobile phone covers, more accessible.

The Violina. (Also see video at www.youtube.com/watch?v=gKaqigwV2aE)

With time marching on we pressed ahead, via Pharmaceuticals, to Musical Instruments. The Phonoliszt Violina, a music automaton, was a spectacle to behold and demonstrated to us in working order having been restored by volunteers and staff. Purely mechanical, the Violina uses air pressure to detect punched holes in a rolling sheet of paper that determine which note is played, when and by what instrument.

A modern equivalent was also demonstrated, a Yamaha acoustic piano complete with optical scanning bar, which detects and records the positions of the keys as they’re played. One of our group played a small ditty, to great applause, whilst the device was recording. This was then played back by electromechanical movement of the keys themselves, rather than mere digital audio.

Whilst en route to our next exhibition, Wolfram paused to impart some of the museum’s philosophy and explain what it considers its purpose to be. The museum sees itself as a champion for technological change, playing a vital role in reassuring the public that such change is a good thing, even though it may reduce employment in traditional sectors such as manufacturing and services, etc. He made the point that technology creates jobs too and that the economy, rather than just disposing of traditional sectors, is instead transitioning from ‘service-driven’ to ‘knowledge-driven’. It is certainly admirable that the museum seeks to reassure the public regarding such change, as well as promote and educate.

The model brick factory

With the Computing and Microelectronics exhibitions in sight, we stopped off in Ceramics to marvel at an automated mini brick factory. A fully operable scale model of a brick manufacturing plant, it is controlled by a Siemens industrial automation system. Whilst there, Wolfram referred to the Stuxnet virus, which targeted industrial automation systems specifically, highlighting the ever-increasing relevance of Cyber Security in a technologically enabled world.

Our final stops were the Computing and Microelectronics exhibitions. Starting with mechanical calculators, we moved past slide rules and abacuses towards the wartime cryptography exhibit. On approach, Wolfram said that this exhibit contained their most popular artefact, an Enigma machine. Whilst many of our members are already familiar with the Enigma, the exhibit did contain one item of particular interest; a rotor cassette for a Lorenz SZ42 cipher machine. Moving on, we paused at the Zuse Z4, which used cinema film for punched tape due to its durability and availability at the time.

Univac I

Moving past the imposing Remington-Rand UNIVAC I Factronic, we arrived at an IBM 360/20. Wolfram stated that IBM had invested 3 years’ worth of profits into the development of the 360, betting everything on the fact that they would be needed for the American space programme. That bet did, of course, pay off.

Dan Hayton rests on an IBM 360/20

Beside the 360 was a 1975 Cray-1 Supercomputer. Wolfram said that this had been gifted to the museum by the German Federal Intelligence Service, the Bundesnachrichtendienst (BND). Whilst we could only speculate on its previous life, I’m sure cryptanalysis was at the forefront of our minds.

Having left the ‘big iron’ behind, we turned a corner to move through some smaller exhibits showing computer games and early home computers such as the Apple II and Sinclair ZX81, etc. Ascending to mezzanine level, we arrived in a section of the gallery devoted to Microelectronics. Mobile telephony was particularly emphasised here, with a modern 4G antenna mast on display. A small exhibit on the development of integrated circuits also caught our attention, with related artefacts including a complete section of a semiconductor device fabrication plant.

Having brought the tour to a close, we were then free to explore the other exhibitions at our leisure. A few of us glimpsed the Astronomy and Geodesy galleries, before deciding that we were exhausted and therefore entitled to return to our hotels in anticipation of our evening meal. With a quick visit to the museum shop, which contained some interesting items, we concluded our thoroughly enjoyable visit. I’d like to thank Rachel Burnett for the notes she made during the tour, without which I wouldn’t have been able to write this report.

Ben Trethowan is a senior volunteer at TNMoC where he has a particular interest in the DEC-based air traffic control systems there. Contact is at . Photos and video courtesy of Brian Spoor.

A Personal Memoir

As a small child in the immediate post-World War II period, I had never heard of computers. But I had heard of the “Atom Scientists”, and I wanted to be one! Many years later, I took a degree in Physics, graduating from Southampton University in 1964. But, by that time, I’d had enough of studying and wanted to see the world so I went off teach in Uganda under the VSO (Voluntary Service Overseas) programme sponsored by the British Council.

After a brilliant year of adventures, I returned to Southampton in 1965 as a research student. On the first day of my new studentship, I was shown to a room housing a newly acquired PDP-8 and told “find out how it works – we need to write some programs”! The only programming I’d done to that point was a short course on Autocode using the university’s valve-based Ferranti Pegasus computer, which occupied its own building. The PDP-8 was transistorised and a bit smaller than a washing machine, and only the third computer on the campus – very exciting! I was a member of a small Particle Physics research group which had links to the Cyclotron Laboratory at AERE (Atomic Energy Research Establishment) at Harwell, which could run at energies up to 150 MEV (Mega Electron Volts) and the adjacent RHEL (Rutherford High Energy Laboratory) at Chilton, where a new 2 GEV (Giga Electron Volts) Synchrocyclotron known as “Nimrod” was nearing completion. (Compare that with today’s 10 TEV LHC at CERN!) We planned to run experiments at both labs, collaborating with a larger research group from Imperial College, London for the RHEL experiment.

Like any classic accelerator experiment these involved smashing a beam of particles into a target and seeing what happened. Usually, each incoming particle would produce one or more outgoing particles which could be detected using a scintillation counter: a sheet of plastic which emitted a tiny flash of light that could be detected by a photomultiplier tube. The output from the tube was an electronic voltage pulse which could be counted or measured, or fed into a computer.

Accelerator time is very expensive, and the results of accelerator experiments are based on statistics, so a great deal of attention is paid to how quickly each experiment can collect sufficient data to provide statistically significant results. This means that automatic methods of data collection are essential for success.

Why Computers in Physics?

Up to that time, many physics labs had used a popular piece of equipment known as a multi-channel pulse height analyser – essentially an analogue-to-digital converter plus, typically, a 4K memory. The converter digitised each voltage pulse and used that number to increment a location (or “channel”) in memory. At the end of an experimental run, the analyser’s memory would contain a histogram of the number of detected particles vs. particle energy (given by pulse height), which would show whether any peaks (corresponding to particles with a specific energy) had been detected.

The main cost in an analyser was memory, which was still very expensive, and physicists soon noticed that you could buy a minicomputer for around £6,000: not much more than the cost of an analyser. Writing a program to re-produce the histogram would be simple and everyone assumed that other programming tasks would be equally easy.

The Southampton PDP-8 was a very early model (I think it had serial no. 004), equipped with 4K ferrite core memory, a 7-track 2,400 foot tape system and, later, a 32K word disc. It was reputed to be the first one installed in Europe, but it wasn’t very reliable! Of the first 1,000 hours running time, around 700 hours were used by DEC engineers in various forms of corrective maintenance. And because other labs were waiting for their machines to be delivered, we frequently received visitors who wanted to test their programs. We would often see one of them get to his feet, after some hours at the console, with a cry of “The machine’s not working again!”. Occasionally, that was true but more often it wasn’t. We were all learning about debugging the hard way so we set up a notice with the immortal words “When all else fails, try reading the instruction manual”!

TV Cameras and Computer Graphics

We wanted to do more than simply count particles. We also wanted to measure the angle at which each particle bounced off the target and its energy. The technology which enabled us to do that was known as a “spark chamber”: a sandwich of aluminium plates enclosing Argon gas, with a high voltage applied to adjacent plates. When a charged particle passed through the chamber it left an ionised track where a spark would form when the voltage was applied. Viewed from the edge of the sandwich, the track could be clearly seen, or photographed. Past practice had been to record a sequence of images with a film camera and then measure each frame by hand.

We decided to use a 625 line CCTV (Closed Circuit Television) camera instead and built special purpose interface logic which could measure the image and dump the resulting data into the PDP-8 using its DMA (Direct Memory Access) feature. Once in memory, the data could then be logged to magnetic tape and displayed on an oscilloscope using additional logic which plotted a 1024 × 1024 pixel display. Computer-based imaging is commonplace now but, back then, it was cutting edge – even though the images were simply white lines on a black background! An initial pulse from a scintillation counter behind the target indicated that a particle interaction had occurred, and this triggered the operation of both the spark chamber and the TV camera interface logic which, in turn, triggered an interrupt in the PDP-8. This caused the execution of an interrupt routine which had to identify the source of the interrupt and then initiate the appropriate data logging and/or display routine. The programming involved was quite unlike the FORTRAN programming which most physicists had been trained for, and it dawned on us that we had stumbled into the world of real time systems!

Real Time Operating System

In the 1960s, real time systems were found in military and space projects, industrial process control applications, and airline reservation systems. Hardly anything had been written about how to design them and the only book I could find was James Martin’s Programming Real Time Computer Systems (1965). But that provided enough information to show that we would need to write a “suite of supervisory programs” which could support the specific application programs needed for multiple experiments and different kinds of outputs. Another step in learning led to realisation that we would need a real time operating system which could support the application programs which would “produce the answer before you have lost interest in the question”! Our questions were “How can we run the required program when needed?” and “How do we log approximately 500 words of data in less than 15 milliseconds, on a computer which has an instruction cycle time of 1.5 microsecond?”.

A prime requirement, as with any operating system, was to have an efficient method of loading and managing application programs. We first attempted this using a library of programs stored on tape but found that, while the tape system was effective for sequential data logging, it could not position the tape head accurately enough to support random access. This demonstrated that we needed a disc system, and that opened the way to a much better system. Most operating systems of that era were simple job schedulers. Given a queue of programs for execution, the OS would allocate the resources needed for that job, start it and wait for it to complete. Input/output devices belonged to the job for its duration and only the most advanced operating systems could run more than one job at a time. Our OS was event driven, i.e. designed to do nothing until it received an external trigger, when it had to be able to execute a program to process the incoming data. Then it had to be able to buffer data and log it to the external tape, while possibly receiving other data inputs or responding to console commands.

We needed to be able to control the system from the console so that we could issue commands such as “enable/disable experimental apparatus for data collection”. This meant that we needed to define a set of console commands and write a command interpreter which could trigger execution of the appropriate utility program. The OS also needed foreground and background processing modes, so that some work such as refreshing the graphical display could be continued in the background while the OS responded to higher priority interrupts or commands in the foregound. In retrospect, it had much in common with the OLTP (OnLine TeleProcessing) systems which were starting to appear in business applications, although without the wide area networking element.

A DEC PDP-8

Software Development

The PDP-8 had arrived with very little software – just a symbolic assembler for PAL (Program Assembly Language), plus a manual “The Small Computer Handbook”, and various newsletters describing how to write interrupt handlers, I/O routines etc. Later, we received another manual “Introduction to Programming”, a disc-based program editor, and various debugging aids. DEC was very helpful, setting up a very successful user group known as DECUS which shared programming tips and organised conferences. They were also willing to answer questions, and even allowed me to visit their base in Reading for development sessions on their bigger system. I got to know their UK chief programmer, Ray Jones, quite well and even met Ken Olsen, the founder – a pattern that would be repeated many times during my career! One of our biggest challenges was that the DEC software only ran in standalone mode, where it had the machine to itself. None of it would work in our online environment, but we needed to be able to modify and debug our applications while they were loaded. If a problem was found while we were setting up the experiment or, even worse, we hit a bug while running the experiment, we needed to be able to fix it then and there – not return to the development environment! It wasn’t practical to run the two pass symbolic assembler in an online environment, so the solution was to build an interactive octal debugger replacing DEC’s ODT (Octal Debugging Tape). Any PDP-8 programmer quickly became familiar with the octal notation which was used to key in the machine’s bootstrap loader and to describe the 12 bit instruction formats and the full word addresses used by indirect instructions. The interactive debugger allowed us to examine the contents of a given address and/or replace it, so that we could patch a section of memory to implement a fix, and then rewrite the program onto the disc library.

The Big Day Arrives

After about two years of preparation, we were almost ready for our scheduled four week slot on the Harwell Cyclotron. We lowered all the apparatus into the underground experimental area and set up cable links to the control room in old aircraft hangar which housed the computer and other control equipment. Things didn’t go well. Physics experiments always involve technologies which are at the edge of what is possible , so unreliable equipment is commonplace. But we suffered from a bigger organisational problem: the Cyclotron was being superseded by the RHEL Synchrocyclotron and was scheduled to shut down in the near future. Very little maintenance had been done for some time, leading to periodic breakdowns in our most important resource and cutting short the time available for the all-important data collection.

We ran the experiment in shifts around the clock. A typical eight hour shift would consist of checking that the previous shift had completed writing up their lab notebooks, demounted and labelled their data tape, and left notes on any problems they encountered. The new shift would then mount a new data tape, select the experimental parameters for the next one hour run, check the equipment and record a particle event under manual control so that it could be displayed and examined, and finally enable automatic data collection. After an hour, the run would be terminated and the procedure repeated.

As mentioned earlier, the results of accelerator experiments are based on statistics. So, when you have less data to work with, your statistical techniques need to be better! Particle interactions could be compared with hypothetical billiard ball collisions in which the cue ball is much lighter than the static ball. In our case, the “cue ball” was a neutron and the “static ball” was a nucleus of carbon or aluminium. During the interaction, the neutron transformed into a proton which could bounce off at any angle in three dimensions. The required trick was to measure the distribution of protons over these angles and, if possible, detect a small asymmetry in the distribution due to the phenomenon known as polarisation.

The traditional technique for measuring polarisation had been to set up scintillation counters to the left and right of the incoming particle beam and detect a difference in counts between these two sides. But this missed out on a great many interactions which resulted in a particle travelling up, down or at other angles rather left or right. The great advantage of our technique was that it detected and measured particles leaving the target at any angle, and this meant we could exploit all the data rather than only some of it. But, to achieve this, we needed a statistical technique known as the Maximum Likelihood method and that involved equations which could only be solved approximately, which no-one had done before. However, we were able to produce statistically significant results with only a few tens of thousands of particle interactions. Today’s experiments, such as the hunt for the Higgs Boson, are much more challenging and may need to record many millions of events.

Looking Back

In September 1968, I was fortunate to attend the DECUS Fourth European Seminar held in Edinburgh: a conference with around 100 attendees and approximately 35 user presentations. This demonstrated that we were not alone. Just under a third of the papers describe applications in physics, mainly in lower energy nuclear reactor physics, and several others describe online applications for the industrial control and medical environments. In several cases, the systems used by these groups were more highly configured than ours and, in other cases, used more sophisticated programming environments. But perhaps we were unique in what we achieved with a small system and, certainly, many later accelerator experiments have used computer-based online data collection techniques which derive from that era.

Geoff Sharman spent 35 years in the software industry. He was responsible for the strategic direction of IBM’s billion dollar CICS software business. He can be contacted at .

For some time David Huxtable and I have been working to resurrect the KDF9 Kidsgrove Algol compiler, with valiant collaboration from Brian Wichmann who has been photographing English Electric’s internal documentation which languishes in the Science Museum archive.

The project involves turning a printer listing from the 1960s into executing code. This compiler is an early attempt at an optimising compiler for ALGOL 60, and consists of a number of overlays (called “bricks” in the documentation), one of which is missing. Our efforts involve implementing the I/O infrastructure that the compiler used, and re-engineering this missing brick, of which Brian has found a hand-written copy. This is clearly an early version. Naturally, we have turned on the maximum level of diagnostics in the compiler as we work to turn the handwritten substitute for the truant into working code. Things went pretty well until we managed to run successfully into the final code-generation overlay, brick 60 (the last of 11 overlays). Turn off the diagnostic output and we can compile some example programs, but turn on the diagnostic output and we get an overflow failure, emanating from the FRB instruction – convert binary to characters. It turns out that this instruction is used in a curious way that is not unambiguously covered by the manual, so maybe our emulator should not set overflow.

Further investigation reveals that there is an inconsistency in the documentation, and brick 60 uses the opposite version from the other overlays. The issue only arises when compiling with compiler diagnostics, so it must be that this inconsistency survived into production code because by that time nobody was compiling with compiler diagnostics. So the bug (and it definitely is a bug) survived from the 1960s until 2017.

We have a dilemma in that the policy is to preserve vanilla versions of preserved software, but the compiler diagnostics would surely be of interest to someone researching 1960s compilers. We have corrected the bug in brick 60, accompanied by a conspicuous comment.

David Holdsworth is a leading member of the Computer Conservation Society with particular responsibility for software conservation and for emulation. He believes that software is only properly conserved if you can run it. David can be contacted at .

May I just make some comments on Geoff Sharman’s excellent walk through The Evolution of Enterprise Computing (Resurrection 77). His article emphasises the evolution of online applications but he also notes that “The first use of computers in 1951, by the J. Lyons company in the UK, was also for accounting, and things did not change until the US Government got involved.” There were two features which distinguished the early LEO –

• Lyons aimed to implement genuine enterprise systems which included accounting as part of much broader systems.
• many of the applications, in seeking to maximise the impact of computer use, anticipated techniques which became commonplace many years later when the necessary technology became available.

The Teashop Ordering system implemented in October 1954 illustrates both points. It was centred on the daily teashop ordering cycle comprising teashop manager s deciding the teashops menus for the next day’s trading, and telephoning the orders to Cadby Hall (Lyons food factories). At Cadby Hall the orders from the teashops were collected and turned into instructions for kitchens, bakeries and stores, as well as assembled into instructions for loading and delivering the completed orders to the teashops by the next morning. In addition, the transactions had to be entered in the teashop accounts and trading statistics collected.

The transfer of this business system to the LEO computer involved far more than an accounting system.

As important was the question of timing. The required scheduling was achieved by the invention of what amounted to a pseudo-online system. Teashop managers telephoned their orders for the next day to a Cadby Hall operator in the afternoon before delivery was required. The operator punched teashop identity and items ordered on to punched cards. These were input into LEO, summarised, and translated into factory and stores orders, packaging requirements calculated and delivery schedules printed for dispatch next morning to the teashops in a fleet of lorries.

The ideas behind the teashop ordering system anticipated the online systems which later developments in the technology made possible.

Professor Harry Huskey, who recently died aged 101, was the last survivor of the first generation of computer pioneers. His passing has been rightly noted in the New York Times and the American media. Although he spent most of his life in his native United States, he and his wife Velma were enthusiastic travellers and they and their family spent several sabbatical periods overseas. Very early in his career, in 1947, Harry spent a year at the National Physical Laboratory (NPL), where he was a key player in what became the Pilot ACE. I met Harry in the spring of 1979, and he told me something of his time in England. He and Velma, who was a computer professional in her own right, were both keen students of computer history, and were making use of their visit to England to research the life and work of Ada Lovelace. In 1980 they jointly published one of the first expert studies of Lovelace’s correspondence with Charles Babbage in the Annals of the History of Computing.

Harry was born in 1916 in rural North Carolina into a somewhat impoverished family. The family moved to Idaho early in Harry’s life, to try to improve their prospects. His parents were especially keen he should get the education they never had. The Great Depression had still not lifted, and times were hard when Harry enrolled at the University of Idaho in 1937. He studied for a degree in mathematics but also took a course in physics, which complemented his natural engineering ability. As with others of the pioneer generation, a knowledge of both mathematics and physics would be their entré into computing. Harry was keen to study for a PhD in mathematics and to make ends meet he became an instructor at Ohio State University, where he taught applied mathematics and numerical analysis. It was there that he met and married Velma, his “best student … a beautiful girl who sat in the front row.” In 1943, having completed his PhD, he became an instructor at the University of Pennsylvania. The university was on a war footing and Harry joined the Moore School of Electrical Engineering, where the ENIAC was under construction. He made both engineering and mathematical contributions, and when it was completed in 1945 wrote the operating and technical manuals for the machine. One of the first post-war visitors to the ENIAC was Douglas Hartree, professor of applied mathematics at Manchester University. Harry sounded him out about the possibility of taking a sabbatical year in England. Hartree was non-committal, but in July 1946 Harry was telegraphed a job offer by the NPL. (Hartree was on the executive committee responsible for the Mathematics Division at the NPL.) Shipping was in short supply and it was not until the very end of the year that he, Velma, and their two small daughters embarked on the rough, seven-day passage to England.

Harry’s abiding memories of his first visit to England were post-war austerity, rationing, and the ferocious cold and fuel shortages of the winter of 1947. He was however, well paid at £1000 a year. After some months in a cold and depressing boarding house, the family’s luck changed when they managed to rent a somewhat palatial cottage with royal connections in Bushy Park, an easy walk to the NPL.

At the NPL, the computer group was working on the design of Alan Turing’s ACE computer. Turing was away in the United States when Harry arrived, and he was set to work with Jim Wilkinson and Mike Woodger. Wilkinson and Woodger were at the paper-programming stage, exploring the ACE’s order code on practical mathematical problems. Harry joined in – both with the ACE work and the wearing of an overcoat and gloves to keep out the cold. As is well known, the unique feature of Turing’s design was the use of “optimum coding”, in which each order nominated the address of its successor. This made the ACE potentially much more cost-effective than more conventional designs.

In April 1947 Harry proposed that they should build a small prototype version of the ACE. This would give the team experience in electronics in addition to the logical and mathematical aspects of the machine. They got the go-ahead for what became known as the Test Assembly. Turing had returned to the NPL by this time. When we spoke in 1979 Harry was keen to dispel the notion that Turing was hostile to the Test Assembly because it would delay the building of the full-scale ACE. This was not Harry’s recollection – he found Turing to be friendly and “non-opposing if not co-operative”. The Test Assembly was well underway by the autumn of 1947, but it was then stopped by an administrative decision of the director of NPL, Charles Darwin. Morale was very low when Huskey left at the end of 1947. The project was eventually restarted and became the Pilot ACE, the prototype of the English Electric DEUCE, one of Britain’s most successful first generation computers.

The SWAC computer with Harry Huskey holding one of the Williams Tubes around which it was based

Back in the United States, Harry joined the National Bureau of Standards (NBS, a sister organisation of the NPL). He was assigned to the Institute for Numerical Analysis at the University of California, Los Angeles, where he worked on the SWAC, a conventional stored-program computer. In 1950, he got 15 minutes of fame by appearing on Groucho Marx’ You Bet Your Life quiz show as an “electronic brain designer”, a very unusual calling at the time. In 1952 he spent a sabbatical year at Wayne State University, Detroit, helping to establish its computer centre. While on sabbatical leave he became a consultant for the Bendix Corporation, specifying the design of its G-15 computer. The G-15 was a magnetic drum-based machine, but because it used ACE-style optimum coding it had a major price-performance advantage over comparable machines. Eventually over 400 G-15s were sold, establishing it as one of the great workhorse computers of the first generation. Of course, the G-15, like the ACE, was a machine of its time and once random access core memories became available optimum programming faded away. The successor machine, the G-20, was of a more conventional design.

When Harry returned to California, the Institute for Numerical Analysis had been merged with the university and he became a professor of mathematics and electrical engineering at the University of California, Berkeley. While there, the Bendix Corporation gifted him a G-15. In 1967, he became a founding professor of computer science at the University of California, Santa Cruz, where he remained until his retirement in 1986. He took his beloved G-15 with him, stored it in a barn for 20 years, and eventually donated it to the Smithsonian Institution.

In Resurrection 68 (winter 2014/15), Simon Lavington and I put together an article Archives and Your Personal Papers with some suggestion as to how colleagues can facilitate the preservation of their personal papers. (The same article is also posted on the CCS website) Our suggestions included the need to weed out materials of no use to archives and to put the papers into an order (usually chronological) that will aid their processing. Processing a collection is costly and short of making an endowment for professional cataloguing, this is something that it is possible to do for yourself. A good way forward is to look at a catalogue of a collection of comparable material and use this as a guide.

John Poulter has recently followed this path and his papers have now been deposited in the archive of The National Museum of Computing at Bletchley Park. John started his IT career programming a Pegasus in 1960. He eventually became a principal consultant with Sema, and later an independent consultant, mostly on NHS computerisation. He was, with Professor Peter Checkland of Lancaster University, a proponent of Soft Systems Methodology. He is currently archivist for the Worshipful Company of Information Technologists.

Appeal for Information

In January 2009 the BCS published an obituary for the late Murray Laver ( www.bcs.org/content/conWebDoc/23798) the senior civil servant who did so much to introduce the techniques of information technology to government. Laver it was who was instrumental in the creation of ICL.

It was remarked that he once published childrens’ books under a pen name. His surviving family know nothing of this activity and would be grateful for any information (including the pen name) which might shed light on his rather unexpected talents. Please contact Roger Johnson () if you can help.

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

LEO 326s handle phone & PO accounts: A LEO 326 computer delivered to the new GPO computer centre in Edinburgh, latest of seven 326 systems supplied to the GPO by English Electric, will replace punched card equipment to produce telephone bills for 1.25 million subscribers in Scotland and the North East. (CW 037 p12)

High Speed Postal Order System: Details of about 800,000 postal orders, involving a total of 10 million characters, are being transmitted daily from Chesterfield to the Post Office DP centre in Kensington for processing by a LEO 326. (CW038 p1)

Fingerprint Processing by Computer: French police have developed a fingerprint detection method for the computerised war against crime. The device consists of a glass half cylinder, to receive the finger, onto which light is played through two prisms and a photographic lens. A print is given on 35mm film as the light-handling components execute a regular movement. (CW038 p9)

Big Naval orders may follow Ferranti mission: A high-pressure sales mission to sell military equipment in Washington and Ottawa may lead to substantial orders for Ferranti in the fields of naval weapons control systems and tactical trainers. (CW039 p8)

418 Speeds Analysis on Cosmic Ray Research: The main task of the Univac 418 installed at the Physics Laboratory of the école Polytechnique in Paris will be the analysis of particle paths through bubble chambers in connection with cosmic ray studies. (CW039 p9)

Navigational role for STL Processor: A central processor using integrated circuits and eliminating the use of core stores has been developed as part of the advanced control system project at Standard Telecommunications Laboratories at Harlow. One model, known as the Phase Computer, is expected to find application in simple control circuits for navigational aids. (CW039 p16)

Big machine project by ICT: Plans for a series of giant computers, the biggest of which would have 20 times the power of Atlas, have been put before the Ministry of Technology by ICT. Development of the machines, known as Project 51 (a.k.a. 1908A), would cost between £5m and £10m but with government backing the company believe the first machines could be ready by 1970. (CW040 p1)

Elliott Systems in Nimrod: Equipment orders worth £4 million, including 40 Elliott MCS 920B computers, have been placed for the Hawker Siddeley 801 Nimrod, the maritime version of the Comet. Other Elliott systems include an inertial platform and four other electronic sub-systems. (CW040 p2)

Boeing order TRACE: Computer controlled automatic test equipment for the Boeing Aircraft Co’s Renton plant, in Washington, is being supplied by Hawker Siddeley Dynamics of Hatfield. The equipment will include three testing stations, based on HSD’s TRACE 600 test equipment, controlled by an SDS Sigma 2 computer. (CW040 p16)

Strongest group in UK industry: The strongest and most versatile computer manufacturing group in Britain will be brought into being if the merging of Elliott-Automation with English Electric goes through as planned. Initially computer operations will account for about £15 million out of an expected yearly total of £400 million for the group as a whole. (CW041 p1)

Atlas II for design project: The remaining ICT Atlas II is to be used by the Ministry of Technology to establish a national centre for Computer Aided Design, CAD, at Cambridge. It will be the first of its kind in the UK and the largest in Europe, comparable in scope with those in the US. (CW042 p1)

Plotting Machine for Met Office: An automatic plotting machine designed by D-Mac of Glasgow, but manufactured by Systems Computers, is being installed at the Bracknell, Berkshire, head-quarters of the Meteorological Office. It will be used off-line to produce weather charts from paper tape output generated by the centre’s KDF9 computer. (CW042 p3)

Farewell to DEUCE: The Dead March from Saul was played by a DEUCE computer last week to an audience including English Electric staff who had helped to design and manufacture the series. The machine, installed in 1960 at English Electric’s Kidsgrove, Staffordshire bureau, was being taken out of service after completing its final task, a stock control scheme. The smallest job DEUCE carried out during its seven years’ service was to design 2,000 bingo cards so that no two of them bore the same combination of numbers. (CW043 p1)

CAD system at Whetsone laboratory: Extensive computer aided design facilities, planned for the Mechanical Engineering Laboratory of English Electric at Whetstone, Leicestershire, will involve a complex of four digital computers and one analogue machine. New computers to be added to the system are a Marconi Myriad II and an English Electric System 4/75. They will link up with two English Electric KDF9s and the Saturn analogue system already installed at the laboratory. (CW044 p1)

Taming the traffic of Paris: Data on vehicle movement in Paris, arriving on French SFIM-supplied equipment at the Technical Headquarters of Paris police, is processed on a GE 425 computer, thought to be the biggest machine used by police in the world and the largest 425 in existence. (CW044 p8)

Canadian simulator for BOAC Jumbo Jet training: A simulator of the Boeing 747 Jumbo Jet has been ordered by BOAC at a cost of £750,000 from the Canadian firm CAE Industries, who were competing with British and American firms for the contract. To be installed at Cranebank, near London Airport, the simulator should be in use by 1969. (CW045 p7)

Modular One ‘At End of the Year’: Although no support is forthcoming from the Ministry of Technology, deliveries of Modular One, the table-top computer aimed at scientific and industrial markets, will begin at the end of this year or early 1968, a spokesman for Computer Technology told Computer Weekly. First machine was to have been delivered to a scientific user in mid-1967. But negotiations with existing manufacturers, undertaken at the insistence of the Ministry of Technology, proved abortive and Computer Technology now plans to manufacture the machine itself at Hemel Hempstead. The announcement follows a statement in the House of Commons in which Dr J. Bray, Parliamentary Secretary for the Ministry of Technology, said that the NRDC would be unable to help the firm because it had no manufacturing capability. (CW045 p12)

Microcircuit system bound for Moscow: The first microcircuit computer system from the West officially to reach the USSR will be an English Electric System 4/50, ordered for the Moscow headquarters of the State Committee of Supply, GOSNAB, where it will handle central planning for allocation of orders to factories and warehouses throughout the country. (CW046 p1)

A General Purpose Interface System for IBM 1130: Realtime Systems Inc, whose European office is at 16 Berkeley Street, London, W1, have designed a general purpose interface system for the IBM 1130 computer to enable it to handle data acquisition and data transmission functions. (CW046 p12)

First 1907 installed at Putney HQ: The first ICT 1907 computer is now installed and operating at the company’s Putney headquarters where it will be used in a multi-programming and multi-access mode for the development of software for the 1900 series. Valued at approximately £800,000 the system brings the total of ICT’s hardware investment for software development to about £1¾ million The company already has 1901, 1903 and 1905 machines for this purpose. (CW047 p12)

Burroughs Introduce 6500 and 7500 Ranges: Further evidence of Burroughs Corporation’s move into the large scale EDP equipment market has been given by the introduction of two new systems – the B6500 and B7500 – designed to fill the gap between the medium sized B5500 and giant B8500 systems. (CW048 p4)

Plessey Develop Optical Reader: A commercial version of the Plessey’s Oscar, Optically Scanned Character Automatic Reader, is due to be announced next week. The reader has been developed under an ACTP contract valued at £25,000. (CW049 p1)

Concordances of the Bard by KDF9: Concordances to 37 Shakespeare plays are to be produced from plates made directly by photographing line printer output at Oxford University Computing laboratory’s KDF9. Each play has been punched on to paper tape from facsimiles of the earliest texts at English Electric’s London bureau and the completed books will be issued by Oxford University Press. (CW050 p12)

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 in the conference room of the Royal Northern College of Music, Booth St East M13 9RD: 17:00 for 17:30.

For queries about Manchester meetings please contact Gordon Adshead 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

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

Bletchley Park : daily. Exhibition of wartime code-breaking equipment and procedures, including the replica Bombe, 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 : Thursday, Saturday and Sunday from 13:00. Situated within Bletchley Park, the Museum covers the development of computing from the “rebuilt” Colossus codebreaking machine via the Harwell Dekatron (the world’s oldest working computer) to the present day. From ICL mainframes to hand-held computers. Note that there is a separate admission charge to TNMoC which is either standalone or can be combined with the charge for Bletchley Park. See www.tnmoc.org for more details.

Science Museum : There is an excellent display of computing and mathematics machines on the second floor. The new 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 Totaliser, 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.