EDSAC — Andrew Herbert

Commissioning remains focussed on the Arithmetic Unit and on Input-Output.

Sadly Nigel Bennée has not been available for a few months. In consequence Tony Abbey and I have taken over Arithmetic Unit commissioning, aided by a new volunteer to join the EDSAC team, Steve Boulton. Fortunately Nigel kept his circuit diagrams up-to-date and also had written an in detail description of his circuits we can follow, but it is a steep learning curve for all three of us.

Looking at Logic Analyser traces we realised that, now the Transfer Unit has been added, the R2 pulse was mistimed and this was leading to the incorrect transfer of operands to the Arithmetic Unit. R2 had previously been taken to indicate the end of a transfer of data from store onto the Master Output Bus (MOB). The MOB had been connected directly to the Master Input Bus (MIB) from which the Arithmetic Unit read in instruction operands. But with the extra delay due to the Transfer Unit (which aligns short and long number operands before passing them to the Arithmetic Unit) there were circumstances in which R2 would now occur too early.

We added an extra minor cycle delay to the generation of R2 in the Coincidence system so that it is only raised when a transfer has completed the transit MOB⇒Transfer Unit⇒MIB. However R2 now no longer necessarily marked the precise end of the transfer. It only guaranteed to occur after the transfer. This has upset the loading of the Multiplier Register (via the H order) and of the Multiplicand Register (via the A, S, C, N and V orders) which relied on R2 as an end of data marker. This has required some redesign of the Support Units for these two registers.

In the case of the Multiplier, an existing signal G10 has been adapted to generate a one minor cycle “clear” of the Multiplier Tank at the start of stage 2 of the H order ahead of the operand arriving on the MIB (guaranteed to be at least one minor cycle after the start of stage 2).

In the case of the Multiplicand, it was possible to simplify the logic controlling the switching between loading and recirculating data when we realised the data only has to persist for the duration of the current order and that the MIB is reliably quiescent other than during the operand coincidence period of Stage 2, thus removing a dependency on R2, marking the exact end of the loading phase.

Bill Purvis has been a helpful consultant to us in this process, using his ELSIE EDSAC Logic Simulator to suggest and check out the proposed design changes.

Having addressed the R2 timing issue, we then found that data was intermittently being corrupted when transiting the Transfer Unit and this was due to delays in the path from store to MOB to Transfer Unit putting data pulses out of phase with the central clock. It was overcome by using a delayed clock to gate MOB data into the Transfer Unit and shortening the Transfer Unit delays to just under 18 and 36 bits respectively so that data output to the MIB was back in phase. This proved to be a tricky process to adjust both timing and levels through the two delay lines but as of last week we have, we believe, now got a reliable Transfer Unit.

However, while making these adjustments we have found loading of data into the Multiplier register by the H order and into the Multiplicand register by the A, S, C, N and V orders is now failing where it previously worked. In the case of the Multiplier it looks like a fault has developed in the Chassis 01 (storage regeneration unit) for the register, to be investigated this coming week, along with the Multiplicand.

Martin Evans continues to work on the Paper Tape Reader circuits, in between his duties as editor of Model Engineering Magazine. He has replaced a monostable by a phantastron to enable a longer waiting time between successive reader requests and, as of last week, has an apparently working circuit, although driving the mechanical reader a little too fast. We are optimistic he will shortly be able to read paper tapes into memory.

Simon Porter has been assisting Martin and in addition, continuing his long term activity of redrawing all EDSAC circuit diagrams to a consistent standard and cross checking against the physical chassis themselves.

Some time ago we had a transformer failure in one of the Display Units, in particular the one for peeking into the main arithmetical registers. The fault was eventually tracked down by Steve Boulton, who discovered the replacement transformer had been misconnected and was delivering insufficient EHT to light up the cathode ray tubes with reasonable brightness.

Peter Linington and Peter Haworth continue to work on the regeneration chassis for the upper half of store and the nickel delay lines, to be ready for connecting to EDSAC in place of the current Digital Tank Emulators.

As a team we are having a debate about “storage regeneration units”. We have built these by copying a surviving chassis from the original EDSAC, but this design has been shown to have problems and so various local “improvements" have been made for these units in different parts of the machine. We have ended up with around five or six variants and we now believe there is some scope for rationalisation. To quote from Wilkes’ memoirs: “I [Wilkes] computed that, if we had given the same level of attention to the design of the individual units as had been given to the design of a radar set or television set, construction would have taken over twenty years. One had to cut corners and accept any unit that did its job even if one felt its design was not optimal. ”

ICL 1900 — David Wilcox, Bill Gallagher, Delwyn Holroyd

I [David Wilcox] now have a PF56/2812 emulator that can support both dual access EDS60 and EDS200 along with a dual access EDS200 DCP which runs with this emulator. So far I have completed my testing using an OLT (Online Test Programme) but I need to do more work running the PF56/2812 on two 1900 systems.

The dual access EDS60 DCP is the version that was running when 1900 systems were still in use. I have developed the dual access 200 DCP on the basis of the work I did around 1970 when I developed the original dual access EDS200 DCP. Unfortunately we have not been able to find out any detail from the original so I have created this as best as I can remember. However I know that the concept is the same.

Meanwhile Bill has been busy scanning various 1900 related manuals and documents from the estate of the late Brian Spoor. These will be uploaded to https://icl1900.co.uk/.

Software Preservation — David Holdsworth

Website

Some time ago the sw-pres. comp... server had been upgraded from HTTP/1.0 to HTTP/1.1, and that there was an occasional web page misload. I believe that I now have a fix, and am testing it in my home environment. The bug relates to the closure of data streams derived from a TCP/IP socket. The intermittent nature of the problem made diagnosis difficult, but my testing shows that things are much improved, although it did manage to throw a Java exception on the server after a few hundred requests. There is no visible malfunction at the browser end. This webserver is a direct descendant of a server used at Leeds University since the 1990s and only decommissioned last month.

Copyright of old ICL documentation

Bob Geatrell is helping identify possible links with the ex-ICL society. This is on-going.

Also I have e-mailed TNMoC to see if they have key KDF9 manuals and if so will they send me copies of the four pages that are missing from my copy of the Service Routine Library Manual. And if they do not have the manuals, do they want my copies when I have finished with them. In the event that TNMoC does not have the manuals, I will try the Science Museum or the British Library.

Emulation is not Software Preservation

Recent email correspondence has made me feel that I need to reiterate that software preservation is not primarily about emulation. I only want emulators as a means to exhibiting and analysing preserved software. My take on this has changed little since this article (www.ccsoc.org/hold2.htm) in 2001.

In this paper I talk of preserving the “significant properties” of digital objects. For software, executability is clearly a significant property. Originally I was thinking in terms of preserving digital material (of which software is one example) indefinitely, say for 1000 years. I now doubt that civilisation will preserve itself for such a period. I wrote emulators for KDF9 and Leo III so that we could be confident that the copy-typed listings were correct. Only by actually running software that has been rescued in this way can one be confident in its correctness. I knew very little of Leo III before being asked to preserve its software. The experience of this activity shows that the documentation is a very significant property of the software, and its preservation is a vital part of software preservation.

The National Museum of Computing — Rachel Burnett

Our transformational building restoration and refurbishment project has been completed on time and to budget, our largest project by a significant margin.

The work was to help preserve the World War II-era building, secure the future for the collections and enhance our visitor experience. It has included the restoration of the roofs over the Tunny and Colossus galleries, modernisation of key facilities and amenities, the expansion of the Museum’s learning spaces, a new meeting room and also new artwork.

This was made possible by the generous support of the Post Office Remembrance Fellowship and our donors and supporters, with ongoing crowdfunding.

Thanks to this, the many Post Office staff who contributed to developments at Bletchley Park during World War 2 will continue to be acknowledged – most notably the Post Office engineers, led by Tommy Flowers, who designed and built the Colossus machines. There is a new pop up exhibition dedicated to the hidden figures who made the creation of Colossus possible.

The World Origin Site plaque for Colossus has been unveiled. A World Origin Site is somewhere unique, marking the place, people and moment when something truly ground-breaking was invented, discovered or first used. The Museum’s reconstructed Colossus is running in the very hut where unit No 9 was operational in 1944.

We are delighted to have a new Collections Manager, Charlotte “Charlie” Hathaway.

Our Collection, the world's largest collection of working historic computers, has passed “Stage 1” Nationally Designated of the Designation Scheme and we shall be proceeding to “Stage 2”. The Designation Scheme recognises and celebrates museum collections of national and international importance, based on their quality and significance. It raises the profile of the collection nationally and internationally, encouraging new research and learning.

We are very fortunate that curation, display, interpretation, guiding, restoration and reconstruction projects in the museum benefit from the skill and enthusiasm of our dedicated volunteers, including those with a technical background, specialist knowledge and engineering skills (several CCS Committee members and CCS members among them).

We are actively seeking volunteers. We run regular recruitment events to attract and introduce new volunteers. Further plans include targeted marketing campaigns.

We are continuing to address succession planning, to ensure that the knowledge of our technical experts is maintained and passed on.

We are celebrating our 20^th anniversary this year as a registered charity.

Elliott 803, 903 & 920M — Terry Froggatt

I have made a replacement for the Jaguar Flight Program paper tape which seems to have disappeared from the display cabinet on the 903 at TNMoC.

Peter Onion reports that the TNMoC 803 is working, and Peter Williamson reports that the TNMoC 903 is working. I can add that the RAA/TNMoC 920M (which I still have at home) is working too, and I’ve offered the use my 920M test rig to evaluate a further six 920Ms in a private collection.

Peter Onion took the 803’s battery home over Christmas and gave it a couple of discharge/charge cycles. This is an ex-RAF SAFT unit consisting of 20 NiCad cells. To discharge it without the risk of reversing the voltage polarity of any cells, he places a 1Ω resistor across each cell, and monitors them in turn using a tree of relays and an Arduino’s Analogue to Digital converter. As each cell “falls off the discharge cliff” he removes its resistor. For the charge cycles, he uses a bench power supply set to 27.5V and current limited to 1A. When the battery was new, a full charge should have taken over 24Hrs, but since it is nearly 40 years old it is much quicker! The second discharge/charge cycle showed a noticeable increase in all the cell capacities, so he’s sure it does some good. He’s also checked the electrolyte level in all of the cells.

Peter also tells of the weekend that he and Gareth spent recently, repurposing the 5-v-8 track mode switch, provided for a second Paper Tape Reader on the 803, to act as an on-line switch for their PLTS (Paper Less Tape Station). The 803 wiring diagrams show a direct connection between one side of the switch and one side of the bulb, but in reality there were two wires disappearing into the wiring loom, which they traced to two adjacent pins on one of the unpopulated Reader 2 logic board slots. And oddly, the corresponding two pins of the Reader 1 logic board were not connected. There was also an untidy green wire attached to the Reader 1 mode switch, and Peter reckons that whoever installed this didn’t try hard enough to understand the wiring. It was duly removed, then tidy wiring and missing links were added.

I have a recent story related to the 903 Paper Tape Station. If you type at the 903 TeleType keyboard, and the 903 is waiting for input, what you type will appear on the TeleType printer. This echoing is implemented by the PTS, not by the TeleType or by the 903. (And if the 903 is not expecting input, the “chomp” of the keyboard will not be followed by the happy clatter of the printer). On a TeleType, a new line usually needs two keystrokes, CR (carriage return) and LF (line feed), but if you have used my BASIC on-line, you may have noticed that you don’t need both: if you type CR or LF, this is echoed by the PTS then my BASIC system outputs a LF or CR for you automatically. As a consequence, when I tried to send just the output of running my “World Tour” BASIC program to a friend, I was accused of posting a “bare CR”. These are banned from emails because of the risk that a header could contain malicious text hidden between a pair of CRs, but this CR was followed immediately by CRLF, and applying this rule to an attachment (which my server simply assumed to be text) seems inappropriate.

As I reported in Resurrection 105, whilst testing 920M (88) with as many suitable programs as I had to hand, I discovered a bug in my own BCPL implementation, in which the B-register is frequently used as the stack pointer. The normal 900-series subroutine exit also uses the B-register, so to avoid having to reload the stack pointer after subroutine calls, I’d used unusual exit code, which adds the link to an unmodified jump instruction then executes it. Alone in the 900-series, and as clearly stated in its Facts Cards, the 920M puts junk into the two top bits of the subroutine link. I’d overlooked the need for a mask instruction to remove this junk, which adds just one word to the exit code shared by all subroutines. I have now corrected my BCLP implementation.

On the 9^th of January the national funeral of the late US President, Jimmy Carter took place in the National Cathedral in Washington DC. Amongst the speakers was the Dean of the Cathedral, the Very Reverend Randolph Marshall Hollerith, great grandson of Hermann Hollerith, a name which will be familiar to readers of Resurrection.

101010101

Readers will recall that in Resurrection 106 we published an obituary for our good friend the late Brian Spoor. Brian had a huge collection of documents relating to the ICT/ICL 1900 Series. In his will he wisely made provision for them to be conveyed to his friend and colleague Bill Gallagher. Quite a lot of material, however was hosted in his various computers which he also left to Bill. When they arrived, Bill was dismayed to discover that the executors of Brian’s will had either wiped or destroyed the hard discs in a (frankly rather clumsy) attempt to ensure compliance with the General Data Protection Regulations.

This underlines the importance of making sure that copies of any historic material should always be held by at least one other competent (preferably younger) person at all times. One should not assume that executors or surviving family members will know how to deal with such material or will have the right contacts. Software source code – not just the executable (of emulators for example) should surely be treated similarly. Many of us (including this writer) are guilty. We need to learn from this unfortunate incident.

Vince Bodsworth of the LEO Society writes – This is a request for data to enhance LEOPEDIA. We need to be informed of any new reference to LEO or LEO Computers in publications or media that refer to LEO, LEO Computers or LEO people that arise from time to time, for example in newspapers, in journals, on tv and radio and at meetings online or otherwise.

If you see or know of any new references will you please let me know giving date, names and a copy or reference to the item. Send it in even if it might be a duplicate as I will check for its existence first and ignore or enhance the existing item as required. If I need more information, I will ask for it.

As an additional request, we are looking for actual CLEO code that was used on LEO. If you have any listings or media with CLEO could you please let me know and I will make arrangements to acquire it or get a copy. You will be asked to complete an acquisition form with your gift specifying the terms.

Send to .

I am pleased to report another active and energetic year for the Society, my first as Chairman.

There have been eight hybrid London Meetings held at the BCS London headquarters and online, plus the Tony Sale Award presentation held at The National Museum of Computing and online. Topics ranged from Alan Turing’s ACE engine to Early Soviet Computing. Wholehearted thanks are due to Roger Johnson for his efficient organisation of a really interesting series of talks.

North West branch have held four hybrid meetings this year, thanks to the efforts of Bob Geatrell and Alan Pickwick.

Access to members’ personal data : we continue discussions with BCS on our access to CCS members’ records for effective communication and administration. We are hopeful that a database of CCS member data hosted by The National Museum of Computing (TNMoC) and managed by the Committee will provide the way forward.

There were three most interesting editions of Resurrection. Many thanks to Dik Leatherdale for encouraging, assembling and editing the articles for each edition, and for managing the Society’s website.

Thanks to Dan Hayton, Dik Leatherdale and Martin Campbell-Kelly for continuing the collection and preservation of the Society’s digital and video archives, including photographs, and thus recording the Society’s history.

A number of us visited the Musée Bolo in Lausanne at the end of April. It was a splendid visit, with a tour of the museum given by Cédric Gaudin, the Director, a convivial dinner with our hosts and then a visit to their computer store in central Lausanne. We saw several Cray supercomputers, and an IBM BlueGene/Q computer, prototype mice, invented by Prof. JeanDaniel Nicoud at the École Polytechnique Fédérale de Lausanne, and made by the Swiss company Logitech, before they emigrated to Silicon Valley, and a number of Swiss Smaky minicomputers, which Prof. Nicoud also developed.

For the first time since 2018 the Tony Sale Award “to recognise a singular achievement in the area of computer conservation and restoration” was held, in conjunction with and at TNMoC in May. The Award attracted an international range of entries. It was judged by a distinguished international panel of judges enabled and chaired by Martin Campbell-Kelly. The winner was France’s Association MO5 for the hardware and software reconstruction of the Micral N microcomputer of 1972. Fabien Wernli accepted the award on behalf of Association MO5.

Hearty congratulations to Roger Johnson, our indefatigable Meetings Secretary, on the award of an Honorary BCS Fellowship for his many years of service to the BCS in many roles, including with the CCS. We are proud too that Simon Lavington was deservedly awarded The National Museum of Computing’s Honorary Fellowship 2024. The presentation took place at TNMoC. Simon gave a splendid talk about Dina St Johnston, one of the first female programmers, and the first female founder of an independent software house.

Sadly, I have to report the sudden death of Aneesa Riffat, first professional Senior Curator of TNMoC, at the early age of 46, and of Peter Short, long serving curator of the IBM Hursley Museum, both representatives on the Committee of the CCS.

Rachel Burnett, a trustee of TNMoC, is its temporary representative; Peter Coghlan has taken over from Peter Short as IBM representative. Also, Hattie Lloyd has left the Science Museum. We await a new representative for the Science Museum Group.

In my first year I have had a steep but most enjoyable learning curve. I would like to record my gratitude to the members of the Committee and the leaders of the various projects which report to the committee, for all their support and hard work. I could not have led the Society without their generous support.

Following on from the news item above concerning Brian Spoor’s Will – This should not have happened. The solicitors/executors had no authority and no reason to do this. There was no point in a legacy of hardware devoid of content. The “excuse” made about data protection was completely irrelevant.

But it did happen, and the situation could not be retrieved.

As a result of this, the following comment is intended as a practical note with a few ideas to think about in minimising the chances of ignorance, misunderstanding or misinterpretation by your executors in relation to computer related material that you wish to leave to a beneficiary.

I’ve used the term “computer related material”, but it’s not a precise phrase, and nor is the term “digital assets” that is sometimes used, which may cover tangible assets like mobiles, tablets, laptops, memory sticks and other devices; refer to what is stored on them, such as files, folders, photographs and other information; even extend to various subscription and other accounts and platforms; software.

• Make a Will when you have time to think clearly about what you want to happen to your assets and possessions.

• In view of the situation which arose in this case, think about the wording in the Will. For example, if you are leaving devices because you want the content you have created of files and folders to go to a beneficiary, include the contents in the bequest: e.g. “my personal computer, memory sticks, and other hardware devices together with their content”, perhaps being more specific than this.

• Consider having a “side letter” with the detail of instructions and information in respect of computer related material that you own and are entitled to leave. This side letter should be easy for you to review from time to time, keep up to date, secure and under your control alone. It will enable you to keep control of your legacy as this may change, without having constantly to amend your Will. Although it is not legally binding like a Will, it can be invaluable. The executors of your Will should know of this side letter and its location.

• Say where the material is to be found and how it may be accessed. You can reflect any additions or changes to the list of your hardware, files and folders and other stored material and anything else you want to have a record of, to their access, or about any technological developments affecting them, or remove any that no longer concern you. If you back up any of your material on offline devices such as memory sticks or an external hard drive, it may be that they could be held in the same place as the side letter, and noted in it.

However, do remember:

• You do not own much, if any, of the software and other copyright material you use on your computer; you have a personal licence, only for your use, which you would not be entitled to transfer.

• Many online service providers, such as social media or other subscription accounts, specify what is to happen when a user dies. The account may be non-transferable and cease, or be transferable only under the particular terms and conditions applying. Some accounts, like bank accounts, allow only you to use your log-in details, and it would be an offence for anyone else to access that account.

• You may wish to leave instructions about deleting confidential information that you hold.

• It is possible to appoint a “digital executor” in your Will separate from your executors for dealing with your digital material after you die.

In modern terms SCL should perhaps be thought of as a scripting language. But the notion of scripting languages wasn’t current back in the day so the most obvious comparison would have been with various Job Control Languages (JCLs). But SCL differed from the then norm in a number of ways. For a start the language employed by users sat at a (MAC) terminal was the same as that employed by batch jobs and more or less the same as that used by operations staff sitting at the operating station controlling the overall computer. Moreover it was (I should really say “is”) a proper programming language bearing a close relationship to Algol 60. It had reserved words like IF, THEN, ELSE, BEGIN, END and GOTO each taking the meanings you have undoubtedly assumed. Readers will note that I have written these keywords in upper case. In fact, lower case would have been acceptable, but on punched cards, only uppercase was normal and things like filenames were usually in uppercase so it made sense to be consistent.

Variables and operators

So where shall we start? Let’s start with variables. Well I did say it was a proper programming language. There were four types of variable – INT, BOOL, STRING and SUPERSTRING. Note please, the absence of CHAR. Unusually STRING is not composed of a vector of characters but is a fundamental variable type in its own right. Let’s look at some sample SCL.

        INT INTEGER_VAR := 17 + 13;
        BOOL BOOLEANVAR := TRUE AND FALSE;
        STRING STR := "ABCDEFGH";
        SUPERSTRING SS := "ABC"&"DEF"&"GHIJK";
        BOOL DECISION := STR INCLUDES "DEF";

The first thing to point out is that the so-called break character “_” is not significant. If used wisely it improves human readability but the SCL interpreter ignores it. Now look at the last line. Here we find “INCLUDES” which is an operator comparing two strings in an unusual way. Besides the usual concatenate (“+”) and the full “compare” operators (“=” and the usual similar set) there are several others – STARTSWITH and ENDSWITH yielding a boolean value, plus BEFORE and AFTER yielding strings. Throw in a few built in functions (SUBSTRING is what you think it is and STINT (string to integer) one of several conversion facilities available) all combine to make SCL a particularly good string processing language – one could argue (and I do) an improvement over many more modern languages.

Although it is possible to use singly-dimensioned arrays of SCL variables, this is only rarely used. However, a SUPERSTRING is, in effect, an array of STRINGs but with the advantage that it can be assigned or otherwise passed around as a single entity rather than having to deal with individual STRINGs.

Fee FI Fo Fum

I mentioned IF, THEN, ELSE above but there is more to it than that. Let me introduce to you FI :

    IF <condition> THEN
        <several statements>
    ELSE
        <several other statements>
    FI

FI terminates a sequence of conditional commands. Note that, in the absence of an ELSE the FI is still mandatory. Thus FI is SCL’s solution to the “dangling else” problem of Algol-like languages.

Block Structure

FI appears to make BEGIN and END a bit redundant. Except that it doesn’t. BEGIN and END have their usual rôle in determining the scope of variables but there is a another task. The user can make operating system requests for various resources – notably files. But such resources are not assigned to the user at the point of request, but the requests are deferred until SCL encounters a BEGIN at which point either all the requested resources are assigned (and might lock other users out depending on the request) or will suspend the process until the resources are available. This is SCL’s solution to the “deadly embrace” problem. END releases any resources claimed by the corresponding BEGIN.

WHENEVER

        WHENEVER INTEGERVAR > 0 THEN
          SEND_RESULT_MESSAGE(50408);
        FI

This means that if something sets a new value to INTEGERVAR the WHENEVER test is performed and if the condition turns out to be TRUE, the specified action(s) is taken. SEND_RESULT_MESSAGE is a call to a function (in this case built into the operating system) and that function would respond by displaying or printing the message “A HARDWARE OR SOFTWARE ERROR HAS OCCURRED”. There are several thousand of these numbered messages known to VME, almost all of them more helpful than 50408.

To this day the WHENEVER idea is rare in programming languages but in the C# and F# languages the so-called “setter” can be exploited to the same effect. But C# is half the age of SCL and F# a mere teenager.

Macros and Procedures

Except that there won’t be much about macros because they were more or less phased out quite early on.

        PROC MY_PROCEDURE(STRING FILE_NAME,INT SIZE,BOOL MAYBE)
        PROCBEGIN

                        <some SCL statements>

        PROCEND

is a very simple declaration of an SCL procedure. Having declared it we might call it thus:

        MY_PROCEDURE("MYFILE",256,TRUE);

But we can do better than that by defining the first parameter as LITERAL FILE_NAME in which case the caller is allowed to omit the quote marks around MYFILE. Inside the procedure, however, FILE_NAME is a STRING. I should also mention SUPERLITERAL in passing. It means what you think it means.

Type declarations in parameters (except LITERAL/SUPERLITERAL) can be preceded by REF which allows the procedure to set variables in the calling program.

Sometimes the caller can omit parameters but the procedure writer can set a default value. So if the writer declares the second parameter declaration as INT SIZE=128 and the caller writes MYPROCEDURE(MYFILE,,TRUE); that is the same as writing the missing parameter as 128.

But there’s more. The caller can venture :

        MY_PROCEDURE(FILENAME=MYFILE,MAYBE=TRUE);

which is the same thing. And the caller doesn’t have to use the whole parameter name, just enough to make it unambiguous. By convention the procedure writer strives to achieve uniqueness in the first three characters of the name. If that isn’t enough, the caller can mix and match parameters identified by name and by position. By name resets where the next positional parameter is in the list.

        MY_PROCEDURE(SIZE=1024,TRUE,FILENAME=MYFILE);

And if the procedure writer doesn’t like the parameter name, rather than re-writing the body of the procedure, (s)he can instead write ... STRING FILENAME(NAME),.. which changes the parameter name visible to the caller:

        MY_PROCEDURE(SIZE=1024,TRUE,NAME=MYFILE);

Once again, as far as I know, this system of specifying parameters by name was unique to VME albeit the HTML markup language has something similar but rather less comprehensive. More recently, the F# language has caught up.

Calling SCL Procedures from the Terminal

Typing the name of the desired procedure followed by a left bracket in early versions of VME would result in the system prompting the user to supply the desired parameter values one by one, each parameter being identified by name.

Later versions of VME improve on this by displaying all the parameter names on the screen as a form to be filled in by the caller.

Storing procedures

While it is possible to declare procedures in the batch job or terminal session in which they are used, it is more usual to make them available, either to a specific user some users or to all users. In VME, the users’ programs are held in libraries (think directory or folder). SCL procedures can be held in the same way by a process akin to compilation.

In early versions of VME, both procedures and macros were held in source form but were nonetheless in a format which was also executable (the interpreter was built into VME, of course). Around the 1980s this changed and procedures could be compiled, not into the native order code of the host machine, but into the order code of an imaginary machine which was then available for interpretation by VME. This is far more efficient and allowed the source of the procedure to be analysed and syntax checked once only rather than repeatedly, but it spelled the end of the line for macros which couldn’t be stored in this way.

Review

So there you have it. A race through the features of SCL. Incomplete to be sure, but perhaps enough to gain an impression of the system.

The reader will have guessed that this writer has a high regard for VME’s System Control Language. There is much to commend about it, but two features stand out – string handling and parameter naming. Have they ever been bettered? I have my doubts.

In Resurrection 105, Roland Ibbett wrote a review of the book The Web before the Web. In it he reports that Ian Ritchie claims to have developed it for the PERQ Workstation Manual. I cannot confirm the exact date, but it was sometime in the late 1970s I supervised a student to write an online Help system for use on the Daresbury Laboratory Time Sharing service. This was a fairly crude hypertext implementation. As I had been influenced by Peter Brown’s work previously, it seems likely that this had stuck in my memory and suggested the technique as a project. Sadly, we never got to publish anything, and I no longer recall the student’s name. He did get the system working, but we never found the effort to write all the required pages, and it never saw general use.

In the article on the ICL 2900 in Resurrection 106 I opined that the “E” in S3E and the “L” in S3L stood for “early” and “late” respectively. In my defence, I can only say that it looked that way from the office in faraway Putney.

Bob Geatrell tells me that “E” was for ECL (Emitter Coupled Logic) and “L” for LSI (Large Scale Integration) albeit originally for a design using an ICL technology which never saw the light of day. Well, he was in West Gorton in the thick of the action and I was 200 miles away so I must defer to Bob.

Bob also asserts the almost-existence of an S3S (Schottky TTL) and an S3J (no idea) neither of which got much beyond the proposal stage.

P2L anybody?

Last September I marked the 70^th anniversary of the occasion when I first met a computer and wrote a program for it. And the program ran correctly!

I must be one of the few survivors among people who used EDSAC regularly. I was a student in the 1954/55 intake to the Diploma in Numerical Analysis and Automatic Computing at the Cambridge Mathematical Laboratory (renamed the Computer Laboratory much later). I still have my copy of Wilkes, Wheeler and Gill (WWG – 1^st edition, of course) which was my textbook then. The four diploma students in our year had desks in an office off the area where tea and coffee were served each day. In this space, too, were electronic racks where parts of EDSAC 2 were being built.

The diploma course started with us joining the annual “Summer School in Computer Programming” that the Mathematical Laboratory ran for a fortnight each September. We were grouped in pairs for writing and testing programs, and my partner was Dr. H. Bottenbruch of Universität Darmstadt. We desk-checked our initial program thoroughly, and it ran correctly. (Naturally my second program had a bug in it.)

Program or Programme?

Andrew Herbert said that Maurice Wilkes insisted on the “American spelling”. My memory is that he would say that program was the English spelling in the 18^th century (which the American colonists naturally adopted), and that the spelling in England changed to programme some time in the 19^th century when French fashion was dominant. (But we still write “diagram”, never “diagramme”.) He claimed that the Shorter OED supported this view. As a graduate of the Mathematical Laboratory I naturally use the old English spelling.

The other linguistic quirk that we were encouraged to follow from our first days was to talk about the instructions of our programs. This was to avoid phrases like “the order in which the orders are obeyed”.

The Diploma in Numerical Analysis and Automatic Computing:

In the summer term of 1954, when I was wondering what I should do after the final Mathematics examinations (I was still liable to spend two years doing National Service), my mother, who had been at a coeducational boarding school with Douglas Hartree in the early 1910s, suggested I should talk with him. He invited me to meet him at his office in the Cavendish Laboratory. It was only when I got there that I discovered that my mother’s friend was Professor D. R. Hartree FRS! He was extremely helpful, telling me that there was an automatic computer at Cambridge, and that the Mathematical Laboratory was running a post-graduate diploma course about computers and numerical analysis. (Their school was Bedales; I don’t know if there were any other coeducational boarding schools at that time.)

Douglas Hartree was one of the most influential UK pioneers in computing. In the 1930s he had built a differential analyser for integrating differential equations wile Professor of Applied Mathematics at Manchester University. After 1945 he was involved in the early stages of the projects to build the Manchester Baby, the Pilot ACE at the National Physical Laboratory, and EDSAC at Cambridge. His name is little known now, possibly because he died as early as 1958.

I graduated in mathematics at Cambridge in June 1954 and then signed up for the Diploma course starting in the following September. Ours was the second intake to what claims to have been the first full-year taught course in computer science world-wide. E. L. Albasiny and Stan Bootle (later known as the folk-singer Stan Kelly) were two of the three students in the initial intake; J. M. Watt and I were two of the four in the second intake – all men, as was normal then.

Jim Watt and I both received postgraduate studentships from NRDC (the National Development and Research Corporation) which were surprisingly generous – on leaving Cambridge, when I moved to the scientific civil service at RAE Farnborough, I was offered a (taxable) starting salary of £392 10s 0d per annum (£32 14s 2d a month!), which was less than the studentship of £425 (with fees paid). But British governments of any colour have always been ungenerous to their own employees.

I presume the course title “Diploma in Numerical Analysis and Automatic Computing” listed the topics in that order so that the Mathematical Laboratory could get the course approved by the Mathematics Faculty Board. In the late 1960s I had similar difficulty getting approval at another university for a combined degree course in Mathematics and Computer Science. One very senior person was heard to wonder why we didn’t offer a degree in Lawnmower Science!

After the Summer School ended we Diploma students were reckoned to be competent programmers and, when the academic year started in October, the course started with lectures from Dr. M. V. Wilkes (later Sir Maurice Wilkes FRS), the head of the Mathematical Laboratory, about computer design, and Dr. J. C. P. Miller on numerical analysis. There were some mechanical calculators for us to use, especially the Brunsviga. I mention this because it was the first time I had ever met one – such a contrast from nowadays, when my mobile phone is also my calculator.

Teaching of Numerical Analysis:

Jeff Miller’s lectures on numerical analysis were a significant portion of our taught course. He was one of the last makers of numerical tables, which until then had been an essential tool for anyone needing a numerical solution to any problem for which no combination of standard mathematical functions was the answer. But the textbook on numerical analysis that we were using was by Douglas Hartree – who had also written the “Introduction to Programming” which was a major part of the September 1954 booklet mentioned earlier.

I was very surprised to hear that Maurice Wilkes was teaching numerical analysis in his later years. He gave us a course (in the spring term, I think) about the history of computers – you may wonder whether any history existed as early as 1955! He started with Charles Babbage and Ada Lovelace, naturally. But Colossus was never mentioned, as it was still an Official Secret. Oddly enough, when I had been a Mathematics undergraduate at Trinity Hall (1951-54), my Director of Studies had been Dr Shaun Wylie. I had no idea that he had been one of the leading people in Hut 8 at Bletchley Park a decade earlier. (Later in the 1950s he returned to GCHQ as their senior mathematician.) He feigned total ignorance of automatic computers at that time, and only admitted it to me shortly before his death at 95.

Fixed-point and Floating-point Arithmetic:

Hardware to implement floating-point arithmetic was still somewhere in the future in 1954, so all arithmetic instructions used fixed-point numbers. But machines differed in whether the numbers were treated as integers or as real ¹ numbers between ─1 and +1. For the add and subtract instructions this made no difference. EDSAC’s multiplier (it had no hardware for division) assumed that the (35-bit) operands were real numbers. Normally programmers used scaling factors to keep their real numbers in the (─1, +1) range so that they could use fixed-point instructions.

By contrast, the multiplier on the Pilot ACE and DEUCE ² viewed numbers as unsigned integers. In practice, therefore, DEUCE programmers used a standard multiplication subroutine which assumed the operands were real numbers between ─2 and +2 and which took account of their signs. The hardware for the multiplication instruction took two major cycles, and the subroutine made these corrections in parallel with the multiplication operation.

EDSAC programmers who needed to work with integers would store them in short (17-bit) words, as long as they did not reach 2¹⁶ (65536). When a programmer wanted to work with integers, they would store m. 2^-16 in a short word (or m. 2^-34 in a long word). After multiplying short integers m. 2^-16 and n. 2^-16 the programmer would have to shift the resulting product m. n. 2^-32 to the left by 16 places to create m. n. 2^-16 , thus matching the format of the operands. Unfortunately the L (left-shift) order was limited to 13 places at most, as McCarthy explains; so his example program uses the 8 place left-shift L 64 F twice.

By way of contrast, an integer n to be used as an address in an instruction would be stored as n. 2^-15. Thus the constant P 1 F, permanently held in word 2, was equal to 2^-15.

When EDSAC first started work in 1949 the largest known prime number was the Mersenne prime M₁₂₇ 2¹²⁷‒1, which has 39 digits when written in decimal. This record had stood since 1876. One of the earliest “real” tasks for which EDSAC was used was to search for larger primes. Of course even M₁₂₇ would have needed at least four long words to store it. In 1951 Jeff Miller and David Wheeler showed that 180 x (M₁₂₇) ² + 1, a number with 79 decimal digits, was prime. (Of course the record has risen rapidly with the coming of more powerful computers. The length of the record prime found in October 2024 is 136,279,841 binary digits, all of them 1s – over 16 Mbytes – or over 41 million decimal digits.) However, EDSAC had a routine (A30) for floating-point arithmetic. Written by David Wheeler, I understand, it interpreted a series of floating-point instructions which looked almost identical to those for fixed-point numbers. Some might argue that interpretation slowed the machine, but here it could be justified because the individual floating-point operations themselves took so much time that the interpretation was a small overhead.

The dissertation project that Jeff Miller had given me was concerned with integrating differential equations using Taylor series. I started by implementing subroutines to manipulate (the coefficients of) Taylor series, e.g.. multiplying and dividing series, and taking the n^th power of a series. (Miller’s long-term interest was with Airy functions, defined by a differential equation for dy/dx that involves the n^th power of y. ) I had to use floating-point arithmetic for the coefficients of the series as their sizes were totally unpredictable.

My project was held up for a whole month because I was getting nonsense results from the floating-point routine, and I spent ages working through its details (nearly 300 instructions) without ever finding a fault in it. But I got to know the coding of A30 very well.

In the end, predictably, I discovered the fault lay elsewhere. I was using an exponentiation subroutine to calculate the leading coefficient in the series for yn, and it turned out that the documentation for that subroutine failed to say that it used the location 6D (which the floating-point routine was also using).

Design Principles:

A major part of Maurice Wilkes’s design intention was to build a computer that ordinary people could use. He didn’t aim for maximum speed and was prepared to compromise for reliability: for instance, he used a clock rate of 0.5MHz, whereas the Pilot ACE used 1MHz. And the next instruction followed the current one in the store (except for jumps), so executing each single instruction occupied at least one major cycle of the delay-line store. The instruction set also hid machine details from the programmer, who could write (and punch) instructions in a language that included letters and decimal numbers. I suspect very few of the early pioneers realised just how difficult it was going to be to write programs that worked correctly.

By contrast Turing’s design for the ACE Pilot Model (which was reproduced in the DEUCE) required every programmer to be familiar with many details how the machine worked. I can still remember the purpose of every single bit of the 32-bit instruction, 67 years after I last used DEUCE. One part of each instruction specified its successor, in order to maximise speed (especially in inner loops): optimistically this was called “optimum coding”. In practice, the first phase of testing a new program usually was to work through it step-by-step to ensure that the “next instruction” parts had been coded correctly.

It is generally understood that Turing was a genius. As a DEUCE programmer I developed the feeling that he hadn’t understood how mere mortals would work.

The B register:

EDSAC was getting quite old by 1954, and, as Dr Herbert hinted, a number of changes had been made. Most notably, the unconditional jump F m F had been in regular use for some years. Also the B-register had just been introduced, as explained in McCarthy’s article. I have a copy of the booklet “Introduction to Programming for an Automatic Digital Computer and User's Guide to EDSAC” dated September 1954, which was issued to us when we attended the Summer School on programming that month. This contains a short section (on page A51) headed “Orders which will be used to control the B register” – note the future tense. By then the B register was in regular use, but this booklet did not mention the use of the letter S within instructions that McCarthy describes. For example, it says that the order B 2046 F should be used to subtract 2 from the B register; we would have expected to write this as BS 2 S (storing the identical instruction, of course). The first S adds 1024 (the B digit) to the instruction, and the second S (for Subtract) means that the lower ten digits of the address part are to be 1024─2.

The routine R30 which modified the Initial Orders to implement these two S notations was remarkably compact. Written by David Wheeler, I presume.

F m D and similar jump instructions:

The “Users’ Guide to EDSAC” (at pages A49/50) lists the F m D instruction for jump-if-non-zero, but I don’t think I was aware of it. The same applies to the E m D and G m D conditional-jump instructions, which cleared the accumulator if the conditional jump occurred. As these were later additions to the instruction set, maybe the lecturer taking our first course decided not to mention them.

Input and Output Paper Tape Codes:

In 1951 the builders of EDSAC had decided to adopt a new paper-tape code for output in which all of the 10 decimal digit characters were represented by combinations of 2 holes out of 5; and computer output was punched on to paper tape, rather than being sent direct to a teleprinter (which had proved insufficiently reliable). All the teleprinters used this new code, of course, including the one which sat beside the tape punch attached to the computer. This meant program tapes in the (old) input code could not be printed. (In any case program tapes did not include Carriage Return and Line Feed characters. ) Naturally somebody had written a program which would read a program tape in the input code and punch it in the output code, with layout characters added – vital for dissertations, for instance.

As regular programmers we got used to reading the characters on the input tapes by eye. I had forgotten about using the comparator device that Andrew Herbert illustrated in his talk. We were encouraged to type each short program tape twice and use the comparator to detect typing blunders. The comparator could also be used to copy subroutines from the library.

The Initial Orders:

Andrew Herbert compared the simplicity of written instructions for EDSAC with those of the Manchester Mark I. My own comparison would have been with the DEUCE, where we had to prepare every instruction as a sequence of 32 binary digits on a single row of a punched card.

The Initial Orders expected each instruction to have an initial function letter followed by (0 or more) digits, optionally followed by Π, and terminated by a “negative” letter. Normally this would be F or D, indicating that the address part was an absolute one. This would be converted into a 17-bit word:

    f . f f f f b a a a a a a a a a a π
    -----------   -------------------
     Function           Address

where b is the B-bit and Π is the long/short bit; when the latter was set, the instruction would operate on a long (35-bit) word rather than a short one. If the resulting pattern of bits is treated as a number, it will be negative only if the leading bit is set; and this depends on the choice of the function letter.

The Initial Orders read paper tape punched in the old tape code, and the design of the assembly language depended crucially on the ordering of the letters in this code.

The 15 negative letters:

        F θ D φ H N M Δ L X G A B C V

had values ‒15 ‒14 ‒13 .. ‒1. (The blank tape character had value ‒16.) The remaining 15 positive (strictly, non-negative) letters:

        P Q W E R T Y U I O J Π S Z K

with values 0 1 2 .. 14. (The erase character had value 15.) The decimal digit characters 0..9 shared codes with the letters P..O.

After the Initial Orders had read an initial function letter they expected positive characters (i.e. digits) and maybe Π; when a negative character was found, that terminated the instruction. Normally this would be F or D, indicating that the address part was an absolute one.

But as Andrew Herbert mentioned in his lecture, the other negative letters φ H N .. V could be used as “parametric addresses” (and θ had a special use for addresses within a routine). For example, programmers could decide to allocate the addresses 0H, 2H, 4H, ... to a block of store for long-word numbers and use instructions with terminal letter H to refer to this block. Later in time, after all the routines had been written and they knew how much storage space was still available for data, they could place near the start of their tape a control combination (see below) such as ³

    T 45 K
    P 700 ΠF

to tell the Initial Orders to store the address 700D in location 45 (where the value of the H parameter was held).

The θ Parametric Address:

Naturally the Initial Orders maintained a register to hold the address at which the next instruction would be stored. When the control combination G K (see below) was placed at the head of a routine, a copy of this address was stored in the θ-parameter. Then jumps to instructions within the routine could use the addresses 0θ, 1θ, 2θ ... Wherever the programmer eventually decided to store the routine, the Initial Orders would adjust these addresses. Note that 0θ was the address of the start of the routine as set by the G K combination; unlike the next-instruction-address register, the value of θ did not change while instructions were being stored.

Local Workspace and Constants:

The Initial Orders occupied words 0 to 55 while the program tape was being read (their instructions were in words 4 to 38). Once the user’s program had started this area could be reused as working store. But as there was a risk that other routines might also use this space (as I found to my cost), it could be safer to provide space within the body of a routine for workspace and specific constants. Space for one long-word workspace could be reserved by including the two (short) instructions:

    Z 0 F
    Z 0 F

The first of these would need to be stored at an even-numbered address. (If, by some accident, the computer tried to obey an instruction at one of these locations before the program had set it, the Z 0 F would make the computer stop.)

Pseudo-orders:

As the Initial Orders could read only instructions in the format described earlier, any constant had to presented as a “pseudo-order”. Usually these looked like a P instruction as the letter P was equal to zero. In McCarthy’s program, for example (p. 16, line 125) he uses the pseudo-order P 0 D (equivalent to P 0 ΠF) to store the constant 2^-16.

If I were writing a program which needed to divide real numbers by 3, I might choose to store the constant 1/3 and multiply by that value, as multiplication was done by hardware, whereas division needed an iterative subroutine. The binary equivalent of 1/3 as a long word is:

    0.0101010101010101010101010101010101
    f.ffffbaaaaaaaaaaΠsfffffbaaaaaaaaaaΠ
    ------ ----------  ----- ----------
     Fn     Address     Fn     Address

The s-bit between the odd and even words is the “sandwich bit”. There was no way to make the Initial Orders store a 1 in it (so I was lucky in my example).

Converting from binary to decimal, each address

            10101010101
            AaaaaaaaaaΠ
            ----------

becomes 682Π, and the function-parts 00101 and 10101 become 5 (=T) and 21 (=H). So my program would have included the pair of pseudo-orders:

H 682 ΠF at an even address T 682 ΠF at the following odd address.

Control combinations:

The program tape would also include control combinations, which were instructions to the Initial Orders to guide their work, rather than instructions to be stored. Control combinations had the same format as instructions, but they ended with the letter K or Z. Some useful examples were:

Control combinations terminated by Z indicated that the current value of the θ-parameter should be added to the address. Thus E m Z would enter the program at relative address m of the last routine read.

Jerry McCarthy’s program example

Jerry McCarthy’s article (Resurrection 105) shows a program to print the values of the squares of the numbers from 1 to 255. In adapting it I have used instruction addresses relative to θ. In the notes:

a is the integer to be squared, stored at location 22θ within the routine; b is the loop counter, stored in the B-register.

To the multiplier it is the value of a.2^-16 that is stored, hence the need for two left-shifts. (A single L-instruction could not shift more than 13 places left, as McCarthy’s appendix explains.) I have assumed that his print subroutine:

needs the B-register to hold the link address (the subroutine will return with a jump back to address b+2); needs to find in Acc the value to be printed; is entered at address 0M; and does not clear Acc on exit (hence the need for instruction 18θ).

When this routine is read (earlier on the complete program tape) the value of the M-parameter would be set.

My version of the program ensures that a and b both start at 1, and it terminates before trying to square 256.

Assembly language:

One of the EDSAC’s major innovations was that an assembly language was provided by the Initial Orders, which were an essential part of the machine right from its 1949 start. Were the Initial Orders the very earliest assembler? I suspect this may be so; certainly, the choice of simplicity for programmers and the facilities for writing programs with parametric addresses deserve recognition.

Progress towards a PoS code system: The development of a Standard Product Numbering System, SPNS, by the UK grocery trade has taken another step forward with the decision by the SPNS steering group, set up by the Institute of Grocery Distribution, to follow the recommendations of the report into the feasibility of SPNS published last October. The report, produced by consultants McKinsey and Co, concluded that a numbering system could save the UK grocery trade about £12 million a year by 1981 if the product code adopted were used in conjunction with electronic scanners at the checkout. In addition to the steering group to formulate long term SPNS policy, the IGD has also set up a working party to supervise technical developments, and this will now take on new members to look into the problems involved with aspects such as printing codes on goods and changes required in packaging. (CW 427 9/1/1975 p1)

Glasgow police car system nearly ready: The computer controlled command system for police cars in Glasgow is due to go live in April, and training has now begun for 3,000 police officers and civilian aides. The system is based on two Argus 500 computers by Ferranti, and cost £500,000 to install. Terminals in police vehicles will communicate details about the location and current work of each vehicle to the headquarters, so that the controller, equipped with a VDU, can see their position and availability. When an incident occurs, a street map of the area can be displayed on the screen, together with information about the nearest police car. The system will also handle message switching between officers. Initially, information about constables on the beat will be added manually as they report in on pocket radios, but it is hoped that the next generation of radios, due in a couple of years, will have keying facilities for direct communication with the system. (CW 427 9/1/1975 p18)

PoS market bid by Sweda: With big hopes of securing a sizeable share of the still largely untapped European point-of-sale market, Litton Sweda has introduced a completely new PoS system, the 800/80, as a world-wide replacement for the 700 series. With powerful interactive capabilities, the 800/80 is aimed at the non-food sector of the PoS market. The 800/80 system is based on an in-store Data General 1200 minicomputer, designated the Model 80, working together with a Diablo disc memory which can be expanded from 2.5 to 10 Mbytes, to enable prices, tax rates and other information to be stored and accessed on-line by up to 128 terminals. Other on-line information could include files of account holders and alphabetic descriptions of products for printing on receipts. Each Model 800 terminal can operate either on-line or in standalone mode, and can interface with a variety of automatic product data capture devices including magnetic and optical hand-held wands. (CW 428 16/1/1975 p1)

Device to aid go/no-go monitoring: A device which has applications in large system environments where go/no-go monitoring is required has been developed by the special components department of Ferranti, at Oldham, Lancs. Known as the System Monitor Display Unit, the device was originally developed following an initial ICL requirement for serial monitoring equipment for its 2900 series. It is understood that ICL took about 10 development models of the new unit and will be ordering production models in the very near future. Valued at under £3,000, a unit can be provided with any type of connection to suit interface and drive circuitry. In ICL’s application, the monitor unit replaces up to 10,000 incandescent lamps used during the investigation and diagnosis of computer faults. Each unit contains a matrix of Light Emitting Diodes mounted on an X -Y addressed printed circuit board behind a polarised plastic screen. A 35mm film, back-projected onto the screen, can have a maximum of 64 frames giving a monitoring capacity of up to 37,000 checks. The LEDs give go/no-go indication of system components and sections. (CW 427 9/1/1975 p48)

Monolithic memory systems for 1900s: Logical progression has led Systems Reliability, of Luton, to introduce a range of monolithic memory systems for the ICL 1900 series. Having doubled the size of the Atlas, produced add-on units for GEC 900s, and sold 4.5 million bytes of store for ICL 4100 systems, it would have been surprising if the 1900s had not provided the next market. The new memory systems range in size from 16K to 64K 24-bit words, and will probably prove to be of most benefit to the lower end of the 1900 range. The systems contain their own power supplies and are offered fully systemised so that they can fit into existing configurations, rather than just being simple add-on units. However, the memories can be tested in isolation without interfering with the rest of the system. A typical 32K memory system can be housed in a standard 19-inch rack, seven inches high and 10 inches deep, and costs about £21,500. (CW 428 16/1/1975 p12)

InterScan handles Barclaycard task: Sales vouchers from shops and other outlets accepting Barclaycards provide the bulk of the source data now being captured for computer processing by three InterScan 2100 key-to-disc systems with a total of 76 VDU key-stations now installed at Barclaycard centres at Birmingham, Middlesbrough and Liverpool. A sales voucher is prepared each time a Barclaycard holder makes a purchase using his card, data from the voucher being required by Barclaycard to pay the shop and bill the holder. The InterScan systems will also be used to capture data from remittance forms sent in by card holders when they pay their bills. Each of the three InterScan systems has a 28K Alpha 16 processor, two 2.2 Megabyte discs and two 1,600 bpi tape drives. There are 31 VDUs at Birmingham, 26 at Middlesbrough and 19 at Liverpool. Middlesbrough handles remittances, Liverpool sales vouchers and Birmingham both. (CW 430 30/1/1975 p11)

Rockwell launches 8-bit micro system: An eight-bit microprocessor is now on offer for evaluation from Rockwell International, and two new European companies are to introduce minicomputers built around it. Designated the PPS-8, for parallel processing system, the microprocessor offers options for 12 different input-output controllers and a full complement of memories, and Rockwell identifies high throughput, ease of system configuration and low cost as key features. The PPS-8 includes a set of more than 90 instructions, with facilities to string instructions together into macro-instruc¬tions. The technology used is P-channel metal-gate MOS, used extensively by Rockwell in the manufacture of calculator chips and four-bit microprocessors. Depending on the configuration, up to 16 input-output channels are available with the PPS-8 without external coding. Among the dedicated LSI input-output controllers available are ones for printers, floppy discs, graphic displays, parallel and serial data controllers, CRT controllers, as well as a general purpose input-output device which provides 12 TTL inputs and 12 latched outputs. The system allows simultaneous peripherals control through the I/O controllers and data processing in the CPU. Memory circuits available include a 256-byte random access memory and 1K and 2K-byte read-only memories. (CW 431 6/2/1975 p6)

RCA’s latest laser beam: With so many potential applications for small, accurate and powerful optical scanner data capture devices, RCA in the US has developed a document reader using a one millionth cubic inch semiconductor diode generating a laser beam which can scan a 10 inch deep page in 14 seconds. The solid-state laser uses only one watt of power compared with the 10 watts consumed by an equivalent but bulkier glass enclosed gas laser. The aluminium gallium arsenide chip in the RCA device generates an astigmatic beam of near infrared light, about 8000 Angstroms. This is optically shaped to a near round cross section and scanned over the document being read in both horizontal and vertical planes by galvanometer driven mirrors. The light is reflected from the characters on the document onto an array of photo detectors which are linked to the reader’s character recognition system. (CW 432 13/2/1975 p28)

Fairchild high density memory: Claimed to represent a “significant advance in the density of solid-state memory”, a charge-coupled memory is to be put into large-scale production by Fairchild Camera and Instrument Corp in the US by autumn this year. Known as the CCD 450, the new unit is a IK byte serial storage element aimed at such memory applications as intelligent terminals, terminal buffers, VDU refresh mechanisms and electronic switching in data communications networks. According to Dr Thomas Longo, vice-president and general manager of Fairchild’s integrated circuits group, the CCD 450 is fabricated using a mix of the company’s NMOS and CCD technologies, and is as easy to use as any MOS memory. (CW 435 6/3/1975 p9)

PoS comes to the petrol pumps: Point-of-sale processing now looks like being extended to petrol service stations with the launching of an electronic pump system, the Avery-Hardoll Mark IV. This can be interfaced with digital data loggers and with data transmission modems linked to a remote computer, as part of an on-line PoS network. The Mark IV pump built by Avery-Hardoll of Havant, Hants, incorporates logic circuitry on LSI MOS chips supplied by Plessey. The logic is used to present the price and, if required, the volume of the grade of petrol selected by the customer using self-service buttons on the pump. More LSI logic is then used to multiply the amount of petrol drawn by the price to calculate the amount to be paid. This is shown on two 16-digit displays controlled by TTL logic which accepts binary coded digit signals from the LSI Logic. Up to eight pumps can be linked to serial interface located in the service station building, and via these to a range of equipment that can include a strip printer, a paper tape punch, a magnetic tape cassette unit, a data logging system or a modem. (CW 434 27/2/1975 p13)

Lamson replaces phone with Instagram: Many large companies faced with telephone and postal bills inflating at a terrifying rate could follow the lead of Lamson Paragon Industries which has now effectively scrapped telephone communications throughout its many divisions and replaced them with an ITT ADX 600-based teleprinter switching network called Instagram. The ITT ADX 600 is sited at Lamson’s Southwark, London, head office and is connected via 31 leased telephone lines to Telex machines located at Lamson offices and factories all over the country. The system incorporates an 8K Digital Equipment PDP-8 minicomputer and, as it stands, could handle up to 36 leased lines and 12 dial-up Telex lines, of which several of the latter could be linked to Lamson’s overseas offices. Lamson believes that in most instances the Instagram will be an adequate and often more efficient replacement for a telephone call. Last year Lamson spent nearly £150,000 on telephone calls and, without the Instagram system, this would almost certainly have exceeded the £200,000 mark this year. Instead, telephone costs this year should be no more than £50,000, plus the £57,000 annual cost of Instagram. (CW 435 6/3/1975 p40)

OCR data capture for £1,300: A complete OCR data capture system for as little as £1,300, something which would have been thought a ridiculous impossibility at one time, is now available and offered to a wide range of potential users by Senosa Ltd, which has successfully interfaced its Directdata 16 terminal with the Recognition Equipment hand-held OCR wand. The Directdata 16 comprises a portable shoulder bag magnetic tape data collection unit linked to a hand-held data entry keyboard. Data collected on cassette can be transmitted later to central location for processing. (CW 442 24/4/1975 p40)

Portable data capture unit from Plessey: With an enormous potential worldwide market in the retail, wholesale and distribution industries, the Plessey 1450 portable data capture unit, now announced, combines a light pen tag reader, a numeric keyboard and a magnetic tape cassette data recorder in a compact shoulder bag unit. This enables stock or order data to be captured quickly and accurately at source and transmitted to a remote mainframe computer for processing. In its development of the 1450, Plessey made use of experience gained from monitoring the effectiveness and acceptability of Plessey light pen source data capture units already in operation at many UK public libraries, and of mobile units used for some time at more than 200 of Sainsbury’s supermarkets for recording shelf stock data. (CW 437 20/3/1975 p32)

Tote orders in France, Spain: Two orders with a sporting flavour have been won by UK firms. Already a major supplier of totalisator equipment to French horse race tracks, Bell Punch, of Uxbridge, Middlesex, has won an £85,000 order for 50 self-service totalisator ticket machines. The machines, a new product from Bell Punch, will be installed at two tracks in Paris and one in Nice. They will be linked to Intertechnique Multi-8 and Multi-20 minicomputers at the tracks, which in turn communicate with a central IBM 360 in Paris. The minicomputers transmit the transactions taking place at the totalisator machines, at present all manually operated, to the 360, which calculates new odds and transmits them back to the track. The second order is for two totalisator systems, both comprising a General Automation SPC-16 minicomputer and ticket issuing machines designed and manufactured by Time Designs International of Hove, Sussex. (CW 436 13/3/1975 p1)

High speed system for chemists: A new distributive processing system enables German chemists to order from a range of 20,000 pharmaceutical products, and expect delivery within two hours. The system is based on 11 Honeywell 716 minicomputers linked to a Univac 90/60 at the Hamburg head office of Reichelt, the German pharmaceutical supplier. Each 716 is housed at a distribution centre at Reichelt’s warehouses throughout Germany, where clerks using Honeywell DET 77 VDUs are able to check on the immediate availability of goods and enter orders into the system. Order requests are made using a simple three or four letter code definition. The product file and its stock quantities are then indicated on the VDU allowing the clerk to act accordingly, and recommend an alternative product if need be. Once the customer’s transaction has been communicated to the Hamburg 90/60, invoices and picking instructions are produced and returned to the distribution centre. (CW 436 13/3/1975 p23)

Step ahead in brain surgery techniques: A new computer program which can assist a neurosurgeon in the operating room has been developed by engineering scientists at Toronto University, Canada. It is called Computerised Data Processing System for Stereotactic Neurosurgery. It involves the use of an automatically directed probe introduced in to the brain through a small hole in the skull. Modern telecommunications could enable surgeons working simultaneously thousands of miles from each other to rely on the same computer program. The idea was conceived by Dr Ian Rowe, associate professor in the university’s Department of Electrical Engineering, and developed in co-operation with Toronto General Hospital and the computer centre at the university. Dr R. Tasker, a neurosurgeon at Toronto General Hospital, uses this technique for the control of tremors and for the relief of pain. The problem, however, has been that the target site of the probe cannot be seen by the surgeon. Under local anaesthesia, the probe is advanced by small increments towards the tentative site. The surgeon determines its position in the brain by passing weak electrical pulses which elicit a response in the patient’s body. The site and nature of the response is related to the location of the probe. Since the probe may pass through 60 stimulation sites with up to five responses in each, the surgeon has to interpret and act upon a mass of data. Professor Rowe determined that this information could be taken from the operating room through a portable computer terminal. (CW 436 13/3/1975 p2)

Locus 16s for radar check: A system for evaluating the operation of plot extractors at radar stations has been developed by Marconi, using modules from its Locus 16 system. One such unit is to be supplied to the Civil Aviation Authority under a £75,000 contract. In the past, analogue signals from radar stations were fed by radio to the control centres where they were needed. This information is now increasingly being digitised by plot extractors at the radar station, and then transmitted over telephone lines. The purpose of the new equipment is to monitor and assess the integrity of the data transmitted from the new radar stations, of which there are two so far in operation. The equipment will assist in the recording, analysis and calibration of the data, when the new stations come into operation and thereafter will be used for periodic analysis of the received data stream to ensure that that quality of transmission does not deteriorate. An S3017 digital plan position display unit will be used with the Locus 16 system, to which will also be linked a variety of data logging devices. The display unit will present symbols for the primary, secondary and combined primary and secondary aircraft plots. (CW 437 20/3/1975 p3)

EMI-Scanner system for whole body: Following the worldwide success of the EMI-Scanner brain X-ray system, which has a current sales level of £25 million per annum, EMI is now to develop another computerised X-ray system for examination of all parts of the body. Although the system is still only at the prototype stage, with clinical trials scheduled for certain UK and overseas hospitals, it is most probable that the system to be marketed will be built around a Data General minicomputer. The new system is designed to provide highly-detailed pictures of such organs as lungs, pancreas and kidneys. In the Scanner system, information gathered during a medical examination is fed to a Data General 820 minicomputer which uses the 28,000 readings taken from each layer of the brain to calculate a picture. This is displayed on a CRT. (CW 439 3/4/1975 p7)

Checking on defence equipment: The performance of a variety of military equipment under development by the Ministry of Defence is to be assessed and recorded with the aid of specialised database management software now in the final stages of implementation. Known as the Reliability Data System, it was developed by Stephen Howe (Consultants) of New Malden, Surrey. The Ministry will use the software in the first instance on an ICL 1903 at one of its research and development establish¬ments. Details of the type of equipment to be monitored are not available, but Howe claims that the system, with small modifications, is applicable to any electronic or mechanical devices “from cars to computers”. (CW 441 17/4/1975 p10)

First supermarket PoS systems in UK: The first supermarket point-of-sale checkout systems in the UK have been ordered for installation at two hypermarkets set up by local retail co-operative societies in Lancashire. Both installations are to be based on NCR 255 systems. Research into the perform-ance and capabilities of various systems, and promised delivery dates, was carried out by the Co-operative Wholesale Society, which reported its find¬ings to the retail societies involved. In July the 60,000 square foot Selda Superstores at Failsworth, South East Lancashire is to install 20 NCR 255 terminals controlled by a 32K 726 minicomputer. This installation will be followed in October by a second at Widnes where the Warrington Co-operative Society is to open a 75,000 square foot store with 24 NCR 255 checkout points. This system will also be controlled by a 32K 726 processor. (CW 441 17/4/1975 p40)

Members and others are welcome to attend CCS Seminars and these are also available via Zoom.

London Seminar Programme

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

You should use the BCS event booking service to reserve a place at CCS London lectures. Go to www.computerconservationsociety.org/lecture.htm. The service must be used both for attendance in person and for remote attendance.

For queries about London meetings please contact the CCS meetings secretary Roger Johnson at meetingssec@computerconservationsociety.org.

Manchester Seminar Programme

Manchester meetings normally take place at The Manchester Metropolitan University, Chester Street, Manchester, M1 5GD – Room E0.05 in the John Dalton East Building starting at 18:00 (but see the description of specific lectures on the CCS website as building work is currently underway).

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

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.

The National Museum of Computing : See www.tnmoc.org/days-open for the 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//url 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 Totalisater, both of which were the subject of CCS projects in years past, and much else besides. Other galleries include displays ranging from ICT card-sorters to Cray supercomputers. Admission is free. See www.sciencemuseum.org.uk for more details.

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

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; The National Museum of Computing (TNMoC); and the Science and Industry Museum (SIM) in Manchester.

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

The aims of the CCS are:

• 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 and by the free use of the facilities of our founders. 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.