Resurrection Home Previous issue Next issue View Original Cover



The Bulletin of the Computer Conservation Society

ISSN 0958 - 7403

Issue Number 7

Autumn 1993


Editorial Nicholas Enticknap, Editor
Guest Editorial Sandy Douglas, Committee member
Society news Tony Sale, Secretary
The CCS and the Science Museum - what now? Doron Swade
Obituary: John Cooper Chris Burton
The Problems of Software Conservation Doron Swade
George Alfred Julius and his Automatic Totalisator Charles Norrie
The design of Pegasus Ian Merry
Working Party Reports  
Letters to the Editor  
Forthcoming Events  
Committee of the Society 
Aims and Objectives 

TopPrevious Next


Nicholas Enticknap, Editor

This issue of Resurrection is the largest we have yet produced, reflecting the fact that the through a most eventful period. The most significant development has been a change in our relationship with the Science Museum, which has resulted in the movement of most of our restoration activity to Blythe House, Olympia, and of the secretariat to Tony Sale's home in Bedfordshire. It will take time to work out the full effect of these changes: the position as we know it at the moment is described by Tony on page 5 and by Doron Swade on pages 7-11.

Sadly, we have to record the death of one of our leading lights, John Cooper. John was the leader of the highly successful Pegasus restoration project, the most celebrated of the Society's achievements. Chris Burton, a member of John's team who has taken over his responsibilities as working party chairman, pays tribute to John on page 12.

The Society now has a second Pegasus restoration project under way, this time in conjunction with the Manchester Museum of Science and Industry. This provides members in the north-west with an opportunity to take part in a restoration project for the first time. Further details can be found in Society News.

This makes it an appropriate time to recount the Pegasus design story. Ian Merry's description of the process is one of three feature articles in this issue. The others desibe the development of the Society's totalisator, and the problems and issues that face us in our attempts to preserve software. We also publish three letters from readers, all responding to items that appeared in previous issues. We welcome such letters, especially when it is a question of putting the record straight.

We are grateful for the good response to our plea in issue 6 for help with the Society's archiving project. We now have another opportunity for members who would like to play a part in our activities but who do not have technical or engineering skills.

Pat Woodroffe has painstakingly produced transcripts of nearly every one of our talks and seminars since the Society was formed in 1989. He now feels he would like some assistance with this task. Any member who has an audio cassette recorder and a word processor and would like to help should contact him direct, or alternatively the Secretary. Contact information can be found inside the back cover.

Top Previous Next

Guest Editorial

Sandy Douglas, Committee member

At the age of eight my parents brought me to live in Cromwell Road, near what used to be the London Air Terminal, only it was open space then. A 74 bus ride for one old penny took me to Exhibition Road, from which I could go towards South Kensington station to my father's office (which is still there) and workshop (now demolished) down by what became the Elysée Française. Alternatively, I could turn north to the Science Museum - a trip I took often.

The winter of 1938-39 sticks particularly in my memory, because we had a white Christmas, and my girlfriend (now my wife) and I made a snowman in the grounds of the Natural History Museum, near the tunnel exit. The tunnel is now much as it was then, except for the mosque exit.

In those days the special attraction of the Science Museum for me was the basement room where the working models were on display. One could learn about various methods of pumping up water by turning handles or pressing buttons. Some, like the Archimedes screw, are still in use on the Nile today. There was also a colour spectrum to look at, from which I learned that two people did not necessarily have the same perception of colours - my wife and I still argue about the blue/green interface we discovered we viewed differently.

During the Blitz in 1940-41 my Home Guard Unit, 'C' Company of the Chelsea and Kensington Battalion of the KRRC, had its headquarters in the basement of the Royal School of Mines, just the other side of Exhibition Road from the museums. We were never actually called out to protect them - my duties mostly took me to the north end of Albert Bridge where we had a defence post, or riding around on a bicycle as a messenger.

Many of the staff were engaged in fire watching, of course, and crossing the road at night was hazardous due to the occasional bit of shrapnel from our own A-A which was more liable to fall on one than a bomb. Luckily the Museum - and my favourite room - survived reasonably intact.

Things have changed at the Museum, and a much expanded do-it- yourself section on the first floor delighted two of my grandsons when I took them there recently. The Director and his staff are to be congratulated on the attractive way in which things are presented. Doron Swade has been a splendid contact point for the CCS and has initiated us into the preservation 'rules' for equipment. Given this background, it has been an especial pleasure for me to take part in the work of the CCS and help to preserve working artefacts from an earlier stage of our industry.

The Pegasus holds an especial place in my affection, it being the machine I installed as the central University machine in a disused chapel in Leeds in 1957 - it was known as Lucifer, for Leeds University Computing Installation (FERranti). Our au pair girl from Spain made a beautiful little devilish doll which decorated the machine - it has probably disappeared by now.

In 1980 I worked out that an Apple with two floppy disc drives was about 300 times as powerful as the Pegasus at 1/300th of the cost. Today we can assume that a further reduction of 100 times in cost per operation has taken place, though I haven' t done the sums with a 486-based micro. We must also bear in mind that the Pegasus represented an improvement of at least tenfold in cost per operation over earlier machines. An industry that has reduced its cost per operation by a factor of 10 million or so over 45 years is surely unique and certainly not easy to keep pace with mentally.

We are now faced with the problem of what to do about software. The article, like a book, is easy to 'preserve', but to run it requires the original hardware or an emulator.

Martin Campbell-Kelly has built an emulator of EDSAC I, and can run the programs on it. But it is difficult, even impossible, to give the flavour of what they did without the photoreader and the screen, since the ability to use these as input or output in unconventional ways, as in my noughts and crosses program where the players interrupted the light beam to input a move and viewed the storage monitor to see the 'board', cannot readily be reproduced on the emulating equipment.

The matter becomes even more awkward with micros, where programs of similar nature, eg Wordstar, Wordperfect and Word, have been implemented on several different machines so as to look as nearly alike as possible to the user. No doubt this will be taken up by the CCS Working Parties in due course and some solutions found for working presentations, which must be our aim.

All of us on the Committee look forward to welcoming assistance from whatever quarter, in our efforts to carry forward a memory of this fascinating and fast changing industry in working order!

Top Previous Next

Society News

Tony Sale, Secretary

There has been a significant change in our affairs since the last issue. The Science Museum needs the space in the Old Canteen building where we have been working since the CCS was formed in 1989, and we have accordingly now moved to a new location: Blythe House, which is in Blythe Road, Olympia, London W14.

We have moved most of our computers and associated equipment to Blythe House already. Some equipment which is not immediately needed has been moved temporarily to premises in Bletchley Park.

Pegasus is also an exception, as it is far too delicate to be moved unless absolutely necessary. It will remain where it is until the Museum decides on its final resting place: we hope this will be in a new gallery in the Museum, though this development has not yet been authorised.

The archive held jointly by the CCS and the Museum has also remained in situ, pending the completion of a new documentation centre in the basement of the Museum, which is scheduled for October. Our archiving work, however, has had to stop for the time being.

The move has meant a number of changes. Until we have settled in, we shall not be running our In Steam days, and we have also had to abandon our plans for an Open Day this year. In addition, I shall now be running the secretariat from home rather than from the Museum: the new contact details are printed overleaf.

Our meetings and seminars will still take place at the Science Museum as before. Details of the planned programme for the autumn can be found on page 44.

The new Manchester Group of the Society is now fully in operation. We have been fortunate in securing the services of two well-known computing personalities to act as the inaugural principal officers.

Peter Hall is the chairman: many will remember him from his days as a senior executive at first Ferranti and then ICL, and will recall his entertaining and informative talk at our all- day Manchester seminar two years ago. Liz Segal is the secretary: active in BCS circles for many years, Liz has recently taken up a post at the IT Institute of the University of Salford.

The new group's first activity is the restoration of the very first Pegasus, which was moved from store into a gallery in the Manchester Museum of Science and Technology in early July.

Another project that this group plans to undertake is the construction of a replica of the Manchester University prototype machine of 1948. The group also plans to run a meetings programme. Volunteers are urgently needed to help with all of these activities. So anyone in the north-west who feels ready to take a more active part in the Society now has the opportunity: they should contact Liz Segal on 061 745 5665.

New contact point

Readers wishing to contact the Secretary should note that he is now running the secretariat from his home, and can no longer be contacted at the Science Museum.

The new secretarial telephone number is 0234 822788. Letters should be addressed to Tony Sale, Secretary, Computer Conservation Society, 15 Northampton Road, Bromham, Beds MK43 8QB.

Top Previous Next

The CCS and the Science Museum - what now?

Doron Swade

Tony Sale has been at the centre of the computer restoration activities at the Science Museum since the founding of the Computer Conservation Society (CCS) in November 1989. It is now perhaps well known that Tony vacated his office in The Old Canteen (which has served as the home of the restoration activities at South Kensington) when his current contract with the Science Museum expired at the end of July.

Tony has been on a series of fixed term contracts which at intervals came up for renewal. In the past, alarms of impending doom were invariably followed by the relief of reprieve. Having survived the threat of severance several times we acquired a sense of security and a belief in the inevitability of our own survival as the achievements of the CCS became increasingly demonstrable and the Society continued to thrive. I wish to register the disbelief and incomprehension felt by everyone associated with the CCS activities at the Science Museum that this time there was no rescue.

With Tony's departure ends the first era in the comparatively brief pioneering history of the Society. I would like to pay tribute to Tony's achievements, place the apparently unaccountable event of his departure in context, and clarify the Science Museum's position.

The origins of the Society are within easy recall. As curator of computing I paid innumerable site visits in response to offers of obsolete equipment from potential donors faced with having to dispose of cherished machines. Visiting these doomed equipments and engaging with their minders made it evident that there was expertise, goodwill and enthusiasm that lacked organised expression. The Computer Conservation Society was conceived to provide a social and organisational focus for this community of isolated practitioners who wished to share, contribute, impart knowledge and skill, or simply participate in a continuing way in an activity that was meaningful to them.

I approached the British Computer Society in 1989 to seek support. The upshot of the appeal was the CCS and the migration of Tony Sale, then head of the Technical Division at BCS headquarters, to the Science Museum, the natural institutional host for such activity.

We should be clear that the part of the context that favoured so promising a start was the prospect of a major new computer and telecommunications gallery and the pledges of financial support for this from a consortium of sponsors. The restoration activities of the CCS and the funding of Tony's initial two-year contract were part and parcel of the Information Age Project (IAP).

The overt justification for incorporating the CCS restoration activities into the IAP was to deliver working historic exhibits for this new exhibition. The political realities were such that without the impetus of the IAP and its attendant external funding Tony would not have been hired, however worthy the cause and however powerful the rhetoric. So the occasion of founding the Society (not the motive, mission or the need) cannot be separated from the IAP venture.

With the demise of the IAP in 1990/1 - a bitter disappointment to the whole team - support for a senior full-time post for computer restoration was always going to be vulnerable. We prolonged the formal ending of the IAP as long as we could and then engaged in several months of roller-coaster lobbying the insecurity of which Tony bore with philosophical fortitude.

Reprieve came in June 1992 when the newly formed Conservation unit saw the value of the pioneering restoration work already accomplished. It recognised the advantages of using the work of the CCS as a model of how to manage complex multi-media holdings. The Conservation unit funded a one-year pilot project to capture and consolidate the lessons to be learned in conservation, archiving and documentation, for application to other collections. It is a significant tribute to the CCS that its achievements were viewed in this light by the conservation unit of a major national museum.

As part of this project hundreds of original circuit diagrams are being archived on fiche and hard copy, and some 2,500 items of documentation and historic archive material have been indexed on a database. These services are very substantial and we are indebted to the Conservation unit for their industry and support. The cavalry had again arrived in time. Regrettably, coincident with Tony's departure, it has galloped off again to other wars and other sieges.

Everyone who has been associated with the activities of the Society knows at first hand that Tony has been the driving force behind many of the major initiatives of the Society. His energy, determination and absolute sense of direction are as legendary as his incomprehension and intolerance of unnecessary delay. Tony defined his goals and could not be deterred or distracted from accomplishing them. His focus and direction are evident in his gait as anyone who has seen him purposefully walking down the long passage to and from his office and navigating his way round the obstacle course of The Old Canteen will know.

With the support and endorsement of the CCS Committee the objectives Tony delivered are a testament to his commitment and to his abilities, strategic, organisational and technical. He established the Corporate Sponsorship scheme which produces income to fund many of the Society's activities. The value of the independence this affords is inestimable.

He established and maintained a programme of seminars which have become a unique forum for the history of computing; he assisted in the creation of Resurrection - a distinctive chronicle of historical activity; as a conscientious recorder of history he produced the only documentary video records of the construction of the Babbage engine and developed the techniques and hardware for indexing video material; he served and continues to serve as an energetic secretary of the Society; he championed the cause, sometimes with explosive pointedness, of indexing our uncatalogued archives of papers; and to top it all, the activity for which he is perhaps most visible is the computer restoration programme for which he marshalled and coordinated the activities of the Working Parties.

I recall the Director of the Science Museum, Dr Neil Cossons, thoughtfully observing a Young Engineer of the Year event a few years ago. He pointed out the bright young kids in DayGlo tracksuits holding forth excitedly on their inventions and commented on the contrast between these brightly attired kids and the unmoved men in dark suits (engineers) that surrounded them, out of whose mouths dust emerged when they spoke. He asked what had happened to transform these creative young individualists into the uniform brigade of otherwise doubtlessly distinguished seniors.

Tony was himself a young electronics prodigy and his insatiable inventiveness is very much intact. I offer him to Dr. Cossons as evidence that at least one of those youngsters from an earlier generation survived the often deadening process of professional life.

The Old Canteen, Tony, and the cheerful band that gathers to beguile old machines into life, are part of a renegade culture. The relationship of the CCS restoration activities to the Science Museum is symbolised by the ramshackle Canteen building in the car park standing alongside, but slightly separate from, the imposing 'mansion' that is the parental edifice of the Museum.

When we colonised The Old Canteen for the IAP and the CCS it had a leaky roof, bad security, and was far from a corporate des. res. - no pot plants, naff decor and not a flipchart in sight. While our building was perceived as a decrepit hut we were left alone, either through the wisdom of benign neglect or institutional indifference.

In this unprepossessing building we created something of manifest value to the Museum which then began to absorb the activities as part of a programme of 'consolidation'. Institutionalisation offers security. But there is a price: our hitherto unfettered freedoms to function efficiently and coherently as we deem fit without the frustrations of a multi- layered and diffuse bureaucracy are lessened, and the distinctness of our identity suffers some inevitable blurring.

The Old Canteen is now a prized piece of real estate fought over by the institutional Titans locked in a territorial conflict. Where to now without Tony on site and with the threat of partial eviction?

In recent negotiations the Science Museum has committed to provide alternative permanent facilities for the continued activities of the CCS Working Parties. The location of these facilities is a short drive from South Kensington - Blythe House, a large fully-warded museum store in Hammersmith shared by the Science Museum with two other national museums.

Two dedicated rooms have been allocated in the first instance. One room will accommodate the Elliott 401 and the Elliott 803. The other will take the DEC equipment (PDP-8s, PDP-12, and more). These rooms will be fitted with racking and storage and will provide facilities for the continued activities of the associated Working Parties.

Restoration activity on the 401 will continue in The Old Canteen for the meanwhile. The project will continue to enjoy the valued attentions of the Conservation unit and the high standards of conservation work they do in preparing the 401 subassemblies for reassembly and recommissioning. Pegasus too will remain in situ while its fate as an object for public display is debated.

We will continue to press for facilities to house new activities - the restoration of visible record machines, a permanent home for the S100 machines and for the investigation of recently acquired machines from Russia.

The restoration activities will therefore be split between the new site and the old. It won't be the same, I know, but we will have made the important transition from being squatters in a car park to having a permanent address. The Museum will continue to provide at no charge lecture hall, meeting room and seminar facilities to the CCS as a learned professional society.

These are the agreed commitments the Museum has made to the Society to date. In allocating permanent facilities the Museum has demonstrated its recognition and support for the Society's activities, and very much hopes that the CCS will continue to take advantage of this and to regard the Science Museum as its parental home.

Doron Swade is Senior Curator (Computing and Information Processing) at the Science Museum.

Top Previous Next

Obituary: John Cooper

Chris Burton

One of the Society's most active members, John Cooper, died on 13 June after a short illness.

John started his career with a telecommunications course at Enfield Technical College while apprenticed with Standards Telephones and Cables, New Southgate. He performed his National Service with the Royal Air Force, where he was involved with both telecommunications and radar, and then joined Northampton College of Advanced Technology (NCAT) in 1959 as one of a small team of computing engineers.

His duties there included maintenance of the College Pegasus, and later an ICL 1905 and a large analogue computer. In addition, his design abilities led him to produce Logic Tutors for the students (long before these were commonplace) and many sorts of interface electronics for the College departments.

He remained with NCAT through its transition to City University, taking on support for all the proliferation of workstations, personal computers and networks - he was skilled at rapidly assimilating new developments as they appeared.

He decided to retire early from the University two years ago to carry out freelance work, which included interfacing a personal computer to the second Babbage Difference Engine in the Science Museum, to facilitate diagnosis.

John was one of the first members of the Computer Conservation Society, and his experience and background made him an ideal first Chairman of the Pegasus Working Party. He ably led the team in pioneering the methodologies needed to combine curatorial conservation needs with the desire to restore a large machine to working order. More recently he was also a key member of the Elliott 401 Working Party.

His energy, enthusiasm, skills and generosity will very much be missed. We extend our sympathies to his wife Beryl and sons Christopher and Simon (all members of our Society) and to his daughter Serena.

Top Previous Next

The Problems of Software Conservation

Doron Swade

Computer software is not yet an explicit part of the custodial mandate of the museum establishment and there is a growing alarm at the historical implications of this exclusion. The nature of software is philosophically problematic. In practical terms, a programme of acquisition and conservation is technically forbidding as well as resource-intensive. This article attempts to locate software as an artefact in the material culture of museums and explores some of our preconceptions and expectations for a software conservation programme.

The purpose of this article is to explore museological aspects of software. The issues raised are concerned less with computing as an historiographic tool than with computing as an object of historical study.

Museums are part of an object-centred culture. Their essential justification is the acquisition, preservation and study of physical artefacts. Physical objects, their meaning, significance and their care, dominate a curator's professional psyche. One of the first tasks, then, is to locate software in the artefactual landscape.

Software, a term in general use by the early 1960s, is usually defined negatively: that is to say, a component of computer systems distinct from hardware. The Oxford Dictionary of Computing (1986) defines software as 'a generic term for those components of a computer system that are intangible rather than physical'.

The Science Museum's Corporate Plan for 1992-1997 states that one of its 'core objectives' is to 'acquire the most significant objects as physical evidence of science worldwide'. We have a conflict. If what distinguishes software is something non-physical, and software is in some sense irreducibly abstract, then it falls outside the mandate of material culture and a conscientious museum curator might have qualms about mobilising resources to acquire and preserve it.

The dilemma may seem pedantic. But there is a real issue: in whose custodial territory does software fall? Is it the responsibility of the archivist, librarian, or museum curator? For unless existing custodial protection can be extended to include software, the first step towards systematic acquisition will have faltered, and a justification for special provision will need to be articulated ab initio in much the same way as film and sound archives emerged as distinct organisational entities outside the object-centred museum establishment.

The distinction between hardware and software is not absolute. 'Firmware' (programs held in ROM) defies categorisation as exclusively one or the other. The ROM-chip itself clearly belongs to the universe of hardware. Yet insofar as the chip embodies a symbolic record of a program it is apparently also software. If forced to answer the question 'is firmware hardware or software?', you could be excused for responding with a helpless 'yes'.

One way of bypassing philosophical misgivings about the materiality of software is to appeal to the broader mandate of science museums to maintain a material record of technological change. Software represents a substantial human endeavour, and the intellectual, economic and material resources involved in its production and distribution represent a major technological movement. Its importance is not in dispute. So perhaps we can bluff it out and collect software by day leaving philosophical disquiet to the troubled night.

In practical curatorial terms the abstraction of software is, in any event, something of a pseudo-problem. We do not collect prime numbers or polynomials. We collect instead physical models, mathematical instruments and the written deliberations of mathematicians. In much the same way our curatorial concern for software centres on the external physical record of programs and data - coding sheets, punched paper tape, punched cards, flowcharts, manuals, magnetic discs, publicity literature i.e. the distinct physical media of representation and storage.

So we could perhaps make a case for offering curatorial protection to artefactual software by regarding it as part of the contextual and functional extension of hardware without which technical history would be incomplete.

But the lump under the carpet is still visible. Once we grant ourselves the licence to collect the physical artefacts of software, there remain respects in which software is both like, and unlike, traditional museum objects.

At the centre of curatorial practice is something called an inventory procedure. This procedure formally transfers the 'title' of the object from the donor/lender/vendor to the Museum. Each inventoried object is the direct responsibility of a named curator, the collecting officer, who signs a formal declaration of responsibility for each object when it is acquired. "I hereby take responsibility for the objects described overleaf" is the forbidding form.

An object once inventoried is subject to formidable safeguards against disposal and unqualified alteration. In museum culture the physical integrity of an inventoried object is sacrosanct and the act of inventorying marks its transition into protective custody.

Objects decay despite our best efforts to conserve them. Nonetheless, when we acquire a brass telescope it remains a brass telescope despite inevitable deterioration. We refer to a rusted telescope as a 'rusted telescope' or more impressively, 'telescope, condition poor'. The time-scale of its degeneration does not seem to threaten its identity as a telescope: that is to say, its physical deterioration is sufficiently slow to support the illusion of permanence. That it is a telescope seems not to be at risk.

Ultimately when time reduces our prized telescope to some orphaned lenses adrift in a little heap of metallic oxide we sadly shake our heads over the debris and say 'this was a telescope', or, in Pythonesque terms, 'this is an ex- telescope'.

So armed, I am now resolved to inventory some software for the computer collection. I take from the cupboard, where it has lain in limbo, the boxed mint-condition version of Windows 1.0 that a kind donor sent me. My hand is poised to sign the ominous declaration of responsibility.

The manuals and the box are unproblematic. It's the thought of the nine floppy discs that furrows the brow and stays the hand. In what sense can I responsibly sign when I know full well that within a few years there is no guarantee that the disc will be readable?

Posterity stretches ahead of us without limit in time whereas disc manufacturers, when they are prepared to commit at all, are reluctant to do so for more than a few years. (Banks were advised in the US in the early eighties that no archived magnetic medium over three years old should be regarded as reliable).

At a practical level, to commit to preserving a functioning Windows 1.0 package is to commit to an active programme of periodic renewal by copying to fresh stock, or transfer to a less impermanent medium. A programme of renewal or transfer requires new resources and, more significantly, implies the provision at some time of operational contemporary hardware or a functional equivalent. Neither requirement is trivial.

But is the Windows disc like the telescope with an identity that transcends its state of repair? If what makes it a Windows disc is the information content represented by magnetic configuration of the disc coating then does 'Windows 1.0, condition poor' mean anything? Does meaningful collection of software imply a functionally intact copy with the promise or potential of running it? We do not ask this of the telescope. 'Telescope, broken' does the job.

We can perhaps draw a useful analogy with pharmaceutical products. I learn from my medical sciences colleagues that the Science Museum has recently placed some proprietary drugs on inventory. Panadol, say, is now an inventoried object.

There is valuable cultural information in the physical artefact: tablet form, bubble-pack press-through dispenser, advertising imagery used in the logo and packaging and information about consumer appeal. But we can be pretty sure that the drug company will not guarantee the potency of the sample beyond its sell-by date.

We are clearly acquiring Panadol at least partly as a cultural artefact on the understanding that its chemical infrastructure and therefore its potency is ephemeral. In museological terms Panadol does not cease to be Panadol when it is no longer chemically potent. Similarly, the centuries-old 'poison-tipped arrow' remains so-called though the likelihood of any residual toxin is remote.

Is the Windows disc like Panadol? There are strong similarities. 'Potency' in both cases is not visually meaningful. Function is not manifest in external form.

Further, the Windows discs are no less a vehicle for contextual and technical messages than the Panadol pack: symbolism and imagery in brand logos and packaging, quality of label print, physical size, soft or hard sectored, whether factory write-protected, presence of reinforcing ring and so on. The discs are informative as generic objects (media) as well as conveying product-specific information about Windows.

So why the nagging need for functional intactness in software? Does 'functional intactness' make especially exacting demands on preservation practice?

Software we know is 'brittle'. It degrades ungracefully. We are all familiar with the awful consequences of what in information terms may be a trivially small corruption. One bit wrong and the system crashes.

There are however situations in which the value of magnetically stored information is not bit-critical. Discs used as storage media for textual data as distinct from programs provide one example. A progressively corrupt magnetic record is usable nonetheless. The residual data is not deprived of meaning or access by partial corruption.

The 'all or nothing' fears do not in this case apply and we may be encouraged to re-examine whether there is some give in the apparently uncompromising need for bit-perfect records of program software.

If we look at the effects of corruption on program performance we can identify three broad categories. Non-critical corruption covers situations in which unused portions of the program are compromised - unused print drivers, irrelevant utilities or subroutines, for example.

With a steam engine, say, 'non-critical corruption' would correspond to the damage to an unused or non-critical part - a nut dropping off, a dented panel. Damage in this case does not compromise the primary function, that of producing traction.

Critical corruption leading to evident malfunction is a second category - the system hangs, the cursor freezes, the operating system fails to boot, or the program produces obvious gibberish. In our steam locomotive comparison, the engine loses traction, or makes an expensive noise and stops. So far the comparison with physical machines works.

The third and most worrying category is critical corruption that produces non-evident errors - a maths program that produces an incorrect numerical result, a database manager that cross-labels data records, for example.

Comparison with the stalled steam engine is not obvious. Perhaps a closer analogy would be with a telescope that misrepresented what we were looking at. The distant unsighted object is a church steeple. But observed through our telescope (condition, good) we see the image of a mosque. It seems reasonable to conclude that if archived program-software is to be run, the need for bit-perfect records is uncompromising.

Once we accept the need for functional intactness in archived program software we are seemingly committed to the indefinite maintenance of bit-perfect records. Engineering instinct favours retaining the medium and format of issue to ensure compatibility with the original hardware.

If the medium of issue is magnetic then we are committing to an active program of periodic copying and integrity checking. Transferring software to a more permanent storage medium (optical disc for example) offers a tempting liberation from the fate of perpetual renewal.

The interdependence of hardware and software poses formidable technical difficulties to running programs so transferred. Machine-independent software is frequently anything but.

Correct operation of applications software relies more often than not on particular revisions of system software, program patches, hardware upgrades, firmware revisions and machine dependent interfacing to peripherals.

Transferring to an alternative medium requires new data formats yet to be standardised and dependence on a new generation of hardware to read or download stored information. Interfacing to these devices and executing code so stored is not straightforward. Transfer to a more permanent medium is not without penalty despite its promise of releasing Sisyphus from his fate in the copying room.

An implicit tenet of museum life is that the original object is the ultimate historical source. Part of the justification for preserving original objects is they can be interrogated in an open-ended way in the light of unforeseen enquiry. A meaningful software preservation program therefore implies the availability of operational hardware.

In 1989 the Science Museum, with the British Computer Society, founded the Computer Conservation Society. The Society has had signal success in restoring to working order a Ferranti Pegasus, a large vacuum-tube machine dating from 1958, and an Elliott 803, a discrete component germanium transistor machine dating from 1963.

At best such ventures can extend the operational life of obsolete systems. But however successful these endeavours, we have to accept the eventual demise of such systems. The fact of the matter is that in archaeological terms the operational continuity of contemporary hardware cannot be assured.

What meaning, then, does an archive of bit-perfect program software have if the material cannot be run? One way forward presently being explored by the Society is to simulate early hardware on present-generation computers using the restored original as a benchmark. Two simulations are well advanced, one for the Pegasus, the other for a German Enigma cypher machine.

In the case of the Pegasus, console switches, console oscilloscope traces, input/output peripherals (paper tape, teletype-style printers) are visually simulated and animated on-screen. The operator can write, run and debug programs by 'driving' the simulated controls and the simulator responds appropriately even to the extent of execution times.

The museological implications of such simulations are intriguing. In museum culture the original artefact is venerated at the expense of a replica, duplicate, reconstruction, or hologram. As mentioned earlier this derives partly from the possibilities the original offers for open- ended analysis.

Physical replicas can only incorporate features and characteristics perceived to be significant at the time of replication. If we wished to test a new theory about Napoleon's allergy to snuff, say, it would not make sense to examine look-alikes of Napoleon's clothing. Prior to the snuff-allergy hypothesis, snuff-content would not be a consideration in the making of a garment replicas. Only the original artefact with authenticated provenance would suffice for this forensic purpose.

However, logical replication as distinct from physical replication seems to offer more. Capturing the operational persona of an early machine on a later machine promises possibilities for open-ended analysis of the kind formerly offered only by a working original. The resources to develop such simulations are substantial and the skills-levels high. But the technique offers a form of logical immortality as computer languages used for the simulations become increasingly machine-independent.

I have touched briefly and perhaps unsystematically on a few of the issues agitating concern in the curatorial world. The task of developing an interpretative framework in which to locate and debate the nature of information and the role of information processing machines is substantial. The technical and resource implications are formidable. We have a long way to go.

Doron Swade is Senior Curator (Computing and Information Processing) at the Science Museum. His article is based on a paper presented at the Society's seminar held at the Museum on 25 June 1992. The original title of the paper was "Collecting Software: Preserving Information in an Object-centred Culture (do we inventory the floppy?)". The paper has previously been published in History and Computing Vol 4 No 3, 1992.

Editor's note: History and Computing is the journal of the Association for History and Computing. This is an international organisation which aims to promote and develop interest in the use of computers in all types of historical study at every level, in both teaching and research. Founded in 1987, its membership consists principally of member associations, though individual membership is also possible. Readers wishing to know more should contact me.

Top Previous Next

George Alfred Julius and his Automatic Totalisator

Charles Norrie

The problems of uncertainty had a fascination for the early pioneers of computing, especially making sense or order out of uncertainty. Babbage was interested in life assurance and in game theory. Turing had a wide variety of interests, including game theory, gambling systems, poker and statistics.

I want to discuss George Alfred Julius, another pioneer who built a system to deal with uncertainty - his automatic totalisator. This talk mainly covers the totalisator as it was at Haringey.

A totalisator is a machine to process the results of a type of bet known as pari mutuel. This is a bet between bettors, and not against a bookmaker, so it acquired the name pari mutuel, meaning bets between ourselves. The payout is calculated by dividing the total pool of stakes, less deductions for tax and the operator's overheads, between the backers of the winning dog, or competitor (the machine could be used for other types of betting such as horse race betting).

There are many sorts of totalisator bet, and there is a series of rules for determining who are the winners and how they should divide the pool.

One aspect of the tote bet is that the ticket issued does not need to say what the payout will be if the bettor's choice wins. It is an entitlement to be paid out at a rate depending on the monies taken before the race starts. Fixed odds are avoided; you don't have to record and process the value of the odds offered when the ticket is sold.

The totalisator originated in South Australia. The South Australian racing community became increasingly irritated with corrupt bookmaking practices. Holding that most robust of Australian investigative devices, a Royal Commission, they proposed to adopt the pari mutuel betting system as used in France.

So a bill was introduced in 1879 into the South Australian legislative council to legalise the tote and curb the "welshing" and corrupt bookmaking. It was strenuously opposed by religious groups lobbying on the grounds that it would promote betting rather than regulating it, and they were to be proved correct.

The legislation made it onto the books by one vote. This success provoked a reaction, and the tote was closed down three years later, only to be revived for the 1888 season.

Tote machines existed before Julius. Eckberg patented a mechanical totalisator in 1879 at the height of the early Australian interest in the tote. Another Australian, Gabriel, had a system which used the counting of marbles, or possibly steel balls, as a method of calculation.

These two systems were not automatic. "Automatic" in this sense means achieving an automatic recording and summing of the bet made by an investor, and printing and issuing of the ticket.

The automatic totalisator, in the sense that Julius used the term, was not used to compute the payout of the winners. This was a manual task at Haringey, performed after the race by two clerks and an accountant. Modern systems do of course perform this last stage automatically.

George Alfred Julius, engineer, was born in 1873 and died in 1946 in Sydney, Australia. His father was a Christian socialist with a bent for engineering. One anecdote has the father as a curate in a poor parish, unable to raise money to mend the turret clock, taking it apart, boiling the parts in oil and putting it back together again.

The family moved to Ballarat, Victoria in 1884 when George was 11. Here his father was vicar of St Peters, a go-ahead mining town. It's tempting to suggest that Julius would have become aware here of the unregulated betting he was to do so much to reform. Victoria at this time, unlike South Australia, had not tried tote betting. Historians believe many of the bookmakers were corrupt.

In 1899 Julius's father became bishop of Christchurch, New Zealand, a settlement founded on Anglican principles. Here Julius came in contact with a man who was to have a decisive effect upon his life, CY O'Connor. Also from an Anglo-Irish background, O'Connor belonged to that essential breed of individual of the Empire - the government engineer.

O'Connor subsequently sought a post in Western Australia as Government engineer there. He worked on the port of Freemantle for exports, railways to develop the State, especially its valuable timber resources, and the water pipeline for the recently discovered Kalgoorlie gold field. Julius on graduation was recruited by O'Connor to the railway workshops at a premium salary.

Julius became an instructor at the technical institute. He wrote a standard work on Australian hardwoods there, a vital exercise in developing the State's economy. Subsequently he quit government service and moved to Sydney to form his own engineering partnership, Julius, Poole and Gibson.

His initial reason for coming to Sydney seems to have been a project to investigate problems with the defective electrical and mechanical installation of the Sydney power and lighting scheme. The totalisator was a minor aspect of a very busy business engineering and political life.

Anecdotal evidence from Julius' son Aubrey, who was the one son to go into Julius Poole Gibson, suggests that though the totalisator was a separate venture from Julius' engineering consultancy, the latter benefited from the orders for buildings at racecourses. Julius' firm's order book suggests also that this was so.

It was while he was in Western Australia that Julius began to patent devices for his totalisator. It's clear even from the first patent that Julius had grasped an important principle of betting, simultaneous demand - people wishing to bet at exactly the same time. Hence in choosing areas for monitoring the sales application of his machine he proposed applications that would have a similar kind of simultaneous demand.

Voting was one. Another was sales in a department store: as sales happened individual departments would ring up the sales and there would be a grand total for all the sales across all the departments in the store at the same time. In this he anticipated computerised in-store stock management systems that began to be only feasible in recent years.

And why Julius? Julius' church background does not suggest a milieu particularly conducive to betting or totalisators. There is no evidence that Julius was interested in betting himself; several anecdotes suggest that he never betted at all, but he did marry into a family well known for their support for the turf. CY O'Connor possessed a number of racehorses which "invariably wore Irish colours".

One anecdote recounts that when the Ellersley tote, which was the first to be opened in Auckland, his father, who was then archbishop of New Zealand, asked to be shown over it by his son. To preserve a certain distance of the church from the tote it was arranged that the archbishop would tour the machine on the morning before the first race. However so engrossed did the old man become that he only emerged while the public was being admitted to the afternoon's racing. This led to a wide and entirely unfounded speculation that the archbishop, not the engineer, had been responsible for inventing the machine.

Haringey was one of the early stadiums to be equipped with a Julius totalisator, taking advantage of the Amended Betting Houses Act. Presumably the Government regarded it as a way of generating revenue. The Chancellor of the Exchequer, Winston Churchill, had no particular respect for greyhound racing, describing it as animated roulette.

The Haringey machine was a typical Julius product, representing about 15 years of development and improvement. Taking the elements in chronological order as shown by the patents, the Julius totalisator was a progressive improvement from that earliest 1913 model in Ellersley. That machine was simply mechanical.

The Haringey machine was probably constructed in Australia. There is some indication that Julius was constructing machines for the English market. Later he was actually to set up in this country.

Haringey Stadium was on Green Lanes, just north of Manor House station in north London. It was closed in 1987, a victim of the extended twilight of greyhound racing caused by the growth of other leisure opportunities, and also rising land values which made attractive alternative site uses. Today Haringey is famous for its supermarket and there's no sign of a dog track left.

Ironically it was the decline of dog racing that preserved the Haringey totalisator. Had the track had a long term viability the machine would have been upgraded in line with apparatus at other greyhound stadia.

It should be stressed that the Haringey totalisator isn't in any sense a one-off. The machines were widely used throughout Australia and America, where they were known as the Australian Tote, the British Empire, and even France.

Relatively speaking they do not appear to have been expensive; there was not the capital available. The Haringey stadium was constructed on the Haringey dumps - waste left over from the construction of the Piccadilly Line. Greyhound racing, though it tried hard to emulate the styles and form of horse racing, was no such thing. This was betting on the cheap.

Though Julius negotiated with a syndicate for their introduction on the racecourses of England he was not successful, as the Jockey Club would not permit the Tote. Nevertheless they relented to the extent of permitting the Automatic Telephone Company of Liverpool to build one at a cost of £2 million in the 1930s. A Julius machine would have cost mere thousands. A tote in England seems to be a particularly low cost operation, though other machines appear in elegant and stylish buildings.

Before I return to the Haringey totalisator I'd like to spend a few minutes talking about the background to it.

Because tote betting only gives bettors a starting price there's no incentive to bet early. Indeed there's a considerable disincentive; as betting proceeds bettors get a steadily clearer indication of the sort of price or odds they will end up with.

The ideal is to make the last bet before the traps are open, when of course betting must cease, in the full knowledge of the odds available from the previous bets.

As all bettors want to do this the demand for bets rises as the time of the race draws near, and the flow of bets becomes faster and faster. (Contrast this with fixed price odds where the decision to bet early is sometimes made in the light of an attempted objective assessment of a dog's probablity of winning.) It's certainly in the tote operator's interest to service this demand as efficiently as possible for his return is a fixed proportion of the total stake.

Julius seems to have had some doubts at an early stage about an electrical installation, and he did not use electricity until he had devised a suitable means of ensuring that a ticket couldn't be issued unless there was a positive registration of the bet that had been made at the same time.

The next bit to go on to is the need for simultaneous betting. The only alternative even in 1920 was the marble system that Gabriel had invented. It was used to drive accumulators, a display drum and an odds machine.

In its original conception as it must have been at Ellersley, the totalisator consisted of direct action ticket machines that mechanically drove an epicyclic mechanism attached to a drum (used for displaying the results). Its arrangement of ratchet wheels, relays and bevel gearing was arranged about a common axis. The operation of a relay permitted a ratchet to turn one position: as a result the axis of the epicyclic chain would turn, usually by one eighth of a complete rotation, to enter one bet. Higher priced bets could be operated by allowing a bigger gap between the ratchets, or by using a different barrel with a different value attached to it.

The rotations were transmitted by bevel gears through the adjacent ratchets, which were all on the common chain. Hence ratchet and bevel gear mechanism had a double function; the bevel gears would rotate when ratchet is operated but they could also transmit motion independently.

Each epicyclic chain could be attached to about six ticket machines. In theory you could have 10 or 20 ticket machines attached to it, but we're looking at machines in which there were usually four to six relays attached to the epicyclic gear.

This early purely mechanical system couldn't meet the speed needs of tote betting, so he had to turn to electricity. One problem was the stopping and starting of the epicyclic chain with many machines attached to it. Various claims are made for the size of the machines eventually created; the one at Champs Elysees is said to have served 600 ticket sellers. Haringey had 150, and there was space for 240.

There was another deficiency with the Ellersley machine. While the machine accurately recorded bets, the ticket seller was still obliged to select the appropriate ticket for the customer. This permitted error, and fraud in the worst cases. Julius therefore began to look at ticketting machines that simultaneously registered the bet and printed the ticket. This does not seem to have been successfully achieved until 1918 or later.

The Haringey machine covered three types of bets for only six dogs (contrast that with over 42 horses at Randwick in Australia). There were Win, Place and Forecast bets. Later totes may have handled quinnella, duella, triplex and the other complex bits loved of the betting community.

One can see that there is a disadvantage in a hardwired system because if you want to increase the number of dogs in a race or introduce a new bet, you've got to get a new machine. It's not programmable in any sense whatever.

Julius realised that electrical operation would permit much higher speed than mechanical. Ticket sellers might be able to sell at 100 per minute but electromagnetics would register 10, possibly 50 times this. Hence rather than having each ticket driving a single relay with the resultant long epicyclic chains - mechanical devices which needed to stop and start with consequential inertial problems - he used a rotating selector associated with a group of ticket machines.

I should be careful in describing this as time sharing; Julius identified its advantage over its competitors as saving equipment, not sharing time on an expensive machine. It was necessary to drive two separate relays for each machine, one on the grand total machine, one on the individual dog machine. In the original Ellersley machine the ticket machine would have driven a counter - a big drum device that could be read from anywhere on the course. These had to be large, 2 feet to 18 inches across. These drums are important because they are the only legal output device required by law.

Haringey had two sets of drums in its time. The original drums had three wheels, but they were disconnected and just put to one side. The new drums had four wheels, five in the case of the grand total drum.

But now Julius had been caught up in the success of his machinery again. Hundreds or thousands of bets a minute put a severe stress on drum moving mechanisms. They were big things - 2 feet across - and stopping them in relation to betting was difficult. The electrical system which controlled the opening of the traps and starting the race also signalled the end of betting, and it was activated with the throw of a single switch. It disabled all the ticket machines simultaneously; they had to come to a dead halt.

So Julius had to solve this problem of the inertia. It was legally necessary to retain the drums, but was it really necessary to show the most quickly moving drum? No, thought Julius, they can be disconnected because if they are moving quickly they can't really be read. But if you disconnect them the addition has got to be done somewhere else; and this is where they had to use the tables.

Julius decided that, rather than feeding the rotor output to the epicyclic train to a drum which had to stop and start as needed, he would feed it into a storage system, and then process output at a steady rate. The storage mechanism would have a lower inertia than the drums, and the steady unloading of the bets would cope with the severe changes in demand at the start of the race. Of course in the process you get a bit behind where the betting has currently reached, but never mind.

So the bets wind up a spring in a barrel and unload it at the other end. Then you can deliver the output in a number of ways: onto drums, or onto other barrels. We could in fact have many barrels to distribute the output over many machines, rather than have one that you're putting a lot of stress on, and distribute the addition. This keeps the number of epicyclic chains small and one gets to a setup with a series of drums side by side built up into a table. So we've got a whole series of relays at the top where ticket machines are coming in through their commutators and the betting information is being unloaded at our end. With that you can drive the rest of the equipment smoothly and efficiently.

The display drums really indicate in some way the state of the accumulator table a little behind time. Could this be described as a mechanical buffer? It's not quite the same as a computer buffer because it's not LIFO or FIFO.

When betting has finished you have got units which haven't been recorded, so they must be transferred automatically through to the drums. Then when you've finished with the race you've got to unload the bets and reset it, and for that we have a man - it's not done automatically. This is one of the major problems of the Haringey machine; you needed to have a team of six people just to reset these things 10 times a night.

We haven't got a lot of information out that's useful to a punter - all we've got is counts of the number of bets. As the size of the Julius installation grew, there was a problem with informing bettors in an effective manner. There seems to have been only one set of display drums per installation: as the size of meetings grew Julius could do bigger racetracks, and it could be difficult to read them. Scaling up the size of the drums was impossible because of their inertia problem.

Again, assessing betting prospects by estimating the ratio of moneys invested in different competitors was not user friendly to the average investor. Julius' search for a solution to this question took considerable time to come to fruition as a workable apparatus. His earliest patent expressed some interest in the idea of comparison between different totals, while a paper dated 1920 on aids to calculation described in detail several ratio calculating devices.

I can't find that he thought of taking instantaneous snapshots and then doing a mechanical computation, but he did come up with an odds machine. He was later to say that he devised this when he came to England in 1928, and encountered British investors who regarded with consternation the lack of odds which the tote gave them compared with the fixed odds machine. Perhaps one reason for the introduction of odds equipment was to encourage people to migrate to the tote; perhaps we should regard this as an early system emulation.

This article is an edited version of the talk given by the author to the Society at the Science Museum on 25 March 1993.

Top Previous Next

The design of Pegasus

Ian Merry

I'm uncertain whether I welcome this opportunity to celebrate the engineering genius of Charles Owen and the conceptual brilliance of Christopher Strachey, or whether, like pious Aeneas before Queen Dido of Carthage, I've been asked to awaken ancient and unutterable feelings of regret. Regret that following the outstandingly successful development of Pegasus the design team was disbanded and, at least to my way of thinking, no worthy successor has ever been developed in Britain.

I'll identify a few of the individual characteristics of the members of the design team which had a significant influence on the design.

I learnt from my experience with Pegasus that good design requires the prejudices of a single design authority to be both articulated and respected. Problem definition is a vital precursor to problem solution.

Successful design depends on solutions with designabilty, amenable to design analysis and calculation, since design is constrained by the limitations of materials. Successful design goes, so to speak, with the grain. These were in effect the precepts on which both Owen and Strachey based their work; they were not however very typical of the world of electronics in the 1950s.

What was this world like? The impact of radar development during World War Two was still much in evidence. A major advance in glass technology, dating from about 1938 with the appearance of the Philips EF50 valve, had fostered a succession of high-gain miniature vacuum tubes only about an inch in diameter and no more than a few inches in length.

Point contact germanium diodes had been developed during the war as radar demodulators, based on little more than the kitchen science of crystal wireless sets of the 1920s. With the inventio a hesitant semiconductor industry had arisen concentrating on germanium semiconductor technology, hampered by the variability of point contact devices, and only marginally familiar with the technology of silicon and junction devices on which we all now depend.

Electronics was still mainly the concern of telecommunications and broadcasting, the former with its 22 inch wide racks of equipment 6-8 feet high, and the latter with racks as wide as 24 inches (at least in the BBC), bearing monolithic cadmium plated steel chassis, each weighing tens of pounds with a dozen or more valves and associated circuits.

Significantly, most of those involved in the wartime radar development had been graduates in physics, without academic engineering backgrounds, since in Britain at least electronic engineering was widely regarded as a dilettante not to say insecure profession until well into the 1950s.

This circumstance together with wartime pressures had confused the concept of design with the narrower field of circuit design, and established a widespread design tradition of suck- it-and-see whenever a problem arose outside the immediate experience of the designer. That's not to say that suck-it- and-see was how circuits were designed; that depended entirely othe intellectual probity of the designer. But suck-it-and- see was still very much the way of dealing with any problem that was not immediately in the competence of electronics.

Again, where the logical power of electronic digital computation had been clear since the early 1940s to the indoctrinated of Bletchley Park, it was the domain of the smallish band of mainly academic successors, among whom few had studied design as an engineer.

Even where, as in the BBC Engineering Department, numerically based design was given its full due, on the electronic front this was in the context of high quality analogue circuits made linear with a quasi-statuary 40 db of negative feedback!

Consequently there was no pressure at all on the makers of valves or semiconductor devices to publish the variances of their device parameter data. On the contrary it was rarely clear whether published data represented design targets or achieved median values!

Lastly, despite the marketing hype of the Festival of Britain in 1951 and the governmental initiative of NRDC, there was no longer the recognition of engineering as an important aspect of the British Raj, as had existed in the 19th and early 20th centuries.

Turning now to the major players in the design of Pegasus, there were four in number: Charles Owen, Christopher Strachey, Brian Maudesley and myself. I would like to pay tribute to Owen's engineering sagacity.

He had the essential vision of a successful engineer, which is to have formed an architectural concept of the finished work from the earliest possible moment. Changes to that concept could be made as the design progressed, but any change had to be demonstrably beneficial, and to meet Charles' exacting standards of acceptability.

Given the clear benefits and the conformity with the standards of acceptability, there was in my experience no need for further persuasion. It was stimulating to work with someone who had no need to reinforce his prejudices with anything but logic and good sense.

In addition Charles was very ready to pass on his own knowledge - a characteristic which endeared him to me as I had no previous experience of digital techniques. With all of that, and though often doggishly witty, Charles was essentially a plain man for whom facts were facts and fancies were fancies.

Christopher Strachey on the other hand was a modern Renaissance man. Besides his achievements as a mathematical logician and systems conceptualiser, he was a most talented musician; he and I used to sing and play together. His skill in technical discussion or general conversation was such as to make everyone else present perform beyond their usual level, as a consequence of his own rather competitive verbal brilliance.

The third principal member of the design team, Brian Maudesley, was unusual in both background and personality. A mechanical engineer from Ferranti Edinburgh fallen among intellectuals, he held his own in consequence of a unique capacity for mechanical innovation, and for his mild manner, all supported by a physical stature of 6' 8".

As for myself, I joined Ferranti after four and a half years in the BBC Engineering Research Department where I had worked on a number of electronic and electromechanical projects connected with both disc and magnetic recording, and where I had encountered many of the problems which were still then at issue in the Pegasus project.

My only previous experience with digital circuits had involved telephone relays - a brief encounter which left me with no yearning for further involvement with relay switching!

We come now to the principles on which the architecture and design of Pegasus was based. Strachey's major objective was to reduce the labour of the programmer, especially by providing efficient and consistent order code; by freeing the programmer from undue concern with machine architecture; by minimising performance bottlenecks; and by maintaining an autonomous invigilation of all machine functions, using odd-parity checking throughout.

Owen for his part had an intense preoccupation with machine reliability and availability. His experience led him to believe that while this required conservative design, with care this did not get in the way of elegance and economy. Both he and Strachey aimed to build all of the complex control functions without recourse to special purpose circuits.

With both prudence and modesty Owen took the view that basic circuit elements used in the Elliott 401 represented the soundest basis for progress. Packages containing several OR configurations of point contact diode AND gates, logically ORed, followed by a cathode follower direct output or an inverter or a simple pulse amplifier retiming and delay circuit furnished the logical armoury of the bit-level logic, as in the 401, while single word packages using a nickel delay line as a serial storage medium provided immediate access memory for accumulators and registers.

Now it's fairly obvious that the more complex a logical function, the more numerous are likely to be the various inputs. So the number of inputs to individual AND gates should be as little restricted by circuit component deficiencies as is prudent.

To upgrade the Elliott logic circuits, Owen instituted a statistical analysis of the problem, and ascertained by experiment the variance of the germanium diode back leakage resistance. In this way he avoided on the one hand the Scylla of AND gates with the more leaky diodes exhibiting pattern sensitive failings, and on the other the Charybdis of oversensitive gate design.

In considering the remarkable success in achieving the design objectives, remember that Pegasus is a serial machine in which the 39 working bits of each word arrive sequentially at any point, or as we now say at every interface in the machine.

To maintain the economic advantages of this serial approach, interface width has to be kept to a minimum, nearly always only one bit wide. The parts of the machine where static registers hold a number of words concurrently are thus few in number.

The thinking required in the logical design, particularly of the control functions, therefore required the designer to envisage successive machine states represented by circuit states changing autonomously and quickly under the inexorable flow of serial data. This is a duality which it is difficult to represent conspicuously in any diagram form, and was quite beyond the descriptive mathematical techniques of the time.

In this regard I well remember the seminar when the logical designers first gave an explanation of the control architecture. By then Pegasus was in active use and the logical design seemed to be consistent, but for my part at least the description of the various control cycles was and remains baffling.

Coming now to the engineering problems which had to be solved, we can regard them arising against three design aims. These are reliability, economy and performance.

Past experience had shown that the major areas of transient unreliabilty were pattern sensitivity of individual logic or storage units, where correct operation continues until a particular sequence of binary digits occurs which evokes an incorrect output.

Secondly, on drum systems generally, think of a difficulty and they appear to have it. Thirdly we had to live with package, plug and socket electrical contact variability. Happily by this time other electrical component deficiencies did not present causes of transient problems, and were adequate in terms of operational life given that they were not sourced from suspect quarters such as Government surplus - a false economy which bedevilled some other projects.

Now except to a mechanical engineer of particular discernment there is little intellectual stimulus in addressing the problem of erratic plug and socket behaviour, which is why, I think, the problem hung around for so long. In many ways this was the most dangerous of the package circuit problems since so many package interfaces were at risk.

Maudesley tackled and solved the problem with determination. To keep the contact resistance of each contact adequately low, he insisted that it was insufficient to rely on the comparative incorruptibilty of noble metal surfaces; instead, on each insertion of a package every female contact should scrape its corresponding male and ensure a new metal to metal interface. Given an adequate thickness of noble metal plating of the male contacts, a quite adequate if limited number of insertions could be made.

It might have seemed a risky way of proceeding, as noble metal surfaces can get worn away very quickly. In fact we reckoned that we could do at least 50 insertions without trouble, and that was well beyond the number of insertions one would normally expect a package to receive.

The in-line multi-contact socket used was to have the necessary female geometry, and a concomitant to this solution was the provision of a robust and stable mounting for package board and socket. This was achieved most economically by the use of aluminium alloy diecastings for the package shelf mounting.

The robust behaviour of Pegasus after switch-on and throughout the life of the various machines has been very largely due to this solution to package structure and contact geometry.

Lastly of course the package board itself had to be of an adequate rigidity and stability. Attention to details of this sort had not distinguished previous computer projects.

The drum system appeared to present problems in every possible area. The geometry of the magnetic fields caused the head signal to be rapidly attenuated with an increase in the read head-to-recording medium gap. About half the signal is lost in geometrical progression for each extra tenth of a bit length gap.

With a drum diameter of 10 inches and 128 42-bit words per track, it turns out that an overall variation in signal of 2:1 ensues if the radial runout of the drum surface (due to machining tolerance, variations in coating thickness and bearing shake) is no more than about half a thou, and exponentially pro rata.

Owen had already decided this was too demanding by a factor of two. He had laid down that alternate bits would be recorded in pairs of tracks, so that we could have double the wavelength for each bit, with write and read head diplexing handled by machine logic. This was a strategy previously adopted at Elliotts.

I soon realised that not only the diplexing but also the actual phase encoded waveform could now come directly from the logic. This removed the need for a special purpose circuit, pleasing everybody especially me.

However even a total runout tolerance of half a thou appeared to have caused difficulties with previous bearing design and bearing life. And there was some disquiet in connection with the drum under development at Ferranti in Manchester for the forthcoming Mercury computer.

At the BBC, while studying the problems of television magnetic recording, I had tackled the problem in the lab by using a horizontally mounted narrow drum or disc with a little known 360 degree bearing design. This had however to be hand lapped to a radial consistency of about one tenth of a thou. The drum coating with its magnetic surface was then sapphire turned.

A 360 degree bearing is nominally permanently lubricated, and it works best with a lubricant with particular physical properties like sperm oil. I introduced this with an eye dropper to my own machines. Maudesley would have none of this quasi-magical 19th century engineering and quickly came up with a solution.

He realised that precision boring spindles have to perform with a radial runout of better than one tenth of a thou without adjustment over a period of many months, so decided to approach the manufacturer of such machine tools and give him the problem.

Bill Burnham of Burnham and Turners in Mansfield cheerfully undertook to make a suitable drum mechanism if we provided him with outline design and details of the motor to be incorporated. Bill entertained no taboos or superstitions about putting three bearings on one shaft.

He assured constancy in bearing behaviour and bearing life by using twin sets of angular contact ball bearings under considerable axial pressure. As I recall it the original prototype which was used in the first Pegasus cost only £300, excluding the electric motor. The drum fitted to the CCS machine is a later and larger version although it's built on precisely the same principles.

Other Ferranti drums were run as slaves to the rest of the machine, synchronised in a phase-lock with crystal controlled logic circuits, requiring an elegant servo system, and culminating in a very hefty power amplifier. This was in my view to turn good design on its head, because you are making a cumbersome object (a rotating drum) slave to a more pliant system (a lot of digital circuits). Our drum needed over a quarter of a horse-power, making this scheme doubly unattractive.

I therefore got Owen to agree that the logic should be driven from a clock track recorded on the drum. The rotational speed of the drum would then be kept within the limits required by the delay lines, using quite a simple servo loop with a crystal reference.

As the drum drive had to be at 150 Hz for the 4000 rpm rotation speed, this loop included the motor excitation of the 150 Hz alternator set. That left us with a small problem: how do you record a clock track on the magnetic oxide, which is consistent, the right number of bits, and actually joins without any bumps?

We accomplished this by first recording an approximately correct, but incomplete clock track, which was then temporarily phase-locked by a hand adjustment of the servo. At the correct rotation speed, using a crystal controlled reference and using an expanded trace oscilloscope, the rotational inertia of the drum made this practically possible without any excessive manual dexterity on the part of the operator. At first a clock frequency of correct length to close on itself was then recorded.

Ferranti drums had previously been nickel coated because the low coercivity required little power output from the write amplifiers. However these coatings had occasional magnetic weak or dead spots, owing I believe to stresses in the plating.

Subsequently when I went to IBM I discovered they had similar problems at about the same time with their drums on the IBM 650. They eventually overcame them with weird chemicals in the plating baths. At the BBC however I'd found that Fe2O3 oxide dispersion used for coating magnetic tape was readily spray painted onto a drum, using just an ordinary spray gun, and so we abandoned nickel for red iron oxide.

Split rings of low loss ferrite also worked as well as read and write heads up to well over 0.5 MHz, needing only pairs of miniature power pentodes to drive the magnetic oxide into saturation. Better still, correctly formed ferrite recording head blanks were then becoming available. I was fortunate in finding a subcontractor, Epsilon Ltd, making multistack heads for tape recorders who were willing to package banks of ferrite heads with a low impedance to my requirements.

Drum system performance, reliability and usability was greatly increased by abandoning relay head switching and developing valve and germanium diode crossbar switches for writing and reading.

The read switch came before any amplification and was entirely novel. Charles Owen had to be convinced by a test lasting several months with a random batch of diodes that diode noise would not cause errors; however diode noise remained below 250 millivolts, and was quite harmless to the unamplified phase modulated signal of some 3-4 mV from the heads.

These switches meant that the relay switch settling times of 20 milliseconds, which is what you got in a Post Office relay, were totally avoided; in fact the read amplifier recovery after writing time of about 500 ms became a limiting factor, while track switching took only about half that time.

So we both improved the performance and enabled single word as well as eight word block transfers to be efficient. Lastly, block addresses in the drum address track were permutated to leave two blocks between blocks of successive block addresses within any block where the addresses remain in natural sequence.

This gave time for some computation between successive blocks without involving the programmer, and he didn't have to go in for fancy addressing of his data via optimum programming, which was in general use for other drum systems.

As a result of these innovations the drum system became in harmony with the general approach that distinguished the Strachey-Owen design.

I'll mention two other features of the logical design that contributed to overall performance. These were the provision of multiple accumulators and many more registers; and the incorporation in the order code of a comprehensive and logically regular method of handling address modification using some of these extra registers.

How much more effective would Pegasus' contemporary, the IBM 650, have been with these features, designed as it was for similar user areas? How sad that Pegasus could not have been equally widely exploited.

That concludes my survey of Pegasus development except to say as I wrote in the Computer Journal of June 1991, "It is a matter of record that all of these features were working in the Pegasus pilot by April 1956.

"Development begun in 1955 added card and tape peripherals in the subsequent years, leading to machine sales of nearly 40 machines overall. Regardless of these good beginnings an evident loss of focus on behalf of the Ferranti senior management, coupled with NRDC's short term financial preoccupations, fostered an atmosphere in which by 1956 the burden of continuing investment was only acceptable at a level requiring a fundamental choice between the Mercury team in Manchester and the Pegasus team in London.

"Except for the peripheral developments mentioned above the Pegasus team was largely disbanded, and staff were redirected to work on Ferranti contract and defence work, or in the case of some of the leading team members regrouped under American auspices in September 1956. This was a blow to the infant British computer industry at a most crucial time from which subsequent events have shown it never wholly recovered, exemplifying how inadequate investment ensures a net and enduring loss."

The history of Pegasus has always seemed to me to be a paradigm of the British industrial malady - not just the shibboleth that Britain fails to market its wares, but more fundamentally that we no longer recognise or foster and therefore we cannot exploit our real strengths.

This article is based on a talk given by the author as part of the Elliott/Pegasus all-day seminar at the Science Museum on 21 May 1992.

Top Previous Next

Working Party Reports

Elliott 401

Chris Burton, Chairman

Conservation has progressed well, with the drum unit, drum cabinet and monitor console returned to our working area since the last report in issue 5. Once conserved, we try to remember to wear gloves when handling items to prevent further corrosion.

To celebrate the 40th anniversary of the first demonstration of the Elliott 401, a reception was held in the Science Museum, welcoming the Director, people connected with the early days of the machine, and other dignitaries. Parts of the machine were on display, triggering many recollections.

During our monthly working party meetings, good progress was being made with recovery of data from the drum surface until John Cooper's untimely death. We will attempt to continue this task using the equipment which John had designed and almost completed. The drum has been run up to 4600 rpm, and it was satisfying to see data signals from one of the read heads on an oscilloscope.

As expected, reconstruction of the current logic diagrams is a difficult and time-consuming job, but headway is being made. At the same time we will be establishing the current machine order code, which does not appear to be correct or complete in any extant documents.

With great trepidation, mains power was applied to the monitor console (cautiously, through a Variac!), and with one exception the power supplies worked after changing a couple of valves. Two resistors were found to be open-circuit in the EHT power supply, and after replacing those the monitor cathode ray tubes came to life with splendid bright, sharp traces. A fine tribute to the original workmanship, for the equipment has been unused and in store for nearly 30 years.


Chris Burton, Acting Chairman

The working party was saddened by the unexpected death of its chairman John Cooper in June. The present good state of Pegasus is largely due to his efforts, and his energy, enthusiasm, skill and generosity will be very much missed.

Pegasus has been operational on In Steam days during the last six months, although reliability was poor initially. Many of the delay line store locations appeared to be marginal and had to be changed frequently. A thorough investigation eventually led John to notice that the system clock waveform derived from the drum had occasional weak signals. Changing to the Master Clock track cured the unreliability.

We were faced with rewriting the working clock track, which is a significant task, in unfamiliar territory. However, we carefully assessed the problem and procedures, found the required equipment among the spare parts, and created an operational script to guide us. Happily, the method worked successfully, allowing program testing work to continue. Weeding out marginal delay lines can now continue from a more solid base, and we have gained more useful experience.

We are now expecting Pegasus to be moved to a public gallery, probably in the autumn. We have started assessing the tasks to be done to make the move and get operational again.

S-100 bus

Robin Shirley, Chairman

A useful contact has been made with Peter Catley, a computer consultant who runs the Windsor Bulletin Board as a spare time activity. Apart from being a kindred spirit and user of several 8-bit micros, Peter has preserved a number of microcomputer user group libraries, including those of the UK CP/M and MSDOS User Groups (the former also held by Emmanuel Roche in France, as discussed in my last working party report in issue 5).

Peter and I have agreed to collaborate later this summer on completing the reorganisation of the UK CP/M library volumes for storage under MSDOS, which principally involves making systematic changes to filenames which contain characters that are illegal under MSDOS. When this work is finished, I shall then also hold a complete copy of the UK CP/M library for the use of the S-100 Working Party and the CCS generally.

Apart from the intrinsic value of Peter's work in making this material more widely available, those in the Society concerned with software preservation might find much of interest in the methods that Peter has evolved to deal with the practical needs of organising and preserving substantial amounts of old software - that this is currently a hot topic, both for the Society as a whole and others, is illustrated by Sandy Douglas' remarks in his Guest Editorial starting on page 3 and by Doron Swade's article starting on page 13.


Adrian Johnstone, Chairman

Restoration activity has been suspended until we can re- establish ourselves at Blythe House, following the Science Museum's decision to require us to move from the Old Canteen building (see Society News on page 5). We have already moved all our systems and equipment to the new location, and it looks like a good working environment.

A copy of the PDP-8 emulator developed by Colin Smith has been given to Worcester College of Technology. The College is now looking for a late model PDP-8, such as a PDP-8/E, to provide its students with practical experience of the machine. Any offers would be greatly appreciated.

This emulator is available to anyone who wants it. It runs on VAX systems, but I am currently porting it to a PC environment.

Elliott 803

John Sinclair, Chairman

The Elliott 803 is still in the Old Canteen building at the time of writing, pending a decision by the Science Museum as to when it should be moved to Blythe House. The processor is currently in full working order, but there is a fault with the film handling system which I have so far been unable to trace.

I have stopped work on trying to locate this fault, as I have no diagrams to work with at present. This is because they are currently being copied onto microfilm. There is only the one set of drawings, which are the originals supplied with the machine when it was new - 30 year old A2 documents. Microfilming them will allow us to make as many paper copies as we wish while preserving the originals in at least their present state.

Another important step we have taken is to make a video which shows how to disassemble the machine and then put it together again. Tony Sale wielded the camera while I have provided the running commentary.

The video shows the best way of undoing the cables, and the way to mark the cables as they are removed. It shows also how to turn the machine on once it has been reassembled, a much more complicated procedure than with today's computers.

It involves taking some of the boards out of the cabinet before switching on the power supplies and ensuring they all work. The boards are then put back in batches in a strict sequence.

Unfortunately, even if the correct procedures are followed there is no guarantee that the system will then work - indeed, it is virtually certain that it won't. It is impossible to explain how to apply the necessary "kiss of life" on a short video: it took me a 16 week full time course to learn how to do it when I joined Elliotts in the sixties!

TopPrevious Next

Letters to the Editor

Dear Sir,

Tony Peach's letter in issue 5 reminded me that the Dynamic Own Array feature in DECsystem-10 Algol 60 did have a use: implementing Ackerman's function (reasonably) efficiently. Ackerman's function spends a lot of its time recomputing previously computed values, so storing them makes sense. Unfortunately it is not easy to predict what size array is needed, so a Dynamic Own Array, suitably resized by re- entering the block in which it is declared, does the job, reducing the computation time by at least an order of magnitude for non-trivial cases.

Dynamic Own Arrays were, to the best of my knowledge, only implemented on two other Algol 60s: a Burroughs implementation, and one produced at Novosibirsk (USSR as was). Unfortunately, my co-authors of the documents leading up to the ISO standard (David Hill and Brian Wichmann) did not agree that it is a very useful feature, and it did not appear in the standard, although we did ensure that Own variables were useful by forcing them to be initialised to zero or FALSE as appropriate.

My apologies for not writing sooner on this matter, but in the account of "The Early Days of Algol" in issue 4 there were a few typographical errors in the part relating to DECsystem-10 Algol 60. "Forced statement" should be "For statement" and "non real" should be "long real". I am not sure what "position" in "We put in a few extras: position..." should have been: the only other thing I can think of is string variables (including their subscription). Also "remainder, operator" should be "remainder operator".

By the way, I was certainly not one of the earliest users of Algol 60 - I learnt it (from a book) in 1964.

Best wishes,

Richard M de Morgan
Padworth Common, Reading
1 March 1993

Dear Mr Enticknap,

I would like to correct the suggestion made in the letter by Tony Peach in your Spring 1993 issue that the two Algol compilers developed for the KDF9 at Kidsgrove and Whetstone were produced by teams who were in ignorance of each other's efforts.

I was in charge of the Whestone compiler project though Lawford Russell and I worked very much as a team. From the outset there was a full agreement with the Kidsgrove group that we would develop a system which emphasised compiler speed and which was intended principally for program development, whilst they would produce a very sophisticated optimising compiler.

Thanks in particular to the good offices of Fraser Duncan at Kidsgrove the coordination remained close. One unplanned but very beneficial effect was that any technical disputes were, wherever possible, resolved by reference to the Algol 60 report. As a result our compiler was, to my knowledge, one of the most pedantically complete that was ever produced, and handled the full generality of for statements, call by name, own variables, recursion, etc. As a result we were able to announce its completion by publishing a certification of Tony Hoare's Quicksort algorithm (which he had described recursively but could only test on the Elliott 803 via a hand- converted iterative version), and to use Don Knuth's horrendous "Man or Boy" algorithm showing the complications of call by name, etc, as the main worked example in our book Algol 60 Implementation.

Yours sincerely,

Brian Randell
University of Newcastle
30 June 1993

Dear Nicholas,

Tony Sale's paper in the Summer 1993 issue of Resurrection gave a good account of the Enigma story at Bletchley Park (B- P), but in the section headed "Heath Robinsons" there were confusions that have been repeated many times since they first arose in the "Secret War" TV series. I would like to tell you a small part of the true story because you are surely devoted to historical truth in your journal.

The term Geheimschreiber is often used, but it is not the official designation of any German cipher system. There were actually two online Baudot code cipher systems in use, and most accounts have confused them.

One was a modified telex machine called T typ 52, made by Siemens and Halske. This could transform either keyboarded messages or punched paper tape messages into 5-unit enciphered telegraph characters on a pair of wires, and it could receive such a signal and decipher it, producing a printed paper strip. The T52 was mostly used on land lines and therefore the opportunity for B-P to attack it was very limited. I have been told that it "was never routinely broken".

When Norway was occupied, T52 transmissions via Sweden were intercepted and broken, but how much and whether the allies benefited is unknown to me. Late in the war some T52 traffic was sent by radio and may have been processed at B-P; I do not know.

Much more important to the Allied cause was a different cipher system known as Schluessel Zusatz or cipher attachment, either SZ40 or SZ42. This machine was made by Lorenz. I have tracked down two existing machines, one now in the DeutschesMuseum and the other in the Norwegian Armed Forces Museum. This system was used by the Wehrmacht for high level traffic by radio and was the target for the highly successful and valuable work of the Heath Robinsons and Colossi.

The SZ machine received a 5-unit telegraph signal, converted it into a five wire form, enciphered or deciphered it and then retransmitted it in the serial telegraph form. Therefore it was always used in-line, between normal teletype machines and their radio link. The intercepted traffic was called Fish, and much of B-P's work on it is described in Hinsley's official history. Several times, changes were made in the SZ machines and countered by hard work at B-P.

Dr Huettenhain of the OKW (Oberkommando der Wehrmacht) cipher bureau made a comparative study of the security of the T52 and SZ systems at the start of the war. He would not tell me the result but I suspect that the T52, in its later forms, was the more secure. The SZ was nevertheless chosen for the most sensitive application and I can only guess that this was because of the immense bulk and weight of the T52.

It has become customary to refer to the T52 as a Geheimschreiber, though people who used it in WWII do not seem to recognise the term. We should be quite clear that this machine was not the source of the Fish traffic broken by the Colossi.

Yours sincerely,

Donald Davies
Sunbury-on-Thames, Middlesex
10 June 1993

TopPrevious Next

Forthcoming events

30 September 1993 Evening meeting

Doron Swade of the Science Museum will be talking about Russian computers.

11 November 1993 Evening meeting

The subject will be CP/M - speaker yet to be finalised.

2 December 1993 Evening meeting

The subject will be the Stantec Zebra - speaker yet to be finalised.

24 February 1994 Half day meeting

Debate on why the British computer industry did not capitalise on the country's lead in computing, starting 2.00 pm at the Science Museum (subject to confirmation).

19 May 1994 All day seminar

The design and development of the IBM 360 series, starting 11.00 am at the Science Museum (subject to confirmation).

All evening meetings take place in the Science Museum Lecture Theatre and start at 5.30 pm.

TopPrevious Next

Committee of the Society

[The printed version carries contact details of committee members]

Chairman   Graham Morris FBCS
Secretary   Tony Sale FBCS
Treasurer   Dan Hayton
Science Museum representative   Doron Swade
Chairman, Elliott 803 Working Party   John Sinclair
Chairman, Elliott 401 and Pegasus Working Parties   Chris Burton FBCS
Chairman, DEC Working Party   Dr Adrian Johnstone CEng, MIEE, MBCS
Chairman, S100 bus Working Party   Robin Shirley
Editor, Resurrection   Nicholas Enticknap
Archivist   Harold Gearing FBCS

Dr Martin Campbell-Kelly
George Davis CEng FBCS
Professor Sandy Douglas CBE FBCS
Chris Hipwell
Dr Roger Johnson FBCS
Ewart Willey FBCS
Pat Woodroffe


Aims and objectives

The Computer Conservation Society (CCS) is a co-operative venture between the British Computer Society and the Science Museum of London.

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 the BCS.

The aims of the CCS are to

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

The CCS is funded and supported by, a grant from the BCS, fees from corporate membership, donations, and by the free use of Science Museum facilities. Membership is free but some charges may be made for publications and attendance at seminars and conferences.

There are a number of active Working Parties 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 corporate members who are supporting the Society are Allied Business Systems, Bull HN Information Systems, Digital Equipment, ICL, Unisys and Vaughan Systems.

Resurrection is the bulletin of the Computer Conservation Society and is distributed free to members. Additional copies are £3.00 each, or £10.00 for an annual subscription covering four issues.
Editor - Nicholas Enticknap Typesetting - Nicholas Enticknap
Typesetting design - Adrian Johnstone Cover design - Tony Sale
Printed by the British Computer Society  

© Copyright Computer Conservation Society