Elliott 803, 903 & 920M — Terry Froggatt

Peter Onion reports that, following his recent power supply work, the TNMoC 803 is once again running reliably, even straight after being turned on, although he speculates that this may change when the weather gets significantly colder overnight. He has recently restarted his training sessions on 803 subjects, for TNMoC volunteers.

The news about the TNMoC 903 is somewhat mixed. After extensive card-swapping by Peter Williamson and Andrew Herbert, we are now fairly certain that there is a problem with the backplane or with the edge connectors mounted on it: touching the card in slot 44 can stop the 903, regardless of which of the many A-FA cards is in that slot. The engineers display unit has now been reconnected (without the adverse side-effects reported in Resurrection 95) which indicates that bit 10 of the Q-register is often stuck on, although it can be cleared by RESET (so it is not a display unit fault). It is not yet clear whether the two faults are related. If they are, then the waveform gating signals GTQ and 0TQ are amongst suspects and, because these signals are common to 9 A-FA cards we can try linking these signals card-to-card. If this does not locate a backplane fracture, we may have to take the whole CPU rack out of the cabinet, possibly for some time, for investigation off-site.

I confess to making no progress on the TNMoC or eBay 920Ms: I’ve been busy on the software front.

The assembler for the 900-series, SIR (Symbolic Input Routine), comes in two forms (excluding the much later MASIR macro assembler): there is a load-&-go SIR capable of loading code into that part of an 8K store not occupied by itself, and 2-PASS SIR, which runs in an 8K machine and converts SIR tapes into binary tapes: this is capable of loading code into almost the whole of an 8K or 16K machine, as needed for embedded applications. I’ve now re-implemented 2-PASS SIR (by a largely mechanical translation into Ada) as a cross-assembler running under 32-bit or 64-bit Windows. It produces exactly the same binary file as the native version, but it is far faster than running the native version on a real machine or in a simulator. The translation revealed two unreachable instructions in native 2-PASS SIR which I’ve traced to an error introduced (over 50 years ago) when a subroutine was lifted from the load-&-go version into 2-PASS SIR without correctly adjusting a short relative jump. Bypassing the two instructions harmlessly implemented a slight language extension which wasn’t supposed to exist, but one wonders whether similar errors occur elsewhere. Remember that this native issue of 2-PASS SIR was used for the Jaguar Flight Program, which included weapon aiming and release.

EDSAC — Andrew Herbert

EDSAC Commissioning work continues at TNMoC. Three groups are active. The “Tuesday Group” is focussed on commissioning of Main Control, Order Decoding and Arithmetic Units. Main Control and Order Decoding has been mostly stable for the past several weeks and the Arithmetic Unit is being checked for correct operation chassis by chassis. The multiplier and accumulator registers are now in operation, jumps have been tested and the next step is to check simple orders like addition, subtraction and collation. The “Thursday Group” is focussed on store address decoding and the Transfer Unit. The “Friday Group” is on the threshold of swapping short nickel delay lines permanently for the current silicon digital tank emulators having unit tested the chassis 01 recirculation units and the nickel delay lines. The six-CRT Display Unit is in regular use as a debugging aid.

As commissioning proceeds and less of the machine is subject to alteration we are learning the main failure modes of the machine and techniques for quickly locating the source of problems. We have experienced some valve failures that have led to other components being “cooked” by high current flows and if this becomes a common problem we may have to look at replacing components at risk by higher wattage variants.

Another benefit of the machine being now substantially complete is that current flow imbalances between racks that would, in the past, trip the power supply are now less of an issue, further adding to our overall sense of growing confidence in the stability of the system.

Once the Arithmetic Unit is fully checked out, the Transfer Unit becomes a priority and the replacement of all register digital tank emulators by nickel delay lines. The step after that will be teleprinter output and paper tape reader input, leaving initial orders and connection of nickel delay lines for the main store as the final work to be done.

Software — David Holdsworth

Webserver issues

In September, I said:

I have long been aware that the long-term longevity of our online preserved systems (Leo III, KDF9, etc) currently depends on the longevity of actual webserver systems. This motivates me to package up the software so that it can be installed on a free-standing machine. My ambition is to release the whole source text under GPL.

My re-implemented javax.servlet API works on various versions of Java on various machines, both in Settle and Cambridge. This includes compilation as well as execution. I have added in GPL headers. The basic javax.servlet JAR file has been compiled with version 7 of Java, and continues to work on all known subsequent versions. I no longer have access to a big-endian system, but in the past I have successfully run on a SPARC system, and the webserver core is the same as the one that ran on a SPARC machine at Leeds University for over a decade.

Free-standing system

The easiest access to the different emulation systems is via the web interface. Preservation of this facility into the indefinite future relies on the continued existence of institution(s) running the appropriate webserver. I am taking forward the system-independent approaches described above to create a free-standing architecture which runs everything on a free-standing machine.

The emulator programs are written in either C or Ada, and there are bits of scripting. The aim is that I can package things up so that the result will work on anybody’s personal machine without modification. I am currently thinking in terms of a core package which implements the webserver and the servlet for launching emulation programs, and there will then be add-ons for different emulation systems. At present I have this working for the Leo Intercode system which does not involve any scripting (i.e. bash or Windows BAT files). I have plans in my head for a general mechanism that will allow me to embrace KDF9 and others. Installation of the package will only involve unzipping, and then running C and possibly Ada compilations.

Elliott matters

Andrew Herbert is making great strides with implementing preservation of Elliott Algol. I have hopes of absorbing his implementations into my above plans. The Elliott Algol situation is different from our previous LeoIII and KDF9 preservations in that we do not have to rescue the source code from printer listings of possibly questionable adherence to the released products. We have the machine-readable original source code.

KDF9 emulator

Version 8.1a of Bill Findlay’s emulator ee9 was released on 3^rd October. It can be found at www.findlayw.plus.com/KDF9/emulation.

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

PF56 Emulator (2812/7903)

David is continuing his work on the PF56 emulator — some progress has been made towards persuading it to communicate with the 1904S emulator using shared files. As part of this process he has made a GIN source from a binary of ESAZ, the 1900 program for DDE (Direct Data Exchange) testing. He has also transcribed a listing of SA0ADD0A, the PF56 application for DDE testing. Unfortunately our copies of ESAZ and SA0ADD0A came from different sources (the latter was transcribed from TNMoC’s ICL aperture card collection, the former is believed to be from the Galdor tapes) and it has become clear the two applications are at different points in their development cycles. When started up, each application waits for the other end to tell it what to do! The next step is to try and gain a greater understanding of ESAZ in the hope that SA0ADD0A can be modified to work with it.

IBM Museum — Peter Short

Current Activities

We are now able to reveal that the loan of our 080 card sorter is for Bletchley Park’s new WW2 exhibition to be opened next year. The machine still needs a new glass top cover to be made and a same size piece of plywood to put in its place instead during shipment.

In addition, our colleagues in Böblingen are making some audio recordings of working unit record machines. They have already sent a recording of their sorter, which will be used in the audio guide to the exhibition.

The new photo archive section referenced last time has been added to the museum website under ‘photographs’ — a large personal collection of IBM hardware photographs collected by Peter S. over the years. igonta.net/hursley/IBM Hardware.

Further progress on the Extreme Blue project has been made with the acquisition of three iPads borrowed from another laboratory project. The prototype app is ready and is being tidied up. Curators have prepared some initial inputs for the app.

Thanks to the agreement by the CCS committee at the last meeting for a small grant, we have now had the clock banner produced. An actual clock will stand in front of the large clock image when we put it out on display.

SSEM — Chris Burton

Demonstrations of the SSEM replica at The Science and Industry Museum have continued but with the restrictions mentioned in previous reports.

Two more volunteers have participated in the “Return to Volunteering” course, but the maximum of two volunteers in attendance in a maximum three-hour slot still remains. Negotiations are continuing with a view to permit use of sufficient test equipment to allow detailed fault finding and machine repair. Unfortunately a number of common faults still occur regularly.

We are awaiting formal issue of updated H&S documentation from the museum, covering normal running, test and repair processes. This has been delayed due to a change in curatorial staff.

Bletchley Park Trust — Peronel Craddock

Block A

The restoration of Block A is nearing completion, and we will open two new exhibitions in the space Spring 2022:

• The Intelligence Factory will be a new permanent exhibition in the largest exhibition space on site. It will tell a key part of the BP story — how Bletchley Park’s potential as an intelligence organisation was unleashed in the second half of World War Two. We are delighted to be including a Hollerith 080 card sorter in the exhibition, kindly on loan from IBM Hursley.
• The Art of Data: making sense of our world (working title), a temporary exhibition in a new exhibition gallery that will take inspiration from the techniques used by the codebreakers to manage information at scale and focus on how data visualisation helps us to make sense of our world today.

UK/USA

We are previewing our new four-part documentary series exploring the UK and USA’s special intelligence relationship that began at Bletchley Park. The films will be screened weekly from 17^th November, with a live Q&A afterwards.

CCS Website Information

The Society has its own website, which is located at www.computerconservationsociety.org. It contains news items, details of forthcoming events, and also electronic copies of all past issues of Resurrection, in both HTML and PDF formats, which can be downloaded for printing. At www.computerconservationsociety.org/software/software-index.htm, can be found emulators for historic machines together with associated software and related documents all of which may be downloaded.

In Resurrection 95 we published this photo which was captioned “... with three sadly unidentified ladies”. Jim Brookes writes — “... they are: at the front Patsy Rouse, then Carol Clegg, and at the back my late wife — (then) Pat Gaskell”.

Thank you for rescuing us from our embarrassment Jim.

101010101

Our industrious friend Herbert Bruderer has published two further papers in the Communication of the ACM which may be of interest — Computers were Originally Humans at ccsoc.org/bru3.htm which discusses the work of people performing complex calculations in the pre-computer age.

Patent Protection in Europe at ccsoc.org/bru4.htm takes us back to the 16^th century and explores the introduction of patent law in various European states.

101010101

Yet another Apple 1 comes up for auction, this time making $400,000 for a working example, with software and a nice wooden case. Prices seem to be in decline since 2014 when one realised $905,000. Best hang on to that machine in your loft for the time being.

See also www.bbc.co.uk/newsround/59231294.

101010101

From the Science Museum Group Rachel Boon reports that Manchester’s Science and Industry Museum has appointed a new curator of Science and technology — Dr Hattie Lloyd. We look forward to meeting her and wish her well.

101010101

November 15^th 2021 marked the 50th anniversary of the Intel 4004, the world’s first commercially available microprocessor. The 4004 was a 4-bit microprocessor with a clock rate of 750kHz and consisting of just 2,300 transistors. Intel had been approached to design 12 custom chips for a new Busicom printing calculator, but suggested an alternative four chip architecture consisting of RAM, ROM, a shift register and a general purpose microprocessor (the 4004). Intel later acquired the rights to sell the chipset, known as MCS-4, running an advertisement with the headline “Announcing a New Era in Integrated Electronics”, a prophecy which has certainly come true.

An Interesting Project in Padua

Franchesco Contin writes —

I am working on the recovery of a calculating machine built in Padua at the end of the 1950s (from 1958 to 1961). I have evidence of certain contacts with A. Booth and The Wharf (they at least bought a drum memory). I am also recovering a good part of the shift register cards and I would like to understand if it is an original electronic project or if there has been an exchange of know-how with London.

I saw that a copy of the HEC has been rebuilt (not quite [ed]) and I would like to know if the project blueprints are accessible in some way for comparison. The machine could be an interesting new APE (I) C to add to the project list of Booth work.

Roger Johnson has supplied much useful information to Franchesco.

The EMAS Operating System and ICL 2900 Series

David Harley wrote to enquire about the EMAS the operating system developed at Edinburgh University which ran on the ICL 2900 range (amongst others). We were able to give him a brief guide to the 2900 order code and put him in touch with contacts in Edinburgh.

Some years ago, Alan Thomson made a scan of John Buckle’s book on the development of the 2900 Series which was supplied to Fujitsu and published on their website. During the conversation, it emerged that Fujitsu had deleted it. Happily, another copy of the scan had been taken. The Society website has been updated accordingly.

The Arcturus 18C Minicomputer

Does anybody know anything about this long-forgotten, early 1970s UK minicomputer? Apparently, the Science Museum has one but otherwise it’s a mystery.

Chair’s Report 2020-2021

I am pleased to report that the Society is in robust good health and has continued to adapt effectively and creatively to the challenges of Covid-19 restrictions.

Issues of Resurrection, the Society’s quarterly bulletin, have been uninterrupted thanks to efforts of its editor, Dik Leatherdale, and tireless contributors to whom we are all grateful.

As an historical record Resurrection is unique in the annals of British computer history. It is a chronicle by practitioners, programmers, engineers and designers with participant accounts that contain a level of detail for which there is no comparable repository. The technical, anecdotal, contextual, political, commercial, and design detail, down to the physical location of machines, is priceless information much of which would pass under the radar of conventional broad-sweep histories. It is, and will continue be, a remarkable contemporary source for future historians.

This issue of Resurrection is Number 96. All being well the Winter 2022 issue will be the 100^th in the series. With just over a year to the milestone of 100 we are running short of time to prepare appropriate celebrations.

Our lecture/seminar programme continues to thrive. For years I have marvelled at how Roger Johnson, our London Meetings Secretary, so effectively secures such a rich variety of speakers, year in year out.

When Covid-19 restrictions precluded live audiences, we successfully migrated, as did many others, from live audiences in BCS headquarters in London to virtual attendees via Zoom. The first of these was in September 2020. A notable highlight, and test of the system, was the January 2021 lecture by Barbara Ainsworth who spoke from Australia on early Australian computer developments and CSIRAC. Moving to Zoom has doubled attendance figures and given an already popular series live international outreach.

With restrictions largely lifted and live attendance again possible for those so disposed, hybrid events with a mix of live and virtual attendees have just been introduced.

The first hybrid Committee meeting was on 16^th September 2021 followed by a lecture on Percy Ludgate by Brian Randell. Both Chair and speaker were remote. The AV facilities for hybrid events are not trivial. Thanks and credit to Roger Johnson, Delwyn Holroyd, Bill Barksfield, and Dan Hayton for the thought, organisational and technical effort and expertise that went into devising the system, thoroughly trialling it on-site at BCS HQ, and running it so successfully.

We were delighted to welcome Adam Bradley, the IBM 360/20 project representative, to the Society and Committee. With the recent affiliation of the IBM 360/20 restoration project there are now some twelve active restoration projects. Adam has also set up a CCS Facebook page. Progress is inexorable.

Looking Ahead Backwards

The Society was founded in 1989. This September the CCS was 32 years old. There are several initiatives in the Committee’s work for the coming year to maintain records of the Society’s history. These include collocating, indexing, digitising and archiving the library of taped video recordings of early CCS lectures, compiling a record of publications authored by members, and working towards a central web presence as an access point to CCS resources, archives, activities and historical content. Included in the content will be a home for ‘Our Computer Heritage’ (OCH), a unique and authoritative database of early British computers, conceived and nursed into being by Simon Lavington over many years.

We have also initiated a promising and constructive dialogue with the BCS, our mother ship, about improving access to members’ records and improving operational efficiency in the service of our members.

I thank the Committee, project leaders, project teams, and members for the Society’s accomplishments and its continued vigour. We have much to look forward to in the coming year.

A Life of Calculation (Part 1)

Apart from my use of a Marchant electromechanical calculator when I worked for International Aeradio (a subsidiary of British Airways) in the 1950s, my first association with calculating machines was when I joined a very long-established family business in London called Muldivo Ltd in August, 1961. The company, located off Fleet Street was started by Mr Henry Easton in about 1912 and was run by his two sons, Roger and Alan Easton.

It specialised in mechanical calculators, electro-mechanical calculators, cash registers and adding machines.

The Mechanical Era

Muldivo was agent for German Thales calculators sold under the Muldivo name and for Madas electro-mechanical calculators from Switzerland. From 1963 it was also agent for the Swiss OERLIKON ULTRA 804 electro-mechanical printing calculator together with the Swiss HERMES PRECISA range of printing calculators. Later, it took on the WALTHER range of hand cranked mechanical calculators made in Germany and from 1964 onwards, the new Italian INDUSTRIA MECHANICHE ELETTRONICHE (IME) electronic calculators. The first IME model was the model 84, soon followed by the IME 86s. The IME 84 was notable as being usable with what I believe to be the world’s first floppy disc unit for recording and replaying programs which is described below.

The IME 86s was associated with a rather more sophisticated programming device with a small electronic memory. The IME machines used a Nixie tube display for displaying numbers typed through the keyboard and for displaying results of addition, subtraction, division and multiplication and, in the case of the IME 86s, square roots.

Muldivo owned various other companies including Guy’s Calculators in Wood Green, North London, (which made hand operated mechanical calculators, cash registers and adding machines).

One of the very early mechanical calculators before 1914 was the MILLIONAIRE, extensively used in the City of London for stock market bond yield calculations. That was also sold by Muldivo in those times.

The various makes of hand operated mechanical calculators were:

All the above, with the exception of the CURTA, were very similar in design —barrel style machines with ‘wind the handle’ mechanisms and multi-column lever type keyboards. The CURTA was small and cylindrical and could be held in the palm of your hand but its internal principles were the same as all the others.

During my time with MULDIVO in the early 1960s great changes were introduced into the teaching of mathematics in English schools via a system known as the Southampton Mathematics Project. A serious part of this was the introduction of hand-cranked mechanical calculators into junior schools because of the way that they made the operations of addition, subtraction, multiplication and division visibly obvious under pupils’ own direct control (and immediately correctable). Many of the hand-cranked calculating machines named above were used in hundreds of English schools to make it easy for pupils to readily see and understand the basic principles of arithmetic at that time.

Yet more varieties of hand-cranked calculators were the following, but these were not used in schools in the UK.

(MADAS and MONROE also produced hand operated mechanical calculators but they were of the full keyboard type like their electromechanical ones; not barrel type machines; they had proper columnar keyboards instead of levers for the entry of digits and were more expensive).

^{1. Different from those above in using a 10-key keypad but still with internal barrel type mechanisms.}

Electromechanicals Arrive

The makes of available electromechanical calculators were:

They typically cost about £500.

These were much used in scientific and engineering establishments such as the Royal Aircraft Establishment at Farnborough and the National Physical Laboratory at Teddington.

The OLYMPIA, PRECISA, ULTRA 804 and BADENIA machines were uncommon, at least in the UK.

Of the above, the OLIVETTI, PRECISA, ULTRA and one of the later DIEHL machines were printing calculators. The OLIVETTI models were called DIVISUMMA and TETRACTYS. All the printing calculators used a 10 key numeric keypad and were based (internally) on barrel type mechanisms. Except for the OLYMPIA, all the others used full banked multi-column keyboards — i.e. MADAS, MARCHANT MONROE, FRIDEN, BADENIA and DIEHL.

I worked for Muldivo from August 1961 to December 1967. I left them to set up the UK branch of Wang Inc. (with offices in the B.M.A. building at Tavistock Square in London) in January 1968.

^{2. Ultra 804 was made by Oerlikon.}

Dr An Wang had designed and patented a device known as a LOGARITHMIC GENERATOR which calculated natural logarithms and exponentials (antilogs) in a digit by digit manner somewhat akin to the process of long division. The first model was called the LOC. At the time that I joined, the available models were known as 300, 310, 320, etc and the LOCI was no longer in production. I only ever saw a picture of one. The logarithmic generators were held in ROM. Later models from Wang were the 500, 600 and 700 series machines.

Wang’s systems performed multiplication and division by forming the logarithms of the two operands, then adding or subtracting the logarithms as appropriate, and then taking the antilog of the result. Square rooting was performed in a similar way. Besides keys for +,-,/,* and √, keys were provided to obtain natural logarithms and exponentials directly. The internal use of logarithms for multiplication, division and square roots was hidden from the user; for all they knew it was just performing arithmetic in the way that any other calculator would.

I left Wang to join HP at Slough on April 1^st 1969 and remained with HP until my early retirement in 1993. I joined HP in 1969 because I was so impressed with the design of the HP 9100a which HP had introduced on the 1^st April 1968. Its invention and design was described in one of the 1968 issues of the HP JOURNAL in great detail. There was also a 9100b with more memory.

The HP 9100 was produced in Loveland, Colorado. It was designed to use digit-by-digit methods for the computation of the transcendental functions i.e.

but it performed arithmetic in the usual way unlike the WANG machines. Its ferrite core memory was assembled by hand with great dexterity by Chinese ladies in a Hewlett Packard factory in Singapore. The ferrite core memory was such that it retained its digital information in the absence of power, so you could switch it off in the middle of its running a program and later switch it back on whereupon the program would continue running from where it was when switched off. No later HP computers had that facility. It used BCD (binary coded decimal) arithmetic and worked internally to 12 decimal digits with an exponent range from 10^(-99) to 10^(+99). All subsequent HP desktop computers used BCD arithmetic processors of HP design and manufacture until and including the HP 9845 machine. Thereafter we used IEEE 754 double precision binary arithmetic starting with the Motorola 68000 based HP model 9826 desktop computer in 1981.

Early electronic programmable calculators were:

Of these, the earliest were the WANG LOCI machine and the IME 84. The programming unit of the IME 84 consisted of a turntable (like a small gramophone player) with a central spindle for a floppy disc — just a bare disc of Mylar coated with magnetic oxide of iron with no outer casing. You just placed the disc with your fingers on the turntable then lifted up the read/write head on its pivoting arm and placed it down on the surface of the floppy disc. You then switched to RECORD mode and typed on the keyboard of the IME 84 the sequence of operations which you wished it to perform automatically, including PAUSE instructions at which a numeric input would be required from the user followed by depression of ENTER. After that you set it back to RUN mode and ran the program, entering numeric data from the keyboard at each PAUSE. As you may imagine, it was not very reliable when the floppy disk had got covered with fingerprints.

The HP 9100 (left) used ferrite core memory and used short magnetic cards for storing and retrieving programs. The HP 9810 and 9820 also used such cards but much longer, hence greater capacity for longer programs. The OLIVETTI 101 used magnetic cards for storing and retrieving programs. I believe that the COMPUCORP did also. COMPUCORP must have been about 1967. I think that CASIO, SHARP and TOSHIBA may have produced electronic calculators by then but I cannot remember if they were programmable. The FRIDEN used patchboard programming (c. 1967). By now, all of these used the 10 key numeric keypad for the entry of numbers except for the SUMLOCK ANITA. There was no provision of a typewriter like keyboard for the entry of text on any of these systems.

The FRIDEN, the OLIVETTI 101, the HP 9100, HP 9810, HP 9815 and the WANG Series 300,400,500,600 machines all used Reverse Polish Notation. I can’t remember what notation was used by the TEKTRONIX machines and by the DIEHL printing calculator. The display was usually a row of NIXIE tubes; although the HP 9100 and FRIDEN machines used very small three-row CRTs.

OLIVETTI machines had no display and relied on an internal printer for feedback to the user. In the case of the OLIVETTI 101 it was a narrow printer but the later OLIVETTI 602 printer used A4 width thermal paper on a continuous roll. The DIEHL printing calculator also used a narrow width inbuilt printer.

WANG and WYLE used HOLLERITH cards for program storage. The programs were not fed into memory. Instead they were interpreted instruction by instruction from each column of up to 8 holes on the 80 column of the Hollerith cards. Each column contained the code for one instruction. One had to learn the binary codes for the entire instruction set and press the appropriate holes out in each column of the card with something like a crochet needle after composing the sequence of instructions that was to be the program including any conditional GOTO instructions. It was very like programming directly in machine code. Programming patchboards on the FRIDEN and CLARY machines required a similar approach, although there one was using pieces of wire with plug ends to temporarily join various pairs of holes in a square matrix of holes on a printed circuit board. The WANG systems used devices somewhat like small toasters each taking one Hollerith card at a time; for longer programs, one could connect a number of such card holder units in series.

The MATHATRON also required a similar approach, but in its case you used a small hand punch to punch holes for eight-bit codes onto a piece of paper tape which was then fed into a small paper tape reader attached to the machine. The eight-bit codes were known as opcodes. Once again the codes were read and operated on one at a time as the paper tape was moved through the reader.

For all the other programmable calculators, the entire program was typed in through the keyboard and then saved from internal memory in its entirety onto reusable media such as magnetic cards, tape cassettes or tape cartridges.

The HP 9830 and HP 9821 used audio tape cassettes. The HP 9830 could also use hard disc drives as big as washing machines.

The OLIVETTI 602, the WANG Series 700 and 800, the TEKTRONIX (? 4608), the HP 9830 and the HP 2648 all used various forms of BASIC (inbuilt in ROM). The IBM 5100 system came with a choice of either IBM BASIC or APL in ROM. (The forms of BASIC used were derived from the original Dartmouth College BASIC; this was long before the time of Bill Gates and Microsoft).

HP, WANG, OLIVETTI and TEKTRONIX were the major players in the market place for these machines. Their users were mainly scientists and engineers whose work involved complicated mathematical equations. (e.g. Land surveyors computing traverses; optical engineers doing ray tracing for lens design; those applications used trig functions very intensively).

The WYLE (1967) and NANOTECH (1968) machines were American. I don’t think either actually got to market. The NANOTECH machine was small, compact and ruggedised and could be carried around in a small shoulder strap bag. Certainly neither of them was sold in the U.K.

The DYNATRON was very unusual in that it performed arithmetic up to (as I remember) 100 decimal digits. I am not aware that it was ever sold in the U.K. It may not even have got to market in the USA. The DYNATRON machine was, I believe, called the DIGITRONIX.

From the same era, I associate the name DURANGO (an American town) with some kind of electronic programmable desktop computer. It never reached the market outside of the USA and I’m not sure that it ever went on sale in the USA.

HP’s first 16-bit machine was its HP9825a introduced in 1975. Program storage was on mini tape cartridges or 8” floppy disc drives. Its BCD processor was designed and produced in HP’s own IC plant in Fort Collins, Colorado. We also introduced an HP 9831 model using the BASIC of the HP 9830; It was exactly the same machine as the HP 9825, but with BASIC in a plugin ROM in place of the plugin HPL language ROM. It was to be years before home computers and PCs that could use 16-bit processors arrived. For years only primitive eight-bit microprocessors were used so the home computers of those times were extremely slow and could only address relatively small amounts of memory. (The common processors in the early machines were INTEL 8080 and ZILOG Z80).

The 16-bit processor of the HP 9825 was also used in the HP 9845 introduced in 1977. The HP 9845 used HEWLETT PACKARD’s famous ROCKY MOUNTAIN BASIC stored in ROM whereas the HP 9825 used HEWLETT PACKARD’s own language called HPL (also stored in ROM). HP’s ROCKY MOUNTAIN BASIC was to set an unrivalled standard of excellence and superiority as a programming language for many, many years. It still continues today on PCs as HT BASIC available from TRANSERA CORPORATION in UTAH, USA although the Microsoft Windows operating system together with the nastiness of PC keyboards detracts from the original user friendliness of the HP BASIC operating system environment. Even today there is still no computer language to rival HP’s ROCKY MOUNTAIN BASIC in ease of use for instrumentation control applications. It is still unrivalled in the clarity of its source code with respect to human readability and comprehensibilit by anyone unfamiliar with the language. It should be noted that it was and is a fully structured language, even incorporating complex arithmetic in the mathematical sense, together with a full range of intrinsic transcendental mathematical functions allowing complex arguments as well as real arguments, not only for simple scalar variables but also for entire multidimensional arrays of data. ROCKY MOUNTAIN BASIC is a truly wonderful way of documenting computer algorithms — far better than anything else that I ever encountered because of its instant and intuitive human readability.

HP ROCKY MOUNTAIN BASIC is utterly unlike the primitive forms of BASIC produced for home computers by Microsoft and indeed unlike any other forms of BASIC used in other makes of home computer and in timeshared computing. Its human interface and programming aids and editor are incomparably better than anything ever produced for use on any other computer.

It was highly recommended by scientific computing experts in the MOD as an extremely fast and efficient program prototyping language.

HP 9845s running HP BASIC were in use on all the ships of the Royal Navy. They were also in use at the Foreign and Commonwealth Office and the neighbouring Her Majesty’s Government Communications Centre at Hanslope Park, a few miles north of Bletchley. Some of the HP computers at the Bletchley Park Museum had previously been in use at HMGCC and the FCO. HP also produced a model 9835a which used exactly same combined operating system/programming language as the HP 9845, but was housed in a desktop box similar to that of the HP 9825; like the 9825, it did not use a screen but instead used a small one line LCD display and an internal narrow thermal printer.

In all cases, the 9830, 9825, 9831 and 9835 could use an externally attached HP A4-width thermal printer like the one built into the HP 9845 and the later DAWN 9020 32-bit desktop computer. The first model of that printer was the HP 9866 introduced in 1972, and later followed by the HP 9876 which was twice as fast. The print head was totally static and was of A4 width; it heated up [or not] a complete row of resistors for one row of pixels of a row of 80 (9 by 15) pictographs at a time. The printer incorporated into the frame of the HP 9845 and HP 9020 was the HP 9876 version. It used the same type of thermal paper as was used in FAX machines.

We called the language of the 9845 ROCKY MOUNTAIN BASIC. It was a fully structured language very similar to Fortran in many ways (e.g. it used COMMON blocks, and SUBs which Fortran calls SUBROUTINES).

Variables used within procedures and functions were purely local unless declared in labelled common blocks or passed by reference (instead of by value) in the parameter list of the procedure header. When passed by reference, variables could return computed values back to the appropriate calling environment of the program. Like Fortran, the scoping is different from that used by the ALGOL family of languages (i.e. PASCAL, C, C++, etc). Procedures and Functions of ROCKY MOUNTAIN BASIC have fully recursive call facilities.

I will here distinguish between programmable calculators and desktop computers. I will take the latter to be using a high level computer programming language and to be equipped with a typewriter like keyboard. The HP 9830, 9831, 9825, 9835 and 9845 were desktop computers in that sense as were the OLIVETTI 602, the WANG Series 700 and 800, the IBM 5100 and the later TEKTRONIX machines.

Part 2 of this article will be found in the next edition of Resurrection.

The animator Tony Pritchett sadly died in 2017 and his archive of films, listings, paper tapes and other documents has been given a temporary home by Kate Sullivan. Amongst the archive we found numerous artefacts linked to a GRAphical Macroprocessor (GRAM), developed by Tony at the Open University from 1972 to 1977, based on Strachey’s General Purpose Macro-generator (GPM). This article describes the GRAM system, a working version recovered from archive documents and examples of its use.

Introduction

Several articles have appeared in Resurrection concerning Stratchey’s General Purpose Macro-generator (GPM), covering code resurrection, translations to newer programming languages and later developments. These include Andrew Herbert (Resurrection 66), on the Elliott 903 version (deriving from a paper tape in Terry Froggatt’s collection), P.A. Cherapanov (Resurrection 80) a port to C, Bob Eager (Resurrection 84) ML/1 — Son of GPM? and Andrew Herbert (Resurrection 84) on Elliott 905 ML/I. Andrew Herbert’s first paper references a BCPL implementation by Martin Richards at Cambridge. In this paper we describe a GRAphical Macrogenerator developed by Tony Pritchett over a period of some five years across a variety of platforms. Kate Sullivan is providing a temporary home for Tony’s archive. In Resurrection 89 we described the discovery of the code that generated what was arguably the first computer-generated character animation worldwide. Further archive exploration has uncovered GRAM code and examples of its use in projects ranging from programmes for the BBC/Open University, ITV and the film Alien. GRAM, written in Fortran, was based on Strachey’s GPM.

We would like to thank Victoria Marshall at Chilton who provided a home for online copies of relevant documents, Bob Hopgood who debugged some of the Fortran code and transcribed numerous documents and Terry Froggatt who read paper tapes on his Elliott ARCH 9000 installation.

The aim was to produce a working GRAM system that would process user scripts and generate graphical output. The target output language used was Scalable Vector Graphics (SVG), now a part of HTML. The recovery task wasn’t straightforward. The archive contains line printer listings, manuscript drafts (including an incomplete GRAM Manual and parts of a thesis Tony was writing) and paper tapes. The paper tapes were the most likely source of complete code, often generated for archival or transfer between machines. Program listings were often incomplete, contained few comments and were accompanied with manuscript changes. Since a working GRAM system consisted of Fortran code, macro definitions and user script, finding consistent versions of all three was challenging. A detailed account of this work is available at ccsoc.org/gram0.htm along with the reconstructed GRAM code and transcripts of key documents.

Why GRAM?

As early as 1967, the BBC explored the use of computer animation for educational programmes. One example, Random Walk (see ccsoc.org/gram1.htm), was produced by Tony and was shown on TV in 1968. In 1971 two trials were carried out for the BBC, one at Culham and the second at the Atlas Computer Laboratory (ACL) at Chilton using their microfilm recorders. These trials showed that computer animations could be generated each week for a BBC/OU maths course. Tony Pritchett and Jeffrey Lickess wrote the Fortran programs, plotted debug frames on a Calcomp plotter and produced final films for the Course on the SC4020 at ACL.

By 1972 it was clear that the production cycle on a remote batch system such as Atlas with an offline microfilm recorder was far from ideal. The Open University had a 32K Data General Nova 16-bit mini-computer and was likely to install other similar systems. A local computer animation system capable of input from a Tektronix storage tube or a pencil follower like the D-MAC and output to a local plotter or magnetic tape would mean that development runs could be achieved locally and just use a remote batch system for film output. Most minicomputer systems did have Fortran available but this was not the ideal language for computer animation.

However, Tektronix storage tubes were versatile, capable of both graphical and textual input and output. The D-MAC pencil follower was useful for tracing the outline of diagrams.

Although aimed at the OU’s Nova, additional computers would be purchased and there was a need to have a system not targeted specifically at the Nova. Magnetic tape would be required for final film output as microfilm recorders were remote and offline.

Development of GRAM and the Reconstruction

In 1972, Tony made the case for an OU computer graphics facility for the Open University called GRAM, based on Strachey’s GPM macrogenerator. It is difficult to construct a precise timeline for the development of GRAM, not least because of the range of systems involved, incompleteness of listings, and the interpretation of such dates as we have.

A May 1974 Nova Fortran listing of GRAM was clearly a system under development with hand-written corrections to the code. There are listings between October 1976 and April 1977 for implementations on a PDP 11 and the CDC 6400 at the University of London Computer Centre. A Nova listing in 1976 included substantial extensions from the earlier version. We also had transcripts of paper tapes from a similar period. We know that GRAM had been ported to the ICL 1906A at Rutherford Laboratory (previously ACL) by December 1976. There were also listings from a PRIME 400 computer at the Rutherford Laboratory.

We started initially with the Nova version from 1974 as this was the simplest. After some effort we created a working version that compiled under the GNU Fortran compiler and the Silverfrost compiler. It was very helpful having two compilers available as each found different issues with the code. Most of the problems were around COMMON blocks / EQUIVALENCE statements having different lengths in different subroutines and a few places where the code jumped back into the range of a DO-loop. As one would expect, transcription errors from sometimes faint and hard-to-read listings also caused problems, not least the difficulty of distinguishing letter “I” and digit “ 1” in the fonts used. Boolean values were sometimes treated as Fortran LOGICAL values and sometimes as integers, which caused problems. We replaced LOGICAL values by INTEGER values throughout. We also used two-byte Fortran integers (INTEGER*2) throughout which enabled us to retain the majority of the original code for character handling and other data type manipulations. As far as possible we adhered to the original Fortran IV language, the only later features used being in two output routines where shift functions and WRITE statements which suppressed new lines were used.

Studying this early version enabled us to gain a basic understanding of how the code was working and in particular how the single stack represented by a pair of arrays LIST and LNK with the latter storing pointers (array indices) and the former pointers or values of the other datatypes, character pairs and integer values.

We briefly looked at the 1906A version but as the 1906A used 4 × 6 bit characters per word, the code was considerably different to the Nova version. Instead we focused on the GRAM Nova 1976 version, with the addition of a few missing subroutines from other sources.

The diagram below gives an overview of the GRAM system. A particular feature was in the incorporation of a graphic editor and macro editor. These supported the interactive development of scripts including interactive construction of geometric shapes. They were implemented using GRAM macros and primitives.

Tony described three main ways in which GRAM differs from GPM, which were made primarily to improve efficiency for interactive graphics, the main one being that the linear search to match a macro-name occurs once only, on input. Thereafter it is replaced by the address of its definition. (This was done at the expense of some useful tricks that can be performed with macro-names in GPM.)

Four types of item were used: Numbers (integers in the range -8191 to +8191); Alpha Pairs (one or two characters out of the ASCII graphic character set (excluding control characters) surrounded by quotes); Names (a string of characters from a restricted set, internally represented as a pointer to an entry in a table, added to a negative constant to keep it less than -8191) and Control Symbols (one of the reserved characters, including < > ( ) # ! represented internally by a large negative integer outside the range occupied by Names). The restrictions imposed enabled the type of a value to be determined by a numerical range check.

A significant change here was that the first Nova version had a string item type, where a string was represented by a sequence of pairs of characters and a terminator. Here strings were replaced by pairs of characters. One implication of this was that a string “ ABCD” presented as a macro parameter would be mapped to two parameters, “ AB” and “ CD”. In this final version the set of control symbols was extended beyond the set listed above.

The original NOVA code was structured into a set of overlays. This was interesting in terms of the grouping of routines, but was redundant for current hardware/software environments and was discarded.

GRAM Primitives

GRAM has a set of functions, termed primitives, for performing a range of essential or useful operations (such as defining macros). Each primitive has a name, and is called in the same way as a macro (<name><argument list>). Instead of executing a macro definition, it executes the appropriate Fortran code in the GRAM program. Primitives are identified by positive integers in the Fortran code.

Each GRAM version has about 100 primitives, some of which extend its power from that of a macrogenerator to a more general-purpose high-level language (for example, there are primitives for performing arithmetic and logical operations).

In the implementation primitives are essentially grouped by functionality, each group being implemented by a subroutine, for example graphics primitives and storage handling primitives. The set of primitives changed from version to version of GRAM and there are instances of the same number being used for different primitives in different versions. A built-in macro, PRIM, is used to associate symbolic names with primitives, for example:

PRIM : 28
PRIM NUTR 61,PRIM DNTR 62,PRIM UPTR 63,PRIM FIG 64,PRIM ROT 67
PRIM EXTR 91
PRIM STOP 100

In the examples described here, the name “:” is used to introduce the definition of a new macro.

Using the primitive names defined above, the GRAM input comprises an additional set of macro definitions, and a script with the output shown here:

:TRIANGLE 4!0 4000 2000 -4000 -2000 -4000 0 4000
NUTR,DNTR,FIG TRIANGLE,UPTR,EXTR 1
STOP

The basic idea is to build a tree structure representing the line graphics, including, as we will see shortly, transformations, then to traverse this to generate graphical output. The output routine in GRAM has been modified to generate Scalable Vector Graphics (SVG) markup rather than Tektronix commands.

:TRIANGLE defines a macro, TRIANGLE, which holds a list of 2D coordinates. The first number, 4, is the number of coordinates in the list and “ !”is a null-character separator.

The next line consists of five primitive functions, separated by commas. Roughly speaking, NUTR starts a new tree, DNTR starts a new level, UPTR, goes back a level, FIG inserts a reference (stack address) to the data defining a figure. These functions are implemented in a subroutine TOTREE which creates a linear representation of the tree in an array. The primitive EXTR is implemented by the subroutine EXTREE which traverses this tree generating graphical output, in this case the SVG path element:

<path d="M 0,4000L 2000,-4000L -2000,-4000L 0,4000"/>

Transformations

The part that has been glossed over in this explanation is the way the coordinate transformation that is applied to the coordinates is calculated. In this case the transformation is the identity transformation, it is easier to see what is happening in general by considering the addition of a rotation transformation (by -90 degrees).

NUTR,DNTR,FIG TRIANGLE,ROT -90,UPTR,EXTR 1

TOTREE computes a transformation matrix for each level in the tree which is stored in an array of 240 elements. Since each array has 12 elements, this allows for up to 20 matrices to be stored. In this instance, TOTREE generates two matrices, an identity matrix for the top of the tree and a matrix representing the rotation to apply to the TRIANGLE. The matrix stack is shown below with a blank line inserted to separate the two matrices. The first three rows in each matrix are a 3×3 matrix representing scaling and rotation, the 4^th row represents translations.

    1.00    0.00    0.00
    0.00    1.00    0.00
    0.00    0.00    1.00
    0.00    0.00    0.00
    
   -0.00   -1.00    0.00
    1.00   -0.00    0.00
    0.00   -0.00    1.00
    0.00   -0.00    0.00

Rather than do general matrix multiplications to apply a transformation matrix to a set of coordinates, GRAM identifies special cases that only require a restricted set of the matrix elements and hence reduces the number of multiplications and additions required, which might well have resulted in a valuable performance improvement at the time.

Tree Traversal

The subroutine EXTREE has to determine the transformation matrix to apply at each level in the tree. Essentially this will be the composition of the matrix at the current level with the matrices higher up the tree to create an accumulated matrix and again, presumably to save execution time, GRAM does not do general matrix multiplications, but uses the types of the matrices to work out the specific elements that need to be combined. Knowing where the coordinates of a figure are located on the stack, EXTREE then invokes a subroutine to apply the accumulated transformation matrix and finally another to generate the graphical output.

A Simple Animation

Next consider the following example, designed to illustrate the basic primitives for animation:

PRIM LIN 71, PRIM HARM 72
:TRIANGLE 4!0 4000 2000 -4000 -2000 -4000 0 4000
:DISP [NUTR,DNTR,FIG #1,LIN 0 5 #2,MOVE 0 0 1000 1000,UPTR,EXTR 1 ]
DISP TRIANGLE 0, DISP TRIANGLE 1
...
DISP TRIANGLE 5

Two further primitive functions (interpolators) have been named, LIN and HARM. To simplify the example a macro, DISP has been defined which renders a single frame of the animation. The first parameter defines the coordinates of a shape and the second is the frame number. DISP is called for each frame to be rendered. The output is shown here. Six frames have been superimposed.

LIN is a linear interpolator, setting a variable, FRACT. If the parameters of LIN are named I1 I2 I3, FRACT is calculated by the formula (I3-I1)/(I2-I1), so for values of I3 0, 1, 2, 3, 4, 5, FRACT will take values 0, 0.2, 0.4, 0.6, 0.8, 1.0. When MOVE has four parameters (M1, M2, M3, M4), the translation in x is calculated using the formula, M1 + (M3-M1)*FRACT and similarly for y using M2, M4. These calculations are done as the tree is created for each frame by subroutine TOTREE. Thus, for example, for DISP TRIANGLE 1 (for which FRACT=0.2) the transformation matrix to be applied to the points of TRIANGLE is

    1.00    0.00    0.00
    0.00    1.00    0.00
    0.00    0.00    1.00
  200.00  200.00    0.00

This interpolation factor can be applied to more than one transformation, for example:

:DISP [NUTR,DNTR,FIG #1,LIN 0 5 #2,ROT 0 -90,MOVE 0 0 1000 1000
  UPTR,EXTR 1]

would interpolate both the rotation and the translation generating the output to the right:

The primitive HARM provides a harmonic rather than linear interpolator. If FRACT1 is the value computed by the linear interpolator, HARM multiplies this by a cosine factor so the new value of FRACT is given by:

FRACT=(1.0-COS(3.14159*FRACT1)/2.0

The effect is shown on the right.

Two additional user-defined primitives have been added to GRAM to enable the system to generate animated SVG output, SG and EG. If we extend the definition of DISP to:

:DISP [SG #2,NUTR,DNTR,FIG #1,LIN 0 5 #2,ROT 0 -90,MOVE 0 0 1000 1000
  UPTR,EXTR 1,EG]

the system generates an HTML file containing the SVG animation. See ccsoc.org/gram2.htm. This uses the approach taken in the reconstruction of Tony Pritchett’s Flexipede animation (described in Resurrection 89). The SVG created by GRAM now surrounds each frame with a g element, for example:

<g id='f1' class='frame0'>
<path d="M 0,4000L 2000,-4000L -2000,-4000L 0,4000"/>
</g>

and JavaScript code is used to set the first frame to visible, and the remaining frames to invisible, then code invoked by a timer sets the current frame to invisible and the next to visible and so on.

Writing GRAM code at this level for other than very simple animations would rapidly become very tedious, so the GRAM system provides a set of macros to enable animations to be written at a higher level and introduces further functionality as described in the GRAM manual (ccsoc.org/gram3.htm). Using these macros, the example could be written:

:TRIANGLE 4!0 4000 2000 -4000 -2000 -4000 0 4000
:TRI [
   FIG TRIANGLE
   ROT(TURN)
   MOVE(PLACE)
   ]
:ATRI [
   PICTURE TRI
   :TURN 0
   :PLACE 0 0
   ANIM LIN 5
   CH TURN -90
   CH PLACE 1000 1000
  ]
VIEW ATRI
0
1

GRAM also supports nested pictures.

Butterflies

The final example was one that Tony used from quite early on in the GRAM development and was found associated with all of the various implementations. It seems as though it was his standard test when moving from one system to another.

The starting point is a single butterfly BODY and a single butterfly WING. Neither are particularly difficult to input but easier with the D-MAC than the storage tube. Tracing the wing for a trained operator probably take less than 30 minutes.

: BODY 33!60   430  170   180    240  -240   240  -770   180 -1220 (
 ) 70 -1480    0 -1520    -70 -1480  -180 -1220  -240  -770 (
 )        -240  -240 -170   180    -60   430  -240   460  -370   570 (
 )        -410   660 -400   760   -360   850  -270   920  -160   970 (
 )        -460  1950 -160   970    -40   990    40   990   160   970 (  
 )460  1950  160   970    270   920   360   850   400   760 (
 )410   660  370   570    240   460

: WING  33!208    32   624   592   800   976  1040  1360 (  
  ) 1216  1568  1488  1792  1568  1184  1504   960 (
  ) 2256  1280  2640  1344  2896  1296  2608   464 (
  ) 1952  -206  2256  -480  2352  -704  2320 -1024 (
  ) 2256 -1456  1600 -1568  1248 -1408   896  -928 (
  ) 1168 -1616  1216 -1968  1136 -2112   944 -2048 (
  )  640 -1760   720 -2448   688 -2704   624 -2816 (
  )  512 -2448   416 -2064   304 -1424   256  -768 (
  )  256  -352 

Brackets in GRAM input were implicit where possible, but in some cases, for example a macro call with too many arguments to fit on one line (there was a 71 character limit), implicit brackets could be cancelled by typing the opposite bracket: ) at the beginning of a line or ( at the end of a line, as seen above.

The figure below shows a selection of frames from the animation.

For reasons of space, the animation script is displayed in several columns.

:FLY[PICTURE BFLIES       ANIM LIN 5        :BFLIES[PIC BFLY 0
  : A2 0,: A3 0,: A4 0    CH AWAY 0 4000       PIC BFLY A2
  : FLAP 0,: AWAY 0 0     ANIM LIN 5  PIC BFLY A2
  AFTER 2        CH FLAP 0   PIC BFLY A3
  ANIM LIN 5     THEN        PIC BFLY A4
  CH A2 -90      ANIM LIN 5 ]
  ANIM LIN 5     CH FLAP 90       :BFLY[FIG BODY 0
  CH A3 -180     THEN        PIC LWING
  ANIM LIN 5     ANIM LIN 5  PIC RWING
  CH A4 -270     CH FLAP 0   MOVE(AWAY)
  HOLD 1THEN        ROT(#1)
  ANIM LIN 5     HOLD 1      ]
  CH FLAP 90     ]       :LWING[PIC RWING
  THEN     SCALE -100 100
       ]
   :RWING[FIG WING
       ROTY(FLAP)
       ]
    VIEW FLY

The first two columns define the animation, the third defines the graphics. Applying a rotation about the Y-axis using ROTY gives an ability to define a right wing, RWING, that flaps. Using SCALE to the RWING achieves another wing that also flaps; the left wing LWING. A complete butterfly is defined as BFLY consisting of the BODY, LWING and RWING. Four butterflies are defined sitting on top of each other but with the ability to rotate and move away. ANIM defines the number of frames and CH the value to be changed. Applying a rotation (ROT) about the Z-axis and a movement AWAY animates the butterflies (ccsoc.org/gram4.htm).

Applications

The OU/BBC often presented scientific graphical information as graphs in TV programmes and GRAM was used to produce animations for a variety of programmes. Tony also worked on animations for other TV Channels including Thames TV and Channel 4.

Ridley Scott’s Film: Alien was produced by 20^th Century Fox at Shepperton Studios in the UK and first released in 1979. Relevant information was to be displayed on the 40 monitors of Nostromo’s control deck including computer readouts, maps, space vistas etc. Tony used GRAM in several animations that ended up on the cutting room floor but a few seconds of footage during the separation of the spacecraft module was used and appeared again, later, in Ridley Scott’s motion picture Blade Runner (1982). After looking through a great deal of GRAM code, we found scripts that generated the relevant display.

Conclusions

The GRAM system was in development/use from 1972 to 1978. Tony wanted the system to be flexible, able to meet and execute new requirements quickly. The decision to base it on a macroprocessor and write it in Fortran was novel. There was knowledge of and involvement with the developments and use of Strachey’s GPM at the University of London and its original use in the development of a compiler for the CPL language. This gave some confidence in the approach. Having X,Y coordinates and character pairs as the basic items that the macroprocessor manipulated was novel and less demanding on space than GPM. Allowing Fortran code to be used as primitive macros did allow flexibility in the way the system’s usage could evolve. Providing standard sets of macros for graphical input/output and animation definition was quite novel. Early usage was simple drawings and animations while later it was possible to define and animate quite complex 3-D graphics.

There does not appear to be much use of GRAM after 1978. One reason might be the closure of the ICL 1906A in 1978 after the merger of ACL and the Rutherford Laboratory. This removed Tony’s main route to the Laboratory’s FR80. Also, film was no longer the only way of generating graphics at both the BBC and the Open University. Another reason was the emergence of more powerful packages for computer animation, initially tied to specific companies and only used internally, but later becoming widely available.

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

CERN orders Satellite One terminals: A significant export order has been won by Computer Technology, which will supply five Satellite One terminals, Model 10, to CERN, the centre for nuclear research at Geneva. CERN will use the five identical systems as remote input/output stations to its Control Data 7600 computer system, due to be installed in the spring. Total value of the order is in the region of £100,000 and was won by Computer Technology’s Paris sales office. Each of the terminals will have 600 lpm line printers, and will be linked to the 7600 by 4,800 baud lines, forming part of a communications network which CERN is building round the 7600. (CW 2/12/71 p1)

IBM-based TOPS for BR freight: Plans to install a computer-based freight information and control system at a cost of £10 million have been announced by British Rail. The announcement confirms a report published exclusively in Computer Weekly earlier this year that British Rail intended to purchase a US freight management system, known as TOPS, which would be run on a dual IBM 370/165 configuration. TOPS — Total Operations Processing System — has been developed over a period of at least eight years by a US railway, the Southern Pacific Transportation Co. Marketing of TOPS and installation support is provided by an associate company, TOPS On-line Systems Inc, which will assist British Rail in modifying the system to cope with conditions in the UK. Heart of the system will be a computer installation comprising two 370/165 machines rented from IBM. One will support the system on a 24 hours a day, seven days a week basis, with the other stand-by machine being used for offline processing unless, of course, it is required to assume the real time role. (CW 2/12/71 p1)

Enhancements to boost System 4: Fulfilling its promise that System 4 would be kept up to date, ICL has announced a large number of hardware and software enhancements that will, in particular, improve the real time and communications performance of the range. A network of System 4 computers can now be constructed using a new Remote Processor Controller. It provides communication from one processor to one or more remote processors at speeds up to 1.5 Mbps or at speeds from 1,200 bps to 48 Kbps on the standard Post Office Datel services. The controller will handle ISO, ASCII and EBCDIC codes and may be used where the J Operating System is used. It is modular and consists of an interface control and scan module and from one to eight channel control modules. It provides for half-duplex working in synchronous mode and its maximum throughput is 200K bytes a second. (CW 2/12/71 p1)

UK to get network nodal centre: The UK intends to install one of the nodal centres of the computer-to-computer communications network which is to be set up to link European research centres, but the projected European software information centre is likely to be at the Euratom laboratory at Ispra, near Milan, and not at the National Computing Centre’s Manchester base. The network project was agreed and the software information centre project was approved in principle at a two-day meeting of 19 European ministers of technology in Brussels at the beginning of last week. The meeting’s swift and cordial despatch of business concerning 10 projects augured well for these new attempts at European co-operation. The groundwork for the two computing projects, details of which were given last week, was largely done by the National Physical Laboratory in the case of the network, and by the NCC in the case of the information centre. And both these organisations will play a large part in the realisation of the projects. (CW 2/12/71 p)

Ferranti equipment for Brazilian Navy: Under a £5 million contract the digital system division of Ferranti is to supply tactical action information and weapon control systems based on its FM 1600B computers to the Brazilian Navy. The Ferranti systems will be fitted to frigates now being built for Brazil by shipbuilders, Vosper Thorneycroft. Three systems will be fitted to each ship. In the design of the ships, as with the Royal Navy’s Type 21 class, Ferranti is acting as weapon system designer and engineer in association with the shipbuilder. In this role they will assist in co-ordinating and integrating weapon system equipment from a number of suppliers, in addition to providing the main control systems themselves. (CW 9/12/71 p7)

1904A to handle Concorde flight test processing: All Concorde’s flight test processing is to be taken over by an ICL 1904A system, due to be delivered in a few weeks to Concorde’s home airfield at Fairford, Glos, which is the British Aircraft Corporation’s flight test centre. The 1904A will take over processing previously carried out at Fairford by a GEC 9030 system and at Filton by an IBM 360/65. The 1904A will be large enough to process several test flights simultaneously, though ideally each flight will be processed before the next takes place, so that the maximum information can be made available for the next flight. The system will be used for testing Concorde prototype and production models. Test data will be recorded in flight on king-size magnetic tape — 33 track tapes each 72,000 feet long which contain about 150 million characters or 2½ hours of test data. The tape reader of the Tolana tape system used will have a special interface with two nine-spindle EDS 30 disc units. (CW 9/12/71 p16)

£3m dockyard system installed for Navy: The four Royal Naval dockyards have taken delivery of their ICL computers which will be used to process the distribution and supply of stores and the operation of motor transport. At Chatham, Rosyth and Devonport, 1904A systems have been installed and an ICL 1902S was delivered to Portsmouth last week. The last remaining system of the £3 million order announced earlier in 1971 is an ICL 1906A, which will be delivered to Ensleigh, near Bath, as soon as a new building being prepared to house it is ready, probably about the middle of 1972. This will be the new inventory control centre for the Royal Naval Supply and Transport Service. The new machines replace ICL punched card equipment and IBM 1401 computers and ancillary equipment at the dockyards. One of the most important advantages to be gained from the new installations will be the degree of centralisation that will be possible. Each dockyard computer will process distribution and supply for that dockyard, but they will all be linked online to the Ensleigh system through VDU and teletypewriter inquiry terminals and also offline via magnetic tape encoders. The Ensleigh 1906A will hold a complete inventory of all naval stores and their location, and will among other things be able to process a request for an item from one dockyard by instructing another dockyard to supply it. (CW 30/12/71 p1)

Banks set up Access to win credit market: The other big banks’ answer to Barclaycard credit is to be called Access, and will become operational at the end of 1972 or early 1973 based on two IBM 370/145 computer systems. Joint Credit Card Co Ltd was set up earlier this year by Lloyds, National Westminster and Midland Banks, and the consortium expects to have an initial three million customers. An important difference between Access and Barclaycard is that Access will be run with immediate credit control. Shops where a customer presents his card will be able to ring the Access centre, where the customer’s particulars will be taken over the telephone and keyed in on one of 70 visual display units. Knowledge of how the customer’s credit stands will thus be available to the shop. (CW 30/12/71 p1) )

Texas introduce giant to Europe: A super computer said to be faster and considerably more powerful than an IBM 360/195 is to be installed in Amsterdam this year. The machine which is known as the ASC, Advanced Scientific Computer, has been developed by Texas Instruments for geophysical work, but if applied to a wider range of applications it could well have a substantial impact on the business of some of the larger European service bureaux. The existence of the ASC has been known about for more than 18 months, but it now appears that this powerful machine is soon to make its public debut. At least two ASCs are understood to have been manufactured and to be operating at TI’s headquarters in Dallas, Texas. A third is earmarked for installation in Amsterdam. The fact that TI has developed such a machine should not be interpreted as a move into the computer mainframe business. It is most unlikely that they have any intention of competing with IBM or the other major computer manufacturers as suppliers of computing systems. However, an eventual move into the international computer service business with the new machine cannot be ruled out. (CW 13/1/72 p1)

Honeywell plugs gaps in range: In a bid to maintain and, if possible, increase its share of the market for medium-scale computers, currently estimated to be worth £75 million a year, Honeywell has announced the Series 2000, a range of four central processors, featuring enhanced communications and software facilities, and priced from £120,000 to more than £500,000. Important features of the announcement are the availability of a new communications processor, the Datanet 2000, which can be used in conjunction with the Series 2000 processors to handle up to 120 communication lines; and the OS/2000 operating system which supports the Datanet 2000 and provides facilities for database management. In introducing the Series 2000 Honeywell has done much the same sort of thing that ICL did with the introduction of the 1900S series, Burroughs with the 4700, and Univac with the 9700. It has moved to plug the gaps in its current product line in order to protect its customer base against competitive offerings, particularly those such as the 370/135 and 370/145 from IBM. In Honeywell’s case the four processors of the Series 2000 are compatible with and, in terms of performance slot into, the existing Series 200 product line. However, it is claimed that the new models give up to 75% more power for the same purchase price than comparable Series 200 configurations. The current Series 200 product line includes the 115/2, 1200, 1250, 1015, 2015, 3200 and 4200 computers. Now, with the introduction of the Series 2000 some important gaps in this range are closed. (CW 20/1/72 p1)

CAP file store in operation at NPL: Independent access to a free standing file store from a network of computers is now a reality at the National Physical Laboratory, where Computer Analysts and Programmers have completed a £30,000 contract for initial development of the file store. At present there are nine computers and about 20 terminals in the network, ranging from one of the laboratory’s KDF9s and an ICL 4120 down through a Computer Technology Modular One three-processor installation to Digital PDP-8s and a Digico Micro-16, the network itself and the filestore are each controlled by Honeywell 516s. The filestore is at present in rather a primitive state, and one of its most pressing limitations is that it can only be accessed by one computer at a time. This can be rectified by the provision of a software packet switching interface on the network itself, matched by an interface on the filestore. (CW 20/1/72 p1)

Grid 77 plan to aid Defence operations: Four major computer centres as the focal points of a massive bureau grid are the main feature of a plan being developed for the Ministry of Defence. A ministry team is at present carrying out a feasibility study of the grid which, if implemented, would take over all MoD data processing activities at present handled by about 60 separate computers. The report on the feasibility of Grid 77, as the scheme is known, will be produced in July, and if current plans are followed, hardware orders will be placed in the first half of next year and the first grid centre will become operational by the end of 1974 or early 1975. The full network with all four centres, a packet switching communications subsystem with maybe eight switching nodes and many hundreds of terminals, intelligent and otherwise, would come into existence probably in 1977. (CW 10/2/72 p1)

Pattern recognition system aids medical research: Automatic detection of the critically sized asbestos particles that cause asbestosis and examination of cervical smears for malignancy are among the important applications of the new 720R pattern recognition system from Image Analysing Computers (Imanco) of Royston, Herts. The 720R is the latest addition to the Quantimet 720 range of image analysing computers. It consists essentially of a set of hard-wired digital processor modules that can be combined in many ways to recognise and classify distinct objects in an image regardless of their orientation. There is a wide choice of source image input devices including optical scanning electron microscopes, cine and slide projectors, X-ray systems and electron probes, and photographs and objects can be scanned directly. The image or object is scanned electronically at the rate of 10.6 720-line frames a second and is converted into 650,000 picture points in a single scan. The digital equivalent of the grey value of the point is processed by the 720R to determine shapes, sizes and optical densities and to classify the objects in the image. This data can be further processed by an online desktop or other computer, or it can be output onto paper tape. (CW 10/2/72 p15)

Desktop Model 20 launched: A desktop calculator introduced by Hewlett-Packard Ltd. can, in its expanded version, solve 36 simultaneous equations with 36 unknowns with its 429-register memory. Known as the Model 20, the calculator has 173 registers in its basic form and a new algebraic program language, ALCAL, has been developed for use with it. Input to the Model 20, which has algebraic notation, complete alphanumeric capability and plug-in read-only memory function blocks, is through a keyboard or by way of magnetic cards. It is also fitted with a 16-character digital display and a thermal printer for the production of output. Peripherals including a plotter, marked card reader, typewriter, digitiser paper tape reader and magnetic tape cassette unit can be attached to the new machine, which, say Hewlett-Packard, is suited for both mathematical and statistical applications and computations where the full potential of a digital computer would not be realised. The high-level algebraic calculator language, ALCAL, has been designed to be a natural man/machine interface which allows the writing of compact statements with minimum characters. The common mathematical symbols are used as well as branching, Boolean capability, and implied multiply. Operations are keyed as written and in the case of keyboard calculations results are displayed as numerical answers. A series of statements separated by semicolons, in lines of from 35 to 68 keystrokes, make up the program. (CW 17/2/72 p20)

Forthcoming Events

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

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

Seminar Programme

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

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

For queries about meetings please contact Roger Johnson at .

Details are subject to change. Members wishing to attend any meeting are advised to check the events page on the Society website.

Museums

SIM : Demonstrations of the replica Small-Scale Experimental Machine at the Science and Industry Museum in Manchester are run every Wednesday, Thursday and Friday between 10:30 and 13:30. Admission is free. See www.scienceandindustrymuseum.org.uk for more details.

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

The National Museum of Computing Normally open Tue-Sun 10:30-17.00 but at present opening days are somewhat irregular so see www.tnmoc.org/days-open for current position Situated on the Bletchley Park campus, TNMoC covers the development of computing from the “rebuilt” Turing Bombe and Colossus codebreaking machines via the Harwell Decatron (the world’s oldest working computer) to the present day. From ICL mainframes to hand-held computers.

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

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

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

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

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

North West Group contact details

Computer Conservation Society

Aims and Objectives

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

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

The objects of the Computer Conservation Society (“Society”) are:

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

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

The CCS is funded and supported by a grant from BCS and donations. Some charges may be made for publications and attendance at seminars and conferences.

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

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