ICL 2966 restoration during 2011
Post this page to popular social media
Each TNMOC project has either a working group or project team assigned to do the work. Working groups are either managed in association with the CCS (Computer Conservation Society) or solely within the Museum.
Below are updates on the ICL 2966 restoration project during 2011.
13/09/2011 update from Delwyn Holroyd
Over the last couple of months there's been plenty of progress on the 2966 restoration. Here are some of the highlights.
Following some more adjustments the printer is now working well and has passed it's TOSD diagnostic tests.
The 7501 terminal has been successfully interfaced to the DCU and teleloaded with a control program by one of the TOSD tests. Unfortunately the terminal immediately crashes when the teleload completes! The cause of this is still under investigation. We were able to take advantage of having a working printer by dumping the memory contents of the 7501 and a comms trace for later examination.
Recently one of the Maximop development team visited the museum. Maximop is an early interactive operating system developed for the ICL 1900 series at Queen Mary College. It was designed to run on smaller 1900 machines lacking the power to run ICL's George 3 operating system, and enabled users to interact with the computer via a video terminal or teletype. At the time this was still quite novel: most computer work was run as batch, submitted on punched cards or paper tape and run by an operator, with the user receiving a printout of the results hours or days later. A binary copy of Maximop from Manchester Grammar School has survived, and with the aid of a PC emulator for the 1900 and the 7501 terminal we were able to demonstrate Maximop running for our visitor on a real terminal (see picture). It's very nearly 30 years since it was last run at the school and probably anywhere!
Work has commenced on restoring the two card readers and it appears this will be quite a job. Generally the mechanics appear to be in reasonable shape, with the exception of some plastic vacuum hoses which have begun to revert back to oil and will need replacement. The larger problem is the electronics. The card reader is based on the same general purpose Minicom processor found in the SCP, DCU and 7501 terminal. The other main boards are store, host interface and a dedicated card reader coupler which interfaces with the mechanism. Unfortunately the processor, store and coupler boards are all faulty in both card readers, and one has a failed power supply too - it really couldn't get much worse! All of the spare store boards also proved to be faulty, but one was temporarily borrowed from the DCU for testing, together with a spare Minicom. This has proven the ROM is intact (it has a checksum test which has passed), and we have full schematics for everything else thanks to our aperture card archive.
I've started design work on a new 2900 peripheral interface PCB to replace the hand wired and unreliable board we have been using so far. The new board will be able to act as an X or Y end, i.e. as a peripheral or controller. The PCB hosts a USB-to-FPGA module and will also connect to my existing EDS80 drive interface, to allow reading of the remaining disk packs much faster than was previously possible over an RS-232 port.
Finally a major tidy up has taken place, with cables re-routed and tidied, spare parts relocated to nearby storage, and the rear cabinet doors fitted for the first time.
25/06/2011 update from Delwyn Holroyd
Last week we fitted the 2900 interface board and plug panel into our line printer. Next we needed an interface cable, which meant delving into the huge pile of 2966 cables we have in one of our storage areas. Several hours later we emerged with a suitable cable as well as an inventory of the whole set which should be useful as we start working on the other peripherals.
On powering up with the new interface board installed the signs were not good - the sequence START/STOP/START on the printer control panel seemed to cause the printer's internal processor to crash, which I'm sure can't be right!
Today I installed a second 2900 interface board in the DCU and tested it by connecting it to the laptop/virtual tape and booting the machine. Having established confidence in the new board I then connected it to the line printer and loaded the machine with TOSD (the test operating system). TOSD recognized the printer and assigned it as an output device, resulting in a print out showing the memory and peripheral configuration of the system (see picture below).
So clearly the interface board is working to a large extent despite the mysterious crash, and we are now ready to run various LP tests under TOSD from the newly reconstructed Engineers Test Library tape.
12/06/2011 update from Delwyn Holroyd
This week I commenced work on the line printer. The printer was run at the museum a couple of years ago so I was anticipating a straightforward job.
This particular printer (an FP1500A) did not come from Tarmac with the rest of the 2966 system, and is in fact fitted with an OSLAN interface for connection to a Series 39 mainframe system. Luckily the original printer, a much larger LP2000 unit which is in our reserve storage, has a 2900 interface board which is compatible with the FP1500A so this needs to be swapped over.
The FP1500A is a band printer: a metal band with the character set embossed on it rotates at high speed in front of a ribbon and a bank of 132 hammers, one for each horizontal character position. In operation an on-board microprocessor works out the optimum order in which to fire the hammers as the required characters pass in front of them. This enables it to print at 1500 lines per minute, which is really moving! The LP2000 is even faster, and as the name suggests can print at 2000 lpm which is over 30 lines per second - much faster than a modern consumer laser printer or ink-jet. The printer uses continuous fanfold stationary. This once common format for high volume printing of utility bills, bank statements and so on is now becoming rare as most businesses have moved to sheet feed laser printers.
Prior to switching on I hoovered out all the paper dust, removed all the covers and inspected the moving parts. I also removed the ribbon and band and cleaned the gate area, by the end of which the printer was clean and I was covered in ink!
The printer powered up and passed self-test with no problems. All the mechanicals seem sound and a test print looked ok after adjusting the band height. However when powering down I noticed a discouraging smell coming from the area of the power supply, so this will no doubt require some remedial attention.
05/06/2011 update from Delwyn Holroyd
I've made good progress on reconstructing the "Engineers Test Library" tape using data recovered from the diagnostic disk pack. Although the programs themselves were on the disk, the necessary tape headers and block structure had to be reconstructed. I was able to deduce the required structure by studying the source code for the loader program.
There are a couple of different types of program on the tape: APF and OMF. APF programs are standalone and loaded directly from the engineers loader. They mainly comprise a suite of tests to validate every aspect of the 2900 instruction code. Running this test suite flagged up a couple of problems, however both were failures to detect a condition that should cause a program exception, so are unlikely to affect normal software.
The final APF program on the tape is TOSD, which is a complete multi-tasking Test Operating System. Under TOSD further test and utility programs in object module format (OMF) are loaded and run. These are mainly peripheral tests and low-level disk maintenance utilities. The picture shows the TOSD load screen with the DATE PLEASE prompt, which will look familiar to anyone who has operated an ICL 1900 system. TOSD is in fact quite similar to operators executive on the 1900 series. I was curious whether it would accept 2011 as the date but it didn't complain!
So far I have loaded one test under TOSD to prove the tape formatting is correct, but we now need peripherals to test! The first candidates will be the line printer, card reader and comms using the ICL 7501 terminal I restored last year.
22/05/2011 update from Delwyn Holroyd
At long last we've finally resolved the problem described in the previous update: even though all the diagnostic logic tests pass the machine still refused to boot.
I had made the assumption that the diagnostic tests checked all the parts of the machine that could prevent a successful boot, and indeed they are supposed to! Eventually it dawned that a communication mechanism used in the bootstrap didn't appear to get tested by the diagnostics.
Armed with this clue I located and buzzed out the 5 possible signals that could be at fault and sure enough one was open circuit crossing between the two platters (backplanes) in the OCP cabinet.
Now the machine goes to the next stage and loads and runs SEM (System Establishment Manager) which is written in actual 2900 order code as opposed to the native MICOS 2 microcode. This is the first time we've actually run real 2900 code on the machine so definitely a project milestone achieved!
SEM goes on to load APF, the engineers program loader (see pic). This talks to the operator via the system console and allows loading of additional standalone engineers test programs written in 2900 order code. The next task is to construct a new "virtual tape" containing the standalone tests, which we read from the diagnostics disk pack many months back.
03/04/2011 update from Delwyn Holroyd
The project reached another major milestone this week: all of the CUTS logic tests now pass with no errors.
The message on the screen starting X002 is an artificial failure included, according to the CUTS documentation, "to inhibit non expert (i.e. customer) use of PSE". PSE (peripheral system exerciser) is the next stage in the CUTS diagnostic test suite.
Several more store boards were discovered amongst the system spares, which enabled us to resolve the remaining problems with the full store diagnostic test. This test will now happily run for hours, which is very encouraging as it relies on large parts of the OCP and SCU in addition to exercising the store.
The channel interface diagnostic test was failing due to a bug in the test itself! Although the test has parameters to specify which coupler to test, and should default to the load DCU coupler, it was actually trying to talk to a channel coupler in position 4 before even prompting for parameters. In our SCU there was no coupler in that position which resulted in a cryptic error message on the console. Having moved our channel coupler into the expected position the test passed.
Our assumption has been that once all the CUTS logic tests pass, the machine would boot: after all this is the purpose of the logic test suite! However, we still have a problem. When the machine is cold it now usually progresses to the operational engineers screen (shown in the 06/03/2011 update), but then stops with the OCP in an indeterminate state. Once warmed up the OCP microcode bootstrap does not function correctly and the SCP instead reports that the "OCP is faulty".
I spent some time analysing the "OCP is faulty" situation, but there was no obvious clue as to what the underlying problem is and the symptoms are not always the same. The microprogram bootstrap is very simple and doesn't on the face of it appear to do anything that hasn't already been tested by CUTS.
I particularly liked the advice given in the CUTS documentation for this situation: "If unable to IPL after this ... then expert engineering attention is required" !
13/03/2011 update from Delwyn Holroyd
Any former 2966 engineers (with good memories) who studied the console photograph from last week may have spotted an error in my analysis!
The system had actually stopped at some point in the handover from the microcode bootstrap to the operational microcode. In fact the system establishment manager code is on the virtual tape and should at this point in the sequence be residing in the main store of the machine ready to be run. It would have been placed there by the DCU via the 'channel interface' which connects the DCU into the rest of the system. This interface is only used for the first time at this stage of the IPL (boot) process, so a problem here would only show up at this stage. Another strong candidate is a known issue running the store in 'interleaved' mode - some of the diagnostic tests only pass in the non-interleaved configuration.
Another reason to suspect the channel interface is that it's diagnostic test program fails in a mysterious way, without a proper error code. I made a start on single stepping it to find out what is happening.
We remain tantalisingly close to being able to run actual 2900 PLI (machine code instructions). The first program which will be run is the 'APF Loader' which finds and loads further diagnostic software from magnetic tape. I made a start on looking through it's source code on microfiche to determine the expected tape format. As mentioned previously we have various diagnostic programs captured from disk and these now need to be transferred to virtual tape so that we do not require the diagnostic disk pack to be loaded in order to continue with fault resolution.
06/03/2011 update from Delwyn Holroyd
Relatively little work has taken place on the 2966 since the last project update.
We eventually traced the particularly stubborn fault discussed in the last update to an open circuit on wiring between the two platters (backplanes) in the OCP. It isn't possible to get at the connectors without removing both platters and all the boards, therefore a temporary repair has been made by bridging a wire directly between the platters.
Now that the weather has finally warmed up a bit the machine is behaving much more consistently. It has been our custom to let the machine run through the normal IPL (boot) sequence before attempting any other diagnostic work. The sequence has always been expected to fail at some point because of the various outstanding faults - usually during the microcode bootstrap, which is responsible for loading the operational microcode from the DCU.
However last week the sequence continued further than ever before and loaded OCP operational microcode and DCU and SCP operational control programs. It only stopped when it got to the point of needing the System Establishment Manager, the first 2900 PLI (machine code) to be executed in the IPL sequence, and only because SEM isn't on the virtual tape we have been using to boot from. The system console was left showing the engineers screen and with the alarm buzzer going off (see photograph).
Some more reverse engineering is now required to add SEM and the test operating system (TOSD) to the virtual tape. We have all the code from the diagnostic EDS80 pack but need to work out what format is expected on tape.
The description in the last entry of George 3 running on a restored 7501 terminal using a filestore from Manchester Grammar School prompted Mr Alan Pickwick, the teacher responsible for the ICL 1902T installation at the school, to make contact and visit the museum to see the project. It was a pleasure to show him the 2966 and reminisce on the challenges of keeping the 1902T running all those years ago, in many ways not dissimilar to the challenges being faced now in the 2966 restoration. He recalled successfully changing and re-aligning a head on an EDS60 disk drive armed only with an Allen key and an oscilloscope, despite being told by ICL that this was impossible!