EDSAC Replica — Andrew Herbert

The increment in chassis count since the last report is, of 142 total to be built:

Good progress continues to be made, but as might be expected commissioning is showing up a number of systems integration issues that need to be addressed.

There remain concerns over the ability of the clock/digit pulse system to deliver large and sharp enough pulses for all the sub-systems that depend on them. There have been further adjustments to the clock pulse generator and it is hoped this provides adequate pulses. It is unclear from the surviving documentation how much reshaping of the clock was done locally versus relying on the clock pulse generator and distributors to send strong “perfect” pulses.

Following problems detected in use of chassis 01 storage regeneration units, Les Ferguy, Peter Haworth and Don Kesterton have introduced a revised test plan. All 42 units are being re-checked. Presently the 16 units in the front row are satisfactory. Another four which are also working are in the store addressing, sequence control and arithmetic sub-systems.

James Barr and Tom Toth continue to commission order decoding. The order decoding system is presently capable of reading an order from a set of test switches serially into the order tank and then generating control inputs to main control for approximately half of the machine’s order code.

John Pratt has demonstrated the counter working in the store access/coincidence system including the counter delay line — similar circuits are used in the sequence control and transfer sub-systems, so we have confidence these will work when required.

Tom Toth is developing a programmable delay line simulator to enable a delay line to be set up with known content to facilitate testing of delay line store reading.

Nigel Bennée continues with constructing and commissioning of the arithmetic system, anticipating delivery to TNMoC when order decoding and main control are sufficiently commissioned.

Chris Burton (right) has delivered a working display unit to TNMoC. This is now being used to display waveforms from the coincidence system counter.

John Sanderson is designing the electronic circuits for the initial instruction loading unit and engineers’ switches.

Martin Evans has a provisional design of the circuits for the I/O system (tape reader, teleprinter) based on Bill Purvis’ logical design.

The next anticipated steps are:

1. Complete order decoding
2. Commission basic machine control
3. Move arithmetic system from Cambridge to TNMoC
4. Demonstrate execution of “Load Multiplier” (H) order to verify order decoding, main control and arithmetic sub-system data paths
5. Demonstrate reading and execute orders from store.

The target for completing this list is late spring, early summer.

Ferranti Argus (Blodhound) — Peter Harry

I extend an invitation to all CCS members to visit our Argus 700 on 24th September 2016. This date is somewhat in the future but the winter months are excluded as the Bloodhound simulator, with its Argus 700, is located in an unheated hanger on the airfield at RAF Cosford. RAF Cosford is located just off the M54 between Telford and Wolverhampton. The visit would include demonstrations of the Bloodhound simulator, a short talk on the challenges faced in restoring the Argus 700 and a second, stand-alone Argus 700, on which a number of software utilities can be demonstrated. For an overview of the complete restoration work being carried out by the Bloodhound Group see: www.bmpg.org.uk.

Harwell Dekatron/WITCH — Delwyn Holroyd

It is just over three years since the reboot event in November 2012, and the machine has been in use almost daily since then. In the early days we didn’t know how reliable it would prove to be. We’re now in a better position to make a longer term forecast on the likely future maintenance requirements.

The Dekatron is a remarkably reliable device. When the HDC was constructed it was brand new technology with unknown longevity. I think we can now be confident the Dekatrons will outlast most of the rest of the electronics and indeed the present restoration team! The only significant issue is ‘stickiness’ brought on by the glow being left on the same cathode for long periods, but this can be cured by spinning for some hours. We continue to periodically spin all the stores to keep the problem in check.

The most frequent problem by far is the failure of the 1M wire-wound store anode resistors. It now seems inevitable these will continue to expire at a low rate. Thankfully they are simple to replace, and we encase the modern resistors in heat shrink to preserve the look and character of the electronics.

Other passive components fail very infrequently. The machine was out of action for a few days in December due to a failed capacitor in the pulse generator, but this was the first such failure since the reboot.

The valves are also reliable for the most part. The only replacements needed have been in the power supply, where some of the valves are being operated at the limit of their specifications. All the valves used in the machine are still available new-old-stock, and we have large stocks of most types.

The high speed trigger tubes will be the biggest problem in the future. Not only do they have a limited life, but we have found that most of the available new-old-stock parts do not work at all due to leakage of the gas mixture. There is no exact equivalent part that could be used.

Possible future options include looking at re-manufacturing or re-gassing, substitution with a different type of trigger tube (requiring circuit modifications), or a solid-state replacement.

The relay side of the machine doesn’t cause very much trouble —unsurprising since the Post Office relays used were designed for many decades of operation in the much harsher environment of a telephone exchange. The biggest problem going into the future will be finding people who know how to adjust them correctly (a job that is more difficult than it sounds).

With the present level of use (essentially program loading only), the tape readers are unlikely to experience significant wear. The ‘oily’ mechanical parts of the machine (printer and reperforator) are not used on a regular basis, but would probably benefit from more frequent use to prevent things gumming up.

Elliott 803/903 — Terry Froggatt

903 high-speed paper tape punch.

In Resurrection 72, I reported that I’d fixed the least-significant track of the 903 punch, by replacing a blown 25Ω resistor underneath the punch, only then to find that the previously working most significant track was off (although its resistor was OK).

So in December I took my own PTS cards to TNMoC to check that it wasn’t, for example, a newly-blown drive transistor. It wasn’t. Then I took off the backplate, which covers the 10 resistors at the back of the PTS power supplies, and put my voltmeter across each resistor in turn, with a program generating output on the punch.

All 9 punch resistors showed a voltage which fluctuated as characters were punched, meaning that there must be current flowing through all 9 solenoid circuits. So I’m not sure why I could feel nothing on the most-significant armature.

Possibilities included:

1. A short from this circuit to ground or to another circuit,
2. this solenoid’s springs need to be adjusted,
3. the resistor(s) underneath the punch should be removed because they duplicate those inside the 903.

The odd thing is that this track was working before, with the spurious resistors and current spring settings. So I visited TNMoC again in February, and tried shorting out the resistor then adjusting the springs, all to no avail.

But then, after some time repeating various checks, the faulty track came back to life, for no obvious reason. The most likely explanation would be an intermittent short to ground inside the circular signal plug on the back of the punch, which I’d had to disconnect & reconnect repeatedly.

In fact too many holes were now being punched in the most-significant track, until I removed the shorting wire from the resistor. This suggests that the solenoid springs have been adjusted to compensate for the spurious resistors.

903 Software.

Regarding the OCR of my 300-page 920M flight program listing, 180 pages have been scanned as half-pages and reunited, I’ve corrected the OCR errors in 150 of these pages to the point where I can assemble them with SIR, and I’ve double-checked the comments in 130 of these.

In Resurrection 71, I asked for help identifying a tape marked “SIR SYS VIA”. Thanks to CCS member Richard Burwood, the peripheral used by this program has been identified as most likely to be an Elliott Series 20 Display, although its light pen is not used.

Our Computer Heritage — Simon Lavington & Rod Brown

Many CCS colleagues, and especially those who contribute to the Our Computer Heritage project, have accumulated old documents such as technical manuals. These documents are now being assembled, catalogued and the artefacts themselves sent to permanent archives for safe keeping. We have nearly completed the cataloguing process. The results can be accessed here: www.ourcomputerheritage.org/OCH_catalogue_home_page_V5.pdf

Most of this archival collection relates to British-designed stored-program computers that came to market in the period 1951 - 1965. It therefore supports the OCH website’s Mainframes section. In total, there are 1,821 items in the archive, contained in 124 box-files. Each item might be single piece of information (letter, photo, newspaper article, etc.) or a larger piece (technical manual, company annual report, program listing, reel of magnetic tape, etc.) or a coherent group of artefacts (for example a folder of correspondence, an album of photographs).

The OCH on-line catalogue entry for each item has four fields:

              <box ID> date> <title> <description/comments>.
    

The total word-count per entry varies considerably, depending upon the knowledge of the cataloguer and the perceived historical significance of the item. In principle there is scope for experts to add to the comments field in the future, though some sort of editorial moderation is needed. In this respect, the catalogue information is no different from the existing OCH web-based content and end-user comments are welcomed.

In the context of the OCH on-line content, the coverage of the 1,821 items in the catalogue has been found to be uneven. For example, over half of the 1,821 items are specific to Elliott computers and their associated company histories. On the other hand, the archive contains useful material on computers such as the MV 950 and AEI 1010 that have not yet been written up on the OCH Mainframes pages.

Speaking personally, completing the on-line catalogue will be my OCH swansong. Within a few months I will be stepping down from leading the CCS’s Our Computer Heritage project. I’ve looked after it since 2003 and now feel that it’s time for a new face. The emphasis of the project has been to describe, in a user-friendly way, the early, commercially-available, British-designed computers. This work will continue, with the OCH web management ably undertaken by Rod Brown. David Bew will continue to look after the OCH Minicomputers section. But for me, it will soon be “So long, and thanks for all the fish”.

Software — David Holdsworth

Leo III — Intercode and Master Routine

Mike Tyzak’s hunt for Leo III mag tapes has so far found 11 tapes, 8 in Scotland, 2 in England and 1 in Australia. A further Leo tape may either be for Leo III or for an earlier machine.

The Scottish tapes are all in the National Museum of Scotland where there is a collection of Leo III hardware. I think that I should arrange to visit them to discuss the prospect of using some of their equipment to read these tapes.

KDF9 — Kidsgrove Algol Compiler (a.k.a. Kalgol)

We are disappointed to discover that we do not have all of the software environment within which the compiler operated, and it would appear that some of the overlaid sections (known as “bricks”) are missing.

It was also a disappointment that Terry Froggatt’s OCR program for lineprinter output was not accurate enough to eliminate copy-typing, but it was sufficiently successful to combine with one copy-typed copy, thus eliminating half the drudgery. Many thanks to Terry for this.

We have processed the OCR output by collecting a list of common misreads and then automatically substituting the correct code. We then produce one copy by proof-reading this and putting it through our Usercode assembler. David Huxtable (one of Kalgol’s authors) has been invaluable, both with recollections and with processing the OCRed code. Volunteers are also copy-typing pages which are then compared with the proof-read version. This activity is only just beginning. Meanwhile David Huxtable has produced proof read versions of the whole lot.

The source code contains a couple of features of Usercode that do not appear in the manual — Z-stores and H-stores. We think that we have dealt with these correctly (adequately), but time will tell.

It has always been my policy to develop assembly and execution early on, to tease out problems like the Z- and H-stores and to give confidence that it will ultimately work.

The compiler consists of a series of passes known as bricks which are overlaid above a piece of resident code that contains routines for manipulating the magnetic tapes upon one of which the Algol source code was to be found. The other tapes were used as workspace, and the resulting binary program was output to tape. Although we have the code of this permanently resident code (KAB00), we do not have the overlay that initialises its operation (KAB80); There are 147 comments in 1257 lines of code, and in KDF9 Usercode you typically have 3 or 4 instructions on a line. The API to KAB00 is in terms of a number of channels, and we are experimenting with reverse engineering this API by attempting to run brick 01 (KAB01), and producing minimal implementations of API calls as they arise. We have got brick 01 to accept:

        begin integer i; i:=read(20); end
    

but a more ambitious program containing a for statement was wrongly rejected suggesting that our copy-typing exercise is likely to find typographical errors.

Perhaps the biggest disappointment is the omission of one brick from the set, brick 20 which does procedure classification and computes the call matrix. It may just be possible to implement a substitute. Otherwise we shall only be able to run the first two passes. The Usercode compiler (brick 84, KAB84) is also missing, and Kalgol compiles into Usercode. If we get that far, we can use our own Usercode assembler — some loss of authenticity, but still an attractive prospect.

Our current expectation is that it will be possible to implement the “channels” of the KAB00 API by simple files rather than trying to make the official resident KAB00 drive simulated magnetic tapes. Rather than attempting to substitute for the missing KAB80, we would prefer to put effort into the missing brick 20 (KAB20) which is part of the Algol compilation process. Having David Huxtable on board is a tremendous asset and may make this possible. Our focus is on the optimising compiler for Algol 60 which broke new ground rather the magnetic tape based file management system (POST) within which the compiler operated.

kdf9.settle.dtdns.net/KDF9/kalgol/DavidHo/readme.htm is a readme file that shows some evidence of success (partial).

KDF9 Documentation

The KDF9 Algol Users Manual and the KDF9 Service Routine Library Manual have both been very useful. Sadly we only know of one copy of each and are therefore reluctant to entrust them to a sheet-feed scanner. It would be good to know of duplicate copies that could be used to produce photocopies of any scanner casualties. Note: The KDF9 Algol Users Manual describes the compilers and is very different from the KDF9 Algol Programming Manual which several people own in its A5 cheapie format. The title page of the A4 manuals bears the footnote “price: three guineas”.

ICL 2966 — Delwyn Holroyd

We have completed another tape data recovery operation, this time consisting of PDP-11 software written in the 1970s. We are making good progress with the demonstration EDS200 drive.

More fault-finding was attempted on the intermittently problematic 7181 power supply, but once again it started working before the problem could be located. Some solder joints in the likely area were re-flowed but this hasn’t cured it.

We are still looking for more volunteers to expand the team and allow regular operation on Sundays.

ICT 1900 — Delwyn Holroyd, Brian Spoor & Bill Gallagher

This winter one of the major tasks planned is to catalogue the software and documentation we have. Unlike some of the other projects, we have such a plethora of riches that we are in danger of losing track of what we have.

We have found copies of the Multiplexor Housekeeping (v.1 and v.2) libraries, but not the associated macro packs. Brian has managed to recreate a working macro pack for v.1 and a slightly suspect macro pack for v.2. If anybody has an old listing or more information it would be appreciated. Test programs have been written to use both of these libraries.

On the same tape that contained the Multiplexor Housekeeping (v.1) library, we also found an Interrogating Typewriter Housekeeping library, put aside for further investigation. We are trying to get as much of this old software working as possible with new demonstration programs.

Also on that tape is a set of utility programs for the ICT 1956 Data Disc (*DD or *DS - type 8 device). This early fixed disc unit had a storage capacity of 31.5 million characters, with a maximum of 126 million characters (4 units on the controller). In programming terms it was totally different to other ICT disc types (EDS, FDS under BDAS or UDAS). We believe it to be made by Data Products and it had 60 words (24-bit) per sector, with records (and logical buckets) apparently spanning multiple sectors. If anybody has any further information, we would love to know more than we have found by looking at the utility programs’ code.

Bill has been making advances on the E4BM front. The binary E4BM for a 1905 at Putney Bridge House that we have has been reverse engineered to source and can be generated to produce an identical binary. A working version can also be generated with certain features/peripherals not included, although more work is needed. He has also progressed the attempt to write a 196x drum (*DR) package based on the E6RM code, this has also been extended to a skeleton version for the 1956 Data Disc so that we can try and run the utility programs found. This work will also allow us to have different configurations running on the 1905 emulator.

A packaged version of the 1904S emulator (beta test) has been created and is available on request. There is still quite a bit of ‘tidying’ work to be completed before an issue version is possible. The latest addition to the emulator is a 7020 Remote Job Entry terminal, successfully connecting to an emulated uniplexor+7010 or multiplexor channel+7010 terminal and working with both GEORGE 2 (via #XKVB) and GEORGE 3 to allow full remote job entry facilities. Console input is, as is becoming almost normal, proving to be awkward.

The PF56 (2814 disc controller/7903 communications processor) emulation is working in that original DCPs can be loaded and run to a certain extent. Further work is required on both the 1900, 7930 (scanner) and disc link modules, more information is required. The console input and paper tape reader are proving particularly difficult to implement.

Nothing further has been done with Maximop since creating a patch that allowed it to work on the 2966 under MPOE last year. Further work on recreating the source and a ‘proper’ issue tape is planned when it can be slotted in.

Some work has been carried out on bringing GEORGE 2+DOF/1T back to life. This was a custom version for Tarmac when they replaced their 1903A with a pair of 2950s at head office in Wolverhampton, later upgraded to a 2966 which is currently at TNMoC. Brian was part of the project team. The project was abandoned (cost overrun) just as it was reaching completion, but it looks as if there was a bit more work after Brian moved on from the team. If anybody has any information on how Tarmac actually used it, please let us know. It would be nice to have this working as an alternative system that could be run on the 2966.

IBM Group — Peter Short

Electromatic Typewriter

One of our curators has managed to find an Electromatic typewriter in the U.S., and it is on its way. Electromatic was acquired by IBM in 1933, forming the beginnings of the company’s typewriter business.

3179

We are also hoping to obtain a 3179 colour display terminal soon. This was the replacement for the 3279 Hursley-developed colour terminal. The overall product was designed in Fujisawa, although the monitor development was sub-contracted to Hursley.

Other

We have also continued to receive a number of other donations, including a PS/2 Model 55, Lexmark printer, flat screen monitors, PC adapters and accessories, PC and PS/2 Technical Reference manuals and more.

IBM 3179	Electromatic Typewriter

Now that our tenure at the London Science Museum is at an end, London meetings are now held at the BCS in Southampton Street. What we had failed to appreciate until after Resurrection 72 had gone to the printers is that the BCS runs a booking system for meetings at its London headquarters and has to keep a record of everybody who is on the premises. We strongly advise anybody who wants to attend our London meetings to book in advance. This can be accomplished online by going to www.computerconservationsociety.org/lecture.htm and following the “book link” (as above) for the meeting you want to attend.

However, it is not essential to book in advance. You can just turn up and book on the day. But the process is likely to be moderately time-consuming and if 30 people all try to register at once... Please also note that, in the event that the event is oversubscribed priority will be given to early bookers.

101010101

We have relocated our set of emulators from www.cs.man.ac.uk/CCS/Archive/ to www.computerconservationsociety.org/software/software-index.htm and made a few additions to it. Associated software can be found here too. Anybody who has similar material to contribute is asked to get in touch with dik@leatherdale.net. The old location remains for the next few weeks but will be deleted shortly.

101010101

We regret to report the passing of Peter Naur, now perhaps best remembered for his co-invention of Backus-Naur format for describing the syntax of a programming language. David Hartley writes — “The machinations that surrounded Algol 68 made him very upset. At the A68 Conference in 1968, he stood up and made a moving speech about the iniquity of those that sided with Ard van Wijngaarden blaming them for politicking in an international committee and he resigned there and then. Whereupon the A68 Committee split asunder and programming language design thereafter was never the same. He was an honest guy as well as nice!”

101010101

Our good friends at the National Museum of Computing (TNMoC) have recently-announced several new appointments. Readers will no doubt, applaud the appointment of Andrew Herbert and Martin Campbell-Kelly to the Trustee Board both of whom are distinguished and respected leading members of CCS. We wish them well.

101010101

CCS member Herbert Bruderer late of ETH (Swiss Federal Institute of Technology) in Zürich has recently published a new history of early computing. Meilensteine der Rechentechnik (Milestones in Analogue and Digital Computing) which looks to be of interest to German speakers. A useful synopsis can be found at www.degruyter.com/view/product/432414.

Dr. Bruderer is a prolific author on the history of computing. Amongst his earlier works is Konrad Zuse und die Schweiz (Konrad Zuse and Switzerland.) an enquiry into the origins of the digital computer.

101010101

CCS member Dr Ian Cullimore, the inventor of a couple of the first pocket PCs in the 1980s — the Atari Portfolio and the Poqet PC, has contacted us with an appeal for help. He is trying to track down a Telxon PTC-1194, from about 1999 for his research. “Relatively modern!” as he puts it, not without justification. If you can help, please email him at .

North West Group contact details

Chairman  Tom Hinchliffe:  Tel: 01663 765040.
Email:  
Secretary  Gordon Adshead  Tel: 01625 549770.
Email:  

The Baby Baby or An Extremely Small Scale Experimental Machine — Part 2

The first part of this article dealt with the motivation for building a “Baby Baby”, and introduced us to field programmable gate arrays (FPGAs) and the process of configuring them by using a language (VHDL) akin to a programming language. Here we conclude the story.

VHDL Entity and Architectures

The design to be implemented is defined in terms of entities and architectures. The entity defines the interface to the system, and the architecture describes the logic to be implemented.

A design must contain at least one entity/architecture pair, but entities and architecture may be nested and the sub-entities may be used multiple times within a design in manner similar to subroutines. Unlike a subroutine each instance of an entity/architectures pair will generate a separate logic implementation on the chip, so in some ways it is more akin to a macro.

The entity could be the logic needed to de-bounce a switch or button. It can be defined once and re-used multiple times within the project.

VHDL Types

VHDL includes a number of types which may be used to define signals on the chip. It is usual to use the STD_LOGIC type which represents a single logic signal. It can of course take the values 0 and 1 but there are additional values which can for example be used during testing to represent high impedance in a tri-state system, or other undefined states. For example the state of the stop/run switch might be represented thus:—

      signal run_sw : std_logic; -- stop/run switch
    

Note the “;” denotes the end of the statement and the “--” introduces a comment. Where several signals are required then vectors of STD_LOGIC can be used which are defined as STD_LOGIC ARRAY. For example the statement:—

      signal addrb           : STD_LOGIC_VECTOR(4 DOWNTO 0);
    

defines five lines which are used in the baby simulation to specify an address in memory. Additional user types may be defined, for example as mentioned above, the Baby divides each instruction into four distinct phases called beats. The statement below creates a type which can represent the four phases and then defines a signal current_beat which can represent the current state of the machine:—

      type   beat     is (scan1, action1, scan2, action2);
      signal current_beat       : beat;
    

As programmers we don’t need to know how many signals we need in the logic vector the system generates to represent that variable, the system will take care of that. If we decide we then need extra states, for example “scan3, action3” we can just add them to the definition and the next time we run the synthesis tool it will generate the appropriate logic.

VHDL Code

Like normal procedural code VHDL architectural code consists of statements. As per for normal code there are both conditional and assignment statements. For example given three signals SW1, SW2 and LED0 we might code:—

      LED0 <= SW1 and SW2;
    

Which would configure one of the Logic Cells on the FPGA to be an AND gate. Whilst this works just fine, in anything more complex race conditions can cause chaos. Most FPGA designs, including the Baby Baby are synchronised to clock edges.

This can be done using the 'event attribute of a signal. This is denoted by appending the keyword event to the variable name, separated by a single apostrophe character. Given the signal clk this code:—

      if clk'event and clk='1' then
      LED0 <= SW1 and SW2;
      end if;
    

results in logic being generated such that LED0 will only change on the rising edge of the clk signal. The Xilinx tools include a viewer that allows the user to see the generated logic.

Here is the logic generated for the above piece of VHDL by the Xilinx tools:—

Implementing the Baby in VHDL

As VHDL is a modular language the Baby Baby was implemented in small steps, allowing each to be loaded into the FPGA and tested before moving on to the next step.

The Main Store

The first component I implemented was the main store. This uses the RAM included on the Spartan 3E chip.

The Xilinx ISE tools include a utility to configure this RAM. For the Baby Baby a memory of 32 words each of 32 bits is defined, to match the Baby’s logical store configuration. The memory is configured as dual port memory with two separate interfaces to decouple the display code from the main Baby code. It is pre-loaded with a slider program which moves a bit pattern representing the word “BABY” across the screen.

The Display

The display is provided by a small 7” LCD VGA display. The VGA signals are generated using standard code provided with the board based on a 25 MHz dot clock generated from the on-board 50Mhz crystal via a divide by two.

The Nexys 2 board includes a VGA output with simple digital to analogue converter allowing 8-bit colour. Only the green output is used by the Baby Baby.

This is used to increment a dot counter which runs from 0 to 800 across the VGA line. When this reaches 800 it is reset to 0 and a line counter which runs from 0 to 600 is incremented. When the line counter reaches 600 it is also reset to zero.

The Hsync and Vsync signals are generated from these counters.

Depending on which selector button is pressed at the start of each line a 32 to 1 bit multiplexor is loaded with one of:—

• A word from Baby store
• The accumulator
• The control store

Bits 4 through 8 of the dot counter are used to select which bit is displayed, so each cell is 8 dots wide. Generally the first two bits are always set as bright green to represent the dots and the next two bright green if the bit being displayed is a one, otherwise no colour is set and the screen appears black.

If the current line being displayed is the action line and action line highlighting is enabled the above is modified by displaying a pale green colour instead of no colour.

I would like to say that I carefully calculated the layout of the store display on the VGA screen, but the truth is that I produced an initial display and then tweaked the counter offsets so it looked central. After some experimentation I found that a dot that is 2 pixels square looked about right meaning that a dash is 6 pixels long × 2 pixels deep.

The CPU

The Master Clock

In order to provide accurate instruction timing the Baby Baby also has a master clock running at 100 KHz with an asymmetric 6 Ωsec/4 Ωsec period and a BLACKOUT signal which is high for 32 pulses and low for four.

Like the VGA clocks these signals are generated on the FPGA using counters and comparators driven by the 50 MHz FPGA external clock to produce signals which exactly match the replica’s documented timings.

The CPU

In general the logical structure of the FPGA CPU mirrors the MSI replica, but implemented as a 32-bit parallel machine. It therefore has:—

• 5-Bit latch for the L-stats
• 3-Bit latch for the F-stats
• 32-bit latch for the accumulator
• 32-bit latch for the present instruction

The four beats of the MSI replica are mirrored by four states Scan1, Action1, Scan2, and Action2 of a VHDL state machine. The BLACKOUT signal is used to trigger the change from one state to the next. The logical operations carried out in each state correspond to those of the MSI replica.

The part of the code that implements this state machine is only 100 lines VHDL.

The PC Interface

The FPGA machine implements the same PC interface as the MSI replica. Initially I had not considered using this interface and was planning on using the serial port provided on the FPGA card to load data. However this would have required a PC program to send the data to the FPGA and logic in the FPGA to allow it to be stored in memory.

After some consideration I realised that if I could replicate the MSI replica interface I could use the same PC program they use and I would only need to add logic to the FPGA.

VHDL Implementation

When I came to this decision I had a working emulation but I was generating the BLACKOUT pulses directly from the on-board 50 MHz clock and did not have a 100 KHz DASH clock. However unlike hard logic implementation, the changes to the clock generation were straightforward and only a few extra lines of VHDL were needed so that a DASH pulse with the correct on/off ration was generated, and the BLACKOUT signal derived from this signal.

Once this was implemented I then had to decide how to store the inputs from the PC into the FPGA implementations store.

I considered two ways of doing this. I could implement a shift register and store the bits in it as it arrived. In the end I decided to construct a simple state machine with 36 consecutive states, 32 for the refresh states and four for the blackout period to match timings on the replica. Each of the first 32 states is therefore equivalent to one of the P-pulses in the MSI replica.

As the data arrived from PC it is stored in the appropriate bit in a register. The complete word is then written to store during the blackout period.

As on the MSI replica the transfer can be triggered from the PC or from a switch on the FPGA board.

Electrical Interface

There was one other tweak needed to this system. The FPGA runs at 3.3V and the printer port expects 5V. On checking the Centronics specification the outputs from the FPGA generate enough current and have a high enough voltage swing to drive the printer port. However if it was directly connected to the FPGA the 5V from the PC would damage the FPGA. Current limit resistors needed to be added to protect the FPGA.

I tested the interface with an old Windows 95 laptop and much to my surprise it all worked wit only a little tweaking.

At this point I had a Baby Baby that could load code from the PC and from switches and run it.

A Full User Interface

Initially the only switches implemented were the KC and stop/run switches. These were implemented using the switches on the FPGA board. To prevent multiple instructions from being executed when it is pressed the FPGA code de-bounces the KC switch. As the FPGA loads a program into memory this was all that was needed to test the machine.

Once the machine was working logic was added to implement the various Clear switches, again using the switches on the Nexys board.

The Typewriter Buttons

At this point I had a working Baby but it wasn’t very pretty and it could only run the pre-loaded code or load code from a PC. There was no way to change a program directly. For this I needed to implement the typewriter buttons. As there are 32 buttons on the typewriter, to directly connect these to the FPGA would use many inputs. Whilst there are plenty on the Nexys 2 board using them would need an expensive Hirose FX2 connector and require a PCB to be made.

If I could use the 8-pin PMOD connectors, which are common on many FPGA boards I would have the flexibility to switch to other smaller FPGA chips many of which have a fewer I/O ports. To do this I decided to use MCP27S16 serial peripheral interface (SPI) chips to reduce the number of inputs. Unlike most SPI chips multiple MCP27S16 chips can be connected to a single SPI bus and individually addressed without needing separate enable lines. This meant that up to four can be connected to the FPGA with only a 4-wire interface. Each chip has 16 I/O pins which can be programmed as inputs or outputs, so the entire typewriter console can be implemented using four ports on the FPGA and two MCP27S16s. The chips are conveniently available in conventional through-hole DIL format and so can easily be mounted on traditional 0.1” pitch prototype boards.

A small board was constructed. Apart from the ICs, only a couple of capacitors and resistors were needed. The chips connect to a PMOD connector mentioned above which provides the four I/O connections and power. Standard 0.1” socket strips were soldered to the inputs for testing.

I was really surprised how easy this was to implement in the VHDL. A small piece of VHDL code was written which continually polls the SPI chips. The content of the switches is read serially and converted to a 32-bit word using a shift register. The state of the switches is therefore continually available to the rest of the system and it can be examined and tested in the same way as if it were using direct inputs.

A third MCP27S16 chip is used to sense the line, function, manual/auto, erase/write and highlight switches. For simplicity this is connected separately and is managed by a second instance of the same VHDL code.

The switch inputs are all handled in the blackout period. The data from the buttons is combined with the data received from the PC interface and written to the appropriate line in store. If any other switches (e.g. KLC, KSC, KAC or KCC) are depressed these are also actioned during the blackout period.

Physical Construction

As you can see from this photo, sadly the physical interpretation is not that of a finescale live steam locomotive, it is rather more a garden railway pastiche.

As I wanted something that was small enough to carry yet still had some feel or atmosphere of the original Baby. I decided on a 10” wide rack, approximately 50% of the width of the replica, but as there are no EHT supplies in the base I have a total height of 17”.

The main body of the rack is constructed from aluminium extrusions purchased from B&Q. The sheet aluminium used for the switch panels and as the bracing for the feet was obtained from a local model shop, as was the plastic sheet used to fashion the monitor surround.

The typewriter buttons are standard push-to-make switches purchased on Ebay, they are similar in colour to the replica buttons, but are a totally different shape, being pure buttons rather than having a hollow button with a skirt at the bottom. I believe that I could use my 3-D printer to print some covers that would fit over the originals that would be a closer match to the originals, but I have yet to try this.

The L-stat, highlight, and manual/auto switches are all standard miniature toggle switches. These should be ball-ended switches, and although I know such things were made as I have some, I could not find enough to complete the Baby. The F-stat, halt/run and erase/write switches are also miniature toggle switches, but with black rubber covers. I feel these look quite realistic.

The monitor switches were obtained from my junk box. These are really too large, but I could not find any smaller latching switches.

Lastly the panel that is on the replica constructed from Post Office key switches is currently crudely represented by some miniature paddle switches. As the paddles clip into place my intention is to modify these so that they bear a closer resemblance to the Post Office switches on the replica.

Mounting the switches

It is pretty obvious from the pictures of the Baby Baby that my craft skills are limited so drilling the mounting holes for the typewriter buttons and toggle switches was going to be a major challenge and I looked for a way to automate it.

As I didn’t have a CNC milling machine, the holes were produced using a Dremel attached to a Maplin/Velleman K8200 3-D printer modified using instructions from the Velleman website.

I had hoped to use the same procedure to mill the plates that hold the feet to the rack verticals, but found that the printer was not capable of milling through the aluminium plates. The table is not rigid enough, and deflects even when milling shallow grooves so these were cut with a small hacksaw.

Mounting the Circuits

The FPGA card and the SPI expanders are mounted on the rear of the machine. It is not very pretty, but then neither is the back of the Baby replica.

The Stop Lamp

The replica machine has a small lamp which is lit when the machine executes a stop instruction. It is extinguished when the KC (single step) switch is pressed. On the FPGA machine this is replaced by a small LED which is directly driven from the FPGA chip.

The Hooter

The replica is equipped with a hooter which sounds if a stop instruction is set. It is silenced when the stop/run switch is moved to stop. It is driven from what of the store refresh counters. The Baby Baby also implements refresh counters. They are not required to refresh the store but they are needed for the PC Interface. The appropriate bit of the counter is gated with the stop/run switch and routed to an FPGA output pin which is fed into the audio input on the VGA display, so the frequency is the same as on the replica.

Operation of the Machine

Generally the machine operates identically to the MSI Replica. Therefore:—

• It runs at the same speed as the MSI Replica.
  • Although the speed of the replica may drift as it is not crystal stabilized.
• A program can be stopped and started by means of the stop/run switch
• Instructions stepped through by use of the KC switch.
• The monitor display buttons can be used to change the store viewed on the display.
  • The present instruction is only displayed when the machine is running
• The L-stat switches and the typewriter buttons can be used to set or clear any bit in store.
  • This means programs can be loaded manually
• The KLC, KSC, KAC and KCC switches clears the appropriate parts of the machine
• On a STOP instruction the machine stops, the STOP LED lights and the hooter sounds
  • Switching from RUN to STOP silences the hooter
  • The STOP LED remains lit until KC is pressed
• When connected to a PC, the machine can be loaded with a program
• The instruction defined in the L-stat and F-stat is executed in manual mode.
  • Once if STOP is set and when KC is pressed
  • Continually if RUN is set.

There are some minor differences:—

• The main store contains a copy of a slider program at power on.
  • For easy demonstration.
• Additional programs may be loaded from ROM by using switches on the FPGA board at the rear.
• The F-stat and L-stat switches are ignored in manual mode
  • On the MSI replica they cause errors.

Summary

At this point I believe that I have fulfilled the initial project objectives and a little more. The FPGA Baby Baby is:—

1. An FPGA implementation of the SSEM that executes Baby programs.
2. Execution times match the replica Baby.
3. Switches, buttons and lamps are correctly implemented
4. A display that can be switched in the same way as the MSI Baby store.
5. It can be loaded from the PC interface programs.

My next project is to replace the DOS based PC interface with an Arduino or Raspberry PI and SD card slot so that I can have a self-contained unit that can load any Baby program.

Dave Wade is a volunteer on the replica SSEM at the Museum of Science and Industry in Manchester. He can be contacted at .

A Letter from Christopher Strachey

The letter below submitted by Clive Page is believed to be one of the last published works of Christopher Strachey before he left Cambridge for Oxford and was first published in January 1965. Strachey attributes the original thought to Turing.

To the Editor, The Computer Journal.

An Impossible Program

Sir,

A well-known piece of folk-lore among programmers holds that it is impossible to write a program which can examine any other program and tell, in every case, if it will terminate or get into a closed loop when it is run. I have never actually seen a proof of this in print, and though Alan Turing once gave me a verbal proof (in a railway carriage on the way to a Conference at the NPL in 1953), I unfortunately and promptly forgot the details. This left me with an uneasy feeling that the proof must be long or complicated, but in fact it is so short and simple that it may be of interest to casual readers. The version below uses CPL, but not in any essential way.

Suppose T[R] is a Boolean function taking a routine (or program) R with no formal or free variables as its arguments and that for all R, T[R] = True if R terminates if run and that T[R] = False if R does not terminate.

Consider the routine P defined as follows

    rec routine P
    §L: if T[P] go to L
    Return §|

If T[P] = True the routine P will loop, and it will only terminate if T[P] = False. In each case T[P] has exactly the wrong value, and this contradiction shows that the function T cannot exist.

It is, perhaps, unlikely that many readers will now be familiar with CPL (frankly it was unlikely then). Fortunately Martin Richards has elegantly come to our rescue with this explanation -

Strachey’s letter is all about proof of what is now known as the Halting Problem, which is regarded as so straightforward that it is now taught to most first or second year computer science students in finite automata courses.

I am probably not the right person to comment on Strachey’s ‘proof’ and there are many people (such as Ken Moody, Alan Mycroft, Mike Gordon and Glynn Winskel) much more competent than me to do that, but that will not stop me having my say.

Firstly, the letter was written in 1964 or possibly 1963 when CPL was not fully developed. In the early life of CPL, parameterless routines were declared and called without specifying their empty argument lists. This awful convention was common in those days and adopted by languages such as Algol, Algol W and Algol 68. The problem was that you could only tell whether the expression P evaluated to a routine or was a call of that routine by the type of the context in which it occurred. Worse still, if P were declared to return P as a result the type of the context would not resolve the ambiguity. The later version of CPL insisted on empty parentheses in both the declarations and calls of parameterless functions. The difference between P and P() is then clear to the reader. Another minor change, in later CPL, was that parentheses were used to enclose function arguments while square brackets were only used to enclose array subscripts. I am also surprised that Strachey constructed the loop using a label and a goto statement rather than a more readable while statement. The Return statement could have been omitted. The declaration of P could have been written in the closely-related BCPL language as follows.

    LET P() BE WHILE T(P) LOOP
    

As Strachey mentions, the language used is immaterial to his argument, but unfortunately his proof is just wrong. In languages like CPL, Algol 60, Algol W, Algol 68, ML or Haskell, all that T can do with its argument is call it. It is not possible for these languages to look at the code of P that will be used when P is called. So the only thing T can do with P is call it, and if P does not terminate, then T will not terminate. For the halting problem T must terminate whatever P it is given. Perhaps the closest we can get to a definition of T is the following.

    LET T(P) = VALOF
    { P()
      RESULTIS TRUE
    }
    

At least this is guaranteed to return TRUE if P() terminates. Unfortunately it loops for ever otherwise. It is just possible an optimising Haskell compiler would observe that P takes no arguments and has no free variables so executing it can have no effect, so its call can be eliminated, causing T to return the wrong result when P() does not terminate.

The conventional proof of the halting problem assumes both T and P are Turing machine or register machine programs, and the proof is based on constructing a variant of the program for T replacing returns of True by code that loops forever, and returns of False by code that halts. Assuming the argument of T is P, there is final modification that causes it to consider the termination of P(P) rather than just the termination of P(). This, of course, requires P to take an argument but that is not a problem. If this modified version of T is called T' we now consider the call T'(T') and observe that

T'(T') = True if T'(T') = False

and

T'(T') = False if T'(T') = True

Both these are inconstant so T'; and hence T cannot exist.

One final observation is that Cintcode BCPL is not like all the other languages mentioned above since the BCPL manual bcplman.pdf does give a description of the Cintcode byte stream code generated by the compiler and that the value of T is a pointer to the Cintcode entry point of the function. So a BCPL program can analyse the flowchart for T as well as calling it. So perhaps we can regard BCPL as being closer to Turing or register machine code than the other languages mentioned above!

CCS Website Information

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

Overture. Back in the late 1950s the public’s appreciation of what a computer was or what it could do was sketchy to say the least. And that of the captains of industry (as they were then known) was little better. The Institute of Office Management took it upon themselves to explain by making a set of long playing records (remember them?) together with a set of film-based slides to be shown in parallel. Leo was heavily featured. The cost? £80 for the set — roughly £1000 today. The contemporary description is presented here —

1. What Is Electronic Data Processing?

This filmstrip, which is a general introduction to the series, is shorter and less technical than those following. It will be found useful for purposes of management appreciation, staff education when a computer is about to be installed in a company and the training of office management students.

After a brief historical introduction to show the importance of recent changes in the office, it explains what is meant by electronic data processing, discusses the significance of the concept of a common language medium and of the possibilities inherent in it for linking up different types of office machines for combined operations.

The film concludes by summarising the great advantages to be derived from a properly planned electronic office.

2. How a Computer Works — Part 1 — General Principles and Input/Output

The first part of this filmstrip briefly traces the evolution of the automatic digital computer from the abacus, shows how its operation differs from that of a modern accounting machine, fully explains the difference between decimal and binary notation, then describes in detail how numbers are represented by electrical pulses, the language of computers. The second part of the film discusses various types of mechanisms by which data fed to the computer is read in, how information is printed out, the significance of on-line and off-line processing and the conversion of ordinary alphabetic and numeric characters into machine language.

3. How a Computer Works — Part 2 — Storage, Arithmetic, Control

Though permanent data translated into machine language can be stored externally on punched cards or magnetic tape, the computer’s program of coded instructions and the intermediate products of its calculations need internal storage facilities. These may be provided by magnetic drums, nickel delay lines or magnetic cores, the operation of which are fully explained.

Next the film describes the working of the arithmetic unit, showing how pulse trains are applied to electronic switches to carry out the basic computing functions of addition, subtraction, multiplication and division.

Lastly, a detailed step by step account is given of how the control unit executes the program, transferring data from one part of the computer to another, from the reading in of the first instruction to the printing out of the final result.

4. Do You Need a Computer?

How can a company find out whether it would pay to do its routine clerical work on a computer? How does it decide what type of computer is required?

This filmstrip takes the viewer step by step through the whole justification study, discussing such questions as to whether to employ outside consultants or the O&M service, the composition of the team for the preliminary survey, the areas of work to be covered, the information to be produced, the effect on present organisation structure and the number of technical staff needed to install and operate the new system. It explains how to set a realistic time-table for the changeover, how to build up an accurate cost statement and how to inform and secure the co-operation of the departments involved, concluding with the contents of the report to the board to enable them to make a final decision.

5. Programming— An Introduction

This filmstrip covers the general principles of programming; shows by means of simple illustrations taken from clerical procedures what it involves; explains why it is so important, takes so long and is relatively so costly. It describes the qualifications required of programmers, the factors which should govern their selection, how their work must be organised, the difficulties they will inevitably meet and how they can be overcome. Included is a brief account of the evolution of programming from its early binary form to autocode plain language programming.

6. Installing a Computer

The installation of a computer calls for careful, detailed planning. The accommodation must be prepared for effective power supply, ventilation, humidity control and maintenance. Different people throughout the organisation must be kept in touch with various developments; information must be exchanged with manufacturers and the views of experienced users sought.

Managerial, technical and routine personnel must be selected and trained; staff who have been made redundant, re-deployed. An economic workflow must be devised for the load to be put on the computer. Programs must be thoroughly tested and kept flexible to permit of last-minute changes and unforeseen developments. Finally, the machine’s performance must be checked against the target on a parallel run with the conventional system. This filmstrip highlights all these essential aspects of successful computer installation.

Intermezzo. You might imagine that such things were long forgotten but in 1990, a set of records and films turned up in the Institute of Advanced Management archive at Warwick University. Graham Briscoe arranged for them to be transcribed to VHS video tapes (remember?) and made available again. A covering article was published in the IAM journal reproduced here —

Peter Ives — one of the members of the team who prepared the original film strip and records.

Seeing these filmstrips in video form has reactivated memories of a time when I was directed to produce a series of filmstrips to explain this new office tool — the computer. At a time of no little scepticism towards electronics in the office by many sectors of management, we set out to produce a guide which was to be quite unbiased in its approach. Even so, the fact that the project was written by “converts” comes through rather strongly in places.

How naïve we must have been: Here was a small group with each of us in the throes of a feasibility study, awaiting delivery of a computer, writing long coded programs or going through the traumatic experience of getting a job onto our first machine. Yet we boldly set ourselves up as being among the country’s DP experts to produce an authoritative text on the subject.

Initially we divided the six strips between ourselves, reporting progress and exchanging ideas at monthly meetings. It was significant that those who already had their computer found it increasingly difficult to give time to the project. It was not uncommon for apologies for absence to be accompanied by the news that, say, the payroll run had collapsed and must be made to work by the following week. However, the strips were eventually completed, a few months late if I recall correctly, but this matched the pattern of frustration in the computer world of the late fifties and early sixties.

Machine delivery delays, software, usually confined to an operating system, behind schedule, long periods of down time etc, all eventually overcome in a spirit of “given the time, we’ll get it right in the end”. To illustrate these delay problems, I am reminded of a firm which ordered a large machine and very extensive software, building penalty clauses into both contracts in case of delay. The hardware was delivered over a year late and the penalties paid. The software was not ready and again the penalties applied but with the added bonus that the firm then rented the machine back to the manufacture until such time as it was completed.

Looking at the filmstrips and bearing in mind the hardware of the time, which can now only be called primitive, quite a lot of what was said in the text concerning staffing, costing and planning still holds good today. One complete change has manifested itself, however, in that we were stressing the need to involve management in the computer project whereas the position is now somewhat reversed for, as new office systems are discussed, management is demanding terminals with instant access to data pertinent to their role.

With hindsight I wonder why we went so deep in explaining the workings of the computer. The theory of binary arithmetic was necessary for the programmer of the day but the explanations of addressable drum stores, the working of the ferrite store and the way instructions were handled within the machine were not really needed for management to assess the potential of this new equipment.

Perhaps we included such technicalities to show that at least we knew what was going on inside those grey cabinets — or at least we thought we did. Concerning the technical side, I became involved in the early computers at the beginning of the fifties because the management of my organisation knew through a company exhibition of hobbies and handicrafts that my hobby was electronics. The man to whom I reported went on a computer course and was taught valve theory and the circuitry of logical gates. Neither of us found our knowledge to be of any use when trying to bridge the gap between manual and electronic systems in our office.

It has been entertaining to see the filmstrips again, not only for the amusement of seeing some of my colleagues and myself as earnest young men, but to stand back and appreciate the developments in this field over the past 30 years. None of us could have guessed the advances to be made in the hardware bringing many more times the then available machine power down to desktop size or through terminal access to a large mainframe.

Today we may feel that technology can advance no further and that systems have reached the ultimate in sophistication but I am certain that in the next 30 years changes will come about even more dramatically than in those which have passed. I picture someone in the year 2020 looking at a training aid written today. As he takes a small device from his pocket and talks in his own language to a computer on the other side of the world he could well be wondering why the writer put so much stress on what to him would be the obsolete VDU terminal!

Geoff Tweedale — curator of the National Archive for the History of Computing at Manchester University, who was involved in the conversion from film strip and record onto video.

Although the development of the electronic digital computer is so very recent, documentation on its early history is remarkably sparse. The Cambridge University computer team made a brief film of the EDSAC in the early 1950s, but none of the computer pioneers committed their exploits to film. Training films are even rarer, not least because the application of the computer to data processing was relatively slower than its application to scientific problems; and also, not all bodies were as enlightened as the IAM.

The pioneering IAM film strips therefore appear to be unique and are an important addition to the National Archive for the History of Computing. In viewing the strips one is immediately struck by the extraordinary rapidity of technological advance: many of the machines depicted already look like dinosaurs — yet they are not much more than 30 years old! Advances in software are equally evident from the sections on programming. As a historical document, the film provides a unique insight into the impact of the computer on the business world — in the days when installing a computer was a major financial and logistical problem and at a time when Britain was a world leader in computing (even surpassing the USA in the 1950s). On the other hand, the explanations of the theory and practice of computing are clear and concise and still relevant today. In short, the film provides an important window on the past, which can still be watched today with profit.

Alan King — recently acting chief executive of the Institute of Administrative Management, following a data processing career with Lyons Tetley — which started off working on LEO machines.

I watched the video with great nostalgia, especially since I suspect I make a brief appearance. Much of the machinery inevitably reflects the technology of a bygone period, both in appearance and performance. You certainly would not now see the 1960s programming techniques used outside of a specialist software house, nor come across the view that users need to understand how a computer works at circuit design level.

In contrast, many of the business concepts explored by the video are as valid today as they were 30 years ago. I was particularly impressed by the sections on the employment of external consultants, on carrying out a cost-benefit feasibility study and on the need for integrated data processing.

Peter Bailes — a curator in the Information Age Project Team (the then new computer gallery) at the Science Museum, London.

The videos are highly informative, both as computer training films and as historical archive material. Most of the content can be found in today’s training videos — the desire to attain a common language medium, although no longer punched card and paper tape is still as poignant, even if just as unrealisable. Indeed most of the information regarding for example Installing a Computer, and Do You Need A Computer? is still relevant to larger computer users, but is unfortunately neglected in today’s small throwaway computer market due to the price and performance improvements we have experienced.

Of particular interest are the attitudes and opinions towards the technology, the computers and the training that cannot be conveyed on other media. Museums collect objects that can be preserved and restored hundreds of years later but the audio-visual recording can communicate more personal experiences and information that, unless captured at the time, would otherwise be lost forever. This is brought across by the dated but now amusing presentation techniques and the Reithian style BBC narrator that informs us that “It must not be forgotten that women can also make good programmers” and presents us with a magnetic tape that can store the whole of Gone With the Wind! “We have an immensely effective tool, can the office put it to work effectively?” is the question we are left with at the end of the first film. Have things changed so much that we can answer it any more effectively?

Marcus Austin — a curator in the Information Age Project Team at the Science Museum, London.

It is interesting to see from this film just how much has changed in computing, how 30 years ago computers spoke the common language of paper tape, and punched cards, and the valve was king. Just how much has changed is illustrated by the 1956 Ferranti Pegasus; it’s now regarded as old enough to be the first candidate for restoration by the Computer Conservation Society at the Science Museum in London. The impressive computer of the 50s has been replaced by the PC which is 100 times faster, has 100 times the memory, and is 100 times cheaper than the Pegasus.

The advice given is in many ways still relevant to mainframe users of today, the reasons for buying a computer, the application it’s used for, and the installation problems all remain the same. They also try hard to dispel the 1950s myth of the electronic brain, something that would instantly solve your problems, a myth that confused a generation of computer buyers and still carries on today. However, the authoritarian tone of the commentary is contrary to the user-friendliness exuded by modern computer training videos.

Edward Cluff — secretary general, Association for Managers of Information Technology Systems (AMITS).

Over the course of many years, I have found that relative newcomers to the business (i.e. in the last 20 years) enjoy and even benefit from anecdotes about how things were in the industry in the early days. This is because there is much to be learned from the trials and tribulations some of us once endured, like trying to squeeze everything into a couple of hard discs on a mainframe each with 4.25 Mb, or fighting with repeated write errors on tapes guaranteed to be error free.

Most of the sources of how things were and why we did what we did are fading into the distant horizons but this video, a collection of audio tape presentations made at the time, is invaluable to those who are not content with the story of today.

Jenny Wetton — assistant keeper for Science, Museum of Science and Industry, Manchester.

Watching these late 1950s training strips on electronic data processing was certainly an education for me. The material provides an interesting comparison with current practice in terms of not only changes in technology, but also how the computer was seen in the office environment, the huge cost of time and money involved, and the changes in attitudes to staff.

The first strip gives a good general introduction to electronic data processing. Computers had been put into offices because there were demands for faster and more accurate information but little mechanisation and a shortage of quality clerical staff. Also mentioned is the important contribution a computer could make by enabling different types of equipment to be linked together — integrated data processing.

The second strip gives a good introduction to what goes on inside a computer. A brief history of the technological advances and how they worked is also provided.

There is a useful explanation in the third strip of how the storage worked, i.e. magnetic drums, read/write heads, nickel delay lines and — the latest method at the time — magnetic core storage. This complements examples of each of these storage mechanisms which we have on display in the Computers Exhibition in Manchester. The strip also points out what many computer users have since found to their cost, machines can make mistakes faster than you ever dreamed possible!

The fourth strip is, to my mind, the most interesting because of the light it shines on the commercial methods and attitudes of the time. It deals with the commercial criteria that need to be taken into account when deciding whether to buy a computer — a large decision when most machines used in business cost between £100,000 and £200,000. It also deals with the need for a detailed EDP study which would take the same amount of time as planning a new factory.

There seems to have been a rigid division of labour between the sexes. The data input and clerical staff pictured are all women, whereas those doing the EDP study and managing the computer’s arrival are all men. There is just a brief mention of the thorny subject of redundancies, mainly the need to consider and explain what will happen to those who will lose their jobs to the computer.

The fifth strip, on programming, explains why computers were so costly in time and money to set up and run as well as buy. It points out that women can be good programmers and that age should not be a barrier either! The final strip on installation emphasises how much has to be prepared before the computer arrives, including the dissemination of information to all staff on the implications of its arrival, with the aim of avoiding rumours.

Finale. Fast-forward that VHS tape by another quarter-century or so and we arrive at 2016. Some of the comments from 1990 seem a little dated, but many still ring true.

Transcription has had to take place once again and the courses will shortly be available for download. The CCS and the Leo Society also have copies.

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

Low-cost version of the 4080 mini released by GEC: A low-cost version of the 4080 minicomputer has been announced by GEC. Designated the 4070, it gives 75 per cent of the performance of the 4080 and is aimed at users who do not really need the 550 nanosecond memory cycle of the 4080. (CW 487 p3)

2903 shows one-shift work pattern: The average ICL 2903 in the UK is used for less than one shift a day, but only 5.5 hours of this is production work, another 1.3 hours on average being used for development, according to a survey by Systemsolve. (CW 487 p4)

US military shortlists Coral 66 in real time language hunt: Initial tentative examination of Coral 66 by the US armed services in their search for a new standard real time language has now assumed a far more definite character, with the inclusion of Coral in a final shortlist of about 12 languages. (CW 487 p32)

Customs plan Import network: A nationwide on-line terminal network planned by the Customs for clearing imported goods at UK seaports looks like becoming a reality. Prospective terminal suppliers have received an operational requirement and Customs are awaiting detailed proposals. Eight major UK ports will be involved in the network. (CW 488 p1)

Lords retrieval going ahead, Commons wait: While plans for the full House of Lords computer-based information retrieval system are nearing the tendering stage, the House of Commons will still have to wait for some time for its own retrieval system, according to a parliamentary reply last week. This has led to protests from Kenneth Warren, the MP who raised the matter. (CW 488 p2)

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. (CW 488 p47)

Philips’ micro controlled teleprinter: TEXT REF

title: The latest development in the long history of the teletypewriter has come from Philips which has introduced the PACT — Programmed All-purpose Communication Terminal — microprocessor-controlled machine. A Philips spokesman said that the microprocessor, an eight-bit 2650, came from Signetics, the US company taken over by Philips last year. (CW 489 p1)

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. (CW 489 p4)

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. (CW 490 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. (CW 491 p1)

ARPA - Coral link-up: The link of the Royal Signals and Radar Establishment’s GEC 4080 processor into the world wide ARPA telecommunications network was officially inaugurated last week by the Queen. The connection will allow the RSRE’s compiler for the government standard real time language, Coral 66, to be accessed by all users of the network. (CW 491 p40)

USAF give minis crisis job: Crisis management is the formidable task to which three SEL 32/55 minicomputers are to be assigned by the US Air Force Systems Command. The three minis being acquired from Systems Engineering Laboratories of Fort Lauderdale, Florida, under a £1million contract, are to be installed at Beale Air Force Base, California, where they will go in to service with the Ninth Strategic Reconnaissance Wing. The minis will form part of the SR-71 Blackbird ground support computer systems, and will improve the capability at Beale for crisis management operations. (CW 493 p25)

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, 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. (CW 494 p1)

IBM challenges desktop market with 5100 release: Designed for commercial, statistical and mathematical problem solving, the IBM 5100 portable computer, now announced in the UK, offers Basic and APL programming and up to 64Kbytes of main memory in a 50 lb desktop unit. The 5100 also incorporates a typewriter keyboard, a numeric keypad, a display screen showing up to 16 lines of characters, and an exchangeable magnetic tape cartridge unit. (CW 495 p32)

Newspaper’s distribution to go automatic: Publisher of the Glasgow Herald, George Outram and Co, has signed a £189,000 contract with Prime Computer for two minicomputer-based systems to handle distribution and commercial applications. They are due to go live by late summer. The distribution system will be based on a 160K Prime 300 running under DOS/VM and using the FIRST transaction processing software. Peripherals will include two 12-Megabyte disc drives, console, line printer, and five Lynwood VDUs. (CW 496 p32)

CTL Series 8000 succeeds Mod One: A new range of small, multi-access computer systems on which Computer Technology will be pinning its hopes of continued success until well into the 1980s was unveiled by the company last week. The new range, called Series 8000, has arrived 10 years after the birth of CTL with its Modular One, and is based on the best features of the latest versions of that machine. The Series 8000 sees CTL turning the Modular One from a single computer meeting all needs, to a range of systems for all sizes of installation and application. (CW 498 p3)

Ideal standard set for US forces: With its selection of a new standard real time language now begun, the US Department of Defense has published its report setting out the criteria for the ideal language. Some of these standards, unfortunately, seem to reduce the chances of either of the two UK languages under evaluation, Coral 66 and Algol 68, emerging as the final choice. (CW 498 p8)

Cray wins two big orders: The specialist mainframe manufacturer Cray Research of Chippewa Falls, Wisconsin, has received two orders for its Cray 1 supercomputer. One machine is in operation at a customer site, while the second is due to be delivered in July 1977. The first machine, with a 500,000 64-bit word memory, is at the Los Alamos Scientific Laboratory in New Mexico on a six month inspection basis. The laboratory is primarily running test problems to evaluate the machine and first reports indicate that the system is performing “exceptionally well”. (CW499 p2)

First UK 2904 order: The first order for ICL’s new 2904 has come from Petters of Staines, Middlesex, an engine manufacturer and part of the Hawker Siddeley group. The £182,000 2904 will be installed early next year, when it will replace a remote job entry terminal linked to a 1903T at another Hawker Siddeley plant. The system will include 40K of memory and two EDS60 disc units. (CW 499 p32)

Forthcoming Events

London Seminar Programme

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

For queries about London meetings please contact Roger Johnson at , or by post to 9 Chipstead Park Close, Sevenoaks, TN13 2SJ.

Manchester Seminar Programme

North West Group meetings take place in the Conference Centre at MSI – the Museum of Science and Industry in Manchester – usually starting at 17:30; tea is served from 17:00. For queries about Manchester meetings please contact Gordon Adshead at .

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

Museums

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

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

The National Museum of Computing : Thursday, Saturday and Sunday from 13:00. Situated within Bletchley Park, the Museum covers the development of computing from the “rebuilt” Colossus codebreaking machine via the Harwell Dekatron (the world’s oldest working computer) to the present day. From ICL mainframes to hand-held computers. Note that there is a separate admission charge to TNMoC which is either standalone or can be combined with the charge for Bletchley Park. See www.tnmoc.org for more details.

Science Museum :. There is an excellent display of computing and mathematics machines on the second floor. The new Information Age gallery explores “Six Networks which Changed the World” and includes a CDC 6600 computer and its Russian equivalent, the BESM-6 as well as Pilot ACE, arguably the world’s third oldest surviving computer. Other galleries include displays of ICT card-sorters and Cray supercomputers. Admission is free. See www.sciencemuseum.org.uk for more details.

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

Computer Conservation Society

Aims and objectives

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

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

The aims of the CCS are to

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

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

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

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

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