Preserving Computing's Past: Restoration and Simulation AUTHORS Maxwell M. Burnet and Robert M. Supnik ABSTRACT Restoration and simulation are two techniques for preserving computing systems of historical interest. In computer restoration, historical systems are returned to working condition through repair of broken electrical and mechanical subsystems, if necessary substituting current parts for the original ones. In computer simulation, historical systems are re-created as software programs on current computer systems. In each case, the operating environment of the original system is presented to a modern user for inspection or analysis. This differs with computer conservation, which preserves historical systems in their current state, usually one of disrepair. The authors argue that an understanding of computing's past is vital to understanding its future, and thus that restoration, rather than just conservation, of historic systems is an important activity for computer technologists. THE COMPUTING PAST The continuous improvements in computing technology cause the rapid obsolescence of computer systems, architectures, media, and devices. Since old computing systems are rarely perceived to have any value, the danger of losing portions of the computing record is significant. When a computing architecture becomes extinct, its software, data, and written and oral records often disappear with it. Older computer systems embody major investments in software, the value of which may persist long after the systems have lost their technical relevancy. For example, the PDP-11 computer has not been a leading-edge architecture since the introduction of 32-bit systems in the late 1970s and has not received a new hardware implementation since 1984. Nonetheless, PDP-11 systems continue to be used worldwide, particularly in real-time and control applications. The unavailability of suitable replacements of worn-out original parts is a serious issue for PDP-11 systems still in use. Another area of potential loss is data. In recent years, archival storage media have undergone rapid technologic evolution, and the industry standards of computing's first 30 years, such as 0.5-inch magnetic tape, are now antiques. Salvaging data from original media is an industry-wide problem and has generated a small cottage industry of specialists in data recovery. This problem will only proliferate, as transitions in media types accelerate. Ten years from now, the large-diameter optical disks used for today's archives will look as quaint as DECtape and magnetic tape storage systems do to current computer users. Finally, the disappearance of older equipment typically entails loss of information: not only design sketches, blueprints, and documentation, but also the folklore about these systems. The absence of systematic archiving, as well as the absence of a perceived value of the archived data, causes continual information decay about design and operational details. This paper describes two techniques for preserving computing systems of historical interest. The first section of the paper discusses the restoration of old computers to working order. It also includes a description of the Australian Museum collection and the process of restoring a particular PDP-11 minicomputer. The second section discusses the simulation of old computers on modern systems. It describes a simulation framework called SIM, which has been used to implement simulators for the PDP-8, PDP-11, PDP-4/7/9/15, and Nova minicomputers. RESTORING OLD COMPUTERS Since the computer became a mass-produced item in the late 1960s, its typical life cycle has consisted of initial installation, rental or depreciation for about five years, retention and use for a few more years (just in case), and then retirement and a trip to the refuse dump. There is only a brief window of opportunity to collect old computers at the end of their working life. Once that window is closed, the computers are gone forever. The Australian Musuem Collection In Sydney, Australia, this window of opportunity first became apparent in 1971, when the early PDP systems reached the ends of their life cycles. Digital's Australian subsidiary began collecting systems by a creative program of trade-ins for new equipment.[1] It was especially urgent to obtain examples of the 12-bit, 18-bit, and 36-bit PDP series, as they were relatively few in number. Table 1 lists the percentage of available units that have been collected. The status of each is given as * Static---can never be made to work for various reasons * Restorable---could be made to work with enough care, patience, time, and effort * Working---running its operating system the last time it was turned on Once a representative sample of the early PDP systems had been collected, the urgency abated. Hundreds of PDP-11 and VAX systems were then brought to Australia; the window of opportunity for collecting them is still open. Table 1 Early Digital CPUs in Australia Model Number Brought Number in Museum Name to Australia Collection Condition ------------------------------------------------------------------------- PDP-5 1 1 Restorable PDP-6 1 1 Some items PDP-7 1 1 Static PDP-8 28 3 Working PDP-8/S 20 2 Static LINC-8 2 2 Restorable PDP-9 7 1 Restorable PDP-10 8 1 Some items PDP-12 2 2 Restorable PDP-8/I 24 2 Restorable PDP-8/L 21 2 Restorable PDP-15 10 1 Static PDP-8/E 90 4 Working The collection has grown significantly during the last 25 years. At the present time, we have in Sydney a comprehensive collection of most early Digital machines, including hardware, manuals, software, and spares (see Table 2). The collection is catalogued in a 6,000-line database that resides, appropriately, on a MicroVAX I computer, running the first version of the MicroVMS operating system. Figure 1 shows an example from the collection, a PDP-8/E computer system with peripheral equipment. [Figure 1 is not available in TXT format.] Table 2 The Digital Australian Collection (chronological order) Year Item Description Status ------------------------------------------------------------------------- 1958 138 A/D converter Static 1960 ASR-33 Teletype reader/punch, 110 baud Working 1962 KSR-35 Heavy-duty Teletype Working 1963 PDP-6 Modules of first Digital computer in Australia Parts 1963 PDP-5 First minicomputer in Australia Working 1967 PDP-7 Third Digital computer in Australia Static 1965 PDP-8 Classic, table-top model Working 1965 PDP-8 Cabinet model Restorable 1965 PDP-8 Typesetting system Static 1965 PDP-8 Cabinet model, first in New Zealand Restorable 1965 COPE-45 Remote batch (OEM PDP-8) Restorable 1966 PDP-9 18-bit computer Static 1966 KA10 Console of PDP-10 mainframe Static 1966 Linc-8 Early medical computer Working 1967 PDP-8/S Serial, under $10,000, CPU Static 1967 PDP-8/S Serial computer Static 1967 DF32 Digital's first disk, 1/16 Mb Static 1967 PDP-9/L Last transistor logic, 18-bit Static 1968 PDP-8/I Digital's first IC minicomputer Working 1968 PDP-8/L OEM version of PDP-8/I Static 1969 PDP-12 Laboratory computer Working 1969 PDP-12 Laboratory computer Static 1969 PDP-15 Last of 18-bit family Static 1969 KI10 Console of DECsystem-10 Static 1970 PDP-8/E Pinnacle of PDP-8 development Working 1970 PDP-8/E Full LAB 8 configuration Working 1970 PDP-11/20 The first PDP-11 Working 1970 CR11 Card reader, 285 cpm Working 1971 PDP-8/F Small PDP-8/E Working 1971 VT05 Digital's first video terminal Working 1971 LA30P Digital's first hard-copy terminal Working 1971 PDP-11/45 Last PDP-11 Static 1972 GT40 Graphics workstation Broken 1972 PDP-11/10 Small PDP-11 Static 1973 PDP-11E10 First packaged system Working 1973 PDP-11/35 Mid-range PDP-11 Static 1973 PDP-8/A Last non-chip PDP-8 Working 1974 PDP-11/40 Mid-range, end-user PDP-11 Restorable 1975 VT50 Video terminal Working 1975 LA36 DECwriter II printer Working 1975 DS310 Desk-based commercial system Working 1975 PDP-11/70 Largest PDP-11 Restorable 1976 PDP-11/34 Mid-range PDP-11 Working 1977 PRS01 Portable paper tape reader Working 1977 LS120 DECwriter printer Working 1977 WS78 Word processor, 8-inch floppy disks Working 1978 LA120 DECwriter III printer, 180 cps Working 1978 VAX-11/780 Original unit of 1 VAX-11/780 Restorable 1979 VT100 Famous video terminal Working 1980 MINC LSI-11 lab unit with RT-11 Working 1980 VAX-11/750 Mid-range VAX system Restorable 1980 PDT-150 Table-top LSI-11 with RX01 drives Working 1981 GIGI Low-cost terminal for schools Working 1982 VT125 Video terminal with graphics Working 1982 WS278 DECmate I word processor Restorable 1982 VAX-11/730 Low-performance VAX system Working 1982 LA12 Portable hard-copy terminal Static 1982 LQP03 Letter-quality printer Working 1982 DECmate II Word processor on mobile stand Working 1982 DECmate II Word processor Working 1982 Rainbow Personal computer Working 1982 PRO350 Professional PC Working 1983 VT241 Graphics color terminal Working 1983 MicroVAX I Smallest VAX .3 VUP Working 1983 VAX-11/725 Lowest cabinet VAX .3 VUP Working 1984 LN03 Laser printer Working 1985 MicroVAX II Famous MicroVAX II Working 1986 VAXmate 286-based PC with RX33 drive Working 1986 DECmate III Small word processor Working 1987 MicroVAX III 3-VUP MicroVAX II system Working 1987 VAX 8250 Dual VAX CPU, BI-based Restorable 1989 VAX 9000 Chip set Static 1990 DS3100 Mips UNIX workstation Restorable The goals of the collection are varied and are summarized in Table 3. Apart from the academic challenge of keeping all old data media running, there is the responsibility to ensure that they can be kept alive and available. The extensive variety of media types offered by Digital alone in only 30 years is summarized in Table 4. The evolving status of the collection has been reported at several Australian DECUS Symposia.[2,3] The restoration of the Australian collection will probably ensure a retirement job for the curator for the next 30 years! Table 3 Goals of the Australian Digital Museum ------------------------------------------------------------------------- To preserve one of each model of Digital's computers To keep each major Digital operating system working To have a working unit of each Digital terminal, console, and PC To provide conversion and archival facilities for old media To preserve significant Digital literature and manuals To preserve a VAX-11/780 computer as the original unit of 1 VUP To disseminate instructive and educational material To educate and amuse our staff, our customers, and the public To support the DECUS NOP (nostalgic obsolete product) Special Interest Group To preserve spares, tools, test gear, and documentation to keep the collection working To preserve and protect these treasures for future generations Table 4 Digital Data Media from 1960 to 1996 --------------------------------------- Paper tape 80-column punched and mark sense cards 7-track, half-inch magnetic tape 9-track, half-inch magnetic tape DECtape and LINCtape systems Audiocassette DECtape II cartridge (TU58) CompacTape (TK50, etc.) Quarter-inch cartridge tape Digital audio tape 8-inch floppy disk 5.25-inch floppy disk 3.5-inch floppy disk RK05 removable disk RK06, RK07 removable disk RL01, RL02 removable disk RP01...RP06 removable disk RM03, RM05 removable disk RC25 removable disk General Issues in Restoration Restoration is a painstaking and time-consuming process. The goal of restoration is to return a system to a state where it will reliably run a major operating system and offer as many media conversion facilities of the vintage as possible. Fortunately, computers do not deteriorate greatly in storage, provided the storage area is dry. (One item that does decay dramatically is the black foam used to line side panels and to separate ribbon cables. After 20 years, it turns into a sticky, gooey mess. It should be removed as soon as possible; otherwise, it falls into the modules and backplane. Replacing it with a modern equivalent can be done but is not essential.) The first step in restoration is to collect hardware, software, and documentation. * Collect the hardware, if possible two or ideally three items of each example. This provides a system to work on and a spare, as well as the ability to make comparisons between units. * Collect diagnostic and operating software on original bootstrap media. Sources are very useful, particularly for diagnostics. * Collect hardware manuals and schematics. There is a network of enthusiasts around the world who can help at this stage. Once the "ingredients" have been collected, the steps needed to restore a 1960s or 1970s vintage machine are as follows: * Inspect the hardware for physical safety, particularly the heavy drawers and slide mechanisms. * Physically assemble the hardware, checking module allocations, cabling, etc. * Carefully inspect the power system, high-voltage sources can kill. Although most of the power wiring material appears to stand the test of time, the early machines often had rather thin coverings on terminals. Safety-first is a principal criterion in restoration, since someday nontechnical people may open the back door. * Assemble a minimal system of CPU, memory, and console switch register for initial tests. * Power up the computer, checking supply voltages, fans, and front console for signs of life. * Use simple routines at the switch register to check for elementary operation. * Fit a serial line unit so that a VT or a Teletype console can be used. * Get the keyboard echoing to the screen or printer with simple routines. * If they are available, run the internal tests of the read-only memory (ROM). Conventional wisdom would now advise that all the diagnostic routines be run. However, diagnostics were (philosophically) always used to find bugs in a previously good machine; they are too complex when huge chunks of the machine might still be missing. The most practical next step is to get mass storage on-line. Depending on the manufacturer, the target device may be a floppy disk drive, a cartridge hard disk drive, or some form of magnetic tape. With a working mass storage device and a bootstrap routine, it becomes possible to boot a simple operating system (like OS/8 or RT-11 for Digital's systems). This quickly shows whether the machine is working or not. If a mass storage device is not available, the next best thing is paper tape. This can be either the system's rack-mounted reader and punch or the paper tape reader on an ASR33 or ASR35 console. The reliability is questionable, however, and the procedure is tedious. Many diagnostics were on paper tape, but usually the quickest test is to load a complete paper system (such as FOCAL for Digital's systems). If the diagnostics run, the system is probably functional. Once the CPU, console, and memory are verified, additional peripherals can be added, one at a time. It pays to take the time and effort to research bus addresses, interrupt vectors, power supply loading, and module placement, and to keep a log book with configuration diagrams and results. In general, if the configuration rules are followed, the items will work. There are few electronic failures, even in 20- or 30-year-old modules. When a problem arises, it is usually address vector strapping, physical damage, or missing cables. Corrosion of board contacts can be a problem; they should be cleaned with a clean cloth or cardboard (for example, a business card), not with a pencil eraser, which leaves residues. Silicon components appear to be very stable and a tribute to the conservative design principles of early computer engineers. The main components that seem to age are power supply capacitors, fans, and lights. The filter capacitors across the high-voltage sources can short, and reference electrolytic capacitors in power supply regulators can dry out. Although the large capacitors in power supply RC filters have proven to be reliable, some restorers replace them as a matter of course for safety reasons. Small rotary fans may seize if they have logged many hours. Incandescent panel lamps are always failing and can be replaced by modern light-emitting diodes (LEDs) if required. The irony is that the panel lamps are needed only during initial checkout; once the operating system is running, they are rarely used. Once restored, are old units reliable? Experience proves that they are. A classic PDP-8 system restored in 1988 still turns on happily (untouched) eight years later. A fully configured PDP-8/E system is still working four years after restoration. Restoring a Minicomputer: A Case Study An ongoing project is the restoration of a large, UNIBUS-based PDP-11 system with many UNIBUS peripherals attached to it. The project was started using the original PDP-11/20 CPU. Since many PDP-11 peripherals were designed long after the PDP-11/20 CPU, it could not cope with single-board direct memory access (DMA) devices, metal-oxide semiconductor (MOS) memory, and other later inventions. The project refocused on the mid-range PDP-11/34, which in retrospect has proved wise. The PDP-11/34 supports MOS memory, has an LED and push-button console, and represents a mature implementation of the PDP-11 instruction set. It has an optional cache, battery backup, floating-point operation, and the extended instruction set (EIS). The current configuration occupies three large cabinets in what used to be the dining room of Max Burnet's house. The virtues of the UNIBUS are many; in particular, it allows modular connection of I/O devices and other components. However, I/O devices of the era often weigh 100 pounds and are mounted in 10-inch drawers; their sheer physical size and weight are disincentives to reconfiguration. The project currently uses the RT-11 operating system because of its simplicity and extensive device drivers. Eventually, it may be possible to run the RSX-11M and the RSTS/E systems, but there is little to gain from a media conversion point of view, because RT-11 includes utilities for dealing with foreign file formats. The main difficulties encountered have been associated with the power supply: the DC low signal threads its way through every peripheral. The absence of UNIBUS grant continuity cards can create havoc. Since this PDP-11 system is very large, it is straining the design rules concerning floating vectors, current loading, and bus loads. The CPU and memory are relatively easy to check out. Due to the versatility of the UNIBUS, however, checking out the I/O system is very laborious. Starting with programmed I/O tests works best, followed by interrupt tests, and finally DMA or nonprocessor reference (NPR) tests. Experience shows that tests need to be rerun whenever a new peripheral is added. The system currently runs the RT-11 version 5.04 operating system on a configuration comprising RT-11/34 CPU with real-time clock and bootstraps 256 kilobits of MOS memory RX01 and RX02 floppy disks Dual RL02 disks TU56 dual DECtape storage system TU58 DECtape II storage system Serial line units for console and serial printer CM11 mark sense and CR11 punched card reader TU60 cassette PC11 paper tape reader and punch Although the following peripherals are available, they await installation time and effort: LPS-40 analog-to-digital (A/D) converter TU10 magnetic tape TSV03 magnetic tape Cache and commercial instruction set Battery backup kit The eventual goal is to keep "the last great (UNIBUS) PDP-11" running with almost every UNIBUS peripheral ever made.[4] Time will tell. SIMULATING OLD COMPUTERS A simulator is a computer program operating on one computer system (known as the host system) which mimics the behavior of another computer system (known as the target system). The simulator's data is the state of the target computer system - registers, memory, timed events, and so on. The simulator operates on presented state and transforms it, usually by sequential evaluation, in the same manner as would the target computer system. Simulators typically consist of an execution engine, which performs the state transformations; a simple timed-event mechanism, which supports deferred and asynchronous events such as I/O completions; and a control panel, which provides user access to simulated state. The execution engine is responsible for decoding instructions in simulated memory and performing the specified alterations of simulated machine state. The execution engine keeps track of simulated time in arbitrary units, which may be precise representations of the execution time of the target system, or simple representations of advancing time, such as the number of instructions executed. The event mechanism provides a way to schedule events, such as I/O completion, for later evaluation. It can also implement other time-based mechanisms such as keyboard polling. Finally, the control panel provides access to simulated state as well as basic control commands such as start and stop. It may also provide more elaborate facilities to support performance instrumentation or debugging. Historically, simulators have been used for many purposes, including the following: * Design of new systems. The simulator mimics the behavior of a future chip or computer system and is used to understand and debug the behavior of the proposed design. For example, prior to fabrication, all modern microprocessors are extensively simulated, first as abstract performance models and then at increasing levels of detail. [5--9] * Debugging for embedded systems. If the simulator contains facilities for program debugging, it becomes a useful tool for debugging programs that run in highly constrained environments such as embedded systems. Simulators can capture more state and provide a wider range of facilities than in situ debuggers. For example, simulators can implement program counter (PC) change queues, data access breakpoints, or precise traps on errors. * Replicable event tracing. Most simulators are fully deterministic. Asynchronous events are scheduled based on simple, nonrandom algorithms, such as fixed time-out or calculated seek time. As a result, simulators allow for straightforward replication or playback of complicated sequences, removing the randomness factor that often plagues the debugging of asynchronous software on real systems. * Preservation of past software. Simulators can provide migration assistance in the transition from older to newer architectures. Many transitional computer systems have provided simulators for older architectures, typically at the microcode level, to assist customers and developers in preserving their investments in the previous architecture. Examples include the early IBM System/360 series, which had models that simulated the 1401, 1410, 7070, and 7090 families, and the early Digital VAX systems, which included a PDP-11 compatibility mode.[10,11] Simulation Levels Simulators can be written at various levels of detail and thus various levels of fidelity to the target system. Three common levels of simulation are register transfer level (RTL), instruction, and software specific. An RTL simulator attempts to mimic the major hardware blocks of the target system and to implement its actual logic equations. The goal is absolute fidelity, the test of which is that no piece of software running on the simulator should behave differently than it would on the target hardware. In practice, such perfect mimicry is difficult to achieve, as it requires a painstaking re-creation of timing detail (for example, the actual acceleration curve of a DECtape storage system) and access to implementation documentation that has often vanished. Nonetheless, some simulators have achieved results very close to this goal: MIMIC, a DECsystem-10 simulator written at Applied Data Research, was able to run CPU- and device-specific diagnostics. (As testimony to the vulnerability of computing's past, all machine-readable copies of the MIMIC sources appear to have been lost.) An instruction simulator steps back from the RTL level and tries to simulate at the functional or the behavioral level. System elements are treated as functions that transform state according to the abstract definitions of the system architecture, rather than as logic blocks that transform state based on implementation equations. Instruction simulators sacrifice absolute fidelity to the idiosyncrasies of a particular implementation and focus on the intentions of the architecture specification. As a result, instruction simulators can usually run systems software and applications but can rarely fool diagnostics. Finally, a software-specific simulation further abstracts the functions of the target system to only those needed by a particular piece of target system software. For example, the OS/8 operating system on the PDP-8 computer does not use program interrupts; a simulator aimed at running only the OS/8 operating system would not need to implement interrupts or even queued events. A recent PDP-11 simulator designed to run the 2.9BSD UNIX operating system abstracted parts of the PDP-11 system's interrupt model and could not run other PDP-11 operating systems.[12] Simulating Minicomputers: A Case Study SIM is a portable instruction-level minicomputer simulator implemented in C. Its objectives are to facilitate the study and use of historic computer architectures by making simulated implementations and historic software available to anyone who has a 32-bit computer. It supports the following target architectures PDP-8 PDP-11 Nova 18-bit PDP series (PDP-4, PDP-7, PDP-9, PDP-15) and has been successfully ported to the VAX VMS, the Alpha OpenVMS, the Digital UNIX, and the Linux architectures. Ports to the Windows NT and the Windows 95 architectures and to an IBM 1401 simulator are under way. General Design Considerations. The design of an instruction-level simulator is not technically complicated; indeed, simulating a PDP-8 system is a common problem in undergraduate computer science courses. SIM follows the processor-memory-switch (PMS) structure proposed by Bell and Newell and implemented in MIMIC and countless other simulators since.[10,13] The simulated system is a collection of devices, one of which has special properties (the CPU). Each device has state (registers) and one or more units. Each unit has state and fixed- or variable-sized storage. In the CPU device, the storage is main memory. In an I/O device, the storage is the device media. The CPU is distinguished from other devices by having the master routine for instruction execution. This routine is responsible for the sequential evaluation of instructions and for the state transformations that represent simulated execution. The CPU also provides a few systemwide routines, such as symbolic disassembly and input and a binary loader. The devices interface to a control panel that provides access to simulated state and control over execution. The available commands in SIM are listed in Table 5. Table 5 Commands Available in SIM Command Definition ------------------------------------------------------------------------------ attach Associate file with unit's media. detach | ALL Disassociate unit's (all units) media from any file. reset | ALL Reset device (all devices). load Load binary program from file. boot Reset all devices and bootstrap from unit. run {} Reset all devices and resume execution at the current PC {or new PC}. go {} Resume execution at the current PC {or new PC}. cont Resume execution at the current PC. step {} Execute one instruction {or number instructions}. examine Display contents of list of memory locations or registers. iexamine Display contents of list of memory locations or registers and allow interactive modification. deposit Store value in list of memory locations or registers. ideposit Interactively modify list of memory locations or registers. save Save simulator state in file. restore Restore simulator state from file. show queue Display the simulator's event queue. show configuration Display the simulator's configuration. show time Display the simulated time counter. show Show device's configuration options. set