EDSAC — Andrew Herbert

Progress on EDSAC commissioning continues to make progress. Many of the problems that have plagued the Main Control, Addressing Coincidence and Order Decoding subsystems have been overcome and we have seen extended periods of the machine apparently operating correctly.

We are still finding some problems with the tank addressing system, but these too are being removed one-by-one.

We have also commissioned the operator control chassis which now gives us the ability to single step through test programs and brings us closer to how the original machine was used than our interim ad hoc controls.

The next steps are to thoroughly test the arithmetic orders for correct operation and results, and to commission the transfer unit. This will allow programs to write to store and also enable calculation with short (17 bit) as well as long (35 bit) numbers.

On a longer timescale remain:

A parallel development is the creation of a system for monitoring EDSAC to provide a means of detecting, analysing and hopefully locating machine faults. This is based on a microprocessor system that can monitor and capture individual signals, sending them back to a central station for analysis. These “EDLA” units have been designed by Jeremy Bentham. A new volunteer Brian Knight has started work on the central station, using a Raspberry Pi and Peter Linington is drawing up the overall system architecture.

We are also reawakening a project to construct a photoelectric paper tape reader as was fitted to the original to Cambridge University, and thus when paper tape input of programs and data became a performance bottleneck.

Overall we are finding EDSAC surprisingly reliable. To a significant degree this is due to a lot of hard work during the commissioning phase improving and tuning circuits to achieve better margins on critical signals. We do suffer valve failures from time-to-time, unsurprising as many have been in operation now for nearly 10 years. With experience we are doing better at being able to pinpoint such failures. Hopefully as we develop the monitoring system, we will be able to do even better. We have found that some of these valve failures do then cause consequential damage elsewhere – for example burning out resistors due to high current loadings. This can be difficult to track down. The Chinese B9G sockets we purchased given the dearth of originals also remain a tiresome cause of intermittent, often vibration-sensitive failures.

If there are CCS members who would like to be involved in EDSAC commissioning the team would be very pleased to welcome them, especially those with electronics experience. Please contact me in the first instance.

ICL 2966 — Delwyn Holroyd

One of the 7181 VDUs developed a fault, although it has actually turned out to be two. The symptom was no vertical deflection on the display. Some investigation revealed the -15V power supply measuring about -1V. It was current limiting due to a short circuit capacitor on the character ROM board, where the supply is used to provide -9V for the ROMs. The other use for this supply is on the scan board, and the vertical scan returned as expected after replacing the faulty capacitor. However the sub-raster, or jiggle scan, did not. On these displays the characters are drawn vertically with a separate high frequency scan.

A burnt out resistor was found on the scan board in the relevant circuit, but the replacement immediately started smoking! Unfortunately it appears to be a transformer fault, but this is preferable to the output transistors. These failed on the only other scan board we possess, and have so far proven impossible to replace. They carry only a house part code, so there is no clue to the characteristics. We’ve tried many different replacement types, but none have given a satisfactory character shape. The repair will most likely involve transferring the working output transistors to the otherwise good scan board. It isn’t clear how the power supply fault could have caused the scan board transformer to fail, or vice-versa, so this is also a mystery.

Turing-Welchman Bombe — John Harper

The bombe has been running reliably in the last months and has only had one small worn part replaced.

As things are almost back to normal after the pandemic it is now time to report that the team of demonstrators has done extremely well over this period.

Demonstrations have been possible almost every day that TNMoC has been open. At the beginning of the lockdown members of our team erected acrylic screens all around the machine in the hope that there were no infections between demonstrators and the visiting public. From what we know this was successful

Our demonstrator team has to be congratulated.

Software — David Holdsworth

Server sw-pres.computerconservationsociety.org

Free-standing Webserver Emulation System In many ways this is a starting point for the above server system. As requested in September, I have had help from Dik Leatherdale of issues of portability. This has revealed that offering binary programs for download onto Windows 11, and probably also 10 tends to excite the anti-malware systems, which then prove less than co-operative. For UNIX-like systems belonging to the sort of person interested in software, I have assumed that one can usually rely on there being a C compiler, normally gcc.

This problem obviously has solutions. Otherwise nobody would ever be able to install anything. I suspect that there are many solutions, some of which involve paying money to trusted (self-appointed) third parties, though my ambition is that an end user would be able to have their own anti-malware software scan the downloaded stuff and pronounce it clean, after which it would work without let or hindrance.

The snag is that things work OK on my own systems where they were created. I only have one Windows machine.

At present the “free-standing” system is not quite autonomous. Although the emulations run entirely on the end user’s machine, it still makes calls to the sw-pres server for images of manual pages and original source text, This material is very bulky. If it were to be incorporated into the downloaded system, it might make the system unattractively large. Of course, I do not own the copyright in this material. I am not sure whether my HTML versions, created by use of OCR and manual editing, count as new works created by me.

Elliott 803, 903 & 920M — Terry Froggatt

The TNMoC Elliott 803 is going well at the moment. Peter Onion mentions that he has been working on how to render pictures with the plotter. Also a version of the two Algol Compiler tapes labelled “803 A504 Issue 1, 17/7/79” has come to light. He is not sure where/when he acquired these tapes, and 1979 seems very late for them to have been an official release. They have been transferred to disc using the 803’s Paperless Tape Station for investigation on an emulator.

So far it looks like it is a version of 803 A104 (the compiler for five-hole programme tapes) that has bee modified to use a seven-bit code, but the output it produces (presumably error messages) doesn’t seem to match any of the known seven-bit codes. The next step is to examine the instruction trace from an emulator run, and to try and figure out how it uses the values from a 128 word lookup table that is referenced in the subroutine that has replaced the normal “060:710” instructions to read a character from tape. Peter is being helped by Bill Purvis.

Despite the previously-reported intermittent faults, the TNMoC 903 “Olly” also appears to have been behaving recently too. In contrast, my own larger 903 has failed recently, losing one word of the store in every 64. This is almost certainly due to corrosion inside a store connector, on a pin adjacent to a pin which I repaired two years ago. A proper repair (with a new connector) will involve 100 solder joints.

Peter Williamson has traced the failure with the TNMoC 903 engineers display panel to one of the modules in its power supply and has a replacement on order. We are lucky here: originally the voltage for the neons was derived from the +/-six volt rails by an internal inverter, which might be hard to repair, but this has been replaced using relatively modern mains-powered modules.

My conjecture in the previous Resurrection, regarding how the microcode in the 920M might be implemented, proved to be correct. I have now located all of the gates which implement it, and I am now close to understanding all of the gates on the register and control decks. (None of which will help me fix the store problems, of course).

I’ve also found signs of evolution. On most 903s, a bistable has been added to turn initial instructions on & off. On the 920M (at position E47), it looks as though a standard 564 dual four-input Nand module has been replaced by a one-off 509 module which adds the bistable. The clue is that there is a now-isolated backplane link between two of the pins: with the general-purpose 564 this was needed between the two gates, but with the special-purpose 509 these pins have been linked internally.

Harwell Decatron — Delwyn Holroyd

The rewiring of the 50V relay power supply referred to in my previous report has now been completed and the supply is back in service.

The machine has recently developed a fault that disappears after a short warm up, whereby the pulse generator doesn’t circulate at the beginning of an arithmetic order. This seems to be caused by the carry B pulses being blocked by part of the circulation check circuit, but so far the fault has gone away before the culprit can be identified.

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

Bill continues to work on the 7930 scanner implementation, which has been modified to require proper sync run-in and SYN sequences. Currently problems are being experienced getting the 7020 bulk-read facilities to work (for Card Reader and Tape Reader).

David is still working on the 7210 IPB. Both the exec mode (S210) and object mode (N210) diagnostics will run to a certain extent before hitting unexpected problems. David has decompiled N210 into source and is now adding diagnostics in the hope of finding where the emulation is going wrong.

Brian has already received a support request following publication of the George 3 Executive Emulator article in edition #295 of “Linux Format”! (see linuxformat.com/linux-format-295.html).

John Harper recently donated a large cache of 1900 manuals and drawings to the team, which Bill is working his way through scanning. A lot of the information is new to us, and will no doubt prove invaluable in future emulation work. Many thanks to John, and to Bill for the scanning.

IBM Museum — Peter Short

Current Activities

Over the last few weeks we have been spending much of our regular Thursdays sorting through the various back office rooms, some of which have been undisturbed for years. We were able to dispose of a quantity of flat screen PC monitors and other hardware, where we already have at least a quantity of two. Another room full of posters, pictures, photographs and other miscellaneous items has also been cleared and tidied. There is much still to do, but we do have more storage space now for hardware that has otherwise been living on the floor.

Complementary Bletchley Park Exhibition

With the successful launch of Bletchley Park’s new exhibition “The Intelligence Factory” incorporating our 080 card sorter and a hand punch, we are in the process of preparing a complimentary display based around a 077 card collator and 416 tabulator.

Many 405 tabulators, outwardly very similar to our 416, were used in Bletchley Park, as well as 077 tabulators, other ‘big iron’ card punch machines and a multitude of card punches.

The Autumn edition of the Bletchley Park magazine, Ultra, includes an article co-authored by Dr Thomas Cheetham of Bletchley Park and Peter Coghlan one of our IBM Hursley Museum curators, which describes how Hollerith and IBM’s punch card technology, dating back to Victorian times, became a vital part of Britain’s codebreaking machine. Alongside an overview of the processes and unique innovations needed to break down message data into usable information, the article also includes insights from some of the machine operators and analysts who worked tirelessly to punch cards, organise data flows and feed the ever-hungry machines.

SSEM Replica — Chris Burton

Volunteers continue to inform the public several days per week with a lot of school visits recently. The replica machine has intermittent problems which clear themselves up then return on another day. It is symptomatic of one or more suspect connections or components not yet traced.

News Round-Up

In Resurrection 99 we mentioned that the LEO Society has published a new edition of LEO Remembered which is reviewed at ccsoc.org/leo0.htm. Copies of the book are available for £8 + P&P by emailing with your address and the number of copies wanted.

101010101

Apologies for a major typo in the paper version of Resurrection 99. Missing from the bottom of page 10 are the words “competent engineer would have few problems grappling with this straightforward”.

101010101

At ccsoc/bru10.htm may be found Herbert Bruderer’s latest opus on the rather dismal history of an attempt to create an international computation centre in Europe after the Second World War.

101010101

We have lost a few notable computer people in recent weeks –

101010101

We recently offered our remaining stocks of early editions of Resurrection to readers to fill in gaps in their collections. No charge was made but it was suggested that, if recipients so wished they could make donations to the CCS Restoration Fund. Recipients responded most generously in this way, and we thank them all for that. We are looking into the possibility of offering some later editions. More news when we have some.

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.

Queries and Notes

Computer dating in the 1960/70s

John Dunn at TNMoC on behalf of a French researcher asks whether anybody has any information about Lowndes Ajax in Croydon and Bedford Computer Services, specifically their involvement in computer dating. By co-incidence, it appears that the latter seems to have been run by the Society’s co-founder the late Tony Sale. Beyond that we have yet to find any information. Please contact if you can help.

Elliott 40x Circuit Module

The IBM Museum at Hursley is having a tidy-up and has offered a number of non-IBM items to anybody who may be interested. In particular this plug-in module labelled “AN1” which includes a magnetostrictive delay line. It has now found a home at TNMoC but it has also generated much correspondence culminating in Delwyn Holroyd positively identifying it as being from an Elliott 405. If anybody has any more information John Dunn (see above) is the point of contact.

A list of the remaining items for disposal can be found at ccsoc.org/ibm0.pdf. Contact Peter Short at if you can provide a good home for anything.

Chair’s Annual Report

The Society, I am pleased to report, continues to thrive and is in rude good health.

The London Meetings Programme has featured and hosted nine events since our last AGM, one a month excluding the months of the summer recess. The hybrid format of lectures and presentations, introduced during the pandemic lockdowns, allows virtual as well as live attendance, something we now take for granted but was quite novel a year ago. This has continued with great success.

The sustained high attendances are a tribute to Roger Johnson, our London Meetings Secretary, who magically attracts and prevails on eminent, expert and lively speakers to participate. The technical aspects of the hybrid platform are non-trivial and that it functions in the near-seamless way it does is in no small measure due to the enabling team - Bill Barksfield, Delwyn Holroyd, and ready support from Dik Leatherdale, Rod Brown and Dan Hayton together with BCS technical staff.

The Society’s quarterly publication, Resurrection, guided and crafted by Dik Leatherdale, its editor, has not missed a beat despite the turbulence and disruption to domestic and world events. The first issue, Volume 1 No. 1, appeared in May 1990. The landmark 100^th issue is scheduled for Winter 2022. Resurrection is a unique chronicle of computing history, especially British computer history, and a century not-out is deserved of more than a ripple of polite applause from the stands.

The Society provides the reporting structure for 17 projects and related restoration initiatives. The Society is an information hub for regular progress reports on the challenges, progress and successes of a rich variety of restoration activity, as well as being a source of expertise, and material support for these programmes. To the 17 projects in the suite, we have recently added another; the recreation of the Delilah voice encryption device for advanced speech security proposed by Alan Turing in his report of 6^th June 1944. John Harper, who led the Bombe rebuild project, has led the Delilah project for some years, and Delilah has been added to the Society’s project portfolio. Delilah is not a computer and its inclusion in the Society’s project portfolio has stimulated ongoing discussion about the scope of the Society’s remit as well as historical connections between cryptanalysis and computing. We welcome this project into the fold.

A highlight during the summer recess was the IEEE Milestone event in Manchester in June. Two landmark awards were made for major developments in computer history that took place in Manchester: the Manchester ‘Baby’, and the Atlas Computer. The plaques were unveiled on 21^th June, the 74^th anniversary of the first program run by the ‘Baby’ – acknowledged as the first successfully run stored program. The Society is pleased to have been amongst the bodies that sponsored the event. All credit and thanks to Simon Lavington, Roland Ibbett, Jim Miles, and Rod Muttram for the substantial work involved in articulating the merits of the Manchester achievements, their cogent advocacy for appropriate recognition, and for the organisational effort in staging so successful an event. Thanks to their efforts the plaques are a permanent testament to a seminal piece of history.

The Society is approaching its 33^rd year since its founding and we have turned attention to preserving records of the Society’s early history. Under Martin Campbell-Kelly’s guidance we are archiving core documents including publications, operational records of proceedings and of the Society’s governance. Video recordings of the lecture series going back to the Society’s founding have been located, brought together, and are now part of a programme of digitisation for archiving. Huge thanks to Kevin Murrell, Dan Hayton, Dik Leatherdale, and others who have been active in this time-critical programme.

We have made substantial progress in proposals to restructure the management of the membership of the Society. A subcommittee has conferred and devised a structure that will allow us to better service the membership by providing improved access to members records in full compliance with Data Protection regulation. The draft proposals have received initial approval from BCS and we will be taking this forward in this year’s programme. Special thanks to Rachel Burnett, our unfailingly industrious committee Secretary, for being the source of invaluable legal advice and guidance, and to Arthur Dransfield, our Treasurer, for the total command of our financial affairs that informs his sure counsel.

My predecessor as Chair was David Morriss. Before taking up the Chair I shared with David my concern about the burdens of so active a programme that lay in store. He said that the Committee’s office bearers were so capable, qualified, willing, and creative, that I had no need for concern. After a year working more closely with the Committee, I see the wisdom of David’s reassurances. Thank you to the Committee, one and all. I look forward to what we will do together this coming year.

Resurrection – 100 Not Out

I was going to start this piece with a cricketing metaphor. The batsman (or batter as we must now say) waving his bat, acknowledging the light applause from the club house. The score sheet, showing also the contribution of the opening batsman (whoops). But your chairman has beaten me to it in his annual report. Great minds? Or perhaps it was obvious.

I’ve been looking at some of the early editions of Resurrection and the thing that stands out is that we seemed to be mainly interested in physical objects. With some exceptions (Martin Campbell-Kelly’s extract from his ICL history stands out in edition one) we were very much interested in the conservation of computers – not unreasonable given the Society’s name. But over time we broadened the scope of our subject matter. We became interested in software, the history of the industry, and the stories behind individual organisations. This edition is proof of that change.

The change which has occurred in these pages reflects the gradual change to the Society itself. While our interest in conserving old computers (and in building replicas of old computers) remains undiminished, the Society has developed into a broadly-based historical group. We have not changed our name. What would be the point? But we have developed our purpose and none the worse for that.

One thing which hasn’t changed much is the era which we study. We tend not to have much interest in anything post-1970 or thereabouts. Of course, the early years were a time of rapid change and of a huge variety of approaches to computing, some of which succeeded and some disappeared without trace. But we should, perhaps move on and broaden our scope in a different dimension.

But Resurrection would be a poor thing, if I had to write it all myself. So, this evening please raise a glass and toast all those hundreds of authors who have contributed to Resurrection over the years. Raise a glass too to those whose work is so vital behind the scenes – Mandy Bauer and Florence Leroy at BCS who are responsible for ensuring that the paper copy is produced. Chris Burton who produced html versions of more than 50 editions and who managed the website at Manchester University where we used to publish online editions of Resurrection. The late Hamish Carmichael whose proofreading ensured that the text was as error-free as possible. BCS which pays for the printed edition.

But most of all, please raise your glass to Nick Enticknap, my predecessor as editor who still serves as proof reader and who protects you all from my poor grip of the conventions of written English. Thanks to all of them from me and I hope from you.

Simulation Modelling of Historical Computers

In the early days of computing, when all computers were physically large devices, students taking computing degree courses could be shown which part of the computer was which and could see flashing display lights showing what was going on inside the machine. With the advent of the microprocessor, this form of human-computer interaction became largely a thing of the past. Around the same time, however, bit-mapped graphical display devices appeared and these could be used to demonstrate the inner workings of computers via animation of on-screen models. HASE, a Hierarchical computer Architecture design and Simulation Environment, was developed at the University of Edinburgh with this purpose in mind.

HASE simulation models of a variety of computer architectures and architectural components have been created, some for research investigations of large-scale computing systems and others for use as teaching and learning resources in lectures, for student self-learning or for virtual laboratory experiments. The HASE website ( www.icsa.inf.ed.ac.uk/research/groups/hase/) provides access to the models and to the Java code for HASE itself. Each model has its own supporting webpages describing the system being modelled, as well as the model itself, and from which the source files for each model can be downloaded. These files can be used as inputs to HASE, which has options to load a project, to compile a simulation executable and to run the simulation. Running a simulation produces a trace file which can then be used to animate the on-screen display of the model to show data movements, parameter value updates, state changes, etc.

Models of five historically significant computers have been created by one of the authors (RI): Atlas, MU5, the CDC 6600, the Cray-1 and, most recently, the Manchester ‘Baby’ computer. Space precludes describing all of them here, so the interested reader is referred to the HASE website for details of the Cray-1 model. The models are intended to demonstrate the principles of operation of the computers they represent, rather than to be able to execute real programs, so they do not attempt to reproduce all of the more esoteric details of the real machines. They do however try to emulate, as far as possible, the organisation and design features of the corresponding hardware. This has led to further development and enhancement (by DD) of HASE itself.

The HASE Simulation Environment

Figure 1: The HASE GUI showing the Atlas Model

Figure 1 shows a screen image of the HASE Graphical User Interface. The icons in the top row allow the user to load a model, compile it, run the simulation code thus created and to load the trace file produced by running a simulation back into the model for animation. The main Project View pane shows the screen image of the model itself, in this case the Atlas model. The Project Inspector pane displays the values of the parameters defined for the model, while the Output pane displays information being reported back to the user during the various phases of activity involved in a simulation experiment.

Each of the blocks in the image represents an entity within the model: HASE uses an Entity Description Language file (project.edl) and an Entity Layout File (project.edf) to specify an architecture. A project.edl file contains five sections: PREAMBLE, PARAMLIB, GLOBALS, ENTITYLIB and STRUCTURE. The PREAMBLE section contains the name of the project, the name of the author(s), the version number and a description. The PARAMLIB (Parameter Library) is used to create the type definitions of parameters used by the project. HASE provides a set of built-in types: bool, char, integer, unsigned integer, long, floating-point, string and range, from which more complex types can be created. These include ARRAY (array parameter type), ENUM (enumerated type parameter) and STRUCT (structure parameter), all of which are similar to those found in C and C++. In addition, HASE provides an ARRAYI type, which allows individual instructions within an array of instructions to be labelled, a LINK type, used when creating instances of entity ports and links between them, and an INSTR type, which can be used to define the instruction set of a processor. The INSTR type allows instructions to be grouped together, a useful feature for decoding purposes.

The ENTITYLIB section contains the definitions of the entities. Each entity definition includes a type name, a textual description, a list of states, a list of parameters and a list of ports. The STRUCTURE section defines the architecture by (a) creating instances of the entities and assigning instance names to each of them, (b) creating links between entity ports. The GLOBALS section contains parameters that are accessible by all entities in the model.

Using the data in the project.edl file, HASE creates a library of parameter types from which parameter instances (variables) can be created and a library of components from which an architecture can be constructed by linking the defined components together in the desired manner. The screen image of the project is defined by the project.edf file which contains screen position information about the displayed entities, their ports and parameters, and the name of the appropriate bitmap icon for each of an entity’s possible states. The icons are contained in a separate bitmaps subdirectory.

The behaviour of the entities is coded in Hase++, a discrete event simulation engine with a programming interface similar to that of Sim++, but implemented using C++ and threads. It includes a set of library routines to provide for process oriented discrete event simulation and a run-time system for multi-threading many objects in parallel and keeping track of simulation time. For each entity there is a separate file (entity.hase) containing its behavioural simulation code. There is also an option to include a global fns file of user defined functions available to all entities.

The HASE GUI and the HASE model compiler are written in Java. The model compiler generates C++ code which is then compiled using the C++ compiler native to the system on which HASE is being run. This is linked against the HASE Runtime (written in C++) to produce the simulation executable. HASE is supported on OSX, Windows 7/8/10 and Linux.

Modelling Constraints

In any simulation modelling system there is a trade-off between accuracy and performance. HASE was designed primarily as a high-level visualisation tool for computer architecture students and therefore simulates systems at register/word level rather than bit level. This inevitably imposes some limitations on the way models can be constructed, e.g. registers are modelled using typed variables and stores are modelled as arrays of typed variables. This means, for example, that fixed-point (integer) variables, floating-point (real) variables and instructions cannot be held in shared arrays. Furthermore, most early computers used what now seem like rather idiosyncratic number formats, so achieving a high degree of verisimilitude in the simulation of floating-point operations would add a significant level of complication. In the MU5 and CDC 6600 models, this problem is avoided by simply representing all numbers as integers. In the Atlas model, advantage has been taken of the way the paging mechanism works to separate, unrealistically of course, fixed and floating-point numbers into separate pages; floating-point arithmetic is implemented using the floating-point operations provided by the underlying hardware of the computer on which the simulation is running, accessed via standard C++ operations.

There are also constraints on nomenclature. The elements of a C++ enum, to which the HASE ENUM construct is mapped, can only contain alphanumeric characters and the first character must always be a letter. This impacts on the way the function field of an instruction can be formulated. In the MU5 model, for example, the function ‘ NB =’ is represented as ‘NBld’. Choosing ways to represent the instruction formats, both within the simulation code and on-screen, were among the most significant design decisions in the creation of these models.

Atlas

The Ferranti Atlas computer resulted from the fourth major computer design and implementation project carried out at the University of Manchester. The first Atlas was inaugurated at the University in December 1962. Designed by Professor Tom Kilburn and a joint University/Ferranti team, it incorporated a number of novel features, the most influential of which was Virtual Memory. IEEE Milestone Plaques recognising this achievement and the “Manchester University ‘Baby’ Computer and its Derivatives” were presented to the University on 21^st June 2022.

Atlas had a 48-bit instruction word made up of a 10-bit function code, two 7-bit index addresses (Ba and Bm) and a 24-bit store address (Figure 2). Functions that operated on the Accumulator (A-codes) were thus one-address with double B-modification. B-register 0 always returned a value of 0, thus allowing for singly modified or unmodified accesses. The most significant bit of the address field distinguished between user addresses and system addresses, while the three least significant bits were used to address one of eight 6-bit characters within a store word.

The B-codes were executed by the B-Arithmetic (add/subtract and logical) Unit and operated on one of the 128 24-bit B-registers specified by the Ba field in the instruction, Bm being used to specify a single modifier. The B-store was made up of 120 words of core store together with eight special purpose flip-flop registers. These included the floating-point accumulator exponent, for example, and the three control registers (program counters) used for user program, extracode and interrupt control. Including these three control registers as B-registers avoided the need for separate control transfer (branch) functions. Extracodes were a set of functions which gave access to some 250 built-in subroutines held in the read-only Fixed Store.

Figure 2: Atlas Instruction Format

User addresses in Atlas referred to a 1M word virtual address space, and were translated into real addresses through a set of page registers. The real store consisted of a total of 112K words of core and drum storage, combined together through the paging mechanism so as to appear to the user as a one-level store. System addresses referred directly to the Fixed Store, the Subsidiary Store (used as working space by the extracodes and operating system), or the V-store. The latter contained the various registers needed to control the tape decks, input/output devices, paging mechanism, etc., thus avoiding the need for special functions for this purpose.

A screen image of the HASE Atlas model is shown in Figure 1. Because integers, reals and instructions cannot be mixed together in a single array, the model takes advantage of the Atlas paging system by modelling the Drum Store as a set of pages and the Core Store as a set of blocks, each made up of 512 words, as in Atlas, but with different blocks/pages containing different types of element. This is unrealistic, of course, but was felt to be an acceptable compromise given the intended use of the model.

At the start of a simulation the program and its data are contained in the Drum Store while the Core Store is empty (i.e. contains zeroes). The program code is in page 0 of the Drum, fixed-point integers are in page 2 and floating-point reals in page 3. In the Core Store, Block 0 is modelled as an instruction array, Block 1 as an integer array and Block 2 as a floating-point array. These arrays are themselves loaded from files such as CORE STORE.block0.mem and DRUM STORE.page0.mem when the model is loaded into HASE. The transfers from the Drum Store to the Core Store take place instantaneously “behind the scenes”, rather than being simulated as word-by-word transfers through the Distributer, since this would be extremely tedious to watch in the playback. The Fixed Store and Subsidiary Store are also included as entities in the model, although the Fixed Store is not actually used.

The Atlas instruction set is modelled using the HASE INSTR construct. INSTR allows functions to be grouped together both for decoding purposes and to allow each group to be associated with an appropriate addressing STRUCT. In Atlas, the addressing STRUCT contains three integer values, Ba, Bm and address, and is common to all instructions:

HASE maps the functions within a function group to a C++ enum, so all functions must start with a letter. The INSTR construct was created during the development of a HASE DLX model and because the DLX instruction set is represented using an assembler code nomenclature, this constraint was not an issue. Functions in the Atlas instruction set are represented numerically, however, so three possible solutions were considered to the quandary that this presented: (a) create an assembler code style representation of each function; (b) simply represent instructions using a STRUCT containing four integers (thus foregoing the built-in decoding facility); (c) prefix each function number by ‘A’ for Accumulator functions, ‘B’ for B register functions and ‘E’ for Extracodes. Option (c) was chosen, so the Accumulator group of functions, for example, is represented within the INSTR definition as

(ACC(A314,A315,A320,A321,A322,A346,A356,A362,A363,A374)

This offers some limited insight into the purpose of each instruction but it was felt that an on-screen method of conveying the full meaning of each instruction to the user would be valuable. This was achieved by coding, in the global_fns file, a get_text function that returns a text string for each function, e.g. ‘ b=b+s’ for function B104. This is then displayed on the Control icon (see Figure 1).

Three versions of the model are available from the website, each containing a different machine code program. The first is designed to demonstrate the operation of each of the instructions implemented in the model, while the second demonstrates the operation of matrix multiplication, one of the most frequently used algorithms in supercomputers. The third is an adaptation of a program that finds values for the lengths of the sides of Pythagorean right triangles. This program uses three Extracodes, B multiply and two print instructions. In the model, the B multiply instruction is executed directly in the B-Arithmetic Unit while the print instructions are implemented by the Control Unit and write values into the Subsidiary Store. These values are printed at the end of the simulation run in the output pane of the HASE GUI. An extension of the model could be to implement at least some of the Extracodes using code held in the Fixed Store, as in the real Atlas.

MU5

MU5 was the fifth computer system to be designed and built at the University of Manchester, in succession to Atlas. MU5 introduced a number of new ideas, particularly in terms of its instruction set, which was designed with high-level language compilation in mind, and novel uses for associative stores. The technical aspects of the project have been documented in numerous publications. MU5 became operational in the mid-1970s and ran as a service machine in the Department of Computer Science until 1982. Many of the design ideas developed in MU5 were used in the ICL 2900 series.

Figure 3: MU5 Simulation Model Instruction Set

It was clear at the outset of creating the MU5 model that it would not be possible to use the HASE INSTR construct to accurately represent the MU5 instruction set. The instruction set used in the model (Figure 3) therefore follows the spirit of the original, rather than the detail, in particular because the instruction format and length have to be fixed in HASE, rather than both being variable as they were in MU5. So instructions in the model are represented by a STRUCT containing 4 enumerated types, one each for the type of function, the function itself, the kind of operand and the base register, together with an integer used as a name or literal. Using a STRUCT of this complexity had not previously been attempted in HASE and modifications to the EDL parser were needed in order to process it.

Figure 4: The HASE MU5 Model

Figure 4 shows the HASE MU5 model, the design of which closely follows that of MU5 itself. At the start of a simulation, the address contained in the Control Register (program counter), CO, in the Execute stage of the Primary Operand Unit pipeline (PROP), is sent to the Store Request System within the Instruction Buffer Unit (IBU). The IBU sends this address to the Store Access Control Unit (SAC), which contains a set of Current Page Registers (CPRs). MU5 itself had 32 CPRs, but the HASE model has just four, preloaded such that the first page of Segment 0 (the Name Segment) is mapped to Block 0 of the Local Store, Segment 1 is used for instructions and is mapped to Block 1, while Segment 2 is used for array elements and is mapped to Block 2. Segment 3, mapped to Block 3, is used to contain strings of bytes. Implementing software to manipulate the CPRs is beyond the scope of this model.

SAC sends the translated address to the Local Store, which returns the two instructions contained in the addressed memory word back to SAC, which itself sends these instructions to the IBU. The IBU enters the instructions into its buffer registers (organised as a drop-down stack) and sends each instruction in turn to PROP. PROP processes instructions in a six-stage pipeline, at the end of which it has accessed and prepared the appropriate primary operand associated with each instruction and then, depending on the instruction type, either forwards the instruction to the B Arithmetic Unit or the Secondary Operand Unit, or, in the case of an organisational function, executes the instruction itself. Instructions sent to the Secondary Operand Unit are those destined for the Accumulator Unit or others that require a secondary operand accessed via the descriptor mechanism. In the hardware of MU5, various extra function bits were added to instruction registers in the pipeline in order to control the different activities that could occur at each stage. In order to replicate this mechanism in the model and to represent the bits in a visually meaningful way, each instruction register includes an additional character, the T field shown in Figure 3.

Three versions of the model are available from the website, each containing a different program. Version 1 contains a program that demonstrates the operation of the MU5 Name Store, Version 2 contains a program that executes a scalar product while Version 3 contains a program that demonstrates the use of the string processing instructions. This program performs three tasks. The first creates the composite string “ Hello world” from individual strings containing its component parts. The second finds the first non-zero digit in the digit string 00083576 and places the ASCII representation of its value in the B register. The third searches for the word ‘ light’ in the sentence ‘Let there be light’; the B register then indicates its position within the sentence.

For visualisation purposes, the strings are held in character format in their own block of the Local Store, with each word containing eight characters. These characters are processed using the same simulated hardware as that used for integer values, however, so to get round type checking constraints, the characters are converted to their ASCII integer values and packed into a pair of 32-bit integer words whenever they are read out of memory and, correspondingly, returning integer words are unpacked during a write-to-store operation. Similarly, in the Descriptor Operand Processing Unit, each character is manipulated as an integer value so an extra register is used to display the actual characters.

Part 2 of this article will appear in Resurrection 101.

Data Processing in the 1960s:
The Commercial Union’s Exeter Computer Centre

Introduction.

By the end of the 1950s electronic computers had developed to the point where even the largest business organisations could feel reasonably confident in moving their data and working procedures on from well-established manual and electro-mechanical methods. That is to say, the ability to store huge amounts of alphanumeric information online and to perform calculations on this information reliably and accurately had matured. Big insurance companies were amongst the most demanding applications for electronic computers.

The size and requirements of insurance companies varied widely. Setting aside conventional tasks such as payroll, at the basic end, a computer might be used by a small insurance company just for fund valuation and risk modelling. At the top end, companies like the Commercial Union demanded large scale data processing of many millions of policyholder records.

In this paper we focus on the Commercial Union Assurance Company [CU], one of the UK’s largest in 1960. At that time the CU was progressing from a manually-based, paper-dominated organisation spread amongst very many branches into an electronic network connected to a single large computer centre at Exeter. Besides requiring powerful new computing equipment, the establishment of the CU’s Exeter Computer Centre involved ground-breaking innovations in trans-regional data communications and high-speed document printing

In 1960 the CU had many millions of policy holders worldwide. Within the UK it had a total of 117 branches and sub-branches and about 350,000 insurance agents, each reporting to a branch office. The CU was a leader in all four types of composite insurance: fire, life, accident and marine.

2. Prelude to computerisation: punched card systems.

Before 1953, all Commercial Union data processing was carried out manually by clerks. From the 1930s onwards, some clerks could have been assisted by electromechanical desk calculators for basic arithmetical calculations but in all other respects the insurance business was based on paper documents handled manually. Although some commercial sectors had begun to use punched card equipment, much of the insurance sector – and in particular the Commercial Union – did not make significant use of punched cards before the 1950s.

From 1952 onwards, the CU began to introduce a mechanisation system based on punched card equipment to handle many aspects of its central business. The aim was to unify the company’s main operations into a flow of information that went from the branch offices to one of four Mechanisation Service Centres where the punching and physical storage of the cards took place. The branches remained the control points as far as the many insurance agents were concerned.

The four Mechanisation Service Centres were at Croydon, Rickmansworth and Exeter (two). The CU’s presence in Exeter dated back to 1894, when the CU had acquired the West of England Fire and Life Insurance Company. The West of England Company, established in 1807, “was the sixth largest British insurance office despite the difficulties inherent in its rather remote [sic] location in Exeter”.

Between them, the four CU Centres performed all punching and physical storage of cards centrally. Commercial Union Branch Offices throughout the UK sent batches of typed-up paper documents by post daily to their assigned Mechanisation Service Centre. Punched cards were created and the tabulated printed results were returned to branches by post. The huge numbers of punched cards themselves were held centrally. To give some idea of physical size, data on one million Life policies might need nearly six million punched cards; these six million cards would require about 1,600 cubic feet of storage space. Nevertheless, the general scheme of four Mechanisation Centres formed an excellent organisational basis for the CU’s eventual introduction of a large electronic stored-program computer in 1962 – as described in section 6 below.

Meanwhile, the punched card equipment manufacturers were moving somewhat slowly towards electronic stored-program computers, with intermediate offerings such as the Powers-Samas Programme Controlled Computer (PCC), announced in 1954 and onto the market in 1956, and the Hollerith 550 electronic calculator, first available in about 1957. The Sun Life Insurance Company installed a PCC in May 1959 for “valuation and statistical work and for administration”. The CU installed a Hollerith 550 calculator (at Head Office) in about 1962/3, for calculations of new surrender values. However, these were exceptions. More generally, the CU in common with most insurance companies decided to bypass PCCs and Hollerith 550s and go straight on towards general-purpose stored-program computers.

All large insurance companies had particular needs for bulk storage, fast data transmission and massive amounts of document printing but it was the bulk on-line storage requirement that was the most crucial. The number of policies (in excess of several million) determined the total size of storage required.

3. Bulk on-line storage: what was available in the 1950s?

For strategic and economic reasons American computer manufacturers at first had little interest in pursuing European markets, where post-war currency restrictions in any case rendered European customers less likely to buy American products. By 1955 four British manufacturers had started to deliver production computers: Ferranti Ltd., Elliott Brothers Ltd., English Electric Ltd. and British Tabulating Machine Company (BTM). In addition, upgraded copies of LEO I, known as LEO II, were produced by Leo Computers Ltd. for sale on the open market from 1958.

In 1955 not one of the above manufacturers could supply a computer equipped with on-line facilities such as magnetic tape devices for storing the huge volumes of information being held as millions of punched cards by organisations such as Commercial Union. In this respect, all the UK’s computer manufacturers lagged behind their American counterparts.

By the end of the 1950s emerging industry standards for magnetic tape tended to follow IBM’s lead, whose half-inch tape systems gave a transfer rate of 15K characters/second, In contrast, the British company Elliott, which initially led the UK field, was using 35mm magnetic Film systems for its Elliott 405 computers. Each reel of magnetic film held about 1.4 million characters with a transfer rate of only 0.3K characters/sec. The Legal & General Group installed an Elliott 405 computer in October 1958 for “payroll, maintaining and processing policy records of group life and pension schemes”.

The Elliott 405 was based on thermionic valve technology. More cost-effective machines, based on transistor technology and with higher-performance magnetic tape systems, were on the horizon. The Commercial Union watched and waited.

4. Selecting the Commercial Union’s first computer system.

4.1. Candidate computers.

Commercial Union’s Frank Knight oversaw the choice and installation of the company’s first general-purpose computer. He evaluated tenders from six British computer manufacturers during the period spring 1959 to spring 1960. Frank Knight reported that “each manufacturer was able to supply machines adequate for all [our] operations but prices, speeds, potential for expansion and the extent of built-in accuracy standards all varied”.

Table 1 shows that, by the early 1960s, seven British computer companies had announced their intention to supply machines suitable for (large) business data processing applications. All the computers in the Table were based on transistor technology.

Two points should be born in mind when interpreting Table 1. Firstly, as mentioned earlier, insurance companies came in different shapes and sizes so entries in the right-hand column need to be interpreted in context. Even the largest companies had specialist tasks that might suggest the use of small computers for part of their business. For example, the Commercial Union installed an English Electric KDF6 computer in about 1964 in its Head Office in central London, “to address the triennial Life Valuation task”. Secondly, price depended on two factors: (a) equipment configuration and hardware options; (b) system software facilities, degree of customer programmer training and support, etc. Customer requirements varied widely. To put the prices in context, in 1962 a four-door family saloon car typically cost about £700. The motoring extremes in 1962 were represented by an Austin Mini at £496 and a Rolls-Royce Silver Cloud II at £6,272.

In April 1960 the Commercial Union finally chose an English Electric KDP10 computer system, at a cost of £297,000 (or £87,000 per annum if rented). It was “the cheapest of the systems considered”. This was in fact the very first installation of a KDP10; it was planned to come into operation in 1962 in a specially-build Computer Centre in Exeter.

4.2. The English Electric KDP10.

The KDP10 computer was based on the American RCA501 machine, which had first been announced in 1958 and which, by 1960, had been purchased by two American insurance companies amongst several other organisations. The KDP10 used printed circuits, transistors and a ferrite core store. The core store was available in increments of 16K character locations, up to a maximum of 256K characters. Various types of peripheral equipment were available. 7-track paper tape was standard, the paper tape reader operating at 1,000 characters/sec. The paper tape punch operated at either 100 or 300 characters/sec. The Card Transcriber read in 80-column cards at up to 400 per minute and wrote the information to magnetic tape. There was a 600 lines/minute Lineprinter. Faster off-line Xeronic printers were available – see below.

What other characteristics might have made the KDP10 stand out amongst the six prospective candidate computers assessed by the CU?

Firstly, the whole KDP10 system design emphasized magnetic tape as the main (long-term) operational medium. Up to 62 tape decks could be directly addressed. Magnetic tape transfer rates were: 16K or 33 K characters/sec. when writing; 33K characters/sec. when reading. (By 1964, English Electric had increased the transfer rate to 66 K characters/sec.) There were 16 channels across the tape, which was ¾ inch wide. Duplicate (i.e. dual) recording was used, meaning that a single lost bit could be tolerated.

The second attractive characteristic of the KDP10 for business applications was that it was a true variable item-length system. Use of control symbols and the ability to address each character location individually permitted the length of any item in any message to be in strict accordance with that item’s actual character count. This allowed for total variability of item and message length. Decimal arithmetic as well as binary arithmetic was provided in hardware.

The third attractive characteristic of the KDP10 was its error-detection facilities. Arithmetical operations were checked by repeat operations using the complements of the operands. Information-transfers were checked by parity. Breakpoints were available to aid program debugging. Rollback was provided upon error-detection.

More technical details of the English Electric KDP10 computer, and a fuller version of this article will be found on the OCH website.

There remain two additional areas of special KDP10 equipment relevant to the Commercial Union’s installation: (a) communications equipment connecting remote branches to Exeter; (b) the high-speed printing of results. Details of these are now given.

5. Special equipment for the CU’s Exeter installation.

5.1. Data transmission: the Swift system.

In Britain in 1959, telex was the only practical data-transmission facility available nationally. Accordingly, the Commercial Union performed experiments in which 5-track paper tape was produced remotely, fed into a CU branch’s telex machine and the data sent by GPO line to a central telex receiving unit at Exeter. Here, 5-track tape was produced and fed to an ICT 1036 tape-to-card converter for test purposes. The 1959 experiments revealed two disadvantages of telex transmission: (i) the data transmission-rate, 50 baud, was slow; (ii) the telex system had no parity bit or other method for error-detection.

By the late 1950s 7-track paper tape systems were coming into use. These clearly allowed a richer character set (64 instead of 32 possibilities) but, importantly, they included a parity bit for error-detection. Accordingly in 1961 experiments were conducted between the Commercial Union’s Brighton branch office and the Exeter Mechanisation Centre, using prototype PT750 transmission equipment designed by Automatic Telephone and Electric Co. A typist in Brighton prepared 7-track paper tape on a Friden Flexowriter. This tape was fed via a Ferranti TR5 paper tape reader into the AT&E equipment and transmitted using phase modulation at 437 baud (or about 62 characters/second) to Exeter. These were the days before Subscriber Trunk Dialling so transmission over the public telephone network was arranged to be in prolonged uninterrupted (PUT) mode. Transmission over the public network did have some oddities. The Post Office ‘pips’ could under certain circumstances be interpreted as meaningful data so the Post Office was persuaded to drop the use of pips for CU transmissions. Experiments during 1961 indicated that the overall expected transmission error rate was under 1.5 errors in a million transmitted characters. Accuracies were acceptable enough for the CU to use the equipment in October 1962 for demonstration transmissions between CU offices in London and New York using the Telstar satellite. Successful live query-answering transmissions were also used between Paris and Exeter in the same month, at an international conference.

As a result of these and the Brighton/Exeter experiments, it was decided to equip all of the Commercial Union’s approximately 40 main branch offices with a data-communication set-up consisting of three sub-units: (i) a Friden Flexowriter, (ii) a Ferranti TR5 paper tape reader and (iii) an AT&E PT750 transmitter for sending data over the telephone network to the CU’s new Computer Centre at Exeter. Connection between Exeter and all of the CU’s 40 main branches was done office-by-office, taking many months following the KDP10 computer’s installation. The first branch connection started with Dundee in 1964. Training branch staff and equipping branches was achieved “at the rate of one or two per month”.

Eventually this interconnection network, which became known as the Swift system, created a total traffic into Exeter of about 1.5 million characters per day over a period of two hours using four receivers.

At Exeter, data received from branches was first automatically punched onto 7-track paper tape. The reels of tape were then fed into the KDP10 computer via three fast (1,000 characters/second) paper tape readers at a pre-arranged time in the central computer’s daily operating schedule. This ensured that the KDP10 was not kept waiting for late-arriving data from a particular CU branch office. Of course, this was before the days when on-line communications equipment became the norm. However, as was observed in a contemporary comment on the Commercial Union’s experiments, IBM in 1962 was “offering real-time channels which incorporated buffers for assembling messages at line speeds and transferring these into the main store, after checking, at memory speeds”. The high cost of using such equipment to service all 40 of the Commercial Union’s branches at speed is not mentioned.

5.2. Xeronic high-speed off-line printing.

Figure 1: One of the two Xeronic high-speed printers installed in Concorde House, Exeter.

The Commercial Union issued several types of Insurance documents – policies, claims forms, etc. – each with a particular layout. Furthermore, the required volume of document production was huge. For example, renewal documents for some 30,000 policies were required to be printed each day. Such volumes were well beyond the capacity of conventional computer equipment of the 1950s.

Accordingly, the CU spent a year in discussions with Rank Xerox Ltd. on the provision of novel printing facilities. The result was the Xeronic high-speed printer, whose first public demonstration in 1960 used CU documents as the examples.

A Xeronic printer was rated at a speed of 3,000 lines/minute. Two images were simultaneously projected onto the paper: (i) a standard form layout; (ii) the particular characters to be inserted on this form. Since the printer could switch rapidly from one form-image to another, documents could be printed in the order in which they were to be despatched, ready and addressed for use with window envelopes. Each Xeronic printer used a 26” wide roll of paper and could print documents at the rate of 40 ft of paper a minute. Each roll of paper ran for about 50 minutes before a re-load was needed. Between 80 and 90 renewal forms could be printed per minute, equivalent to about 4,500 per hour. A Xeronic printer is shown in Figure 1.

At Exeter, the CU installed two Xeronic printers, working off-line from data provided on magnetic tape by the KDP10 processor. One magnetic tape deck could feed both printers. Each printer had to be stopped for about five minutes every hour for off-loading the printed output and inserting a new roll of blank paper.

6. The Exeter Computer Centre.

Figure 2: The twin-processor KDF8 installation in Concorde House, during the daily maintenance period. The three men on the left are English Electric engineers. The two people standing at the console are CU staff. On the left is Dave Barwell; on the right is Alan Mazonovich.

A new four-storey, 36,000 sq. ft floor area, custom-designed building called Concorde House was opened at the end of 1961. The English Electric KDP10 computer was delivered in January 1962. The machine was nicknamed CUTIE, standing for Commercial Union Totally Integrated Electronics, with the implication that from henceforth most of the company’s business would be ‘integrated’ within a single system. Amongst the special facilities installed at Concorde House were the Swift data-transmission equipment and the Xeronic high-speed bulk printers.

At first, CU ‘programmers’ were all male. They produced flowcharts on large sheets, on which each box was a (group of) pseudo-instructions. Then women ‘coders’ produced the actual KDP10 coding sheets based on the flowcharts. David Olphin believes that “men were felt to be creative and women accurate!”.

The overall vision was that the new Exeter Computer Centre would absorb from Branch Offices the issuin of policies and endorsements, the maintenance of records, the renewal processes and all work on accounts and statistics. It would eventually also provide for internal Commercial Union administrative activity such as payroll, budget forecasting, name and address indexes, etc.

To quote Frank Knight, “The effect of using a computer in the manner described is to limit the work of the clerical staff of the company to what is of first importance: public relations service. The branch staffs are able to concentrate on interviews and correspondence concerned with arrangement of policies, settlement of claims, disposal of queries, and provision of decisions and advice. When the results of this work are sent as data to the Computer Centre, the latter becomes fully responsible for checking, issue of documents, all functional running – the whole being completely self-checking and guaranteed to a high degree of accuracy”.

However, the actual coverage provided by Exeter was more modest and evolved more slowly than had been hoped. Peter Monk remembers that initially the Exeter system “covered the policy records, financial records etc for Personal and Domestic General Insurance. This included matters such as house content, house property, private and commercial vehicle insurance. It famously produced statistics, the life blood of the underwriting world that had been weak previously. It didn’t incorporate claims, and it didn’t extend to other classes of insurance such as the CU’s Life business”. The Life side was not fully computerised until much later.

The target in 1962 was to process five million policies per week. Each policy record averaged 350 characters. The eventual daily computing load was to handle 1,000 new policies, 5,000 policy alterations and 28,000 policies affected by cash payments. Data would be arriving daily from several tens of branch offices or departments.

In 1962 the plan called for two main computer runs per day. In brief:

By late 1965 the above scheme was extended by the introduction of Two-Shift working. During 1965, twin KDF8 processors replaced the KDP10 in Concorde House. Figure 2 shows the Commercial Union’s upgraded computer room. Each KDF8 had 131K characters of core store and 13 tape decks per machine.

7. What came next?

Work at Exeter continued apace until March 1968, when the KDF8s and the Commercial Union’s entire computing equipment were moved from Exeter to Whyteleafe in Surrey, to spacious converted factory premises ten miles south of central London. The CU sold Concorde House in Exeter, the building eventually being converted to house 28 one and two-bedroom apartments.

Why did the CU’s Computer Centre move? Surrey was clearly closer to the company’s London headquarters but wages in Surrey were higher than those in Devon. Space was one reason for the move. At Whyteleafe there was plenty of room for expansion. Indeed, at Whyteleafe a new computer system was installed alongside the KDF8s (see below), with a period of co-existence before the new system took over.

By the end of 1968 all the CU’s core business had been transferred to the two KDF8s. To supplement the two KDF8s, an ICL 4/40 was rented. All this equipment was installed at Whyteleafe. During 1969 a number of Head Office jobs (e.g. investments, share register) were converted to another ICL 4/40, installed in Head Office in London.

In due course the CU switched from the KDF8s to English Electric Leo Marconi System 4 computers, which were based on the American RCA Spectra 70 range and were IBM 360 compatible. Programming for the KDF8 had been mainly in KDF8 Octal machine code until the System 4s arrived and Usercode (IBM Assembler) was adopted. Eventually the CU moved to COBOL and the IBM 360/370 range of mainframe computers.

In 1970 it was decided to hire two ICL System 4/70 configurations. These would provide capacity to undertake all CU core business and all Head Office jobs and provide facilities for the later use of remote data terminals. The two KDF8s and the two Xeronic printers, by now showing their age, were offered free of charge to educational institutions and the 4/40 at Whyteleafe was returned to ICL.

The Commercial Union itself continued to flourish. Its Whyteleafe Computer Centre was eventually closed down at the end of 2001, following the CU’s mergers with the General Accident Company in 1998 and then with the Norwich Union – the resulting entity changing its name to Aviva in 2002. All computing activity was subsequently centralised in Norwich.

Obituary – Kathleen Booth

Roger Johnson

Kathleen Both Working on APE(X)C

Kathleen Hylda Valerie Booth (née Britten) who died on September 29^th 2022 at the age of 100 years was one of the last of the very first generation of UK computer pioneers. At the end of the war she joined Birkbeck College, London as a research assistant in a small group led by Andrew Donald Booth automating crystallographers’ calculations.

Starting in late 1945, the Booths began building their Automatic Relay Calculator (ARC). In 1946 Andrew Booth spent six weeks with John von Neumann at Princeton and in 1947 he returned with Kathleen Britten for a six month visit again based at Princeton. This led to the redesigning of ARC1 with a “von Neumann” architecture (ARC2). In 1949 work began on the Simple Electronic Computer which led to the best known All-Purpose Electronic Computer (APEC).

The construction of these pioneering machines led to a number of fundamental contributions to computing technology. Firstly, ARC2 needed a memory which was provided by a drum, the world’s first rotating computer storage device. Secondly, the computers needed a fast multiplier in the form of the Booth multiplier which appears today on billions of chips every year.

In 1950 the circuits from APEC were traded with BTM who used them in the ICT 1200, the UK’s first mass selling computer with over 100 sold across the world.

In 1962, following a disagreement at Birkbeck, they emigrated to Canada. They remained active in both academic and practical computing. Andrew died in 2009. They are survived by their daughter and son, Amanda and Ian, to whom we send our condolences.

Review – The History of Computing: A Very Short Introduction

This book is a very welcome addition to Oxford University Press’s celebrated Very Short Introduction series, which now has some 500 titles.

As one would expect from Doron Swade, this book is not a traditional abacus-to-smartphone history. This book is also a thoughtful discussion of what properly constitutes the history of computing as a field of study. When did it begin and who writes it? What are the boundaries? Swade locates the beginning of the study of the history of computing in the 1970s with Brian Randell’s Origins of Digital Computers (1973) and the 1979 launch of Annals of the History of Computing. In the early years the history of computing tended to be written by practitioners (such as Randell) and later by historians of science, technology and business. More recently social historians have taken up the subject.

Doron answers the question “what should be studied?” with his well-known “river diagram”. In this view the founding tributary of today’s “information age” is calculation – from finger-counting to the electronic pocket calculator. Next, automatic computing started with Babbage in the 1820s but did not fully blossom until the electromechanical machines of the 1930s and 1940s. Information management began with record-keeping in the prehistoric era but flowered with office machinery, especially punched-card machinery in the 1890s. The newest tributary is communication – from fire-beacons to the internet.

The book follows this discussion with chapters on calculation, automatic computation, and electronic computing. All of these have a commendably internationalist perspective. A chapter on the computer boom takes us through the familiar territory of the rise and rise of IBM, real time computing applications, and the ascent of System/360. Next comes the revolutionary era of semiconductors, Moore’s law, mini- and micro-computers, and the rise of Microsoft, Apple, and the personal computer.

In the closing chapter Swade reflects on the question: What should be the new master narrative of computing? We have long since moved on from portraying the computer as a “scientific tool”, that dominated the early studies. The computer as an “information machine” served well for practically a generation, but now fails to capture much of the 21^st century computer landscape in the era of the social internet and regulatory conundrums over issues such as fake news. This is the challenge for the coming generation of historians.

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

Philips makes a move into OCR market: In what represents the first real move into the difficult OCR market for the giant Philips group, MEL Equipment, a UK subsidiary based at Crawley, Sussex, has announced a flexible high performance system for both page and document reading which costs less than £40,000. Known as the X1300, the new reader has been developed entirely at the Crawley centre. This plant will also be responsible for all manufacture of the X1300, which was officially announced this week at Computer 72 and simultaneously in Holland, France, Germany and Belgium. (CW 7/12/1972 p2)

Ferranti graphics package: Advances in circuit technology, graphics accessory modules and the advent of the Argus 500E processor has enabled the Electronic and Display Equipment Division of Ferranti Ltd to introduce the Compact Graphics package. This is a flexible kit of parts, so called because it is possible to put all the main items of equipment except the display screen into a single six foot rack. Apart from the display screen unit and the 500E 24-bit word processor, the package contains an MD3/4 display controller and a wide choice of input and output peripherals. Standard CRT displays include 11, 21 and 26 inch diagonal tube sizes with others available to special order. Displays are random access types, available with dual video inputs for two level brightness working, and have high linearity to enable accurate graphical and format work. Display features include the drawing of solid or dashed lines, circles, ellipses and quadrants. Complete pictures as well as special symbols can be drawn and stored. Character sets include upper and lower case Roman and Italic in four sizes, the smallest allowing 64 lines of 128 characters to be displayed. According to Ferranti the Compact Graphics package is particularly suitable for the smaller user and for research and experimental establishments. (CW 7/12/1972 p31)

Gas grid gets telemetry network: Using 15 Computer Technology Modular Ones, two Ferranti Argus 500s and software and system commissioning services from Logica, a telemetry network for the control of the UK natural gas grid has been accepted by the Gas Council and became fully operational last month. The telemetry service is made up of three separate but interrelated systems – 12 Mod Ones used as Data Reduction Computers (DRCs) with one located at each of the national Area Gas Boards supervising telemetry outstations; three Mod Ones at the main Hinckley Operational Centre (HOC), Leicestershire, acting as a front-end processor to two Argus 500s and as processor stand-bys; and the HOC Ferranti System 40 operational displays controlled by the Argus 500s. (CW 14/21 Dec 1972 p28) )

Two models added to H2000 range: Two new models have been added to the medium size Series 2000 range by Honeywell at the lower end, intended to compete on a price/performance basis with computers such as the IBM System 3, Burroughs 1700, NCR Century 50 and Univac 9200, according to the company. The new systems are designated the 2020 and 2030, and fit between the Model 58 and the 2040, according to Honeywell. In this respect they offer an alternative to the company’s existing 115/2 and 1200 systems in the Series 200 range, but whereas these are intended for conventional data processing, the Series 2000, announced earlier this year is more communications oriented. (CW 28/12/1972 p16) )

Credit card system for automatic fuel: The first commercial application for the updatable credit card system developed by Revenue Systems Ltd, and now called Money Card, is to be in the field of automatic fuel dispensing. The application has been developed by Automatic Fuel Dispensing Ltd, of Harpenden, Herts, a jointly owned subsidiary of Revenue Systems and Automation Devices, of Launceston, Cornwall, which has been marketing automatic fuel dispensers operated with prepaid cash for some time. With Money Card a customer wanting petrol from a garage simply has to insert the card into a terminal on the forecourt and key in his¹ card code number. This will activate the pump he¹ requires and as he¹ draws petrol his¹ credit status which is magnetically encoded on the card is automatically updated. At the same time his¹ code number, credit status before and after, the sale, and the amount involved in the sale are recorded on a printer inside the terminal to provide a record for the garage. The terminal also produces a receipt for the customer. (CW 4/1/1973 p2) )

^{1. Were women also allowed the use of this system? Answer came there none.[ed]}

More features added to DECsystem-10: New features announced by Digital Equipment to extend the capabilities of the large-scale DECsystem-10 processors include a remote terminal, memory units and some items of software. As well as supporting card reader and line printer, the new DC72 remote station, priced from £11,100, can also connect up to 16 typewriter or VDU terminals to the central DECsystem-10 machine. The new memory unit, called MF10, is priced at £41,300 for 64K 36-bit words, 60 per cent cheaper than existing DECsystem-10 core. Although the basic cycle time is still about the same, at a microsecond, overlapped memory control logic in the MF10 unit allows the CPU to transmit a second message while still awaiting the outcome of a previous instruction, so achieving an effective increase in processing speed. (CW 4/1/1973 p5) )

Potter’s diskette challenge to IBM: A challenger to IBM’s revolutionary 3740 diskette data entry system using floppy discs has been launched by Potter Data Products Ltd. It has already been announced as the DDS 1073 diskette data station in the US, where it is unique as the IBM system has so far been only announced in continental Europe. An announcement is expected over here within the next month. The 1073 consists of a keyboard. processor, printer and floppy disc unit, this being the DDS 480 unit which Potter announced last summer. A sample price quoted is about $7,500 (£3,125) for a unit with 4K processor. The floppy disc is a small flexible disc about eight inches square which is used for much the same purposes as a magnetic tape cassette, but has the advantages of random access. It was introduced by IBM as a microprogram storage device for the 370 series. (CW 11/1/1973 p1) )

MDS 2021 cartridge tape drive for the UK: The first cartridge tape drive to emerge from MDS Data Processing Ltd, the MDS 2021, has been introduced to the UK market just six months after the US launch. Available in nine versions, as a desk-top console, a panel mount assembly and a mechanism-only configuration, with single, dual or four-track recording, prices start at £100. The 2021 incorporates the 3M DC 300A Data Cartridge, which consists of two quarter-inch wide tape reels, 300 feet of magnetic tape and a drive system. The cartridge is packaged so that the tape need never be touched by hand. The recording head is a dual gap, read after write device with a spacing of 0.15 inches between gaps. Input receivers and output drivers are TTL circuits. The recording format used to store data on the tape is determined by the controller, with the density varying from 800 to 1,600 bpi. The cartridge transport writes forward, reads forward and backspaces at 30 inches per second, while fast forward search and tape rewinding carried out at 90 ips. (CW 18/1/1973 p11) )

Firefighters aided by H316s in Glasgow: The first computer system in Britain to provide a dedicated online firefighting information service has been ordered from Honeywell by Glasgow Corporation Fire Department. Glasgow has suffered a series of tragic fires over the last year and the new system will help in the fight against this menace. The system is based on a duplex Model 316 which will be able to provide detailed information on buildings and fire hazards directly to the cabs of the city’s fire engines as soon as the alarm has been raised. The 316 will be linked to each fire engine by a radio network which will feed a facsimile printer installed in each cab. Up to 40 fire engines are to be equipped in this way. The computers will be installed at Glasgow Central Fire Station and are due to come into operation during June and July. A database is to be created which will initially contain information on about 4,500 buildings in the city, building up to 10,000 in two years. This data will be gathered by fire officers in the normal course of their inspection work and will include plans of the buildings, details of occupants, and all known hazards. This information will be updated daily from routine inspection reports. (CW 18/1/1973 p17) )

PDP-11 at the heart of new ‘bleep’ PO service: At the heart of a new Post Office service which will enable people to be contacted via small radio receivers activated by a telephone call is a 28K byte Digital Equipment PDP-11 at the Reading trunk telephone exchange. Each user of the service will have a portable receiver which will emit a high-pitched ‘bleep-bleep’ signal when a unique 10-digit code is dialled over the public telephone network. At present the service is based at Reading and covers about 500 square miles of the Thames Valley. The PDP-11 is used to check that the 10-digit code is valid and then initiates the relevant radio signal to be transmitted to the paging equipment. The caller is also informed by a recorded message that the paging request has been accepted. In the trial scheme, two signals are transmitted. The first, which lasts for 2.7 seconds, will cause all available receivers to switch on and decode the signal and only those which respond to the first signal will be available for the second tone, which is transmitted for 0.8 seconds. There is a unique combination of tone pairs for each receiver so that only the relevant device will emit a bleep. The user of the service can then take some pre-determined action, such as telephoning the office or home. Future plans for the service, which the Post Office hope will eventually be nationwide, include providing three different types of ‘bleep’ to provide more action options for the user. (CW 25/1/1973 p5) )

PO network to be tested by users: The important experiment into the feasibility of setting up a national packet switched data transmission network in the UK will start at the end of 1974 and about a dozen organisations have already committed themselves, in principle at least, to take an active part in the evaluation. Last week the Post Office sent out a manual outlining the facilities and requirements of the service to about 100 groups, including large companies, bureaux, manufacturers and universities, together with a ‘letter of intent’ which must be signed by anyone wishing to become a user of the EPSS (Experimental Packet Switched Service). One of the first companies to sign up was British Olivetti, whose DP product manager, Lance English, described the Post Office’s attitude towards open involvement of users from an early stage as ‘an enormous step forward’. Other users who have committed themselves in principle, if not formally as yet, are understood to include BOAC, Edinburgh Regional Computing Centre, Scicon, Data Dynamics, Univac and CRC Information. Although he is aware that there are many difficulties to be ironed out during the experiment, such as the important question of how users will be charged for using the service, Mr English feels that the EPSS ‘makes sense because we must be approaching the limits of the number of data paths available on physical media and packet switching seems to make optimum use of physical resources’. This is because in a packet switched network data is transferred in discrete packages preceded by a ‘header’, which includes the address of where the data is to go and ended by a ‘tail’ containing error checking information. Once entered into the system, the packet reaches its destination via routeing its packet switching exchanges (PSEs) which means that a two-way dedicated line need not be connected between transmission points as with existing circuit switching systems. (CW 1/2/1973 p1) )

Plessey system to regulate gas supplies: Supplies of gas to some 540,000 consumers in Wales are to be regulated by a £750,000 computer supervised telemetry system which is now being brought into use by Wales Gas from a control centre at Grangetown, Cardiff.

Designed by Plessey, the system, claimed to be one of the most advanced of its kind, will eventually use three Honeywell computers, two 316s and a 516, to scan outstations, control valves and gas flow, process data and work out analyses and forecasts. At the Grangetown control room, engineers seated at a 20-feet long control desk will be able to assess the flow of gas, check pressures and activate valves at outstations throughout Wales. Alarm signals will indicate abnormal states such as pressures becoming too high or too low, or when there are insufficient stocks of gas. The two operator positions at the desk each have a visual display unit and control keyboard, a back projector with a magazine containing 80 slides to give information about the network and outstations, and a telephone link to all essential Post Office lines and private wires. Instructions to the system are given through the keyboard and displayed on the operator’s VDU (CW 8/2/1973 p31) )

UK link to ARPA in use by June: The experimental data link between the UK and the Advanced Research Project Research Agency’s ARPA network in the US is expected to start operation by June when an Interface Message Processor (IMP) for front-ending the UK side of the operation, is scheduled to become operational at London University Institute of Computer Science. The IMP unit, supplied by ARPA, will eventually be linked in the experiment with the institute’s Digital Equipment PDP-9 machine, and to London University’s Control Data 6600 and the IBM 370/195 at the Science Research Council’s Rutherford Laboratory at Chilton. In the experiments, data will be transmitted by high speed line to a seismic experimental centre in Norway equipped with an IBM 360/44 and then by satellite to the Seismic Analysis Centre, near Washington, DC, which is linked directly to the ARPA network. The UK end of the experiment is being funded largely by the National Physical Laboratory. The IMP is being supplied free of charge, ARPA itself is supplying over £20,000 of computer time, and the Post Office is not going to charge for the use of the direct line to Norway during the first year of operation. The project, which will bring US computing power to the UK ‘within weeks’ of the IMP becoming operational, makes no commitment to provide anyone with computer service, but the NPL obviously have a vested interest in the scheme as they are subsidising it to the tune of about £5,000. (CW 15/2/1973 p2) )

Forthcoming Events

Face-to-face meetings at the BCS in London have now been resumed. It is as yet uncertain when Manchester meetings will recommence.

However, in view of the success of the online Zoom meetings that have taken place over the last year in allowing many more members to attend, we are now operating in hybrid mode by making meetings available over Zoom as well as in person.

London Seminar Programme

London meetings take place at the BCS — 25 Copthall Avenue Moorgate EC2R 7BP starting at 14:30. The venue is near the corner of Copthall Avenue and London Wall, a three minute walk from Moorgate Station and five from Bank.

However, in view of the success of the online Zoom meetings that have taken place over the last year in allowing many more members to attend, we will now operate in hybrid mode by making meetings available over Zoom as well as in person.

You are strongly advised to use the BCS event booking service to reserve an in-person place at CCS London seminars in case the meeting is fully subscribed. Web links can be found at www.computerconservationsociety.org/lecture.htm . The service must also be used for remote attendance.

For queries about meetings please contact Roger Johnson at

Manchester Seminar Programme

North West Group meetings take place take place in the Business School of Manchester Metropolitan University Chester Street, Manchester, M1 5GD: 17:00 for 17:30.

We are expecting to resume Manchester meeting in early 2023. No details yet but please put 31^st January, 28^th March and 30^th May in your diaries and keep an eye on the website.

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 Museum in Manchester are run every Wednesday, Thursday and Friday between 10:30 and 13:30. 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 Normally open Tue-Sun 10:30-17.00 but at present opening days are somewhat irregular so see www.tnmoc.org/days-open for current position Situated on the Bletchley Park campus, TNMoC covers the development of computing from the “rebuilt” Turing Bombe and Colossus codebreaking machines via the Harwell Decatron (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 Mathematics Gallery has the Elliott 401 and the Julius Totalisator, both of which were the subjects 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.

North West Group contact details

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 objects of the Computer Conservation Society (“Society”) are:

• To promote the conservation, restoration and reconstruction of historic computing systems and to identify existing computing systems which may need to be archived in the future;
• To develop awareness of the importance of historic computing systems;
• To develop expertise in the conservation, restoration and reconstruction of historic computing systems;
• To represent the interests of the Society with other bodies;
• To promote the study of historic computing systems, their use and the history of the computer industry;
• To publish information of relevance to these objectives for the information of 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 a grant from BCS and donations. 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.