Resurrection Home | Previous issue | Next issue | View Original Cover | PDF Version |
Computer
RESURRECTION
The Journal of the Computer Conservation Society
ISSN 0958-7403
Number 108 |
Summer 2025 |
Society Activity | |
News Round-Up | |
Queries and Notes | |
DEC in the UK and its Rôle in Biscuit and Crisp Manufacture | Ed Smith |
The VME Catalogue | Dik Leatherdale |
Previously Unknown Feature on the 1902A/1903A | Bill Gallagher |
Obituary : Gordon Eric (“Tommy”) Thomas | Simon Lavington |
Obituary : Dr Raymond (“Dickie”) Bird | Roger Johnson |
Fifty Years Ago .. from the pages of Computer Weekly | Brian Aldous – TNMoC Archivist |
Forthcoming Events | |
Museums | |
Committee of the Society | |
Aims and Objectives |
EDSAC — Andrew Herbert We have now resolved issues with the Transfer Unit and are now back to commissioning the Arithmetic Unit. The final problem turned out to be that our microprocessor-based monitoring system was injecting crosstalk noise into the unit. Since Nigel Bennée has been able to rejoin the team we have been focussed on the interface between the Arithmetic Unit and Main Control (instruction fetch and decode). The timing of this interface was disrupted by the introduction of the now fully commissioned Transfer Unit. The two principal data paths, from the store to the Multiplier and Multiplicand registers respectively, have now been verified as working, and the two registers (implemented as recirculating delay lines) correctly retaining their content once loaded. Work is now resuming on commissioning the arithmetical orders, picking up from where we were last November. Tony Abbey and Simon Porter have started work on commissioning the interface between Initial Orders and Main Control. The Initial Orders subsystem has been working for some time, the commissioning is concerned with how this subsystem persuades Main Control to load the initial program from the uniselectors into the store. The circuits for this have been latent in Main Control for some time but only now are being tested and the usual issues of pulse timing and signal levels are being worked through. The electrical noise generated by the uniselectors and relays in the electromechanical part of the subsystem has been problematic, but is now suppressed. At the time of writing, the overall Initial Orders process sequencing of events is working, but data is not being correctly transferred to store. Hopefully this will be fixed in a few weeks. No major progress has been made with the electronics of the paper tape reader subsystem. This has been temporarily put to one side while progressing Arithmetic and Initial Orders. At the risk of giving a hostage to fortune, some parts of EDSAC are now regarded as fully commissioned and generally continue to work from week to week, which is quite pleasing given the folklore about the relative unreliability of the original. Our major source of problems is disturbed inter-chassis wiring resulting from testing during commissioning – fastons get accidentally knocked off, or signal wires are temporarily removed and not put back, or put back on the wrong tag. |
Delilah — John Harper Funding is in place to make a pair of new sets of modules. They will be as close to my original as possible physically, but will include changes such as a much more stable power supply |
Perforated Sheets — John Harper Recently I have started a new project. During the early years of WWII German Enigma operators sent their own three letters twice encoded at the current setting before the main message was sent. It was realised at Bletchley Park that as the letters were encoded on the Enigma machine at the settings of the following main message, there was an encoded relationship between the first and fourth, second and fifth, third and sixth letters. The method used to break these early settings was to produce perforated sheets that when stacked on a lightbox to a set of positions derived by studying the rest of the message left just one or a very small number of lights shining through. Further analysis was applied from which the enigma settings were found. To create the necessary perforated sheets, the data is converted into Gcode (a programming language for controlling computer numerical control (CNC) machines) with which my engraving mill can laser cut the holes onto paper. We have learnt that standard A3 120 and 350gsm black paper works well. Sheets have 52×52 possible holes being 260×260mm in size, each sheet taking about 70 minutes to cut. However, we have encountered a small problem where when the laser cuts a hole, due to a very small amount of backlash in the drive a small whisker holds the chad in place. To eliminate this, it has been necessary to cut the hole twice using both clockwise and anticlockwise Gcode commands. This appears to have solved the problem with the remaining centre of the hole dropping out cleanly. For a full exercise in WWII, Bletchley Park had to produce many thousands of sheets, but we are assuming that we know the wheel order as we did with the Bombe Rebuild so that studying previous traffic, we were able to determine the wheel order used for a particular transmission. As we assume the wheel order, we can repeat the stacking process with just 26 sheets. A test run with four sheets gave the expected result with the assumed wheel order. We are now in the process of producing sheets for the same wheel order as we run on our present Bombe in order that we can make direct comparisons between the two methods of finding Enigma settings. The long-term aim is to set up a master class where both techniques can be demonstrated. |
Data Recovery — Delwyn Holroyd ICT 1301 Readers may remember that just over a year ago we started to capture data from ICT 1301 tapes using one of Flossie’s original tape decks, based on the Ampex TM-4 transport. Since then, the handful of tapes held at TNMoC have been captured. Late last year Rod Brown brought over the remaining tapes – a large stack contained potentially the most interesting and valuable data.
Unfortunately we hit problems only a couple of tapes in when the deck started to chew up the tape being captured. By an extraordinary stroke of luck the tape was being chewed by the capstan roller after the heads. I saw the problem and stopped the deck about 0.5 seconds after what turned out to be the end of recorded data on the tape! The tape speed varied wildly during the capture, but luckily the tape format is not sensitive to that. There was also a lot of skew that required manual correction, but I was able to decode all the data on the tape error free. A sigh of relief then, but this incident has brought home the importance of checking the tape path for oxide build up after every tape and the need to keep a close eye on the tape whilst it’s running.
I decided it would be a good time to address the other known issues with the deck, namely the capstan motor and the cabinet fans. The capstan motor required new bearings and the run capacitor. The cabinet fans have likely been inoperable for many years – this was probably ok when Flossie was running in her chilly barn, but in the warm environment of the Large Systems Gallery at TNMoC I was concerned about the potential for overheating during long data capture runs. The deck contains Thyratrons for pinch roller control as well as the reel, capstan and vacuum motors, so a lot of heat is generated. Both fans required attention to their bearings and one which was open circuit required new external wiring – a tricky job to solder directly onto the very fragile windings. Finally, the cabinet wiring to the fans had damaged insulation and part of a fuse holder was missing so this was all rewired and a terminal block installed to allow the fans to be easily removed for maintenance in future. ICL System 25 The ICL System 25 at TNMoC has for many years run simple demonstration programs loaded from cartridge tape, but the tapes have never been reliable and recently it has not been possible to load any of the demonstration tapes, nor to create new ones, so some other solution was required. Johan Iversen (the museum’s System 25 expert) and I sat down to consider our options. One possibility was to design a solid-state tape drive emulator – the interface details were located in the museum’s large collection of ICL technical documents held on aperture cards. Another option considered was to emulate the terminal interface, allowing a program to be injected into the machine as if being typed in by a user. The third option was the hitherto unused disc controller in the spare System 25. The museum has a small collection of hard drives salvaged from various System 25s. Some years ago I had captured the data from these MFM drives using a “Disc Ferret” USB capture device. Johan discovered that one drive contained a bootable copy of the System 25 disc operating system, DMF III. Due to the age of the drive, it didn’t seem wise to rely on it continuing to work long term, but building an MFM disc emulator would be a good way forward. As luck would have it, someone had already done a lot of the hard work! David Gesswein, based in the US, has an open source MFM reader / emulator design and supplies the PCB for a nominal fee. I ordered the PCB from David and set about building the unit. It uses a Beaglebone Black SBC, which is based on a Texas Instruments SoC. The SoC consists of an ARM processor running Linux and two “programmable real-time units”. It is the latter that make this device suitable for emulating an MFM hard drive. Unlike more recent interfaces such as SCSI, IDE or SATA, the interface to an MFM drive is very low-level. The host controller sends a serial stream of MFM encoded clock and data bits to the drive which are directly recorded onto the disc surface as flux reversals. The PRUs are fast enough to handle the task of capturing and generating the MFM pulses with the necessary precision. The emulator works in a very similar way to the one I built for the 2966, although in the latter case an FPGA handles the much faster serial data rate from the ICL CDC drives. It is the host controller that decides the details of the track format, including the number of sectors, sync patterns, gaps and error correction codes. All these details must be known to recover useable sector data from MFM clock and data pulses, and to recreate MFM pulses from sector data. Being an ICL machine, of course the System 25 has its own unique track format! Once again. the ICL aperture card and microfiche collection came to the rescue, producing copies of the product specification document (PSD) for the disc controller (known as the H coupler) and the circuit diagrams. The PSD gave all the details of the track format except for one vital piece of information – the polynomials used for the CRC and ECC codes protecting the header and data fields respectively. A study of the circuit diagrams revealed that the codes are generated using a Western Digital chip, and Bitsavers provided the data book containing the polynomial – twice luckily as the first mention of it turned out to be missing one term! The idea was to create an offline workflow for software development where an image from the MFM emulator could be converted to sector data, modified on Johan’s System 25 simulator and then transferred back to the MFM emulator to run on the real machine. We now had all the pieces in place, but the first test of a re-encoded MFM image failed to work – the first sector on each track was inaccessible, but later sectors could be read. I went back to a dump of the original hard drive and discovered that the gap between the index pulse and first sector was slightly longer than in my image, which was using the gaps specified in the PSD! Having changed the gaps to match the real hard drive, the image worked successfully. There are still a couple of issues to track down, but we’re well on the way to having a functional system. David Gesswein’s website: www.pdp8online.com/mfm/mfm.shtml. |
Harwell Dekatron — Delwyn Holroyd The negative power rails have been going over voltage at power on, eventually settling down. This problem has been getting steadily worse until it became necessary to replace the pair of EL360 valves in the stabiliser unit which regulate all the negative rails. In fact, on testing one of these was still serviceable and will be matched up with another part used one in future. Because the valves are in parallel, they have to be fairly closely matched to ensure the load current is shared equally between them. We have seen another warm-up problem recently that disappears after a few minutes – not long enough to properly diagnose! The issue is the Dekatron in the pulse generator on spins more than once before stopping. I can’t yet be sure but my suspicions lie with the pair of high-speed trigger tubes in the pulse generator. When these eventually fail it will be necessary to build a replacement circuit as working examples of these parts are few and far between. |
ICL 2966 — Delwyn Holroyd The beginning of March saw a major re-organization of the Large Systems Gallery at TNMOC which has housed the 2966 since 2008 when it was brought into the museum from D Block, having languished there since 1999 when it was decommissioned by Tarmac. One of the impressive features of the system is its sheer size, which always amazes younger visitors. However, that size also means it occupied a significant amount of space in the gallery. In order to freshen the gallery and make space for other working exhibits the decision was made to move some of the 2966’s disc drives into storage. Unfortunately, some of the drives suffered water damage whilst in D Block. The remaining drives on display are the cosmetically better examples and still include a mixture of EDS 80, FDS 160, EDS 200 and FDS 640 drives. The large Bryant disc platter (used on 1900 systems) which used to lean against the drives has now been wall mounted along with the smaller platter. The space in front of the 2966 is now occupied by a DEC PDP 11 and the ICL System 25. The space previously occupied by the ICL System 25 and DRS 6000 has been taken by a recently restored Ferranti Argus 500. All these systems are working. |
ICL 1900 — David Wilcox, Bill Gallagher, Delwyn Holroyd David Wilcox reports that he is still progressing 7903 emulation. He can now successfully run the built-in online test program with teletype devices both reading and writing. That is a fairly significant step forward. He can also download the DCP and configuration from his George 3 system, but has yet to persuade George to communicate with the attached terminals. Bill Gallagher continues to scan and sort 1904S material recently received from Phil Brady. |
Science Museum Group — Rachel Boon Science and Industry Museum New web pages – Alan Turing Objects and Stories are now online. They discuss the collections we hold around early Manchester computing, and respond to questions we often get on the gallery around the Baby computer. See www.ccsoc.org/smg1.htm. Baby volunteers have been issued with new touchscreens to go alongside the new content which was installed near Baby at the end of March. The new content highlights the vitally important CRT memory around which Baby is built, and presents a people story about Geoff Tootill, so that audiences can find out more about the people who built Baby. Baby volunteers and colleagues from the Museum also featured in a student film organised from the University of Manchester recently. The filmmakers made the production an insight into the volunteers, exploring why people volunteer, how they interact with the visitors, what they get back in return – and the importance of volunteering to the museum. Baby features extensively and we will receive a copy once editing is completed. Science Museum Somaya Langley, Digital Preservation Manager is defining the Science Museum Group’s policy on collecting and conserving digital material. This includes requirements for quarantining digital content on carriers and virus scanning of digital content before being transferred to main networks. We would warmly welcome any examples of projects like this from your own working groups or wider sector. Rachel Boon and Doron Swade contributed to a documentary about Charles Babbage and his engines filmed at the Science Museum and the Science and Innovation Park. Science and Innovation Park (formally Wroughton Collections Centre) The Science and Innovation Park (SIP) is open for research requests to both the Library and Archive and object store. Find out more, including how to request an appointment on the SIP website at www.ccsoc.org/smg0.htm. |
The National Museum of Computing — Charlie Hathaway Work has recently been completed to rotate collection items in the Large Systems Gallery and PC Gallery, replacing static with working machines. We are currently working on new object labels/signage for the Large Systems Gallery, planning to complete by July. The “Flowers to Fibre” collaboration with the Communications Museum is now fully installed and working, it will be in place until March 2026. We have collaborated with Reading Museum on “Reading’s DIGITAL Revolution” – TNMoC has lent DEC equipment, including the Blacknest, a BBC Micro and a Hollerith Punched Card Machine to the Reading Museum. The Museum has begun a large project to inventory the collection in reserve currently held at an off-site storage facility. We have recently accepted a donation of a Chilton Atlas Ampex TM2 Tape Deck, which will be stored in the workshop space off-site so that Delwyn can work to recover Atlas software from the tapes. We are currently conducting extensive audits of the TVs & Monitors and Mobile Phone collections in the museum and compiling an inventory of the ICL One Per Desk equipment. We are working with our collection in reserve for Atari, TVs & Monitors, Consoles & Controllers on power testing and repairs. |
Elliott 803, 903 & 920M — Terry Froggatt 803. Peter Onion reports that a few weeks ago a fault occurred in the 803’s floating point maths logic. Running the X6 test program showed that every test was failing. Examination of the mantissa register showed constantly changing values, even when the machine was stopped, when it should have been clear. The fault was quickly traced to a missing inhibit signal that prevents the contents of the accumulator from entering the mantissa adder except when required. Peter took the faulty board home and, using a recently recovered board edge connector, he built a board test rig. This provides the appropriate signal levels to the two trigger drivers and also generates the logic level signals to inject into the logic gates. This is only the second time he has needed such a tool to find a logic fault. Further tracing found a gate with a small output pulse that was not setting the following gate. A replacement OC84 output transistor fixed the problem. The 803’s Paper Tape Station has had a couple of issues lately, but on both occasions the faults have cleared before diagnosis could begin. As Peter says, sometimes just removing and replacing a board can fix faults! 903. TNMoC is currently looking at upgrading the mains distribution boards around the museum to accommodate RCD protection as part of H&S compliance. When the 903 was tested with a portable RCD breaker it instantly tripped. On further investigation Peter Williamson found that the main culprit was the fan tray. When a 920B or 903 is turned off at the control panel, relays turn the secondary side of the MCB24 power supply transformer off, but the primary side remains connected to the mains. So it is usual to also switch off at the wall, or unplug at the wall if there is no switch. Back in the late 1960s, I did just this on a 920B, and I happened to touch the live and neutral pins of the unplugged 13A plug, which gave me quite a shock. Yes, there are filters in the live & neutral wires which include capacitors to earth. On a 903, these filters are in the fan tray, and there are resistors to take away the residual charge on the capacitors. Some years later when I got my own machine, which has the filters but no fan tray, I promptly fitted 82 Kohm 2 watt resistors. So this is a well-known problem. If the capacitors don’t trip the RCD breaker, the resistors certainly will. A good fix is to isolate the filters from earth but leave them connected across live and neutral. This is what Andrew Herbert and I did when we installed Don Hunter’s 16K 903 at Andrew’s house, and what I did when I prepared Don Hunter’s 8K 903 for CCH.
The photo shows the filters lifted off the chassis. The resistors are under the “Mains Voltage” tag. And what we didn’t spot initially was another connection to the chassis under that tag. Peter Williamson also found that the 5-pin connector on the mains cable for the 903 extra store cabinet was incorrectly wired. I think I remember a similar fault on one of Don Hunter’s 903s. It has duly been fixed 920M. As I write this, I’m sitting in my Computer Room surrounded by no less than ten Elliott machines, which include six 920Ms from a private collection which I have been asked to test. These are outside my reporting brief, but I’ll mention that the core store in one of them still contains the waypoints for a Jaguar mission from Germany to the UK and back. Whilst doing these tests, I decided to un-wire-wrap a few modules from my eBay 920M serial 5343, and explore them by plugging them to a 40-way IDE cable, which has the right pin pitch, wired to a ThinkPad printer port. I’m happy with the 920M wiring schedule which I’ve published on my website at www.tjfroggatt.plus.com/MCM7.HTM but I’ve found that some of my speculations about the internals of the modules are not quite right. I hope to publish an addendum before the next Resurrection. I’ve offered the use of my 920M test rig to evaluate a further six 920Ms from a private collection. |
Many CCS members will remember Jonathan Aylen’s masterful 2018 presentation on the British Railways TOPS computer system (see www.ccsoc.org/ayl0.htm and thence the associated video of the lecture). Since that time Jonathan and his collaborator Robert Gwynn have undertaken a great deal of further research into the subject, much of it concerning the pre-history of TOPS. The results of their labours have been published in a new paper atwww.ccsoc.org/ayl1.htm. Well worth a read. A contemporary British Transport Films video on the subject can also be found at www.ccsoc.org/ayl2.htm. It makes an excellent companion piece. 101010101
Our friends in the LEO Society report that the building in Hammersmith which replaced Cadby Hall (headquarters of the Lyons organisation and the location of LEO 1) some 40 years ago is, in its turn, about to be demolished. Hoardings have been erected which explain the history of the site and include information about the creation of LEO the world’s first commercial computer. Go to www.ccsoc.org/cadbyhall.pdf for more pictures. Hat tip to Peter Byford for the photos. 101010101 The School of Computer Science at the University of Manchester has a large collection of photographs and videos of their historic achievements. The collection is now online at history.cs.manchester.ac.uk/. |
A recent enquiry from the grandson of a former BCS President brought forth a veritable tsunami of reminiscences from leading CCS members. The CCS has, of course, quite a lot of ex-BCS Presidents amongst its membership, many of whom continue to serve on the CCS governing body long after their time as CCS chair has passed. 101010101 Can anybody account for the sudden explosion in the number of retail businesses dealing in second-hand mobile ’phones and vapes? One or the other is quite understandable, though perhaps not entirely respectable. But the combination of these two apparently unrelated products in such numbers seems bizarre. Twickenham, not exactly a contender for retail capital of the year, boasts no less than seven such emporia. Why? Somebody must know. 101010101 A newly joined CCS member has asked a question which the CCS great and good have thus far been unable to answer – I am reaching out to inquire whether your society holds any documentation or archival material related to the Compucorp 300 Series calculators. We are particularly interested in technical information concerning the internal logic of these machines. Any type of resource would be highly appreciated – be it a reference to items in your collection, contact with someone in your network who may have worked on or maintained these calculators, or even leads to former vendors or companies that might still have archived documentation. To give some context to our request: we are currently reverse-engineering these machines and have made significant progress. We are now able to observe the strings of microinstructions traveling across the data and control lines. A deeper understanding of these microinstruction strings would greatly aid our work, though any general technical information would also be of great help. If anybody out there can help, please contact the editor. |
DEC’s origins and development. The origins of the Digital Equipment Corporation (DEC) can be traced back to MIT’s Lincoln Labs, where founders Ken Olsen and Harlan Anderson noted that students preferred to work on a machine known as TX-0, rather than a faster IBM machine, causing them to consider the potential market for interactive computing. TX-0 grew out of MIT’s involvement in the US military Whirlwind and SAGE projects, and the desire, once those projects had completed, to develop a machine based on transistors rather than valves. The 18 bit TX-0 was built in 1956 as a proof of concept and was succeeded by a 36 bit machine, the TX-2, once the idea was proven.
Olsen and Anderson set up their company in 1957 when computer companies were seen as high risk investments and they were advised to avoid using this label. They therefore chose to call their new company the Digital Equipment Corporation, setting up their operation in an American Civil War era textile mill in Maynard Massachusetts. Their original proposition was to sell computer modules as standalone devices that could be purchased separately and wired together to form solutions. Their first products were based around their MIT work and their first computer was marketed in 1960. They are probably best known for their PDP-8 and 11 minicomputers and later their VAX range. Their first computer the Programmable Data Processor (PDP) was designed in 1959, had an 18 bit word and supported 4K words of transistor based memory. It was followed by the 18 and 24 bit PDP-2 and PDP-3 machines and a cheaper derivative of the PDP-1 known as the PDP-4, which was re-implemented using a new chip design as the PDP-7, with a more dramatic upgrade it became the PDP-9. A 36 bit machine the PDP-6, intended to take DEC into mainframe market, ultimately evolved into the well-known PDP-10 range.
In 1962 DEC launched the PDP-8 as a 12 bit machine that sold for less than $24k and is considered, by many, to be the world’s first minicomputer. In its original form it was based on germanium transistors and up to 4K magnetic core memory and was the size of a domestic fridge. These were sold through original equipment manufacturers and over 50,000 were sold. The machine evolved over time and the last commercial model sold in 1979 was based on CMOS LSI technology. DEC did not initially believe that a 16 bit minicomputer would sell, leading to Ed De Castro and other designers leaving to form Data General. They launched their company with the 16 bit Nova and its success caused DEC to re-examine their position and develop the 16 bit PDP-11 in 1970. This leads on to the development of the VAX in 1977, which was very successful. In 1988 they became the world’s second largest computer company. However, this level of success could not be sustained as microcomputers became more popular and the market for minicomputers declined. The company got into financial difficulties and in 1998 they were acquired by Compaq, who merged with Hewlett-Packard in May 2002. DEC in Reading In keeping with the company’s policy of using functional buildings, DEC opened its first UK offices above Bilbey’s furniture store at 11 Castle Street in Reading, premises that had once been a bingo hall. When it began operation in 1964, the UK office was run by John Leng and one other employee. The initial products included a magnetic core tester and products based around the PDP-8. As DEC’s UK presence grew, the business moved to what started as a single building in Arkwright Rd and quickly grew to five buildings: Sales and Marketing had the least spartan building, with senior management, low volume manufacture, hardware engineering and software engineering occupying the others. These buildings had the appearance of long (forty foot) single story “sheds” each with a single central corridor with offices and labs off either side. Further expansion led to a move to Acre Rd, which was a warehouse type building, a little further out of town. DEC rapidly became Reading’s biggest employer and in the 1970s and 1980s the workforce grew to over 2,000 people in the town. In 1981 the operation was moved to DEC Park, a purpose-built facility at Worton Grange near to a junction with the M4. DEC Park was well known for the pyramid shapes on its roofs, its central thoroughfare known as “The Street” and the open plan campus environment. All the time it was in Reading DEC had some small-scale manufacturing capability for specialist products engineered to suit the European market. DEC had a manufacturing plant in Ayr, which started as a small factory built by the Scottish Development Agency, and grew to a facility employing 3000 people. This was a final assembly and test plant. The largest factory in Europe was probably Galway, which employed somewhere between 3,000 and 5000 people. There was a second Irish factory at Clonmel. The company played a major role in establishing the Thames Valley as a key part of the UK’s IT industry and in the 1980s it was DEC’s most successful national subsidiary. The PDP-11 and its architecture The DEC PDP-11 was a 16 bit machine, which could address at the byte level but could utilise memory management to allow memory protection and addressing of more than 64K bytes. It inspired the design of late-1970s microprocessors including the Intel x86 and the Motorola 68000 and over 600,000 were sold. It supported a number of operating systems, most notably RSX-11M, originally defined by David Cutler, who went on to play a major part in the development of VMS, the operating system used on the VAX and later,Windows NT. RSX allowed the development of real time event driven real time applications in a multi-tasking environment as described later in this article. The first processor launched was the PDP-11/20 and the range ultimately spanned from the PDP-11/03 to the PDP-11/94, with CPUs running at 4 MHz and 18MHz respectively and spanning a power differential of about 20. The PDP-11 was based on a 16-bit instruction set, with each instruction comprising a 4 or 10-bit operation code and one or two 6-bit fields representing the source and/or destination operands. Each of the latter could be divided into two 3-bit fields representing the register number and the addressing mode. The addressing mode determined if the operand addressed was a variable, an address or the address of an address, it also allowed indexing by adding an offset to a register acting as a pointer. Other modes allowed incrementing or decrementing the address pointed to by a register. The PDP-11 had six general purpose registers plus one register (R6) which acted as a stack pointer and one (R7) acting as a program counter. The stack that was addressed through R6 was a Last In – First Out stack and was central to subroutine linkage and interrupt handling. The table below shows a fragment of code using the Macro 11 assembly language used on the PDP-11. Here the result variable is cleared and a counter set to 10 using register 0. The contents of register 0 are added to the result variable and the counter in R0 decremented in a loop until the value in the register is zero and iteration is stopped. (The example is kept simple for illustration, but once register 0 is equal to zero, the next instruction would be the RESULT variable, containing 60, which would be an illegal instruction.)
Additional elements of the PDP-11 architecture will be described, in the context of the applications used by United Biscuits to automate production processes. United Biscuits – Harlesden The remainder of this article will look at how United Biscuits used the PDP-11 to control production processes for their food and biscuit divisions. Their main data processing division ran an IBM 370 based installation in Liverpool and a team was formed in Harlesden in north-west London to look at factory automation. This was a mixed team of hardware and software engineers, who began implementation using IBM System 7 computers, but by the late 1970s had switched to the DEC PDP-11. The Harlesden factory used a PDP-11/40 for live working and an 11/34 for development. A factory could be run using computers with 32K words of memory (16 bit word) and removable discs with a capacity of 2.5 MB. The factory machines interface with DEC PDP-11 computers via GEC Media interfaces.
The business objective was to use the technology to improve the efficiency of the biscuit plant by monitoring equipment failures, waste and the adherence to minimum product weight regulations. The latter required the computer to interface to analogue based devices such as Hunting check-weighers as well as digital (on/off) signals and switches that enabled the control of individual pieces of equipment. The interface to these devices was by means of an interface known as GEC Media, which provided digital to analogue conversion and performed the necessary voltage conversions and signalling between the computer and the plant. Information was presented to the computer through a hardware mapping between the status of Media and the top 4K words of the computer’s memory. This was a technique known as memory mapped I/O, which relied on a user program regularly monitoring the state of Media and did not involve any processing of interrupts. Some of the principles are shown below.
This relied on exploiting a capability in RSX11M known as a common area, this allowed authorised processes, in RSX parlance “tasks”, to share access of a portion of memory, under the protection of the memory management hardware. The common area would be mapped to the top 4K of memory, which was shared with the interface to Media. The necessary permissions were set up when executables were assembled from individual object files, using a process known as task building (in some circles called link editing). Individual digital inputs from and digital outputs to a piece of plant would be grouped and expressed as a word in memory, where they could be written or read by a program with the necessary memory access privileges. Similarly the weight output from the check-weighers would enter the Media system as an analogue voltage and be transferred to a memory word as a digital expression of that voltage, clearly a calibration process was needed to convert this to a meaningful weight value.
The user interface that allowed users to change products, monitor plant status and monitor production status also had a number of novel features. Terminals were adapted Lynwood DAD-2 terminals with the QWERTY keys replaced with single function keys spanning three character positions and a straight forward numeric key pad. So if a user wished to request a report, he or she pressed the large key labelled “report” and an interactive session would guide them through report selection and enable them to enter relevant parameters. A Motorola MC 6800 based controller translated these inputs into standard ASCII key strokes, conformant to the expectations of the PDP-11 software. The MC 6800 controller was connected to a Cambridge Ring style local area network and interfaced to the PDP-11 via a DU-11 interface. Plant status was reported through a series of laminated punched cards, pre-coded to reflect specific issues and their clearance. There were read using devices known as badge readers, that were also connected to the MC 6800 devices. This arrangement was known as the “Harlesden Loop” and is shown here. All the applications were programmed in RTL/2, an Algol- like high level language developed by John Barnes (of Ada fame) at ICI or in the native DEC assembly language Macro 11. Typical functions were to manage and record biscuit packet weights to ensure within tolerances, rejecting underweight packets. Systems also managed the current status of the factory, note when plant was down and manage its repair. There was also the means of recording raw material waste and managing the efficient use of raw materials. Crisp Weight Control
United Biscuits Food Division operated crisp manufacturing plants at Ashby-de-la-Zouch, Billingham and Grimsby. Here the cooked crisps were expelled from the fryers onto overhead conveyors, which distributed the product onto tributary conveyors, which fed rows of crisp bagging machines. There was a need to ensure that the bags of crisps that were delivered met the minimum weight specification, without giving away large quantities of product. This diagram shows the hardware set up for a crisp weighing machine and its interface into the computer. Note in this case there was no equivalent of the Harlesden loop and conventional Lynwood terminals were used. As before the interface between the plant and computer was via GEC Media. Vibrators shook the crisps down towards the weigh pan, access to and exit from the weigh-pan was controlled by two access gates known respectively as the lip gate and dump gate. At the bottom of the machine was a three-way switch that could be set to: “machine under local control”, “machine under computer control” and “tare” (calibration). When the switch was placed in the computer control position, the computer would monitor the state of the various machine interfaces, taking control at the start of the next cycle and signalling that it had accepted control by turning on an indicator light on the machine. The weigh pan sent an analogue weight towards the computer and this was converted into a digital value by the Media system. The digital inputs to the computer were bits that reflected the state of the three-way switch (tare, local control, computer control), together with the digital representation of the analogue output from the weigh pan. Digital outputs consisted of controls that opened and closed the lip gate, started and stopped the vibrators, opened and closed the dump gate and turned the computer control lamp on and off. Crisp machines were two types, Wrights and Woodmans, and up to 16 machines could be referenced by one analogue input card on the Media system. Each machine had four digital inputs to accept commands and four digital outputs. The crisp weighing machines were arranged in lines, each line interfaced to a watchdog timer on the Media system. If the watchdog timer was not pulsed every 220 milliseconds all the machines would revert to local control. The software running on the PDP-11 included three principal control programs. The main control program pulsed the watchdog timer, polled and monitored the quantity of product in the weigh pan and controlled the weighing process. A second lower priority weighing program managed the switch from local mode to computer control and vice versa. It also handled machine calibration. A third control loop handled the calculation of the final weight of each bag produced and implemented an algorithm for identifying when to stop additional crisps being added to a bag. The system kept track of the weighing process by means of a linked list of control tables. Each line of machines was represented by a line control table, which linked to a list of control tables, each one of which stored operational parameters and data used to control the machine it represented. Information was extracted from these tables by another program which accumulated reporting data in core on a regular time-dependent basis. Once such data occupied half of the program’s data storage space a further program was summoned to add the accumulated data to disc files, thus minimising the level of disc access required. Production reports were produced per line automatically every hour and could be requested at any time. Diagnostic programs were provided to produce analogue traces of a given weigh pan, to log crisp final weights over a period of time and to dynamically display a given weigh head’s control table. The weighing cycle began with the computer activating the vibrators, opening the lip gate and closing the dump gate to allow crisps to pass onto weighing pan. At this stage the computer continually monitored the output from the weighing pan and once it detected that minimum weight had been reached it stopped the vibrators, closed the lip gate and opened the dump gate. This allowed the crisps to fall into the bag and the bag to be sealed. Some crisps would still be “in-flight” when the minimum weight was detected and the lip gate closed, meaning the weight measured was an underestimate of the actual weight of the crisps that would be dumped into the bag. To allow for this the computer recorded and tracked the weight of in-flight crisps as a moving average and statistically used this to anticipate when minimum weight would be reached. If the computer overestimated the weight of the in-flight crisps then it could reactivate the vibrators and briefly open the lip gate ahead of activating the dump gate. This allowed the bag weight to be made up to the statutory minimum. Once the crisps had been bagged, then the dump gate could be closed, the vibrators activated and the lip gate opened to fill another bag. The systems also required programs to set up the machine for a specific product and provide production reporting. Up to 60 machines could be controlled and all programming was done using Macro 11. Conclusion In this article, the origins of DEC as a company have been examined, along with setting up its UK subsidiary, with the emphasis being placed on the PDP-11, not just its architecture but also its use in two specific industrial applications.
|
So let’s see if we can shed some light on the structure of the catalogue and its purpose. We’ll start with a serious oversimplification. The catalogue is acollection of records each of which contain data and pointers to other records (a CODASYL database in essence). There is an origin to the structure called the INSTALLATION NODE which is located in a well-known place. 1 The INSTALLATION node “owns” USERs and they, in turn, own FILEs each file having a relationship with a volume which tells VME where to find the file. Here we have the first break with modern technology because we can see that ownership doesn’t need to be related to location. In the example above we should note a number of thi
But as we noted before, the diagram above is an oversimplification. The astute reader will have noticed that no mention of the whereabouts of the filename has been introduced. Surely that is in the FILE node of the catalogue. Not so! Now we must introduce “relationships”. The relationship node lies between the USER and the FILE and it is here where the name of the file is held. Two differences can be seen in this new diagram. Firstly that the USER node does not contain pointers to each of its owned files, but is the origin of a chain of relationship nodes each of which contains the filename and a pointer to the FILE node where most of the useful information is located. But we can also see that : USERA has created a relationship with : USERB. MYFILE. This is known as an “alias” and it allows : USERA to refer to the file as HISFILE. Although the alias is quite interesting, it is not, in itself, much used. But there is a form of alias which is much more useful. Here we introduce the concept of “specific privacy”. : USERB can choose to allow : USERA some access permissions to the file like those specified by the file’s general privacy setting but with a potentially different setting.. Any clash of permissions is resolved in favour of the most generous. The mechanism which supports this is that the operating system creates an alias with a unique name, the alias carrying the specific privacy setting. So we are inching rather slowly towards a description which can be taken as reasonably accurate but we have some way to go yet. For now we can forget about relationships and take them as read.
Our next enhancement is FILEGROUPs. Think of a Unix or Windows folder and you’re almost there. A FILEGROUP is uniquely named within the set of FILEGROUPs owned by a USERNAME but, unlike Unix/Windows the set of filenames is separate. As with folders FILEGROUPs can own subordinate FILEGROUPs recursively. Creating files within a FILEGROUP can be done simply for the sake of neatness but more usefully it can support a privacy structure. As with FILE aliases and hence specific privacy relationships FILEGROUPs are supported in exactly the same way. In this diagram : USERA has created a FILEGROUP TOPGR within which lurks a subordinate FILEGROUP which can be refered to as TOPGR/BTMGR. There is also a FILE OWNEDFILE which can be referred to as TOPGR.OWNEDFILE. :USERB can see that as :USERB.TOPGR.OWNEDFILE. If :USERA has created (for example) a write relationship between TOPGR and :USERA then subordinate objects like OWNEDFILE will inherit that permission. As before, any ambiguity is resolved in favour of the most generous setting. Working yet further downwards in the structure we should note the existence of “primitive files” and “file sections” subordinate to the FILE object. But this article is just an introduction to the catalogue, so we will ignore this complication which doesn’t add much to the total.
Now we must introduce the reader to “libraries”. Libraries do not seem to have figured in the original design of the catalogue but were added in fairly early on. A library is a collection of similar serial files all with the same characteristics and all in the same place on disc. The files within the library do not have any privacy settings. These are inherited from the owning library. Only the name and contents differ between member files. The catalogue supports libraries as a special sort of FILE node but instead of leading the user to a file, it leads him to an index of files. This index lives outside the catalogue on a disc. The full name of a member file in the diagram above might be :USERA.TOPGR.MYLIB.SOURCEFILE0. Typical use for a library is as a host of the complete set of source files for a program. More importantly executable files of object code must be held in libraries since the loader will only seek executables within libraries (more about this in a later edition of Resurrection perhaps). Note that, in this case there is no relationship node intervening between the index and the file. That said, however, there may be more than one index entry for each file. These additional index entries are known as “synonyms” and it allows the user to refer to the file by more than one name, in this case :USERA.TOPGR.MYLIB.S0. In the early 1990s many public sector organisations were instructed to mandate Open System conformity (meaning support for Unix) in their purchase of computer equipment to avoid lock-in to one supplier. VME at that time was not compliant. So a serious effort was made to introduce Unix support to VME and to do it in such a way that both traditional VME applications and Unix apps could be run side by side. But Unix filestore, as we have noted, is structured in a rather different manner than VME’s. The problem was resolved noting that a VME library index was just a special case of a simple serial file. Thus by allowing “libraries within libraries” replicating the Unix file structure the problem was solved at modest cost albeit it is a little more complex than described here. We started this description with the idea that FILEs live on VOLUMEs and that there is a connection between them in the catalogue which reflects the reality. Now this is indeed the case for magnetic tape files, but for disc files it’s more complex. Somewhere between the disc FILE objects and the VOLUMEs is a complex web of CATEGORYs, PARTITIONs, PARTITION PLEXes and (formerly) CONTROLLING FILEs all of which are “owned” (directly or indirectly) by USERs. But again, these bring little to the party and we will leave them to one side today. Life’s too short. Thus far we have examined the catalogue’s support for filestore. But there’s more to it than that. There are various non-file objects which hang off the USER node. Most of these don’t add much to our understanding of the catalogue’s structure and capabilities. But a special mention should be made of USER OBJECT NODEs (UONs) which hold small amounts of information (< 2Kb) and are used to steer applications in a similar manner to the Windows Registry. There are two interesting special forms of USER OBJECT NO
So there you have it. Not the whole truth, but perhaps sufficient to give a flavour of what was offered half a century ago. A different way, arguably a more sophisticated way to hold information all in one place and designed as a complete solution rather than being implemented piecemeal as in some other operating systems. The heroes of this development were Tony Gale and then Alan Kitchenham two of ICL’s finest. Well done lads I say.
|
1. Not quite. The catalogue origin was called the FOUNDATION NODE and this had a pointer that led to the INSTALLATION NODE.
For some time we had only a few ICL 1902A/1903A documents – the Technical Description etc, intended as an aid to field engineering. I will use the term PF50 as did ICL to describe a range of processors from Stevenage which all had a common core platform. The various speeds etc were a result of different clock and store options. One of these documents shows an interrupt source called ‘Inter Processor Interrupt’. We knew that the West Gorton machines 1904E etc supported multi-processing resulting in the 1906E/F and 1907E/F machines. The mention of inter-processor sounded strange in the context of the smaller Stevenage machines. My initial thoughts were that they were associated with some Inter Processor Buffer (IPB) or other. The same documents mentioned also two related executive mode instructions – 150E and 151E, but no further details were provided. This remained the situation for some years. Then a veritable cache of PF50 documents arrived. Hidden in a pocket in one of the folders was an A2 logic drawing, a problem to scan. It is without any of the usual Stevenage style document numbers but written on the reverse in large letters is “128 MULTI-PROCESSOR MACRO 6169”. Now that 6169 certainly sounds like a PCB number for the PF50 series (all the cards were numbers in the 6000s). It also carried the legend “MULTIPROCESSOR FUNCTIONS 150/151”. That chimed with the West Gorton machines from the 1904E onwards using 150E and 151E for Multiprocessor synchronisation in executives. But did these instructions act in the same way as their West Gorton counterparts? The diagram shows a set of seven bistables (or binaries as ICL called them) named MP0 through MP6. The surrounding signals clearly made them a part of the PF50’s instruction sequencing logic, and they followed the same style of usage making it easy to determine the sequencing of these binaries. Examination of these signals and where they were to be found in the main CPU sequencing of the PF50 CPU confirmed that they were invoked for the 150E and 151E instructions. These instructions are employed in the 1904E and 1904A/S machines to provide synchronisation primitives between the nodes of a 1900 multi-processing setup. I spent a fair amount of time checking and re-checking and whilst I could see that it was very close to its 1904E counterpart I could not see how it looped, it was issuing a store-read and testing for zero. If the value was zero, it would write into the store location and exit to the next instruction. My problem? As far as I could see the non-zero condition simply exited to the next instruction also. After spending a little too long on the investigation, it went onto the shelf, alongside numerous other ‘cold cases’. Many months later, after looking several times at the instruction microcode in general and thus improving my knowledge, I was certain that the step called FI7 was the ‘end of instruction’ step. So, was this logic only partly implemented or was there a bug? I seriously doubted a bug as this was clearly well designed and the requirements of the 150E and 151E instructions were simple and well specified, at least for West Gorton machines. At least another year later I decided to re-examine the matter. The answer was there all the time. A signal that I had been overlooking, generated on this option card and did not appear on my early inspections to be significant turned out to be the answer. This signal inhibited the clocking of the RP register (the instruction address) in step FI7. One of those realisations that it is ‘so simple’. Inhibiting clocking RP meant that the end-of-instruction processing in FI7 would not store the incremented instruction address, resulting in the CPU re-fetching and obeying the 150E or 151E instruction. The instruction microprogram was missing the loop structure that I had expected, but Stevenage design implemented the required loop in a simple, clean and elegant way. The elegance is two-fold:
Should anyone wish to pursue this in more detail, see icl1900.co.uk/musings/pf50multi.html. There I intend to create a number of documents describing aspects of the 1900 Series that have not been seen in the available ICT or ICL literature. |
The death at the end of January 2025 of Dr Raymond “Dickie” Bird, aged 101, marks the passing of one of the last major figures in the early development of the UK computer industry. He obtained a degree from Imperial College and joined British Tabulating Machines Ltd. Around 1950 BTM entered a partnership with Dr Andrew Booth at Birkbeck College, London. As a result Dickie Bird led a small team who copied the circuitry of Booth’s APERC computer. These formed the basis for the first of BTM’s Hollerith Electronic Computers (HEC). Dickie Bird was their designer. In 1957 he received a PhD from Birkbeck College for his design of the HEC 4 (which became the ICT 1201). Over 100 ICT 1200 series computers were sold around the world, providing both India’s and East Africa’s first computers. This was followed by the much more powerful ICT 1300, then early 1900 machines and finally the ME29 before becoming Chief Engineer at ICL Bracknell. He was a delightful man to know with an endless string of stories which even when retold on a later visit were unchanged in the telling. Posterity is very lucky that he was the subject of several in-depth interviews as part of the BL Oral History of British Science project. In addition the BL videoed him for several hours with his HEC1 prototype in the Birmingham Museum store. He later opened the display of the HEC1 at TNMoC where it is normally on display although currently on temporary exhibition back in Birmingham. TNMoC also has a working ICT 1301 in store awaiting a suitable space in which to display it. Away from computing he enjoyed shooting from a young age and continued until failing eyesight in his mid-90s forced him to give up. He also had a fascination with deserts around the globe including northern and southern Africa as well as in central Asia. He organised trips with a small group of friends to visit these for nearly as long as he was able to continue to shoot! He is survived by his son and two daughters and I would like to thank his son Andy for his help in preparing this short tribute. Kevin Murrell and I were pleased to attend his funeral on behalf of the CCS and TNMoC. |
TV decoder from Texas: A decoder for building into television sets to enable them to receive Teletext transmissions has been announced by Texas Instruments. Experimental Teletext transmissions are currently being made by the BBC under the name Ceefax, and the IBA starts its experimental Oracle service next month. Texas Instruments sees its Tifax decoder adding about £100 to the cost of a television receiver at the start, possibly falling to £20 by 1978. Teletext uses blanking lines in the television signal to carry digitally encoded text which can be displayed on the screen instead of the television picture. The current experimental service consists of brief news items, weather, financial news and travel information. (CW 445 15/5/1975 p1) Printing firm gets OCR reader: A significant breakthrough in the doggedly traditional UK printing industry has been made with the first sale to a UK printer of the Compuscan 180 OCR reader, a machine designed especially to read pages of editorial copy for computer typesetting. The customer is Unwin Brothers of Woking, Surrey, a firm which already makes extensive use of computer typesetting and photo-composition. The Compuscan 170 was sold to Unwins by Crosfield Electronics Ltd of Holloway, London, the UK distributor for its manufacturer, the Compuscan Corp of New Jersey. Unwin Brothers prints books and periodicals, and types pages of copy in Olivetti Perry font for reading by the Compuscan 170 after they have been proof read. Unwins estimates that the Compuscan 170 mis-reads no more than one in 70,000 characters. (CW 445 15/5/1975 p3) Teletext decoder launched: A small Leicester-based company, Jasmin Electronics, which specialises in research into and development of digital systems, is offering a Teletext decoder to meet the anticipated demand for systems to evaluate the BBC Ceefax and IBA Oracle transmissions before the Texas Instruments Tifax decoder becomes generally available next year. The Jasmin system, called CeeView, is available as an integrated sub-assembly, and has been developed primarily for Rediffusion, but also works satisfactorily with all the UK-manufactured colour sets with which it has been tested, although not with some Japanese-made receivers. It costs £700 with the set, and £500 without it. (CW 448 5/6/1975 p32) Challenge to Intel from AMI: A determined challenge to Intel’s dominance of the microprocessor market with its 8080 has been launched by AMI Microsystems. This US firm believes its S6800, based on the Motorola MC6800, is the most powerful, economical and easy to use microprocessor available. The S6800 has a single 5 volt power supply, whereas the 8080 has three, and AMI claims that the S6800 is easier to program because of the simplicity of the instruction set. It is said to be up to 25 per cent faster for most applications. The S6800 is not yet freely available from AMI, but its US plants are well geared to meeting anticipated demand. The company estimates that its plants in Santa Clara, California, and Pocatello, Idaho, can produce two million MOS/LSI units per month. It supplies processors for Hewlett-Packard calculators and manufactures electronic components for products ranging from computers to wristwatches. (CW 449 12/6/1975 p7) Versatile micro from Intel: Process control, traffic control and point-of-sale processing are just some of the wide range of applications areas seen by Intel for its single PC board microcomputer module, the 4-43, which is based on the Intel 4040 four-bit processor. Data storage on the 4-43 is provided by the Intel 4002 RAM which can be expanded from 320 x 4 bits up to 2,560 x 4 bits. The program memory, which is separate from the data memory, goes from IK x 8 bits up to 4K x 8 bits. The unit costs £200 and offers 60 different instructions, 24 index registers and up to seven levels of subroutine nesting. Intel believes that one very promising applications area for the 4-43 is in portable traffic light controllers, mainly because the machine is able to match rigid Department of the Environment performance specifications. (CW 451 26/6/1975 p7) Port system examined by Customs: A major study is under way at the Department of Customs and Excise to examine the feasibility of developing a computerised import-export entries system for the major ports, providing the same kind of service as the LACES air cargo system at Heathrow. The report of the study group is under way, and a decision is expected within the next three months on the system to be implemented. The department wants the system running in about a year, and it would eventually link about 15 ports to the Customs and Excise computer centre at Southend at which VAT applications run on a twin System 4 installation. Software is being developed capable of running on either System 4 or ICL 2900, and so a major decision will be whether to acquire another System 4, run the system on the VAT machines, or get a 2900, which, however, would probably not be ready by the deadline. (CW 456 31/7 1975 p1) Domestic teletext by phone project: Viewdata is the name given to a research project currently under way at the Post Office. The idea behind it is that the telephone might be used to supply a visual text service in the home similar to the BBC and IBA’s experimental teletext services, which use blanking lines in the television signal to carry data which can be displayed on a normal television set with the addition of a decoder. In the case of Viewdata, the information would be fed into the home over the normal telephone line, and would be displayed either on a television set fitted with an adaptor, or on a purpose-built terminal. A small keypad would be used to call up the information, which would probably embrace the same sort of services as planned by the BBC and IBA for their Ceefax and Oracle services -things like weather forecasts, sports results, headline news and local shopping and entertainment information. (CW 457 7/8/1975 p32) Keeping British Rail trucks on track: Information relevant to the movement of all British Rail’s 280,000-plus freight wagons and 3,500 locomotives is stored on 3M Scotch 936 disc packs, as British Rail’s Total Operations Processing System, TOPS, continues its planned implementation phases towards completion in October. At present, the TOPS computer centre at British Rail’s Marylebone headquarters has 180 936 disc packs in use with more to come in later. TOPS involves a large number of files on which most of the information changes continually as trains move across the country. From about 400 on-line terminals at some 200 locations, users will interrogate the files at any time they wish, to obtain detailed information concerning the movement, contents, control and so forth of all wagons and locomotives. All information concerning the make-up of a train is entered on punched cards and transmitted to or from the terminals. At the same time, this information is written to the appropriate disc files. (CW 459 21/8/1975 p14) Packet switching service takes step forward: Preparations for the introduction of the Post Office’s Experimental Packet-Switched Service have taken another step forward with the interchange of packets between the Post Office in London, using an Interdata 50 mini, and ICL at Letchworth where a 7503 RJE terminal was linked to a 1903A. Transmissions were at 2,400 baud, up to the level of packet interchange, indicating compatibility between two independently designed terminals. The experiments are continuing, and operational error control conditions at link level will be tested. Call level protocols will also be tested, although such tests will be limited until the packet-switching exchange is up and running. The 7503 is ICL’s remote job entry terminal, introduced two years ago as a terminal offering line-printer, card reader and magnetic tape facilities, but it incorporates a processor with up to16K 16-bit words of store. The 7503 plays an important part in ICL’s EPSS plans, because the company is offering it to those customers with 1900 or System 4 mainframes who are taking part in the experiment as a full-programmed interface to the network. This will obviate the need for them to make any changes to the software on the mainframe. (CW 460 28/8/1975 p3)
|
Members and others are welcome to attend CCS Seminars and these are also available via Zoom. London Seminar Programme
London meetings take place at the BCS – 25 Copthall Avenue Moorgate EC2R 7BP starting at 14:30. The venue is near the corner of Copthall Avenue and London Wall, a five minute walk from Moorgate Station and 10 from Bank. You should use the BCS event booking service to reserve a place at CCS London lectures. Go to www.computerconservationsociety.org/lecture.htm. The service must be used both for attendance in person and for remote attendance. For queries about London meetings please contact the CCS meetings secretary Roger Johnson at meetingssec@computerconservationsociety.org. Manchester Seminar Programme
Manchester meetings normally take place at The Manchester Metropolitan University, Chester Street, Manchester, M1 5GD – Room E0.05 in the John Dalton East Building starting at 18:00 (but see the description of specific lectures on the CCS website as building work is currently underway). Details are subject to change. Members wishing to attend any meeting are advised to check the events page on the Society website. |
SIM : Demonstrations of the replica Small-Scale Experimental Machine at the Science and Industry Museum in Manchester are run every Wednesday, Thursday and Friday between 10:30 and 13:30. Admission is free. See www.scienceandindustrymuseum.org.uk/ for more details. The National Museum of Computing : See www.tnmoc.org/days-open for the opening hours schedule. Situated on the Bletchley Park campus, TNMoC covers the development of computing from the “rebuilt” Turing Bombe and Colossus codebreaking machines via the Harwell Dekatron (the world’s oldest working computer) to the present day. From ICL mainframes to hand-held computers. Please note that TNMoC is independent of Bletchley Park Trust and there is a separate admission charge. Visitors do not need to visit Bletchley Park Trust to visit TNMoC. See www.tnmoc.org for the opening hours schedule. Situated on the Bletchley Park campus, TNMoC covers the development of computing from the “rebuilt” Turing Bombe and Colossus codebreaking machines via the Harwell Dekatron (the world’s oldest working computer) to the present day. From ICL mainframes to hand-held computers. Science Museum : There is an excellent display of computing and mathematics machines on the second floor. The Information Age gallery explores “Six Networks which Changed the World” and includes a CDC 6600 computer and its Russian equivalent the BESM-6 as well as Pilot ACE, arguably the world’s third oldest surviving computer. The Mathematics Gallery has the Elliott 401 and the Julius Totalisater, both of which were the subject of CCS projects in years past, and much else besides. Other galleries include displays ranging from ICT card-sorters to Cray supercomputers. Admission is free. See www.sciencemuseum.org.uk for more details. Bletchley Park : Exhibition of wartime code-breaking equipment and procedures plus tours of the wartime buildings. Go to www.bletchleypark.org.uk to check details of times, admission charges and special events. Other Museums : At www.computerconservationsociety.org/museums.htm can be found brief descriptions of various UK computing museums which may be of interest to members.
|
|
Computer Conservation SocietyAims and ObjectivesThe Computer Conservation Society (CCS) is a co-operative venture between BCS, The Chartered Institute for IT; the Science Museum of London; The National Museum of Computing (TNMoC); and the Science and Industry Museum (SIM) in Manchester. The CCS was constituted in September 1989 as a Specialist Group of the British Computer Society. It is thus covered by the Royal Charter and charitable status of BCS. The aims of the CCS are:
Membership is open to anyone interested in computer conservation and the history of computing. The CCS is funded and supported by voluntary subscriptions from members, a grant from BCS and by the free use of the facilities of our founders. Some charges may be made for publications and attendance at seminars and conferences. There are a number of active projects on specific computer restorations and early computer technologies and software. Younger people are especially encouraged to take part in order to achieve skills transfer. |