Elliott 803, 903 & 920M — Terry Froggatt

TNMoC 903

Peter Williamson reports several issues:

1. The fan tray has not yet been modified to avoid tripping the new circuit breakers.
2. He has been working on the expansion PSU which is not regulating the +6V (which was found after replacing the mains lead whilst on the bench). All the regulator transistors have been replaced but the problem persists. He’s taken many measurements comparing against the -6V supply. He plans to remove transistor VT1 and to see if the +6v supply switches off, then he’ll look at the feedback circuit. The references across D2 and D4 look OK.
3. He has still not got any further with the punch issue, except that it is electrical not mechanical. (Remember this Peter does have a day job).
4. Now that the weather has changed the old Q-register bit 10 reset pulse issue has returned, causing intermittent problems monitoring.
5. Finally, the teleprinter locked up, but this has been since fixed.

TNMoC 803

Peter Onion adds that the circuit breaker upgrades initially failed as they predictably tripped as soon as the “big red switch” was turned on. The breaker was changed so it doesn’t trip any more. He is unsure whether this is a permanent or temporary fix.

RAA/TNMoC 920M

I still have this at home, I test it occasionally, and it is OK.

Jaguar XX764

In recent issues of Resurrection, I’ve made mention of six more Elliott 920Ms. They are the property of Neil Atterbury, who also owns the Jaguar airframe XX764 (without engines) currently parked at Enstone airfield in Oxfordshire. Google ‘Jaguar XX764’ for plenty more information.

Way back in Resurrection 75 (Autumn 2016), I described how I’d OCRed the listing of the Jaguar flight program, written for the 920M in SIR assembly code. I’d had a hand in writing this code in around 1970. Buried in this listing are the input/output addresses needed to talk to the various bits of equipment in the Jaguar. And since 2019, Erik Baigar and I have reverse-engineered most of the 920M circuits. During 2025, I tested Neil’s six Elliott 920Ms, which ranged from ‘perfectly OK’ to ‘to blowing the fuses in my test rig’, and I wrote three new SIR programs to test Neil’s equipment in the Jaguar. Meanwhile Erik designed and built a portable interface to connect a modern laptop to the 920M in situ in the nose of the Jaguar.

All of this effort finally paid off, when Erik flew in from Munich one week in October. On the Monday afternoon, I showed Erik around Blenheim Palace grounds (free if you stick to public paths). On the Tuesday and Wednesday, Neil, Erik and I met up at Enstone, and we managed to make some pretty significant progress ‘waking up’ some elements of the Navigation and Weapon Aiming SubSystem (NAVWASS).

On the Tuesday, we concentrated on the 920M computers, the Navigation Control Units (NCUs) and Interface Units (IFUs), the basic set of parts required to get the system to work. We knew which 920Ms were good, and using one of my new programs we were able to test the (previously unknown) serviceability of Neil’s stock of IFUs and NCUs. And yes, much to everyone’s relief, we did find a working combination.

On the Wednesday, we ran the program that I’d written to simulate flying a circuit around Enstone, with the latitude and longitude appearing on the NCU. We were also able to see various switch inputs from some of the weapons controls panels using my third program. We had hoped to also see the Projected Map Display light up and possibly synchronise with the heading being generated by the 920M, but this proved a step too far this time. Possibly hardware issues, or maybe a software issue to which to return.

All in all, a very successful week, and definitely some potential to get additional components working. At the moment, Neil is not going to rush into firing up the Inertial Platform/Platform Electronics Unit/Waveform Generator/HUD, so there is still some work to do, but a lot of progress made on the core of the system.

Personally, I was delighted to see the NCU 7-segment displays light up again. It reminded me of a happy evening at Borehamwood in 1968, when Airborne Computing Division engineers Roger Strange & Howard Jones powered up their prototype NCU for the first time, and I wrote code on the spot to drive it. Some of those seven-segment displays were deliberately mounted upside down, but that’s a longer story.

EDSAC — Andrew Herbert

Little new to report on EDSAC – the team has taken a break over the festive period.

The focus remains Initial Orders, Paper Tape Reader and Arithmetic Unit.

Some progress has been made in each area.

• For Initial Orders we have identified a potential timing problem that may be leading to incorrect loading of the Initial Orders program. We have solved the problem of data corruption of the program in transit to the store from the uniselectors that act as the EDSAC “boot ROM”.

• We have finally solved the timing problems with paper tape reading. As ever it has been a problem with monostables. When reading from the mechanical reader a 100ms busy signal is required, but if implemented as one monostable, it cannot be reset in the gap between instructions. The solution, obvious once identified, was to use two monostables each holding up the signal for half the required interval. Thus when the second expires, the first will have reset and be ready for retriggering.

• On the Arithmetic Unit the working continues, checking the correct functioning of individual functions. These have been built and running for several years now, but not subject to detailed testing while the focus has been elsewhere in the machine. We are finding that where valves have aged some drift in timing (and failures) has occurred and so work has focussed on checking circuits in detail and improving level and timing margins on signals.

Over the holiday period Simon Porter and Tony Abbey have taken some of the circuits concerned with store addressing and operator controls home for rework and improvement and Martin Evans has been reviewing the Teleprinter circuits in the light of his experiences with the Paper Tape Reader.

Software — David Holdsworth

In November I reported “I have embarked on a project to document the software preservation material at sw-pres.computerconservationsociety.org/”. That is now ongoing, and in recent days has been going faster than hitherto. As part of this activity I have been moving away from using a demountable flash drive to hold a replica copy of the website, towards having the master chez moi and using a differential upload to populate the real website.

The webserver suffered an outage during the Christmas break caused by a fault on a flash drive which held the replica copy. The new approach allows that to be demounted and abandoned. Last year our house was upgraded to have fibre to the property. This produces a big (by a factor) increase in upload speed, which makes bulk updates entirely feasible.

Part of this consolidation exercise has involved revisiting the 1900 preservation, where we attached a Gnu licence (license) to the emulator code. I plan to take the same step with the software on sw-pres. comp... , now that it is no longer in use at Leeds University.

In revisiting the 1900 material, I discovered a cache of ICL1900 tape images that came from Hazel Campbell-Grant. I transferred a copy to Bill Gallagher who is checking them against his holdings from Brian Spoor.

ICL 2966 — Delwyn Holroyd

The 2966 display area has been re-arranged and tidied up to make room for a new exhibit. The area behind the tape decks which used to hide an assortment of spare parts has been cleared, tools and other parts have been relocated and the old desks removed. The tape decks are now in line with the processor cabinets. This leaves a reasonable sized area clear at the far end of the gallery.

When the Large Systems Gallery was re-carpeted a few years ago, most of the large exhibits and the carpet beneath them were left in place. Hence whenever something is moved it exposes the old carpet and inevitably huge pits where the wheels of the equipment have sunk into the floor. The floor under where the tape decks used to be has now been repaired and the old carpet replaced with tiles to match the rest of the gallery.

As for the new exhibit – watch this space!

Data Recovery — Delwyn Holroyd

Atlas tape deck in situ in the workshop at TNMoC.

TNMOC has recently acquired an original Ferranti Atlas tape deck. Based on the Ampex TM-2 one inch tape transport, the deck has a lot in common mechanically with the ICT 1301 TM-4 based decks. Unlike the latter which has tension arms, the TM-2 reel motor servos are controlled by the position of tape loops in the vacuum columns.

This particular deck is one of only two of the original sixteen known to survive from the Chilton Atlas installation. The other is in storage at the National Museums Collection Centre in Edinburgh alongside most of the computer cabinets. After decommissioning in 1973 our tape deck was donated to Liverpool University, where it was on display for many years. Then in 2002 it was acquired by Chris Burton of this society. In the intervening years Chris has made progress in re-commissioning it. This work will now continue at TNMOC with the aim of restoring it to full operation to allow tape data recovery.

Chilton Atlas tape decks as originally installed.

Readers may recall I have written about the data capture system I designed to recover data from ICT 1301 (Flossie) tapes. The system was designed with sixteen channels and the necessary bandwidth to handle Atlas one inch tapes, specifically with this tape deck in mind.

There are a number of Atlas tapes held at Manchester University which are thought to contain the renowned Atlas supervisor (in binary form) and various compilers, which we hope to read in due course. However we also obtained from Chris a tape thought to contain the otherwise lost source code for the Atlas supervisor. This would be a significant historical find if it proves to be case and the tape can be read successfully. The Atlas supervisor is considered to be the first computer operating system. It allowed multiple user jobs to be run concurrently to fully utilise the resources of the computer.

Bletchley Park Trust — Erica Munro

The last third of 2025 focussed on a number of high-profile public events, drawing new audiences to Bletchley Park, interpreting the wartime story in new ways and helping to broaden and improve our visitor offer. These included:

• 6 September: Misread Signals The launch of Dermot Turing’s latest book Misread Signals celebrating the remarkable and often overlooked contributions of women in World War Two codebreaking. Attendees enjoyed hearing from Dermot Turing about the lesser-known female codebreakers, as well as a book signing.
• 19 September: Heritage Open Days With 2025’s HODs theme of architecture, visitors to Bletchley Park enjoyed free access to talks by in-house historians David Kenyon and Tom Cheetham, “The Buildings of Bletchley Park”. These illustrated presentations explored the development of the site from the pre-war site to the blocks hastily constructed to house the ever-increasing number of wartime personnel.
• 27-28 September: 1940s Weekend The second of Bletchley Park’s hugely popular twice-yearly 1940s weekends took place in September, welcoming nearly 4,000 visitors over the two days, despite the unpredictable weather.
• 19 November: Film premiere: Breaking Enigma The world premiere of the feature-length film Breaking Enigma: A World War II Game Changer”, created by the US-based WWII Foundation took place at Bletchley Park. A Q&A with the Director and Videographer took place after the screening, and included a guest appearance by actors from HBO’s “Band of Brothers”.
• 4-30 December: A Codebreakers’ Christmas Visitors stepped into the festive spirit at Bletchley Park throughout December, with storytelling, interactive theatre, craft activities and our much-loved Grotto. This new approach for 2025, drawing more closely on the 1940s history of the site, and the kinds of wartime Christmas that might have been experienced by BP staff, proved extremely popular with adults and children alike.
• Awards: Bletchley Park received the Gold award for Large Visitor Attraction of the Year at Tourism South East’s Beautiful South Awards for Excellence in December 2025.

The Block E Learning Centre and Friendship Auditorium project was Highly Commended in September 2025’s Architect’s Journal Retrofit and Reuse Awards.

The IEEE has recognised the invention of Manchester code in 1948 as a Milestone technical achievement and the Milestone will be awarded at a ceremony at The University of Manchester on the afternoon of 13^th April 2026. There will be technical talks describing the invention and its impact as well as the formal handover of the Milestone plaque.

Manchester code was invented for the storage of data in the magnetic drum store of the Manchester Mark I computer. It became a standard for computer magnetic tapes and floppy disks, and was used in digital communications including the Voyager 1 and 2 spacecraft and early Ethernet networks. It found wide use in Radio Frequency Identification (RFID) tags, many control network standards and domestic remote controllers found in millions of homes across the world.

For more information about the event and to register please go to ccsoc.org/man0.htm.

In-person attendance is encouraged and is free of charge, however tickets are needed and obtainable via the link above.

The event will also be publicly live streamed (no advance booking required) at ccsoc.org/man1.htm.

101010101

Our good friend Barbara Ainsworth writes – I thought you might be interested in a series on YouTube that I have been involved with recently. It has been put together by Karl von Moller. He is working through early computer installations in Australia on his site State of Electronics (www.youtube.com/@StateofElectronics) – an example is CIRRUS built in the early 1960s in Adelaide www.youtube.com/watch?v=VGwcOXVAsU8. Karl has also interviewed electronic engineers.

And our ever-energetic colleague Dr Herbert Bruderer has recently published yet another volume on the history of computing and calculation Turning-Points-in-the-Analog-and-Digital-World.

We received a request from a researcher for a copy of the publication The Logica Way. After initially replying that he didn’t have one, our esteemed treasurer, Arthur Dransfield managed to locate one deep within his archive.

101010101

We have also received an enquiry seeking examination papers from the Institute of Data Processing Management Institute of Data Processing Management (IDPM) which merged with the BCS in 2013. Enquiries so far have not located any such material and it appears that the BCS has no copies either. Perhaps someone out there...... Contact the editor if you can help.

      A U T O C O D E R
      S
P L A S Y D
      E           U
      M     P L A N
A P D B           I
S     L     N     D A S S
M     E     S P A A
B   G R T   B     S
      S     L     S
			

Ok, enough silliness, but all of the words in the above were low-level tools for the generation of programs used by ICT/ICL on the 1900 Series.

What are assemblers?

They are programs that provide the simplest and lowest level way of coding for a machine. At the simplest level they all allow a one to one conversion between a human-understandable language and the binary instructions that the machine itself concerned uses. Whether it is 1900 machine, an IBM/360, a PDP/8 etc all of these had one or more assemblers, each providing what the creators of the assembler thought was needed. Some like say ASM.COM under CP/M were very simple, and the user coded a set of lines, each of which created one instruction. As time went on, these programs were enhanced and various features were added. These included the ability to create a linkable output file, that would then be used to create a program by including selected code from other assemblies or from libraries of routines. Another common feature that was added to later assembler from all manufacturers was the ability to use macros – common sequences of code could be defined once at the head of a source and then referenced multiple times to be expanded to generate longer, possibly tailored sequences. These features were typically only available on versions of the assembler for machines with larger stores or with access to magnetic data storage.

The question raised here is what were the 1900 assemblers? – I am hoping that readers can shed some light on. I’d guess that almost all 1900 hands will recognize PLAN, but what were the others, and what were they used for? What I can provide is summarised in the following :–

We have most of the above programs in various forms –

APDB	We have at least two versions, one of which has some dedicated support for coding 1904/5/9 bootstraps. These assemblers can assemble the Stevenage execs E1HS, E1DS and E3NG (inter alia). We have no ICT/ICL documentation for this program. The SPAA assembler was coded using APDB.
ASMB	(Not available.) Probably the earliest of this group, it is in a list of deletions in an update list dated 25.2.70.
DASS	Also declared deleted in 25.2.70, but still exists built-in to a number of 1900 hardware test programs. It is embedded to allow the engineer to add modifications to test programs by supplying a paper tape of changes to the test program and using the handkeys to start DASS running at *30000 or *40000 (octal addresses).
UNIDAS	Dated 12.4.67. This could be assumed to be a unified DASS. The programs identifying themselves as DASS are executive mode programs and are entered at either *40000 or *30000. Having been referred to the TPM programs manual, I am now aware that DASS is entered (if present) in a diagnostic at *30000 and UNIDASS at *40000 UNIDASS therefore requires a machine with over 16KW of store. – The West Gorton CPU test FLIT diagnostic programs that we have were likely coded using UNIDASS.
GIN/GINX	We have several versions of GINX and a range of GINs from GIN 5.02 to 5.24.5.24 is required to compile GEORGE 3 and GEORGE 4. There were versions of GIN below 5.0, we have no information on those except for this comment in the GIN 5 manual: I am not sure that GIN versions < 5 were ‘fun’.
GRT	There is a set of different GRTs, each used to build execs for specific ranges of West Gorton 1900 machines, they included: #GRT4 Building E4BM for 1904/5/9 #GRT5 Building E6RM for 1904/5/9 #GRT7 Building E6RM for 1904E upwards to 1906S. #GRTM Building EXG3 – George 3 execs (prior to use of GINX when the ‘New Interface’ executives were created. These GRTx programs took a common source tape (say E6RM Gen 54) and a control deck, either on paper tape or cards. These cards defined the exec by stating the store size and the types and attachments for the peripherals, as well as any executive options such as Floating Point, Trusted Programming etc. It would then create a bootable executive on seven or nine track magnetic tape. They could also be used in a batch mode creating a set of tapes ready to be shipped to customers. Again we have no ICT/ICL GRTx documentation at all, so one was created from disassembling #GRT5 and #GRT7.
NSBL	At least one version has been found and was used by Brian to create a limited set of exec overlays for E1DS. – Brian found it easier to use than the likely authentic #APDB.
PLAN	Widely used by customers (who likely never heard of the others) and internally to create compilers (Algol, FORTRAN, COBOL etc. ). Well documented and we have multiple versions of the program.
PLASD	A sort of halfway house between PLAN and a somewhat simplified Algol. #XEMC (Range COBOL) was at least partially written in PLASYD. Members of the ‘Compiler Team’ have provided us with excellent documentation, and I use PLASYD now in preference to PLAN for new programs. Originally created as PL1900 but apparently edicts were issued from on-high to change that and peace was restored with the new name.
SPAA	Used for DCP (Dedicated Control Program) coding and for the PF56 ‘bare metal’ diagnostics. The PF56 emulations would not have been possible without this assembler, as we needed to create test programs as it was being developed. This assembler was rekeyed from an APDB assembly listing as part of the PF56 project.
And, lastly
AUTOCODER	I have recently seen in a FORTRAN compiler manual for the root of the 1900 series, the Ferranti-Packard FP6000. That manual refers to FP6000 autocoder (sic) and provides an example of how to write autocoder subroutines and to call them from FORTRAN. The example they give has a certain familiarity... 3. Common Storage Areas 3.1 The FORTRAN statement COMMON /POOL/ I,X,A(4),LIST(5,2) integer variable   I     -   1 word real variable      X     -   2 words real array         A     -   8 words integer array      LIST  -  10 words The AUTOCODER directive #UPPER COMMON /POOL/ ITEM,RES(10),K1(5),K2(5),Y Intersegment Communication 1. This memo describes certain details of FORTRAN which must be known in order to write programs partly in FORTRAN and partly in AUTOCODER. Does anyone else see that as familiar?

I would be grateful for any feedback regarding this fascinating similarity to our beloved PLAN. ().

I have had an email providing some confirmation that AUTOCODER was what became PLAN. This of course, raises further questions: who first specced it out? where was AUTOCODER first developed? and by whom?

Full ACE

Full ACE, like MOSAIC was a four-address code machine, and had a clock rate of 1.5 MHz and minor cycle time of 32 microseconds, which is 50% faster than Pilot ACE or DEUCE. The major cycle was 1024 microseconds. It supported four magnetic drums and seven one-word delay lines, four two-word delay lines, five four-word delay lines and 24 32-word delay lines. A schematic is shown in figure 5.

Figure 5 – Full ACE schematic.

One design goal for full ACE was to eliminate the setup minor cycle allowing instructions to execute at a maximum rate of 32 per major cycle. The limited design documentation available does not explicitly confirm that this was done, but the overall description of operation implies that it was.

As with MOSAIC the next instruction field was five bits and the source addresses and destination address were each 6 bits long, thus full ACE could access fewer delay lines, but its delay lines were longer, 32 words as opposed to 16. The word length was 48 bits as opposed to 40.

It had functions which were split into eight groups each containing eight functions and therefore had no need for functional sources and destinations. There was an explicit function for modifying an instruction based on an address pair which could be a combination of W (Wait number) and various combinations of the three six bit addresses. W would have the effect of moving the minor cycle when transfers begin. There was also a forced discriminate instruction. The instruction word layout is shown in figure 6.

Figure 6 – Full ACE instruction word

The T (Timing) and W fields in the instruction ceased to be expressed relative to the first obey cycle of the instruction, but were expressed in terms of an absolute minor cycle. The wait number which was five bits long specified the minor cycle with which the transfer started and the timing number (T) of five bits identifying the minor cycle from which the next instruction was extracted. An additional field, the auxiliary timing number (J), was five bits and could be used by the programmer for counting, similar to the Joe bits with DEUCE. The characteristic offered four options:

• single, the transfer occurred in minor cycle W only,
• double, W and W+1,
• quadruple W, W+1, W+2 and W+3
• long started at W and continued until T.

Destination 58 was used to control all the input and output equipment. Only the source 1 and 2 fields were significant in a destination 58 instruction. These provided a possible 4096 (12 bit) possible orders, for example 56,0 --> 58 meant “Start card punch”. The machine had an 80-bit Input Dynamiciser and 80-bit Output Staticiser, divided into two sections of 48 and 32 bits and aligning with an 80-column card format.

The total multiplication time was 13 minor cycles, but the most significant half of the product needed to lie in the odd numbered minor cycle, the maximum rate at which consecutive multiplications could be performed was 14 minor cycles. This was significantly faster than the rest of the ACE family. Multiplication was accelerated by processing four multiplier bits at a time, shifting the partial product four places to the right instead of one and adding the appropriate multiple of the multiplicand at each step.

The divider contained a two-word store and a single word store. The former was two single word delay lines normally connected in series and stored the dividend before division, and at the end contained the quotient and remainder. The single word store housed the divisor. ACE implemented a non-restoring division process carried out for 49 cycles.

Punch card equipment included: the high-speed summariser (450 cpm 8mS per row), endwise card reader (600cpm, 1.1mS per column – normally used for decimal data – and a broadside card punch running at 100cpm (37ms per row) could be used for output. To accommodate working with 80 column cards, both the IDS and OPS were 80 bits wide.

The drum store had similarities with that of Pilot ACE and provided a total capacity of 32,768 words, with four drums, each with 256 tracks and 16 read heads and 16 write heads. The heads were moved as a single unit into one of 16 discrete positions. The head shifting time was expected to be 20-40ms. The drum’s hysteresis motor ran synchronously at 12,000 rpm and the drum rotated exactly once in five major cycles. Simultaneous read or write operations could be carried out, within specific rules and combinations of instruction. There was at least an ambition to provide magnetic tape.

Bendix G-15

The Bendix G-15 was designed by Harry Huskey and launched in 1956; about 400 were sold. It utilised version V of Turing’s architecture, which was a three-address approach. It used a drum as its main memory rather than mercury delay lines. The drum emulated twenty long lines of 108 words each and four short lines numbered 20 through 23, each holding four words and repeated so they could be read 27 times per drum revolution. Hence one revolution was the equivalent of a major cycle. Four more short lines were called registers and labelled ID, PN, MQ and AR; the first three holding two words, the last one holding one. The AR and PN registers were “accumulators” used for addition and subtraction. MQ, ID and PN were used in multiplication and division: MQ holding the multiplier or quotient, ID the multiplicand or denominator and PN held the product or numerator.

The G-15 design used 450 valves and 3000 germanium diodes. Single precision addition or subtraction took 0.54ms and the same operation using double precision 0.81. The corresponding times for multiplication and division were: single precision 2.43 to 16.7ms and double precision 2.43 to 33.1ms. The average access time for a word in a long line was 14.5ms, reducing to 0.54ms for a word in a short line.

Figure 7 – The Bendix G-15 instruction (command) word

When representing data, the sign was held in the least significant bit of the word, the remaining 28 bits being the binary number. Figure 7 shows the format of the G-15’s instruction word, known as a command.

Programs were written in decimal form and converted to binary form using the Program Preparation Routine which was supplied in a paper tape magazine. The 40 basic commands could be executed from the command lines, which are 0.... 5, 19 and short line 23 or the AR register. Commands were grouped as: arithmetic operations, information transfer, conditional transfer of control, command channel selection, extract operations and special commands. Once a command line was selected, all subsequent commands were taken from that command line until another channel was selected by a command or the operator.

The S (source) and D (destination) fields specified the channel, in the range 0-31, in which the operands were located and T was the position in the line. N represented the position in the line of the next instruction (analogous to W and T respectively in Pilot ACE). The operation to be executed was given by a combination of the C, D and S fields, often indicated by an S or D greater than 27. The use of registers ID, PN, MQ or AR was not explicitly coded but implied within the command.

Breakpoints could be set by setting bit 9 in an instruction word and enabled by setting the Compute switch, which had three positions to BP. To resume computation following a breakpoint, the operator set the switch first to “off”, then to BP and finally to GO.

Codes could be modified to use double precision numbers and multiword transfers. AR could not be used for double precision arithmetic because it was one word long. A multiword operation was specified in a single command, which applied to consecutive words on the drum. A block command was effective for the word in S or D numbered one greater than the word position of the block command itself and remained effective on every word up to but not including the word number in the T position of the command. Commands could be modified by adding to an instruction, using specialist codes for altering commands.

In multiplication one bit of the multiplier was processed every two-word times (the G-15 equivalent of two minor cycles), beginning with the most significant bit. The multiplication could be terminated once all the relevant bits had been processed, by placing a number in the T position of the command that is equal to twice the number of bits needed. In division one bit position was processed every two-word times. A double length product or quotient could be obtained from either single-length or double-length factors. In double-precision operation, register PN was used as the accumulator.

The machine supported higher level programming systems such as “Intercom 1000” and “Algol”, the former being interpretive and the latter, which followed the principles defined in the Algol specification, compiled. A wide range of peripheral devices were supported, for input: punch tape, punch card input and up to four magnetic tape decks could be used. Output could be done using a typewriter, paper tape punch or a card punch. A 100 line per minute lineprinter could be used. It was also possible to connect a graph plotter. A differential analyser could be fitted to enable the solutions of differential equations to be evaluated.

In Summary

ACE, DEUCE, MOSAIC and Full ACE belong to the same architectural family, but were implemented by different organisations. As a consequence, the documentation available places a stress on different aspects of the design making direct comparison more difficult.

DEUCE and Pilot ACE were both based on version V of Turing’s logical design and therefore were three address machines, with no instruction field, unlike MOSAIC (version VII) and Full ACE (version VIII) which were four address machines, with a separate function field and could therefore be programmed without recourse to functional sources and destinations. Pilot ACE, DEUCE and Full ACE implemented magnetic drum storage and DEUCE and Full ACE had a hardware divider.

As a commercial machine, DEUCE had a much bigger user community which stimulated development and generated a richer library of useable subroutines and more automated and higher-level program reproduction. NPL, RAE and English Electric produced the bulk of subroutines. Further, a number of programs were developed to provide translation from a high-level representation to object code. RAE developed a method that allowed DEUCE itself to allocate Wait and Timing numbers using the programmer’s specification of instruction flow and storage allocation. Other, application specific, approaches included Alphacode, the Alphacode Tabulator, GEORGE (General Order Generator), GIP (General Interpretive Programme) and TIP (Tabular Interpretive Programme). STAC – (Storage Allocation and Coding) extracted the source, destination and length of transfer information from the flow diagram and allocated the storage, wait and timing numbers required for optimum coding. An ALGOL compiler was delivered in 1962, as a vehicle for gaining experience of ALGOL in anticipation of the migration to a KDF9.

These trends were also evident when examining the Bendix G-15.

Further Reading

The following papers and documents provide more useful details on these machines:

Pilot ACE:

‘An assessment of the system of optimum coding used on the pilot automatic computing engine at the National Physical Laboratory’, J.H.Wilkinson, Proc.Roy.Soc.Volume A 248, pp.253-281, 1955.

DEUCE:

‘English Electric DEUCE Programming Manual’, 1956 www.ccsoc.org/ace0.htm.

MOSAIC:

‘The Development of the MOSAIC Computer’, E.A.Smith, Resurrection 101

Full ACE:

‘Some of the features of the ACE Computer’ F.K.Blake, D.O.Clayden, D.W.Davies L.J.Page and J.B.Stringer, 1957, available at: www.ccsoc.org/ace1.htm.

Bendix G-15

‘Coding Manual for the Bendix G-15 General Purpose Digital Computer’, 1960 www.ccsoc.org/ace2.htm..

In Resurrection 109 we learned that each process (Virtual machine or VM) had an address space 2³¹ bytes of local store and 2³¹ bytes of public (i.e. shared store). Today we are used to such largess, but in 1974 it was a revelation! This generosity had a profound effect on the way in which store was allocated and managed by the VME Loader.

In operating systems with which we were then familiar, there were two ways in which program loaders commonly operated. The first was that each process was given an address space in which to operate and when the job called for the execution of a program, it was copied into the address space overwriting any previous programs. The Unix way was completely different in that the operating system created a new, independent process with its own address space into which the program was copied. At the end of execution, this process was terminated and the resources recovered.

VME used neither of these strategies. It didn’t need to. With such an apparently huge amount of store available, VME took the view that when a new program was called for, then it could be loaded alongside any programs already in residence in the current process. Obviously this couldn’t continue indefinitely though. In Resurrection 107.htm we learned that the END statement of the System Control Language (SCL) released any resources claimed since the matching BEGIN. This included any store created within the SCL block and hence any programs which had been loaded.

A user’s program is typically composed of a main program and many subroutines. Compilers create an object code file for each one. Of course, there are some things which the compiler can’t know but loader has to know, notably the addresses of things. The addresses of subroutines for example not to mention the addresses of items of data and variables. Compounding this, the compilers can’t have any knowledge of items which are already present in the process and what addresses are therefore free to use. Again, in most (but not quite all) operating systems, there is a linker process which brings all the modules together allowing the unknown addresses to be filled in. But in VME, this still leaves us with the problem of what addresses are already taken.

VME addresses this conundrum by combining the functions of the linker into the loader. Typically, the job/user will call for the main program to be executed and VME makes a start by putting its name into a list of modules being sought. When the object code module is found, loader will examine the contents of the file and discover what subroutines it calls, these are then added to the list of modules being sought and the process continues until the list is empty. In due course we will consider the detail of what happens, but for now we can say that all main program and all its subroutines are loaded into store. This process is known as “cascade loading”. Cascade loading ensures that the programmer doesn’t need to know anything much about how source code maps onto executable store images nor need they have much knowledge of what subroutines are involved apart from the one being worked on.

Although VME lacks a conventional linker, there is a facility which does something similar – the “Collector”. The collector’s job is to amalgamate several small object code files into one big one in the interests of Loader performance. The crucial difference from a linker is that the input format and the output format are the same – “Object Module Format” (OMF).

So let’s see what OMF looks like and how it supports the objective of loading incomplete store images and resolving their unknowns. An OMF file is a simple serial file with three zones. We’ll start by examining the middle zone.

In the middle Zone lives the most important part – one or more (usually more) store images. Think of each image as a piece of Emmenthaler cheese – it has some holes in it. Holes for addresses that the compiler couldn’t have known because the compiler didn’t know what addresses would be available nor would it have details of the other modules with which it would be combined. In due course each image will be copied into store and the holes will be filled in, but not yet.

Now we can turn our attention to the first zone – the zone of red tape. But before we go there, we need to consider the way in which Loader operates. As soon as the initial module name is put on the list of names being sought, Loader swings into action and, with luck will find it in a file somewhere. I’ll skip over what “somewhere” means, we haven’t enough space today. Suffice to say that OMF files all live in libraries and that each process maintains a list of OMF libraries which are subject to loaders searches. Refer to Resurrection 108 for more information. Loader then reads all that red tape information in the first zone and in doing so it will often find the names of subroutines which are held in files we haven’t found yet. These are called “External References”. The external references are added to the list of modules being sought and Loader looks for these in turn. Rather recursive don’t you think? Note that, at this stage, the middle zone is not read. In practice the External References are satisfied in one of two ways. Either the name has already been loaded, in which case Loader will have a record of it, or Loader will find it in a file and the process recurses until the list of names being sought is empty.

Something I have omitted to tell you is that when a VM is created the record of modules which have been loaded is already present. Of course this is nonsense. Loader hasn’t loaded anything yet but its records say otherwise. The operating system comprises a huge number of subroutines. Some of these subroutines are callable by users’ programs and it is these names and the details of the subroutine such as its location which are falsified in the “already loaded” table. Thus a call to an operating system subroutine is much the same as a call to any other subroutine.

Once Loader has located all the files it needs it does some intense calculation. The red tape zone contains a description of each of the store images, in particular their lengths. Readers of Resurrection 109 will recall that store segments carry certain properties the most important of which is whether the segments holds instructions or data. The red tape information will also carry information which will tell Loader what type of store segment is needed. All this information is put together and Loader then decides what store images can be concatenated and allocated to a suitable segment.

Now, at long last, the data in the middle zone – the store images – are read and copied to their target locations. Readers will remember that the store images contain certain holes. Each hole is defined in the red tape – the hole’s location within each store image and what is supposed to go there. Loader now knows where everything is located in store and the holes can be filled in.

So now Loader’s work is done and the computer is all set up and ready to do what the user wanted it to do – execute the program.

But hang on. We said that there were three zones in an OMF file and we’ve only considered two of them. Well if everything goes to plan the third zone is not needed. It’s not even usually read. But suppose something goes wrong. Suppose our program does something silly like dividing by zero or violating an array bound check. The VM will tell us what the problem is and will start to tell us as much as it can about the state of the program at the point of failure. It will tell us what module it was executing, and the line number of the source statement which caused the fault. It will give us the value of each of the variables. Then it will do something even cleverer. It will tell us whence the faulty subroutine was called and again tell us about variable values. And so on until we work backwards to the main program.

This is possible because in the third section the compiler has recorded the mapping between source code line numbers and the location of the corresponding object code relative to the start of the module. Similar information about variables is also recorded. Combining this information with Loader’s information concerning what is where in store allows VME to be so helpful to the unfortunate programmer. But remember that the third zone only comes into play if something goes wrong.

My brilliant friend Gordon Jones was responsible for this wonderous piece of work together with Dave McVitie and Dave Sparks in around 1976. Please raise a glass to them if you are as impressed as I have been over nearly 50 years.

This has been a gallop through the mechanisms of Loader. There have been quite a few simplifications and omissions. But that’s the point. The conventional compile/link/load/execute cycle is a complex beast and, in VME, much of that complexity is hidden beneath the covers so that the user doesn’t need to know much at all.

There is, of course, much more to know if you put your mind to it and peer under the covers, but it’s not really necessary. Back in the day, this writer used to give a one-day seminar on VME Loader in which many more aspects were discussed. The thesis was that you didn’t need to know, but if you did, it opened the possibility of working with the grain rather than across it. And a little knowledge gave you the ability to do some rather sophisticated programming. The course handout ran to some 191 pages and the slides numbered 119. The seminar began at 10:00 and usually ended sometime after 16:00, though on one occasion I was still going at nearly 19:00 in the face of a slowly diminishing audience.

So you have got off lightly. Be grateful for that!

Simon Lavington, who died in October, was our most prolific writer on early British computing. His books included definitive accounts of the Manchester University computers, and early computer development at Ferranti and Elliott-Automation.

Simon was educated at Haileybury College and went on to study electrical engineering at Manchester University, graduating in 1962. He then pursued a PhD in automatic speech recognition. When the Department of Computer Science was established in 1965, he became a lecturer and was heavily involved in the MU5 computer project. In the early 1970s there was a growing interest in computer history and Simon became aware of Manchester University’s historic rôle. He established that the Manchester Baby computer had first worked on 21^st June 1948, making it the world’s first operational stored-program electronic computer. In 1975 he published the classic A History of Manchester Computers and in 1982, Early British Computers. In 1986 Simon became professor of computer science at the University of Essex. There he put his passion for computer history to one side in order to lead research on topics that included knowledge-based systems, databases, and video conferencing.

Simon retired at the end of the academic year in August 2002. Making up for lost time, he produced a flurry of books and articles on computer history. Simon was a stalwart of the Computer Conservation Society and established the Our Computer Heritage website which captured in digital form a substantial fraction of the technical literature of early British computers. In 2024 Simon’s contribution to computer history was recognised by the award of the Honorary Fellowship of The National Museum of Computing. His acceptance speech focused on the largely overlooked contribution of female programmers to the development of British computing. At the time of his death, he had identified some fifty women and was in the process of writing a book chronicling their achievements. One day someone will carry on where he left off.

IBM’s satellite communications plan develops: The intention of IBM to carve a niche for itself in the satellite communications business took another step forward on December 22^nd with the formation of a new company, Satellite Business Systems, SBS. The company is owned jointly by IBM, Comsat General and Aetna Life and Casualty, an insurance firm which joined the IBM-Comsat consortium in September. SBS has now filed applications with the US Federal Communications Commission seeking authorisation for the establishment of an all-digital domestic satellite system serving large industrial, government and commercial users. (CW 478 1/1/1976 p1)

ICL ready with packaged 2903: The new, smaller 2903, designated the 2903/20, is now expected to be announced by ICL this month. It will be a scaled-down, packaged version of the existing 2903 with a selling price of a little over £25,000 for a basic configuration. The machine will have a basic 16K of 24-bit words, 150 lpm printer, 300 cpm card reader, console, 10 million characters on disc and one or two local interactive VDUs. (CW 478 1/1/1976 p4)

NCC interface for EPSS tests delivered: The first of ICL’s interface units for the Post Office’s Experimental Packet Switched Service has been delivered to the NCC in Manchester. Known as the ICL NIFU, Network Inter Face Unit, the device is built around the ICL 7503 peripheral controller, which offers line printer, card reader and magnetic tape facilities. Successful packet exchange experiments were carried out during the summer using the NIFU and the product is being offered by ICL to all 1900, 2900 and System 4 users who intend to take part in the EPSS project. (CW 478 1/1/1976 p11)

CAI minis control petrol pumps: Self-Service filling stations run by the Arco Petrol Company on the West coast of the United States are now controlled by “Naked Minis” from Computer Automation. Each minicomputer monitors six petrol pumps and handles cash and credit card sales-transactions. The minis have special slots for credit cards and paper money. The machines are linked to a credit card control centre, where card numbers are automatically checked against a file of stolen cards and bad accounts. When the credit card checking is complete, the customer presses the appropriate button to select the required grade of fuel, and fills his tank. The Naked Mini then prints a receipt, which shows the date, time of day, amount of petrol bought, the type, the price per gallon and the pump number. If change is required it issues a credit note. Reg Hazelton, CA’s European marketing director for the Naked Mini, says the systems used by Arco could be a foretaste of things to come on this side of the Atlantic. (CW 480 15/1/1976 p26)

Network scheme for world trade: A packet-switching data transmissions network linking computers run by companies and authorities involved in international trade is one future development suggested in a report on the use of data processing and data communications in this area. This report has been produced by Leonard Griffiths and Associates and was commissioned by the government’s Simplification of International Trade Procedures Board, SITPRO. The packet switching is a long-term proposal but, although the report is described as a preliminary inquiry, the Leonard Griffiths team suggests that two recommendations, port-based cargo control systems and establishment of standard data formats for trade documents, be acted upon immediately. (CW 481 22/1/1976 p1)

Gap filled with cost-effective DEC system-20: The newest addition to the Digital Equipment product range, the DEC system-20, plugs a gap not only in DEC’s own product range but in the interactive transaction-oriented market as a whole. Priced from under £200,000 to over £400,000, the system is competitive with machines like the biggest ICL 2903, the Univac 90/30, the biggest IBM System 3 and the 370/115. However, DEC believes that the performance and capabilities of the system, particularly in applications with a heavy time-sharing transaction processing load, make it an extremely competitive rival for more expensive machines. At the top end a DEC system 20 can have 256K words of store, eight 100Mbyte disc drives, and eight tape drives. The 20 fills the gap between the largest PDP-11, the 11/70, and the large DEC system-10 with the new KL processor which directly addresses up to four million 36-bit words and competes with the largest 370/158. (CW 481 22/1/1976 p40)

Command system for Staffs police: An on-line real time command and control system is to be installed by Staffordshire police at the regional headquarters in Stafford. Based on Ferranti minicomputers the system will have three applications, command and control, message switching and management information. At its heart will be Argus 700S and Argus 700E minicomputers and peripherals will include 27 VDUs, teletypes and an interface to the force’s teleprinter network. The system is scheduled to come into operation early next year linked to the county council’s IBM 370/145. VDUs for Staffordshire and for Suffolk police systems are now being evaluated. Whatever unit is chosen, it will need a 2,000-character screen capacity and be Burroughs-compatible in order to access the B6700s at the Police National Computer Unit in Hendon. (CW 483 5/2/1976 p4)

World first claimed DRI: The UK based disc drive manufacturer, Data Recording Instruments, of Staines, Middlesex, has claimed a world first with the introduction of a 12 Megabyte front loading single disc unit. This is the 3212, part of the Series 3200. The Series 3200 comprises three models. The 3206 stores six Megabytes on one front loading disc and offers a 1.5 MHz data transfer rate. The 3208 is like the 3206. but is aimed specifically at users of DRI Series 30 drives, being controller compatible with them. The 12 Megabyte 3212 has a transfer rate of three MHz. DRI claims that the 3212 is the only front-loading single disc drive with a track density of 200 tracks per inch and a recording density of 4,400 bits per inch. (CW 483 5/2/1976 p28)

Table top drum plotter: A low-cost table top drum plotter, the Calcomp 836, will be introduced in the UK by Calcomp soon. The 836 takes over from the Calcomp 563 drum plotter, which has been sold by the company for the last 15 years. The 836 can interface on-line with any computer or minicomputer via the Calcomp 500 series interface and also can be driven offline by any Calcomp 900 series controller. The 836 measures 51 inches (130 cms) across, by 18.75 inches (48 cms) deep, and uses a quiet DC motor to drive the drum and carriage and a linear motor to move the pen mechanism. This draws at 1.97 inches (5 cms), per second, with an increment of 0.004 inches (0.1 mm). The pen can be a ballpoint, plastic tipped or liquid ink, as required. The 836, which will cost around £4,000 in the UK, can produce drawings up to 34 inches (86 cms), in width, and up to 120 feet (36 metres), long. (CW 484 12/2/1976 p7)

Low-cost main memory system from EMM: A main memory system, claimed to be over 60 percent cheaper than equivalent IBM kit, has been introduced by Electronic Memories and Magnetics, of Hawthorne, California. Designated the Multimemory 158, it is based on N channel MOS devices with 4Kbit capacity which EMM has used successfully in OEM and end user applications. These NMOS RAMs are manufactured by subsidiary EMM Semi, of Phoenix, Arizona. Modules are built up from the 4Kbit devices into units with a 16K byte bi-directional interface data path, with a 345 nanoseconds access time, a 460 nanosecond fast write time, a 920 Nanosecond write time and an 805 nanosecond fetch time. EMM can supply Multimemory systems for all versions of the 370/158 including the Model 3 and multiprocessor systems. The maximum size available is four Megabytes. (CW 485 19/2/1976 p7)

Euronet plan moves forward: The nine Common Market PTTs have agreed to go ahead with the development of the European data transmission network, Euronet. This should go live within two years, and by 1980, more than 1,000 terminal users all over the EEC will have access to about 20 computer databases via the packet switching network. The nine PTTs have formed a consortium to liaise with the EEC Commission in Brussels, which is funding the whole project. At the same time two sub-committees have been set up by the consortium, one to deal with the commercial problems of running Euronet, and one to supervise the planning, specification and implementation of the network. (CW 485 19/2/1976 p32)

Mainframe power with Prime 400: One of the fastest growing firms in the minicomputer business, Prime, has launched a supermini, the 400, claimed to be in the IBM 370/158 power bracket. The firm is now packaging its hardware and software into systems under the brand name, Tempus, identifying four market areas, timesharing, transaction processing, data acquisition and communications. The Prime 400 joins a line-up of super minis that includes the Digital Equipment PDP-11/70, the Data General Eclipse, the Interdata Megamini, and the General Automation16/440. Notable features of the Prime 400 include a main memory capacity of up to eight Megabytes. This can be segmented into virtual machine spaces of 64K words, each of which, in turn, can be divided into 1Kword, 2Kbyte, pages. Prime points out that this maximises the efficiency of the 2Kbyte 80 nanosecond cache memory on the 400. The single 2Kbyte cache is held in the CPU. This method contrasts with the technique of having a small cache on each memory module used in some other big minis. (CW 486 26/2/1976 p4)

Hand-held data collection unit from Muirhead: A handheld data collection unit which incorporates a semiconductor memory holding up to 64K characters of data has been launched in the UK by the computer systems division of Muirhead. Known as the Infopac data terminal, the unit complements the division’s other main product line, the Voicepac voice response order entry and inquiry system. The Infopac is the size of a hand calculator and competes with the portable data collection terminals now being marketed by MSI, Plessey, Senosa, Techmation and Senodean and has the advantage that there is no need for a shoulder bag to carry a cassette recorder. In fact. Muirhead has now stopped manufacturing its own Dace Datalink key to cassette unit in favour of Infopac, which is built in the US by Azur Data Inc. , Richland, Washington state. The Infopac unit comes with a 15-character LED display and a keyboard which includes keys for retrieving data already entered. The complete Infopac system comes with a compact desktop data transmission unit, into which the handheld unit slots, literally. Data can then be sent down the line to the remote computer centres at up to 120ch/s. No special receiver unit is needed at that end, says Muirhead. The basic Infopac unit is supplied with 4K characters of semiconductor memory and costs about £800. (CW 486 26/2/1976 p7)

Low-cost version of 4080 mini released by GEC: A low-cost version of the 4080 minicomputer has been announced by GEC. Designated the 4070, it gives 75% of the performance of the 4080 and is aimed at users who do not really need the 550 nanosecond memory cycle of the 4080. Another development on the 4070 is that the memory, which has an 800 nanosecond cycle time, can be extended from the standard 32K of 16-bit words up to 256K-words, which is twice the capacity on the 4080. The 4070 is fully compatible with the 4080, and the full range of 4080 peripherals, including magnetic tape, drum and disc storage, paper tape equipment, displays and printers are available with the 4070. (CW 487 4/3/1976 p3)

N-channel M0S RAM from Hitachi: The latest semiconductor manufacturer to introduce a 16Kbit N-Channel MOS RAM is Hitachi, and the Japanese firm has also launched a 1Kbit RAM based on the emitter coupled logic, ECL, bipolar technology. The 16Kbit NMOS RAM from Hitachi offers an access time of 200 nanoseconds. Hitachi does not quote write or fetch times, which would both be much longer than this. The refresh time is two microseconds. Hitachi follows several US semiconductor manufacturers with its 16Kbit NMOS RAM, and predicts that 16Kbit devices will be used in future computer systems in place of the existing and widely used 4Kbit devices. However, the yields rates for 16K bit devices, in general, are far from satisfactory. The 1K emitter coupled logic, ECL, bipolar RAM completes a range of bipolar memories from Hitachi, ranging from 64 bits to 1Kbits, in ECL and TTL, transistor-to-transistor logic. (CW 488 11/3/1976 p22)

World challenge to EMI brain scanner: Challenges to EMI’s near-monopoly of the X-ray brain scanner market have come from the US, Germany, France and Japan, as other companies try to cash in on this specialised market which has brought the UK firm £80 million worth of business in four years. EMI’s new competitors are Varian and General Electric from the US, Siemens from Germany, Hitachi from Japan and Compagnie Générale de Radiologie from France. Few details are available on the Japanese scanner, which is apparently still undergoing clinical trials, but the others work on the same general principles and cost roughly the same. The most serious challenge to EMI is likely to come from the two US companies on their home ground. Varian’s scanner incorporates the company’s V70 series minicomputer, and has already notched-up some prestige orders from the UK. (CW 488 11/3/1976 p47)

EPSS packet exchange: A major step towards the full operation of the Post Office’s Experimental Packet Switched Service was taken at the beginning of the month when packets were exchanged, via the switching exchange in Manchester, by the National Computing Centre and Manchester University Regional Computing Centre. The link was the first to be made using ICL 8790 network interface units, which are built around the 7503 processor. Both the NCC and the university are equipped with an 8790, and the NCC’s unit is to be enhanced by multiplexer facilities so that NCC members can hook on their mainframes and get a taste of the service. The link was made between the NCC’s ICL 1905F and the University’s system comprising a Control Data 7600 front ended by a 1906A. Packets passed through the Ferranti Argus 700 system installed at the Manchester packet switching exchange. (CW 489 18/3/1976 p4)

Paper tape facility to aid small systems designers: A reader/perforator combination, Model 1315C, which enables small systems designers to add paper tape facilities to their systems at low cost is available from Tally. The unit reads, perforates or duplicates six or eight track paper tape in either roll or fan-fold form and combines two of Tally’s paper tape devices within a single module measuring 19” x 10½”. The unit’s photoelectric reading head is capable of bi-directional reading speeds of 150chps in asynchronous mode or 300chps in synchronous mode. Maximum tape perforation speed is 30chps and the unit features an integral paper tape supply and take-up mechanism. Plug-compatible interfaces are available. The perforator takes up to 1,000 feet of roll or fan-fold paper tape and provides a fan-fold take up of 200 feet independent of the reader tape. (CW 489 18/3/1976 p33)

London tests of EPSS exchange: Following the successful exchange of packets over the Post Office Experimental Packet Switched Service by the National Computing Centre and Manchester University, the London exchange has been put through its paces by a number of users with different mainframes, network interfaces and terminals. Last week the exchange, equipped with seven Ferranti Argus 700 computers, handled the routing of packets between Queen Mary College, the National Physical Laboratory, the Computer Aided Design Centre, ICL and the Post Office. Network interfaces used included ICL’s 8790, specially developed for EPSS, and an Interdata minicomputer. EPSS is expected to be available in a limited capacity next month, with the linking of the exchanges in London, Manchester and Edinburgh taking place later in the year. (CW 490 25/3/1976 p40)

ICL gets its 2960 workhorse on the road: Some 12 months after it was originally scheduled to be released, the ICL 2960 has now been formally announced. Seen as a mid-range machine which will appeal to many existing ICL 1900 users, the 2960 has just over half the power of the 2970 and sells for upwards of £520,000. Key features of the medium-scale machine are a new highly adaptable operating system, VME/K, and a Schottky-TTL central processor which is more economical in terms of size, power-consumption, cost and heat generation than the faster emitter-coupled logic used on the 2970 and 2980. The 2960 is intended to be the workhorse of the 2900 range, and in effect slots into the gap left by IBM’s unannounced 370/148. In ICL 1900 terms, its throughput capacity is 2.5 times that of the 1904S, yet prices start at £10,000 below the base price for that model. Its speed, measured in Post Office work units on a particular job, is 1.15 times that of the1904S, twice as fast as the 1903T and three times as fast as the 2T or 3A. (CW 491 1/4/1976 p1)

Honeywell release may fill ICL gap: Coinciding with the release of ICL’s 2960, Honeywell has brought out a range of conversion software aimed squarely at the large gap in the ICL New Range below the latest machine. The products provide substantially automatic ICL 1900 to Honeywell Level 66 conversion for Cobol, Fortran and assembly language programs and data files. They are aimed, says Honeywell, at ‘the medium-scale ICL 1903/1904 bracket customer, looking to change within a two-year period’. A Honeywell spokesman confirmed that the ICL ‘gap’ was one of the chief reasons for pitching the attack on its rival at this level. Outside sources, however, are rather less confident. The 2960, they contend, could prove an attractive upgrade to these very users, and with the almost certain prospect of a 2950 release later this year. Honeywell has perhaps aimed a little high. Nevertheless, with or without the gap, the conversion programs will undoubtedly improve the competitive position of the Honeywell Series 60 machines over the 1900 and 2900 series. (CW 491 1/4/1976 p10)

DEC dual machine launched: The dual processor DEC system expected from Digital Equipment has now been unveiled in the US. Called the DEC system 1088, it features two powerful KL-10 processors, high capacity disc storage and an operating system called Galaxy which offers both batch and time-sharing facilities. Digital Equipment says that an existing DEC system 1080 with one 36-bit KL-10 processor, can be field upgraded to a 1088 in a few hours, by adding a second KL-10 and changing the software. Disc storage for the 1088 takes the form of the RP06 disc sub¬system, announced with the 1088. Each RP06 drive holds 176 Megabytes, and up to 32 of them can be hung onto one system, giving a maximum capacity of about 5,600 Megabytes. Digital says that the RP06 offers twice the storage capacity per spindle as its existing drives, with only a 30 per cent increase in price. It is claimed that the 1088 is comparable in power with the IBM370/158, some Univac 1100 machines, the CDC Cyber 72 and 73 and the Burroughs 6700. The 1088 comes with a PDP-11/40 as a front-end console and diagnostics supervisor. A basic DEC system 1088 configuration includes dual 256K word processors, 176 Megabytes of disc storage, 16 tape drives, a 1200 lpm printer and costs around £600,000. (CW 492 8/4/1976 p32)

Intel ready with ‘chip’ computer: The ‘computer on a chip’ will come a significant step nearer in the summer when Intel launches its new 8048 device, which incorporates active and passive memory on the same chip as the processor itself. The 8048 will not be available before September at the earliest, but Intel sees it as the most important development in the microprocessor industry since the introduction of the Intel 8080 eight-bit microprocessor chip itself. Few details of the device are yet available, not least because its exact characteristics have yet to be settled. However, it is known that as well as the processor, the single chip will include 1K-bytes of programmable read only memory, 64 bytes of random access memory, a clock powered by an external crystal, one level of interrupt and 27 input-output ports. (CW 494 22/4/1976 p1)

Navy installs voice system at charts HQ: To digitise feature information of navigational charts, the office of the Hydrographer of the Royal Navy at Taunton, Somerset, has installed an EMI-Threshold Voice Information Processor 100 system. Interfaced to a Ferranti Freescan digitiser at Taunton, the VIP 100 voice recognition system is the third to be ordered by the Ministry of Defence. Data not recorded automatically by the Ferranti system is entered verbally via the VIP 100 machine. Digitising of co-ordinates using the cursor position of the Fresscan combined with such features as depth measurements spoken into the VIP microphone, fully automate the entry of chart data at Taunton. The VIP 100 system, announced 16 months ago, is built around a Data General Nova 1200 minicomputer with 8K core and a “black box” unit, otherwise known as the speech preprocessor. In addition, the equipment consists of a directional noise cancelling micro¬phone, single-line alphanumeric display and teletype. (CW 495 29/4/1976 p3)

Canadian system to clear imports: While HM Customs in the UK is still evaluating an online terminal system for import clearance at seaports, the Canadian Customs and Excise Authority has an online system for clearing imports at all seaports, airports and points of entry in Canada running live. CEPACS, Customs Entry Processing and Cargo System is based on dual Honeywell 600K machines at Montreal linked to terminals all over Canada. About 450 will eventually be connected on-line. Development of the network was aided by the consultancy, SPL International, which says it provided a critique of the overall design and made detailed assessment of software strategy for system. The UK firm is now monitoring the further development of the import processing operation which SPL describes as time-critical, transaction real time application. The only comparable system in the UK is the London Airport Cargo EDP Scheme LACES, although this is restricted to handling imports at Heathrow. (CW 495 29/4/1976 p32)

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 .

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 opening hours schedule. Situated on the Bletchley Park campus, TNMoC covers the development of computing from the “rebuilt” Turing Bombe and Colossus codebreaking machines 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 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 www.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.