Resurrection Subscriptions

Readers who pay for printed copies of Resurrection should note that this edition is the last in the current subscription period. To subscribe for the next four editions go to www.computerconservationsociety.org/resurrection.htm .

EDSAC Replica — Andrew Herbert

At the February EDSAC integration meeting the main discussion was around the interface between Main Control and the Store, known as the Main Output Bus (MOB). Despite its name, the MOB is essentially a two stage star network – the first stage being local concentration in each store access rack, the second stage being concentration from all stores (and arithmetic unit and tape reader) in main control. The interface is further complicated by the imposition of the transfer unit delay line in the path when fetching short numbers with odd addresses. Problems have been reported with both the timing and magnitude of incoming signals to main control and understanding the precise operation of the transfer unit. The decision was taken to first make the MOB work for long numbers only and then to investigate the transfer unit at a later stage.

From a reading of the original EDSAC logs it appears there may have been two delay lines in the transfer unit, whereas we have only made provision for just one. Subsequent experiments with ELSIE (our logic simulator) have shown that a two delay line transfer unit may be necessary to relieve some of the tight timing constraints in the current design.

A further discussion dealt with a missing circuit relating to the inhibition of adding one to the Sequence Control Tank (program counter) during jump and input/output instructions – a signal known as “SCTOne”. This function takes inputs from the arithmetic unit and input/output units, feeding back to main control. Although defined in our logical model for EDSAC, we had omitted to assign this function to a specific chassis. It turns out the circuit is necessarily split across main control, arithmetic unit and input/output units and space is available on the appropriate chassis in each subsystem to implement it.

In subsequent testing we have demonstrated orders being retrieved from the main store into the order tank, and from there setting up the order flashing units in turn detecting and executing a Z order (stop and ring bell). Ongoing work is to make this behaviour robust and then have main control execute successive order fetch, decode and execute cycles.

Our Computer Heritage — Simon Lavington

In the Minicomputer section of OCH, there has been some progress on discovering the deliveries of CTL Modular One computers. There are obviously still many omissions and, no doubt, some errors in our list.

SSEM — Chris Burton

The machine continues to attract many visitors on demonstration days, and is generally robust. However, for the last several weeks an intermittent fault shows up shortly after switch-on and then disappears within 15 minutes. A video recording watching the indicator lights on the power supply stack has shown a transient extinction of one light, coinciding with the moment that the machine crashes, so there is now a definite lead to follow-up in fault finding.

Arrangements were made for the celebration of the 70^th anniversary of running the first program on 21^st June 2018, and the 20^th anniversary of the replica operating in MSI. A prestigious Manchester Lecture on the subject of Early Computing was presented by the Manchester Literary and Philosophical Society at MSI in the evening of the 21^st.

The Baby replica was staffed by the volunteers and demonstrated all day, with the ceremonial re-running the first program at 11.00.

The SSEM Volunteers Archive which aims to keep all the relevant information to do with maintaining the SSEM has been copied to the CCS server and semi-integrated into the CCS website structure. It is accessible via the CCS Projects item in the main menu. The existing presence on the Manchester University School of Computer Science server will remain for the time being for continuity for old incoming links, but may not be updated regularly. We are extremely grateful for the service they have provided for so many years at no cost to us.

Analytical Engine — Doron Swade

Our original intention in supporting the wider release by the Science Museum of the Babbage technical archive was to enlist, in due course, the support of a wider community of interested volunteers. Until recently we have not taken up generous offers of help largely because it was not evident how our limited resources could stretch to manage an extended programme of work and to give the new input appropriate attention. A new development has been to make images taken of the Scribbling Book held in the Cambridge Library available for transcription by an enthusiastic volunteer. This trial programme has prompted us to address a number of issues: access to material that is on conditional release to the project by institutional archives; usage rights and access to the database; rights to edit, amend or add material; issues of attribution and checking to maintain the integrity of the content; and the formalisation of editorial conventions for database entries. The experiment has provided a valuable opportunity to address these and related issues in preparation for enlisting wider participation when we return to the task of interpreting the new indexed material to make a final assessment of the designs and the extent to which the material supports a consistent description of a complete machine.

The Cambridge manuscript belongs to Babbage’s later period (1850s and early 1860s) when he returned to refine and develop his earlier work. The most substantial single section consists of some 65 manuscript pages the transcription of which is now complete. Tim Robinson has vetted the transcriptions and incorporated them into the database. Preliminary review of this new material suggests that while cryptic in parts it is more coherent than previously thought and contains some potentially dramatic simplifications of implementation. This material will be the focus of close study in due course.

The database marathon has been undertaken by Tim Robinson in the US and the most recent work takes us to the mid 1860s (Babbage died in 1871). Tim reports that this later content is fragmented and not as systematically referenced by Babbage to the mechanical drawings as is his earlier work. This kicks the interpretative can down the road somewhat as once the transcriptions are complete this content will need to be revisited to integrate it into the larger picture. Page-by-page inspection, while exacting, has the rewards of close reading one of which is revealing new content in the cracks. Here is one such: in the context of manufacturing methods Babbage calculates that the total number of teeth to be formed for a store with 1,000 registers would be 1,800,000.

The Science Museum’s small store at Blythe House has been cleared and a missing Scribbling Book has come to light. A microfiche from the 1970s, illegible in places, was all that was thought to have survived. The Museum generously made the re-found volume available at its viewing facilities in the Dana Centre, South Kensington, and we have photographed the volume using a copying rostrum as an interim measure to resolve by comparison unclear material in the microfiche. The Museum intends to digitise the volume in due course and add it to the online digital archive.

A new development comes in the form of Pip Meadway, a volunteer who has generously been transcribing manuscripts. Using captured digital images of the sources he has transcribed material from the Cambridge Scribbling Book. He is currently working on images of the essays on the Analytical Engine Babbage wrote while travelling in Italy after his memorable visit to a convention in Turin in 1841 where he gave his one and only lecture on the AE designs. The manuscripts are in the Buxton archive in Oxford and the archivists kindly allowed image capture for the transcription work.

Harwell Dekatron/WITCH — Delwyn Holroyd

The Creed 7 teleprinter, recently serviced by John Pether and John Watson from the Tunny team, has now been re-attached to the machine and is working reliably again.

The machine has generally been behaving itself with the occasional reported hiccup. Of course these never occur when an engineer is present and watching it!

We recently received a donation of some GTE175M trigger tubes and GC10B Dekatrons, which are always welcome.

Elliott 903 — Terry Froggatt

A small plaque has been made to be attached to the 903, naming it “O11y” in memory of Oliver Harlow who donated it to TNMoC. An unveiling ceremony was be held in May after the 903 had a morning to warm up and I’m pleased to report that the TNMoC 903 behaved perfectly at the ceremony.

Reportedly the 903 has been less reliable than it was last year (when it was using some of my cards). So I visited TNMoC in February to investigate. Somewhat frustratingly, the 903 ran without fault all day.

Possibly the TNMoC 903 takes time to warm up, and both of the Cambridge 903s have similar problems during winter, whereas neither of my 903s do, possibly because I keep my computer room warm overnight. Damp in the store’s D-connectors could be the cause, but the TNMoC 903 still has the locking clips on its D-connectors which make it almost impossible to undo, and more importantly, to do up, the connectors, without removing the whole rack from the chassis.

Next time I’m there I’ll see what happens if I reconnect the extra 8K store.

I understand that Peter Onion has been running 803 Algol courses, including demonstrations on the TNMoC 803.

IBM Museum — Peter Short

The remaining artefacts from Oslo have now arrived. They include some interesting pieces of equipment, including an electro-mechanical time synchronisation unit from around 1938, a differential pressure gauge and an environmental monitoring unit, which was used as part of the installation planning process to ensure a suitable environment for hardware. We now also have the typewriter and keypad for the 632 tabulator which came with the first shipment.

The System/370 console is now on display in the Hursley room. Although this is from a Model 155, it is our only artefact that remembers the Model 135 which was developed in Hursley.

Hursley celebrates 60 years of IBM presence on the site during 2018. Celebrations will take place in September, and the museum has been asked to provide some additional displays on the ground floor of the House. A week before this, Hursley opens its doors for the Heritage open weekend, so the museum will be preparing exhibits for both occasions.

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

ICL 1901A

The 1901A sub-project has reached a natural break-point; the 1901A emulator is now running both E1HS and the fixed part of E1DS successfully. With our recreated overlays, we can now use magnetic tape in addition to basic peripherals (cards, p/tape and printer), but UDAS (disc access) is currently beyond us without further information. We are still looking (hoping) for the missing the 2^nd paper tape for E1DS (the overlays).

Yet again – if anybody has any information, listings etc. of Stevenage Executives – we would welcome it.

ICL 1904S

Our current focus is on final testing and polishing of the 1904S emulator, ready for full release, albeit not with all peripheral types initially supported. Beta versions have been out there for some time, running successfully, but final testing has thrown up a few minor snags.

This has led to a large-scale peer review of the code. Part of this review has been to consider how much of the code should be common (as much as possible) between the 1904S and 1905 emulators (as well as a base for any further emulators). Although causing much disruption to the release schedule (and many dark mutterings) it is leading to a much slimmer and cleaner codebase, placing initial emphasis on the 1905 rather than the 1904S due to fewer peripheral types required and, as a result, less code to initially be made common.

The aim is for release is the next couple of months, after which missing peripherals will be addressed.

Application Software

Now that we have an emulator, work is underway on demonstration software to run on it. It is all very well being able to compile etc., but it would be nice if the machine could actually do something. Accordingly, a mail order type system for a fictitious company is being written, a sort of Amazon of the 1960s/1970s with orders via post or telephone.

There are three phases planned, as a sort of natural progression that a growing company would go through:–

• 1) Batch Magnetic Tape based (currently being designed/written)
• 2) Batch Disc/Tape based
• 2a) Online data entry added to phase 2

FP6000

Some documents have been made available as a result of establishing contact with some members of the design team for the Ferranti-Packard 6000. This has resulted in some considerable clarification of the original machines 1904/5/9 which directly inherited from the FP6000 as well as setting a standard for all later 1900 machines. This documentation covers both the FP6000 hardware, peripherals and the original software, with some excellent insights into the consolidation system, GPL etc. Many thanks to everyone who has contributed to this.

BCPL

While we have been working on the emulators, John Hughes has been looking a the recently recovered 1900 BCPL implementation and restoring some vital missing code, so that it is once again fully working.

Maximop One of the tapes collected from the Fujitsu Bracknell Archive earlier in the year was labelled Maximop 6A-0. We didn’t want to get our hopes up until it was read, but I am happy to report that it was indeed a Maximop release tape – complete and error free. Previously we only had a binary copy of the overlay file (from Manchester Grammar School) and an incomplete set of utilities. We now have the ability to generate a system with different options and of course a complete copy of the source code.

ICL 2966 — Delwyn Holroyd

I’m pleased to say the fault on the OCP -5.2V power supply has not re-occurred on the machine since the spare supply was fitted, and the spike seen apparently coming from the over-voltage output of the suspect supply has now been observed on the bench with the supply running into a dummy load, thus proving that the fault is indeed somewhere within this supply. Unfortunately the observation was made after replacement of the driving transistor, which seemed to be the only component that could reasonably be responsible for the fault! I then attached some wires to the control board to allow monitoring of a few other points in the circuit around the transistor. After another multiple hour test run another spike appeared on the output, but not at any of the other monitor points. So we are now thoroughly mystified, and a close examination of the board will be required to see if there is the possibility of a short. A resistor in the output circuit is part of a DIP resistor pack and this is now also under suspicion.

Meanwhile the comms link between the 7501 terminal and the 2966 DCU has developed a fault, with about half the output characters coming out garbled. This has not been investigated yet, but the terminal works fine when attached to the Raspberry Pi running the George emulator, so the issue is either in the SMLCC or the cable. The two 7181 terminals on the same SMLCC (Synchronous Multiple Line Comms Coupler) are working fine.

An intermittent fault has also appeared in the right hand SCP monitor, with the scan collapsing from time to time. A light tap brings it back so this is probably a dry joint somewhere. Meanwhile the monitor from the left hand SCP has been pressed into service.

The 2966 tape decks have recently been used to recover a copy of the source code for MUSS, the operating system of the Manchester University MU5 machine. This machine was of course one of the inspirations behind the 2900 architecture.

I met Bob Whittaker at the CCS North West Group meeting in March. Bob, it turns out, was instrumental in saving the 2966 from the scrap heap when it was retired from Tarmac. He arranged for the system to be transported from Tarmac to Bletchley Park and even persuaded ICL to pay! He has shared with us a number of photos of the system in situ at Tarmac and is currently digitising a video taken on the last day of running.

Bob is still at Fujitsu and is very kindly providing valuable help with the museum’s Trimetra DY system. We have discovered that it was the very first production machine!

CCS Visit to Pisa — Dik Leatherdale

To Pisa in Italy for a CCS visit to the Museum of Computing Machinery (www.fondazionegalileogalilei.it/index_en.html) there. It’s quite a small, but very interesting collection run largely by volunteers from the computer science department of Pisa University. We were made most welcome by our hosts Fabio Gadducci and Giuseppe Lettieri with whom we dined (rather well) on the previous evening. CCS regular Elisabetta Mori – currently undertaking research into the history of LEO at Middlesex University, London – had set up the details of the visit for us and gave us a wonderful presentation at the start of our visit. We are immensely grateful to all three of them. Some 11 CCS members were in attendance, some apparently disguised as Mafiosi.

Two particular exhibits caught my eye. The first was a working replica of the adder of a prototype computer built by Olivetti and Pisa University in the late 1950s – the Macchina Ridotta itself inspired by the adder of the IBM 701.

The other item was the reconfigurable read-only microcode store from the Pisa University/Olivetti Calcolatrice Elettronica Pisana (CEP). A wire mesh into which tiny ferrite cylinders could be inserted. Ex-Ferranti hands will immediately recognise the principle of the Atlas fixed store in which a pulse in the horizontal wire will momentarily magnetise the ferrite cylinder and this, in turn will generate a pulse in the vertical wire (or not, if the ferrite is absent). I was once given to understand that the Atlas wire mesh was woven by a Manchester carpet manufacturer. The Italian version was woven by local nuns!

CCS North West Group — Bob Geatrell

Alan Pickwick, Gordon Adshead, Tom Hinchliffe and Bob Geatrell on the occasion of the presentation to Gordon and Tom of the Ladybird book: How it works: The Computer which gives an interesting overview of computers from the 1970s, should they ever wish to take an interest in such new-fangled things.

KDF9 Software Preservation — David Holdsworth

David Huxtable and I continue to make incremental improvements, many of which emerge as a consequence of Brian Wichmann’s test programme.

We are totally convinced that we do not have the final definitive version of the Kidsgrove Algol compiler, and have had much debate about how best to deal with this. We have decided to aim for a mid-point between authenticity and functionality.

Where we identify a bug that we can clearly fix we shall do so (and already have done so in several cases), but with source text annotation.

Much to our dismay the optimiser brick (KAB41) is clearly pre-release and so far refuses to optimise correctly the access to subscripted variables, a particular disappointment, given that the KDF9 architecture is particularly suited to such access.

A race of computers spanning eight decades was won by a BBC micro:bit operated and programmed by a nine-year old student.

The Grand Digital Computer Race was held to celebrate the 10^th anniversary of The National Museum of Computing. Seven computers and one calculator, spanning a period of eight decades, were each given 15 seconds to find numbers in the Fibonacci sequence.

Nine-year-old Connie, of Milton Keynes, wrote a program for the BBC micro:bit, a bare bones computer, which found 6843 numbers in the sequence in the allotted 15 seconds.

An iPhone 6s found only four numbers in that time – but it used Siri voice command and response to demonstrate just how far computers have come since the 1940s.

The slowest was the 1951 WITCH. It found only three numbers.

Kevin Murrell, the race starter, said: “This is the first time that machines from so many decades of computing have raced together. We don’t think such an event could happen anywhere else in the world! The spectators loved it especially as our youngest operator won the race with a BBC micro:bit. Nine-year old Connie wrote the Fibonacci program herself – a fantastic achievement for someone so young and an inspiration for young computer scientists everywhere.

“I suspect this was the first of many Grand Digitals as we have many other original working computers, skilfully restored by our Museum volunteers, that could enter the race to demonstrate the advance of computing.” Other machines in the race were a 1940s Facit calculator (7 numbers), a 1965 PDP-8 (16), a 1977 Apple II (38), a 1981 BBC Micro (70), and a 1998 Windows 98 PC (1477). Not all computers were able to stay the full 15-second course because although their processors might be speedy and willing, their memory could not cope with the number of bits to store large numbers.

101010101

All the way from Australia, Brian Conlon contacts us to let us know that a new book A Vision Splendid – a History of Australian Computing by Graeme Phillipson has been published. Available on paper or on the Web.

101010101

Ferranti/ICT/ICL/Fujitsu people may be saddened to learn of the demise of the tower block at West Gorton in the early summer.

Last year it was the turn of the office in Carlton Drive, Putney in which your editor once toiled.

West Gorton (left), Carlton Drive (above)

101010101

Our friend Herbert Bruderer writes from Switzerland to tell us that a new edition of his two-volume, 1600 page opus, Milestones in Analog and Digital Computing , has been published.

101010101

The Bombe is Moved!

CCS members will know that the Turing-Welchman Bombe trustees decided some time ago that the best future for the Bombe was to relocate it to The National Museum of Computing on the Bletchley Park campus.

A highly successful TNMoC crowdfunding appeal raised over £50,000 in just four weeks to pay for the cost of the relocation, of the building and of other works needed to create the new Bombe gallery.

Planning for the move occupied John Harper and the team of Bombe volunteers intensively for weeks. Everyone at TNMoC had also been very busy, contacting planners, organising builders and painters as well as managing the practical aspects of creating the new gallery.

Not only is the Bombe a delicate electro-mechanical device but it weighs in at a modest one ton. What’s more it had to be got out of a narrow sub-basement entrance, be craned on to the back of a lorry at road level, conveyed about 400 yards, unloaded into the car park of TNMoC and finally hauled through the narrow corridors of the museum to its new home.

Moving day was Monday April 30^th. The weather forecast could hardly have been worse with torrential rain and high winds. Fortunately, the weather gods took pity and while East Anglia and much of the south-east got the forecast storm, Bletchley remained dry if overcast. The morning was spent on two tasks – hauling a reluctant Bombe out into the open air ready for lifting by the crane and secondly final preparations at TNMoC to receive it. The cost of the lorry and of the removal was generously provided by Bletchley Park Trust.

The Mighty Crane By lunchtime the Bombe, covered in a large tarpaulin complete with banners proclaiming what lay within and its destination, had emerged into daylight. At 15:00 the mighty crane arrived to transport the Bombe to its new home.

By 16:30 it had been safely delivered to the TNMoC car park to be pulled and pushed up the slope by perspiring volunteers into the building which was the original objective for the first day.

At this point, the day was transformed when the three members of the Flegg Transport removal team, possibly taking pity on the elderly gents struggling to move the Bombe, offered to move the Bombe the rest of the way on their skates – two sets of low rollers on which heavy items can be transported. Even for these skilled operatives it was still a tricky job. Large boards had to be laid down under the Bombe throughout the museum to prevent it sinking into the soft floor surface which was never designed for such loadings.

“Right,” said Fred, “Have to take the door off....”

So, yard by yard the Bombe was moved towards its new home. While straight line movement required only strength, any deviation needed cunning! In particular, the final entry into its new home necessitated rotating the Bombe through a right angle effectively on the spot and then to draw it through a doorway with under a centimetre clearance either side even after the doorframe had been removed. However, with a few further “adjustments” to the surround, through the Bombe rolled! By around 20:30 the Bombe was safely delivered surrounded by aching muscles and a great sense of sharing in a job well done.

Only Just!!

As a result of completing the move on day one, the Bombe volunteers returned on Tuesday after a good night’s sleep to ceremonially remove the tarpaulin and, fortified by coffee and doughnuts, completed the setting up of the Bombe even as its first visitors peered in to see it in its new home. For the record the Bombe was running successfully by about 14:15 on Tuesday less than 24 hours after its departure from its old home. The first official demonstration for visitors took place on Thursday May 3^rd at 13:00. So the Bombe was back on the air less than four days after the final demo in its old home.

The new Bombe Gallery will be officially opened this summer when the gallery refurbishment is fully complete. The Bombe team look forward to welcoming everyone to our new home when you next visit TNMoC.

On behalf of all the Bombe volunteers, we owe a huge thank you firstly to the brilliant Flegg Transport guys without whom we would probably still be trying to get the Bombe in place, secondly Jacqui Garrad and the TNMoC staff members for their warm welcome and help (not least for fortifying us with pizza as Monday evening wore on and tummies rumbled) and finally everyone who supported the fund raising without which the move would not have been possible.

Roger Johnson is a trustee of the Bombe Rebuild Trust.

All photos by John Cape.

Language H: An Informal Overview (Part 2)

Being the second part of an article concerning Language H - a COBOL-like language devised by Elliotts for their 405, 803 and 4100-Series computers

Input Output

Data is fed into and results received from the computer by means of input and output commands. These make use of input-output channels that are referred to by channel numbers. A typical configuration might be:

The principal formats of READ are:

1. READ NUMBER (MAX a) BEING b FROM CHANNEL n
2. READ NUMBER (a DIGITS) BEING b FROM CHANNEL n
3. READ NUMBER (MAX a DIGITS) BEING b FROM CHANNEL n
4. READ STERLING (MAX a) BEING b FROM CHANNEL n
5. READ STERLING (MAX a) BEING b FROM CHANNEL n
6. READ STERLING (a DIGITS) BEING BEING b FROM CHANNEL n
7. READ CHARACTERS BEING b (UP TO m CHARACTERS) FROM CHANNEL n
8. READ a CHARACTERS BEING b (UP TO m CHARACTERS) FROM CHANNEL n
9. READ a CHARACTERS BEING b (UP TO m CHARACTERS) FROM CHANNEL n
10. READ QUANTITY (MAX a) BEING b RADICES (c, d, ...) FROM CHANNEL n

The effect of (1) is to replace the current value of b with a number obtained from the next group of decimal digits on input channel n¹. After the number has been read the modulus of its value is compared to the value of operand a. If the modulus is greater than (a) an error indication is given. Format (2) reads exactly as many digits as are specified. If a non-digit character is encountered an error indication is given. Format (3) will read up to a maximum number of digits but will terminate without an error on reading any non-numeric character. (4-6) provide analogous input of sterling prices in pounds, shillings and pence. (5) assumes (a) pounds digits followed by two shillings digits and two pence digits. (6) permits a more flexible version of (5) in which a space is used to separate pounds shillings and pence (with at most (a) pounds digits). If a minus sign ‘-’ is read in any part of a numeric quantity it is negated. Format (7) reads a sequence of characters terminated by an asterisk ‘*’ ². Format (8) reads exactly (a) characters. Format (9) permits the input of quantities in mixed radix form. The effect is to employ the operation READ NUMBER (MAX a) ... as many times as there are radices involved. The final value is the number of smallest units in the mixed radix quantity. For example, the following statement can be used to assemble successive groups of three numbers as yards, feet and inches with a maximum value of 100 yards:

^{1. If no channel number is given, 1 is assumed}

^{2. The terminating characters for the various formats have defaults but can be changed by program action using so-called “special operands” e.g., “ OPERAND 519” that specifies the terminating character for text input. It is initially set to 3 which is the 803 code for asterisk ‘*’. To change this to ‘?’ the programmer should write the statement LOAD OPERAND 519 WITH 200.}

READ QUANTITY (MAX 3600) BEING LENGTH RADICES (3, 12, 1)

Note that the final radix should always be 1.

Associated with the input commands are a number of special input flags and operands:

DECIMAL POINT and DECIMAL PLACES are set by the READ NUMBER (MAX a) command. DECIMAL POINT is turned ON if a decimal point ‘.’ is encountered and DECIMAL PLACES records the number of decimal digits following the point. The input number is assembled as an integer in b, but may be scaled as required by using one of the CALCULATE functions. If no decimal point is encountered, DECIMAL POINT is turned OFF.

All input flags are OFF at the start of a program and must be reset subsequently if necessary by the program. HOLD will contain the six-bit value of the last character read (or zero is there was no last character).

If there is an input error, the following rules apply:

1. if the INPUT ERROR flag is ON:
   1. the INADMISSIBLE flag is turned ON
   2. the failing statement exits and normal program execution continues
2. If the INPUT ERROR flag is OFF the program waits for operator intervention before continuing; the operator may either attempt to reread the data (perhaps after correction) or cancel the program
3. If the INPUT ERROR CONTROL flag is ON
   1. the INADMISSIBLE flag is turned ON,
   2. the failing statement exits and normal program execution continues.

INPUT, INPUT CONTROL and SEEN-CHARACTER are linked to the SEE command:

SEE CHARACTERS a, b, c, ...

The characters a, b, c will be detected during the operation of certain READ commands. If any one of the characters is detected, the INPUT flag will be turned ON and the value of the last seen character placed in SEEN-CHARACTER. Only one SEE command may be in operation at any one time and it relates to all READ commands which SEE characters and which precede the next SEE command.

The PRINT and PUNCH commands are concerned with output, PRINT referring to a line or character printer channel, PUNCH to a paper tape punch or card punch channel. The permitted forms (using PRINT) are:

For (1) the value of b is output in a format depending upon the value of a. If a is an m digit number then (m+1) characters will be output. The first character will be a leading space for a positive number or ‘-’ for a negative number. Leading zeros are replaced by spaces. If |(b)|>|(a)| m asterisks ‘ *’ will be output. If the DECIMAL POINT flag is ON and the operand DECIMAL PLACES contains the integer r one of the following formats will be used for the digits following the initial space or ‘-’:

1. r = 0: m characters will be output with no decimal point;
2. r < m: (m-r) characters will be output with zero suppression for all leading zeros except the last character. Then a decimal point ‘.’ will be output followed by the remaining r characters, which will be decimal digits without zero suppression.
3. r >= m: a decimal point will be output, then (r-m) zeros ‘0’ followed by m decimal digits without zero suppression.

In all three cases if |(b)|>|( a)| ‘*’ characters will be output in place of all decimal digits and the decimal point will be output.

If both operands a and b have the same name, the value of the operand will be output as a string of m digits with a leading space or ‘ -’.

The rules for sterling quantities are similar. The status of the DECIMAL POINT flag and operand DECIMAL PLACES are ignored. The three output groups for pounds, shillings and pence are output separated by two characters ‘.’ space (this can be changed using special operands). No ‘£’ character is output. The format of the pounds group is derived from (a) as for PRINT NUMBER, with m being the number of whole pounds in the quantity. If |((a))|<240 or if a is a sterling literal with no pounds digits, the pounds digit group and separator is omitted. If |(a)|<12 or if a is a sterling literal with no pounds or shillings digits, the pounds digit group, shillings digit group and their separators are omitted.

(4) is a short form version of (3) that can be used to output fixed text, i.e., where a is an alphanumeric literal.

Forms (5) and (6) control page layout. It is assumed that at the start of a program run all output channels are positioned such that the first character to be output will appear at the left-hand margin of the first line of the page. Character positions within a line are numbered from zero across the page. Likewise, lines are numbered from zero down the page. The current line coordinate is set to zero when the end of a page is reached.

There are no direct facilities to input or output flags and switches.

Filing System

H allows programs to use a backing store, which is assumed to be a sequential tape or film, called a “reel”. A “file” consists of “records” which are, in broad terms, simply lists of operands. A file may spread over several reels.

1. FILE R ON CHANNEL n
2. FILE FROM CHANNEL n TO CHANNEL m
3. GET R FROM CHANNEL n
4. GET AGAIN R FROM CHANNEL n
5. FINISH WITH CHANNEL n

For GET, R should be a list of labelled and unlabelled numeric, sterling or character operands. For FILE, R can additionally include literals. (Flags and switches cannot be filed).

Form (1) writes all the operands appearing in R to the reel on channel n in the order in which they are named. Form (2) copies the last record read from channel m directly on channel n. In either form, if the record fills the output tape, the flag REEL-END is turned ON. Normally a FILE statement turns it OFF. If a GET error occurs the END-OF-FILE and UNOBTAINABLE flags are turned ON, and possibly also the END-OF-REEL flag.

Form (3) copies the operand values in the next record in the reel on channel n to the operands of R. It is not necessary to specify a complete record. Form (4) copies the operand values in the current record in the reel on channel n to the operands of R. In either form, if the record is the last on the input reel, the flag REEL-END is turned ON. Normally a FILE statement turns it OFF.

One use of form (4) is to read files containing dissimilar records. Suppose for example a file consists of five different types of records, all of which possess as their first operand an operand called MARKER, which may have the value 1, 2, ..., 5 according to the record type. Then the method of reading the file could be:

        GET MARKER
        BRANCH TO MK A OR MK B OR ... OR MK E ACCORDING TO MARKER
        ...
MK A:   GET-AGAIN record specification
        ...

Form (5) signals that if writing has been taking place on channel n, the file is now complete and should be finalised. This marking has the effect of turning on the END-OF-FILE flag when the last record is subsequently read by GET.

The programmer can control error handling by turning on the SEQUENTIAL FILING ERROR flag: if an error occurs and the system can continue, the INADMISSIBLE flag will be turned on and execution passed to the next statement in normal order.

Dumps

H provides a means to allow recovery after a system malfunction causes a run to be abandoned and restarted. There are versions of FILE and GET that can be used to salvage essential information from the working store of the computer. FILE DUMP ... will not only write a record in the ordinary way, but also file all the relevant information concerning the status of the filing system at that time. GET DUMP... should be used in the restart sequence to recover the status of all the relevant flags and operands. It is for the programmer to keep track of the order of ordinary and dump records on a reel: it is an error to attempt to GET a dump record or GET DUMP an ordinary record.

Program Layout

H programs are essentially free format – the programmer may use layout as they see fit to improve the readability of their code. Program statements must be indented by at least one space from the left-hand margin. Statements need not start on a new line unless they are labelled for reference by a flow statement. A hyphenated word cannot be split across two lines.

A source program must have a heading consisting of:

DATA PROCESSING PROGRAM (1962) FOR Computer

Title

1962 defines the version of the language being used. Computer (e.g., “803”) defines the object computer (H permits cross-compilation). Title is an optional description of the program.

The source code proper starts with ‘CHAPTER 1’, which must occur in the left-hand margin. After CHAPTER 1, any operand lists may be noted by use of the control word NOTE, which must also occur in the left-hand margin. (NOTE may appear anywhere in the source program but is best used immediately after a chapter heading).

A program can be divided into multiple chapters which act as overlays. The program chapters must be serially numbered. Any chapter can be called in by the statement GO TO a IN CHAPTER n this causes control to be transferred to the label a in the n^th chapter. The new chapter will overlay the object program and literals associated with the old chapter, but all labelled operands and flags will be preserved. At the end of every program one of END or OBEY must appear. END causes the compiling computer to stop the compiling process and output a machine code version of the object program. OBEY likewise completes compilation and immediately transfers control to the object program (and thus can only be used if the compiling computer is of the appropriate type).

Comments may be inserted at the programmer’s convenience in the source program. They must be preceded by and terminated with the character ‘ *’ .

Only CHAPTER, END, NOTE, and OBEY and END statements, statement labels, the terminating, but not the starting, apostrophe of an alphanumeric literal, or a comment including its enclosing ‘ *’ may appear in the left margin. All other words must be indented at least one space.

H is generous with the use of punctuation to improve legibility. Any of =+:%()?/@ terminate operand names and can be used to separate the fields of a sterling literal; a minus sign makes an integer or sterling literal negative, immediately following an alphabetic character it is treated as a hyphen and ignored; commas (,) are ignored in numeric literals and terminate operand names; full stops (.) separate integer groups of a sterling literal, otherwise they terminate an operand name; the positional characters space carriage return and line feed terminate words and numbers. The words AND, ARE, AT, BEING, BY, FROM, IN, IS, THAN, THE, THEN, TO, USING and WITH are all reserved, but treated as ignorable punctuation by the compiler.

Conclusion

This article has given a comprehensive survey of the NCR-Elliott Language H, designed as an autocode for business data processing on medium sized machines such as the Elliott 803. H shares many of the design objectives of the better-known contemporary language COBOL. It has similar arithmetical facilities and control facilities, but a more impoverished input-output capability in terms of data format control. The absence of any sort of subroutine facility is surprising. It has a novel if somewhat confusing means of handling record and array structures and storage allocation for variables.

The author has not been able to find any evidence as to how successful H was in practice with Elliott 803 and NCR 315 users. Perhaps there are CCS members who used H and can tell us?

Andrew Herbert is a leading member of the Society, Chair of The National Museum of Computing and leader of the EDSAC Replica Project. He can be contacted at andrew@herbertfamily.org.uk. Part 2 of this article will appear in the next edition of Resurrection.

North West Group contact details

The issue of New Scientist dated 13^th January 2018 contains a report of the discovery of a prime number larger than any previously known. This is a particularly rare type of prime, being one less than a power of two, and known as a Mersenne prime. There are only 50 known in total.

Back in the mid ’60s I was a physicist using the KDF9 at Oxford University, for solving partial differential equations arising from the hypothesis that quarks might be real dynamical objects. This involved dealing with large (by the standards of the time) matrices, using KDF9 short loops.

I remember being slightly dismayed at the amount of time that the number theorists were using on a machine that I thought should be doing calculations about the real physical world, instead of messing about with “useless” prime numbers.

Guy Haworth was an undergraduate working for Leslie Fox in the Computing Laboratory during his final long vacation, and was investigating Mersenne numbers, perhaps as light relief from his other work on numerical integration. It seems that I had some reputation as a user of KDF9 short loops, and Guy was advised to seek my advice to see if his loop could be shortened so as to exploit this feature. In order to reduce the amount of time “wasted” on prime numbers, I wrote a routine for him that used the KDF9 short loop to calculate the remainder on dividing a Mersenne number by a single-length integer, i.e. less than 2⁴⁷. The loop in this routine ran as a short loop, i.e. a sequence of 8 to 12 instructions locked in the CPU. All the operands lived in the nesting store, so the algorithm needed no access to main store, whose 6µS cycle time was widely regarded as the limiting factor on the KDF9’s speed. It ran faster than an Atlas and helped Guy to confirm the results of other researchers.

The machine had two words (12 bytes) of buffer storage in the CPU into which program instructions were fetched. The variable length order code had 1-, 2- and 3-byte instructions, and this buffer made it possible for 2- or 3-byte instructions to cross a word boundary. Arithmetic took place in the register stack which took the form of a push-down stack and was known as the nesting store in EE documentation. An instruction such as + occupied only a single byte (called syllable in the EE documentation), and operated on the top two cells of the stack (called N1 and N2), leaving the result in the top cell, and so shrinking the number of items in the nesting store by one. Multiplication of two single length integers gave a double length result, and a rich panoply of divide instructions offered options for the reverse process.

In addition to the nesting store there was a second push-down stack primarily used for subroutine entry and exit, and a more conventional file of 16 registers called Q-stores. For instructions addressing Q-stores, the Q-store number was embedded in the instruction in the conventional way. Each Q-store divided its 48 bits into three 16-bit fields, the least significant one of which was a modifier. The other two fields were a counter which could count iterations, and an increment which was added to the modifier, often with a value of 1, but also used with larger values for striding through matrices. A memory access instruction had a bit to indicate that after the fetch or store the counter should be decremented, and the increment added to the modifier.

A table summarising the order code of KDF9 is available on-line at sw-pres.computerconservationsociety.org/STRSUBS/KDF9/orderCode.htm .

The KDF9 short loop is described in minute detail in the English Electric Programming Manual, which we have on-line at sw-pres.computerconservationsociety.org/KDF9/programmingManual/kdf9pm.html courtesy of the Cork University Computer Club. Of particular relevance is §14.2. The crux of the matter is the special short loop jump which jumps to the start of the previous word if the Q-store counter is non-zero. The two words of code were locked in the CPU until the Q-store counter got to zero. This short loop jump occupied only two bytes, so the challenge was (is) to divide the multi-length Mersenne number by a single length number where one iteration of the loop takes only 10 bytes of code plus the 2-byte jump instruction, and makes no reference to main store. If you are allowed to use Q-stores it is possible to do it with one byte to spare,

However, this limits the Mersenne number to have less than 216 words, each of which will have 47 binary digits. Also my recollection is that in 1967 it was done using only the nesting store. I have since tried to reproduce this loop, and made contact with Guy. We both remember that it involved NOTting the number and then a logical shift and another NOT to bring in another batch of ones. I believe that we now have a routine that is at least the essence of the 1967 version. However, during the search I produced a different loop, which is actually far superior, in that it will handle enormous Mersenne numbers with a maximum length of almost 2⁴⁸ × 47 bits, and consumes 47 bits per iteration. If we had had that idea in 1967, we would almost certainly have discovered a factor that was not known until 1976.

Before entering the loop, Q15 is set to the number of iterations - 1 + 2³². The counter C15 will first become zero when Q15 is 2³² - 1. I have tested it with double Mersenne numbers ³. This is a number of the form 2ⁿ − 1 in which n is itself a Mersenne prime. Mersenne himself discovered that the first four such numbers were themselves prime.

This 2018 version of the loop is embedded as a code procedure in a small KDF9 Algol program ⁴ that can be run using the Kidsgrove Algol compiler via our online facility ⁵. A possible recreation of Guy’s first 1967 attempt is also online ⁶. This is the version which is too long for a short loop. A possible reconstruction of the 1967 algorithm is also available on-line. A sample data set for all of these programs consists of the two numbers 47; 11;. In each case the remainder should be zero, and is computed as the remainder on dividing 47 into 2^211-1 - 1. a number composed of 2047 ones in binary.

^{3. See en.wikipedia.org/wiki/Double_Mersenne_number.}

^{4. See en.wikipedia.org/wiki/Double_Mersenne_number.}

^{5. At settle.ddns.net/KDF9/demos.htm.}

^{6. At settle.ddns.net/temp/mersenne3.a60.}

Why is the 2018 version so much better? I suspect that in 1967 neither Guy nor myself had read the Programming Manual in sufficient detail to encounter the ÷R instruction which is key to the 2018 version. It is hidden away in section §12.3 of the programming manual entitled “Lesser Used Arithmetic Instructions”.

Acknowledgment It is a pleasure to acknowledge the contribution to this reminiscence of Guy Haworth whose monograph entitled “Mersenne Numbers” ⁷ gives a fuller and better informed picture of the subject.

^{7.See centaur.reading.ac.uk/4571/1/1987_H_Mersenne_Numbers.pdf}

More about Double Mersenne numbers

There is a wealth of material on Wikipedia, but these few snippets have amused Guy and myself in recent times.

Firstly, notation. M_n is used as an abbreviation for 2ⁿ - 1. So M₂ is 3, which is the smallest Mersenne prime, and M₃ = M_M2 = 7.

M_M3, M_M5 and M_M7 are all prime. M₁₁ is not prime, and so M_M11 cannot be prime, as M_n can only be prime if n is prime.

Although M₁₃ is prime, M_M13 (2⁸¹⁹¹ - 1) is not prime but no factors were known until 338,193,759,479 was discovered in 1976.

Our 2018 version of the KDF9 short loop Mersenne remainder routine confirms this under emulation very quickly. So Guy might well have found this in 1967 if only I had made a better job of writing the short loop.

Mersenne’s original four double Mersenne primes are the only ones known. M_M17 , M_M19 and M_M31 are known not to be prime. The smallest factor of the first two was known in the 1950s and each is easily confirmed using our 2018 routine. M_M31 is just beyond the range of this routine. Its smallest factor is just slightly greater than 2⁴⁸. However, this 2018 version can confirm at least one factor of all double Mersenne numbers up to and including 2^229-1 - 1. The program contains a special kludge to cater for a factor > 2³⁹ and < 2⁴⁷. This is because all numbers are read in as reals, which have a 39-bit mantissa, whereas the maximum integer is 2⁴⁷ - 1. Look at the Algol code to see how to input the first factor of M_M13.

The next possible candidate is M_M61 whose status is unknown.

With encouragement from Bryan Birch, John Merriman and Frank Barnes, Guy continued to enjoy computational number theory and in 1983, using an Amdahl, it was he who discovered the smallest factor of M_M31. viz 295,257,526,626,031. Other factors of M_M31 were found by others later, but no factor of a larger Double Mersenne number has been found – despite huge efforts.

More about KDF9 Short Loops

The KDF9 Programming Manual almost suggests that the short loop facility was not so much a design goal as a by-product of the variable length instruction format. Be that as it may, the most common use of this feature was in matrix operations in linear algebra calculations. An inner product is:

Actually the optimum coding of this operation requires two DUMMY instructions, as is explained in §14.2.3 of the Programming Manual. By placing these two null operations ahead of the ×+F, it is pushed into the second word of the pair, so that the main control unit can be fetching the next two operands while the arithmetic control is doing the hard sum.

Although the compilers of the day probably did not optimise Algol to this level, there were library routines for matrices that used this technique. This feature enabled various vector operations to be programmed so that the only store accesses were for operands, a DIY vector processor – sort of. The machine did not have a move order, but did not really need one.

Note: This article has hot links which enable anyone to experiment with the code, and perhaps try to find the 1967 version with all operands held in the nesting store, or perhaps I am mistaken in thinking that such a version ever existed.

More about KDF9 Arithmetic

The KDF9 arithmetic instructions all work on operands in the nesting store. The only instructions to access main store are fetch and store. There are two types of fetch instruction:

1. Single modification:, e.g. E456M1 in which 456 is the address of a memory location which is embedded in the instruction, to which the contents of the modifier part of Q1 is added to compute the actual storage location. This instruction occupies 3 bytes.
2. Double modification:, e.g. M4M15 The address of the memory location to be accessed is the sum of the contents of the modifier parts of Q4 and Q6. This instruction occupies only two bytes.

The value fetched from store always ends up in N1. Q0 is always zero, and provides for unmodified access to memory using a single modified instruction, and indirect access using a double modified instruction.

Similarly there are store instructions whose formats are =E456M1 and =M4M15. The effect of a letter Q appended to the instruction is described in the above example.

This architecture means that a FORTRAN statement such as:

        Y = ( X + 3.0 ) * ( Z - 7.3 ) / 6.5

    compiles to:

        E2M1; V3; +F; E3M1; V7; -F; ×F; V6; ÷F; =E1M1;

M1 contains a pointer to the stack frame of the current routine, and V3 is a memory location set to 3.0 at compile time. Similarly for V7 and V6. This is extremely simple to compile, and is optimum code. The whole sequence occupies 22 bytes, less than four words.

The short-loop example above shows how the machine could evaluate an inner product, using the Q appendage to count through memory. By using the double modification feature and increments sometimes different from 1, matrices can be processed very efficiently. Although compilers rarely (if ever) achieved this level of optimisation the library routines certainly did.

Here is the code to multiply two square matrices, – A = B × C. We assume the address of the top LH corner of A, B and C are in N1, N2 and N3

It occupies only 10 words of store and comprises 32 instructions.

Following Brian Russell’s article in Resurrection 79, and the talk, on 15^th March 2018, by Brian Ford of the Numerical Algorithms Group, I thought it might be useful to put on record a “feature” of IBM System/360 floating-point.

Single-precision floating-point format has to make some sacrifices, given that it has only 32 bits available. Of the 32 bits, one bit is the sign bit (0 for positive, 1 for negative), seven bits are the exponent [“characteristic” in IBM terminology] and 24 bits (or six hexadecimal digits) form the mantissa [or “fraction”]. Subtracting 64 from the binary value of the seven-bit exponent gives the power of 16 by which the mantissa should be multiplied to give the value of the number. If normalised, the mantissa is treated as a fraction with a value less than one and greater than or equal to one sixteenth; in other words, the most significant hexadecimal digit should be non-zero. (The only exception to this is if the value is meant to be zero, when all the 32 bits are zero.) The use of powers of 16 by which to multiply the mantissa gives a very wide range of values but it means that the accuracy of representation can be limited.

Given the 24-bit size of the mantissa, the maximum integer that can be held accurately is one less than 16,777,216 – a number seared into the memory of anyone who did low-level programming on a System/360! 16,777,215 would be held as “FFFFFF”, with an effective exponent of six. Thus 76,543,210 (a not-quite-arbitrary number) cannot be stored with complete accuracy (the closest you can get is 76,543,216) whereas 7,654,321 can be.

Dividing by ten, 765,432.1 can be stored with reasonable accuracy: the integer part will occupy five hexadecimal digits, leaving one hexadecimal digit, four bits, to represent the single decimal digit.

Real problems arise, however, with 76,543.21: because representing 76,543 still requires five hexadecimal digits, only four bits are available to represent the two decimal digits of the fractional part! This is the disadvantage of the use of powers of 16.

If we continue to divide by ten, things get better but slowly. (For 7,654.321 the three-digit decimal fraction has to be represented by only two hexadecimal digits, allowing 256 possible values; for 765.4321 the four-digit decimal fraction has to be represented by only three hexadecimal digits, allowing 4096 possible values, and for 76.54321 the five-digit decimal fraction has to be represented by only four hexadecimal digits, allowing 65,536 possible values.) It is only when we get to 7.654321, when we have five hexadecimal digits (or 1,048,576 possible values), that we can represent each possible value of the six-digit decimal fraction uniquely. (The fraction 0.7654321 would be represented by six hexadecimal digits which can take 16,777,216 values.) My conclusion: if at all possible, use double-precision floating-point! I should add that, if you think that the problems of representation are entirely down to the use of powers of 16 in the exponent, think again! The original thoughts behind this note were formulated back in the late 1970s after reading a paper (the details of which have long been forgotten), which noted that even with an exponent representing powers of two, there were floating-point representations that didn’t give the expected accuracy when thinking in decimal notation.

Anyway, numerical analysts always want an additional half bit!

The editor reminisces...

In the early 1970s I was working on a CDC 6500. We were asked for help by a person from the London Business School. He had developed an economic model on an IBM 370/135 written in Fortran. But applying larger and larger volumes of data to the model had revealed that the 135 really wasn’t up to the job. He wanted to run his model on the London University CDC 6600. Sensibly, he had done some test runs on both systems with a small set of data but the outputs didn’t match. Support staff at the university had failed to identify the problem. Could we help? Indeed we could. I got the job of looking at the problem and, after a couple of days of trial runs and study, I wrote my report.

I found that the divergence seemed to be dependent upon the result of a subtraction of one value from another, very similar value. Declaring the two variables as DOUBLE PRECISION in the 370 version would, I opined, make it give the correct answers in line with the (60-bit floating point) 6600. This must have been the right answer, because they paid up immediately.

32-bit floating point remains an elephant trap for programmers to this day.

CCS Donations Fund

COMPUTER CONSERVATION SOCIETY

DONATIONS POLICY

At the March meeting of the CCS Committee, a formal policy governing the Donations Fund was adopted:-

1. INTRODUCTION
   1. This is the Computer Conservation Society’s Donations policy.
   2. The Computer Conservation Society (“CCS”) is a Specialist Group of BCS, the Chartered Institute for IT.
   3. Definitions
      1. “Donation” means a voluntary contribution, gift or bequest to the CCS, or sums raised from fund-raising activities for the purposes of the CCS as set out in its Constitution, being:
         • 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.
      2. ldquo;Officers” means the CCS Chair, Secretary and Treasurer.
      3. “Officers” means the CCS Chair, Secretary and Treasurer.
   4. Exclusions
      1. This policy does not apply to:
         • Sponsorship
         • Subscriptions to the CCS journal Resurrection payable in certain instances by non-BCS members in order to receive copies of the journal by post.
2. PURPOSE OF DONATIONS
   1. There is no membership subscription to belong to the CCS.
   2. The costs of running CCS events and associated expenses are met by an annual allocation by BCS.
   3. The CCS welcomes Donations for the purpose of supporting its objectives as set out in its Constitution and on its website, and customarily asks its members to make an annual voluntary Donation.
   4. Donations may be used to support any endeavour in support of CCS objectives. Such endeavours may include but are not limited to support for computer restoration projects, computing system projects and other working groups, prizes and awards, education and research, workshops, symposia and other activities.
3. ALLOCATIING DONATIONS
   1. A request may be made in writing to an Officer of the CCS or to the CCS Committee to make a grant from the Donations Fund.
   2. The CCS Committee may itself initiate consideration of making a grant from the Donations Fund.
   3. Decisions on grants from, and the use of, the Donations Fund are made by the CCS Committee, except that if a decision is required at short notice, the Chair in consultation with the Officers may make the decision, and subsequently report such decision to the CCS Committee.
   4. Decisions may properly be taken by the CCS Committee, or by the Chair in consultation with the other Officers, to make grants from the Donations Fund for activities, projects or for any other purpose in which one or more CCS Committee members may be involved, such as, but not limited to, being a Leader of a Project or other Group or Regional Group as defined in the Constitution.
   5. A donor may designate an individual Donation to support a particular endeavour in support of CCS objectives, in which case the CCS Committee will take account of such designation in making a decision on a grant to be made to such endeavour from the Donations Fund.
   6. If no use is made of part or all of the Donation allocated, it must be repaid to the CCS Donations Fund.
4. PRINCIPLES RELATING TO DONATIONS
   1. CCS Committee members shall derive no personal benefit from Donations.
   2. The CCS Committee has the power to refuse any voluntary contribution, gift or bequest offered if the activities of the potential donor are contrary to the objectives of the CCS, or for any other reason that the CCS reasonably considers is in the interests of the CCS.
   3. A notice will be posted to the CCS website and published in the CCS journal Resurrection annually stating the grants which have been made during the preceding twelve months from the Donations Fund.

A Note on Copyright

Having just completed a book with copyright issues, and also having a website which tries to avoid the issues, I have had some exposure to the problems. It sounds simple: find the copyright holder and get permission to use the material in the way you wish.

In one case, I wanted to put a book of my own on the web. Unfortunately, the publisher had assigned the copyright to another party, but did not have a record to whom that was! In another case, a revision of the publication was undertaken (to use modern computer graphics), but the publisher never replied. The revision was undertaken using the authority of the original author. Perhaps not legally correct, but it worked! I had difficulty using material from the National Library and Archive of Egypt, but this was eventually resolved by the publisher via a personal visit and a letter in Arabic. Determining the copyright holder and getting permission is problematic for most material gathered from the web – annoying since this is often a good source of information. It is frequently the case that the Creative Commons Licence [creativecommons.org] is used for copyright. This has several variants, so it may be important to ensure which one is specified. For a website, one can use a hypertext link to avoid copyright concerns, but one then has the problem to ensuring the link is retained.

It seems to be the case that museums regard the person who donated documents as the copyright holder. This is often not correct, but may be the easiest way to solve permission issues.

Given all the above, it might appear that ensuring the preservation of computer documentation would present problems. Fortunately, there is a simple solution. Hand in copies of the material to one of the three main national museums for computing [The Science Museum, The National Museum of Computing, and The John Rylands University Library at Manchester]. (I used this method to preserve the archive concerned with my website by donating it to the National Art Library.) It might be wise to ensure that no charge can be made for inspection of such material. I would suggest that the Computer Conservation Society produces an index of these depositories. (Of course, most of the material is already on the web, but often such sites cannot be guaranteed to be there in perpetuity.) Note that I am not legally qualified, so perhaps others can add/correct this note!

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

Supermarket chain to get B3500: One of the major supermarket chains in the UK, Fine Fare Ltd, is to replace its second generation IBM 1401, installed in 1965 with a £200,000 Burroughs B3500 system at its head office in Welwyn Garden City. Using COBOL, a comprehensive management system is to be developed. (CW 090 p24)

Programs to aid the blind: A regular weekly Braille News Summary will be one of the most important results to be derived from a suite of programs developed over the past two years by the computer unit of the Royal National Institute for the Blind. (CW 091 p1)

Elliott 903 monitors train movements at Leeds Station: Train movements along the 47 miles of railway track around Leeds City station are being monitored by an Elliott 903 installed in the basement of the station. The computer is used to translate signals received regarding rail traffic and to supply information to the signal box where signalmen can control movements of passenger, goods and shunted trains in the area without any need for visual observation. (CW 091 p7)

Fingerprinting with pattern recognition: The rapid identification of fingerprints by computers using pattern recognition techniques is now being studied at Strathclyde University, Glasgow, in co-operation with the city’s police. (CW 092 p16)

NPL plan national network: A data communications network that could be the model for a national system is to be established within the National Physical Laboratory at Teddington, next year. One of the principal aims of the scheme will be to demonstrate the practicality of a modular type of network. The NPL system will simulate a local level of a national net and will be used by the staff at the laboratory to access an information library held on disc file under the control of a small computer. (CW 093 p1)

GE’s Direct Access for N/C Tool Users: Allowing for a considerable time reduction by substituting an automatic application for the present manual one, De la Rue Bull’s GE 265 time sharing service is offering direct system access via ordinary STD lines to numerically controlled machine tool users to create coded tapes through teletypewriter terminals installed in their plants. (CW 093 p16)

VDEC launches two more PDP machines backed by new language: Two new low-cost computers, the PDP-8/L & PDP-9/L, and a new language, FOCAL, Formula Calculator, have been introduced by Digital Equipment Co Ltd. of Reading, placing the company, already one of the leaders in the small machine field, in a strong position with a still bigger share of the £100 million OEM and education, research and industrial markets. (CW 095 p12)

New UK Firm in Disc Pack Market: By the end of the year the first British produced exchangeable disc packs should be on the market. This is planned by Memory Magnetics Ltd, a new company partially financed by Memory Magnetics Inc, of California, whose product line already includes similar discs. (CW 096 p1)

Off-the-Shelf Argus Leads Low Cost Bid: A low cost computer hardware package which will soon be available ‘off the shelf’ is being offered by Ferranti from its Argus range of process control equipment. The package, known as Argus Model L, is designed as a low cost laboratory system for use in research departments by industry, government and the universities. The basic L configuration comprises an Argus 400 or 500 mounted with peripheral control equipment and power supply module in a single equipment rack, together with a desk, monitor panel, fast paper tape reader and printer. The standard Argus interface is included, so that customers can attach their own equipment to the computer or extend the system on site. (CW 097 p20)

ICL launch mag-tape encoder: The first new product to be launched by ICL is a magnetic tape encoder jointly developed with the Potter Instrument Co of the US. The companies have been working in close co-operation and Potter recently ordered $1 million worth of exchangeable disc stores from ICL’s subsidiary, Data Recording Instrument Co, of Staines. The new encoder, known as a magnetic tape data recorder, will be demonstrated at IFIP. A self-contained unit, it provides for direct recording from a keyboard on seven-or-nine-track, half inch tape at densities of from 200 to 800 bits per inch. (CW 098 p1)

System 4 wins over IBM customers: Compatibility with IBM’s 360 series has been a key factor in ICL gaining two further orders for its System 4 range. Announcement of the orders came within days of Arthur Humphreys, managing director of ICL, stating that “We shall use the System 4 for our attacks on IBM users” when defining ICL market strategy in Edinburgh last week. (CW 100 p1)

Datel Development Aided by Survey: The demand for data transmission facilities over the next 15 years is to be assessed by Scientific Control Systems Ltd, formerly CEIR, under a survey commissioned by the GPO. This survey, the largest ever undertaken on its subject within the UK, will run for the next eight months in parallel with the GPO’s own R and D programme and is expected to yield results vital to the development of the Datel services. (CW 100 p16)

Giro Service Aims at one Million Customers: With the first of three ICL System 4/70s installed and fully operational at its centre in Bootle, Lancs, the GPO has announced that the official opening of its Giro service will be on October 18^th. Initially the 4/70 will be supported by two RCA Spectra 70/45s, installed earlier at Bootle for development work, though these are later to be replaced by further 4/70s. The GPO believe it has the first Giro in the world to be entirely computer-based from the outset, and to make this possible has needed to invest in what is thought to be the largest single EDP centre in Europe, and among the largest in the world. (CW 101 p12)

Burroughs Machines for Online System: An attempt to design and implement an on-line management information system is to be made by the British American Tobacco Co based on three Burroughs computers that are part of a £610,000 order. Design of the system is being carried out by BAT and Scientific Control Systems. At present only the basic design is complete, and the precise computer configuration is not yet decided. However, the system will rest on a B3500 located in London, two B500 satellites at BAT’s UK factories at Southampton and Liverpool, and an unspecified number of on-line terminals. (CW 102 p12)

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.

Forthcoming Events

London Seminar Programme

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

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

For queries about London meetings please contact Roger Johnson at .

Manchester Seminar Programme

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

For queries about Manchester meetings please contact Alan Pickwick at

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

Museums

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

Bletchley Park : daily.

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

The National Museum of Computing Colossus Galleries open daily 10.30-17.00; full Museum open Thursday, Saturday and Sunday 12.00-17.00; Provisional opening for the Turing-Welchman Bombe is likely to be as per the main museum.

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

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 new Information Age gallery explores “Six Networks which Changed the World” and includes a CDC 6600 computer and its Russian equivalent, the BESM-6 as well as Pilot ACE, arguably the world’s third oldest surviving computer.

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

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

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

Computer Conservation Society

Aims and objectives

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

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

The aims of the CCS are to

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

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

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

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

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