Maxwell M. Burnet
Robert M. Supnik
Preserving Computing’s
Past: Restoration and
Simulation
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 largediameter 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
Digital Technical Journal
Vol. 8 No. 3
1996
23
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 Museum 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.
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.
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!
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
Table 1
Early Digital CPUs in Australia
24
Model
Name
Number Brought
to Australia
Number in
Museum Collection
Condition
PDP-5
PDP-6
PDP-7
PDP-8
PDP-8/S
LINC-8
PDP-9
PDP-10
PDP-12
PDP-8/I
PDP-8/L
PDP-15
PDP-8/E
1
1
1
28
20
2
7
8
2
24
21
10
90
1
1
1
3
2
2
1
1
2
2
2
1
4
Restorable
Some items
Static
Working
Static
Restorable
Restorable
Some items
Restorable
Restorable
Restorable
Static
Working
Digital Technical Journal
Vol. 8 No. 3
1996
Table 2
The Digital Australian Collection (chronological order)
Year
Item
Description
Status
1958
1960
1962
1963
1963
1967
1965
1965
1965
1965
1965
1966
1966
1966
1967
1967
1967
1967
1968
1968
1969
1969
1969
1969
1970
1970
1970
1970
1971
1971
1971
1971
1972
1972
1973
1973
1973
1974
1975
1975
1975
1975
1976
1977
1977
1977
1978
1978
138
ASR-33
KSR-35
PDP-6
PDP-5
PDP-7
PDP-8
PDP-8
PDP-8
PDP-8
COPE-45
PDP-9
KA10
Linc-8
PDP-8/S
PDP-8/S
DF32
PDP-9/L
PDP-8/I
PDP-8/L
PDP-12
PDP-12
PDP-15
KI10
PDP-8/E
PDP-8/E
PDP-11/20
CR11
PDP-8/F
VT05
LA30P
PDP-11/45
GT40
PDP-11/10
PDP-11E10
PDP-11/35
PDP-8/A
PDP-11/40
VT50
LA36
DS310
PDP-11/70
PDP-11/34
PRS01
LS120
WS78
LA120
VAX-11/780
A/ D converter
Teletype reader/punch, 110 baud
Heavy-duty Teletype
Modules of first Digital computer in Australia
First minicomputer in Australia
Third Digital computer in Australia
Classic, table-top model
Cabinet model
Typesetting system
Cabinet model, first in New Zealand
Remote batch (OEM PDP-8)
18-bit computer
Console of PDP-10 mainframe
Early medical computer
Serial, under $10,000, CPU
Serial computer
Digital’s first disk, 1/16 Mb
Last transistor logic, 18-bit
Digital’s first IC minicomputer
OEM version of PDP-8/I
Laboratory computer
Laboratory computer
Last of 18-bit family
Console of DECsystem-10
Pinnacle of PDP-8 development
Full LAB 8 configuration
The first PDP-11
Card reader, 285 cpm
Small PDP-8/E
Digital’s first video terminal
Digital’s first hard-copy terminal
Last PDP-11
Graphics workstation
Small PDP-11
First packaged system
Mid-range PDP-11
Last non-chip PDP-8
Mid-range, end-user PDP-11
Video terminal
DECwriter II printer
Desk-based commercial system
Largest PDP-11
Mid-range PDP-11
Portable paper tape reader
DECwriter printer
Word processor, 8-inch floppy disks
DECwriter III printer, 180 cps
Original unit of 1 VAX-11/780
Static
Working
Working
Parts
Working
Static
Working
Restorable
Static
Restorable
Restorable
Static
Static
Working
Static
Static
Static
Static
Working
Static
Working
Static
Static
Static
Working
Working
Working
Working
Working
Working
Working
Static
Broken
Static
Working
Static
Working
Restorable
Working
Working
Working
Restorable
Working
Working
Working
Working
Working
Restorable
continued on next page
Digital Technical Journal
Vol. 8 No. 3
1996
25
Table 2 (continued)
Year
Item
Description
Status
1979
1980
1980
1980
1981
1982
1982
1982
1982
1982
1982
1982
1982
1982
1983
1983
1983
1984
1985
1986
1986
1987
1987
1989
1990
VT100
MINC
VAX-11/750
PDT-150
GIGI
VT125
WS278
VAX-11/730
LA12
LQP03
DECmate II
DECmate II
Rainbow
PRO350
VT241
MicroVAX I
VAX-11/725
LN03
MicroVAX II
VAXmate
DECmate III
MicroVAX III
VAX 8250
VAX 9000
DS3100
Famous video terminal
LSI-11 lab unit with RT-11
Mid-range VAX system
Table-top LSI-11 with RX01 drives
Low-cost terminal for schools
Video terminal with graphics
DECmate I word processor
Low-performance VAX system
Portable hard-copy terminal
Letter-quality printer
Word processor on mobile stand
Word processor
Personal computer
Professional PC
Graphics color terminal
Smallest VAX .3 VUP
Lowest cabinet VAX .3 VUP
Laser printer
Famous MicroVAX II
286-based PC with RX33 drive
Small word processor
3-VUP MicroVAX II system
Dual VAX CPU, BI-based
Chip set
Mips UNIX workstation
Working
Working
Restorable
Working
Working
Working
Restorable
Working
Static
Working
Working
Working
Working
Working
Working
Working
Working
Working
Working
Working
Working
Working
Restorable
Static
Restorable
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:
■
26
Inspect the hardware for physical safety, particularly
the heavy drawers and slide mechanisms.
Digital Technical Journal
Vol. 8 No. 3
1996
■
■
■
■
■
■
■
■
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).
RX01
DUAL 8-INCH FLOPPY DISKETTES
TD8E TU56
ACCUMULATOR TRANSFER
DUAL DECTAPE SYSTEM
PC8E 300 CPS READER,
50 CPS PUNCH PAPER TAPE
PDP-8/E CPU WITH EXTENDED ARITHMETIC
ELEMENT, 16K WORDS MEMORY,
KL8E 2400-BAUD CONSOLE,
KL8E 2400-BAUD COMMUNICATION PORT,
DECTAPE BOOTSTRAP, RK05 DISK BOOTSTRAP,
REAL-TIME CLOCK
RK05 REMOVABLE 2.4-MB
CARTRIDGE DISK
STORAGE RACK FOR 10
DECTAPE SYSTEMS
H861 POWER DISTRIBUTION
Figure 1
PDP-8/E Computer System
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 relia-
bility 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 30year-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
Digital Technical Journal
Vol. 8 No. 3
1996
27
Table 3
Goals of the Australian Digital Museum
Table 4
Digital Data Media from 1960 to 1996
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
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
(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 lightemitting 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
28
Digital Technical Journal
Vol. 8 No. 3
1996
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
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 timebased 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
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
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
Digital Technical Journal
Vol. 8 No. 3
1996
29
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.9 BSD 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 sim-
ulator 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.
30
Digital Technical Journal
Vol. 8 No. 3
1996
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 variablesized 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.
The control panel also includes routines that are
needed by most simulators, such as event queue maintenance and character-by-character terminal I/O.
Different simulators need not use the same time base,
but all the SIM-based implementations to date use the
number of instructions executed as the time base.
Note that the control panel provides for starting simulation, but termination is determined entirely by the
simulated CPU. By convention, the CPU returns control to the control panel under the following conditions:
1.
2.
3.
4.
If a HALT instruction is executed
If a fatal exception is detected
If a fatal I/O error is detected
If a special character is typed at the controlling
terminal
Likewise, the control panel does not implement any
debugging facilities beyond state examination and
modification and instruction stepping. To facilitate
debugging with operating systems, CPUs provide
a simple instruction breakpoint capability and a onelevel PC trace facility.
Implementation The implementation of a particular
simulator begins with collecting reference manuals,
maintenance manuals, design documents, folklore,
and prior simulator implementations for the target
system. This is nontrivial. In the early days of computing, companies did not systematically collect and
archive design documentation. In addition, collected
material is subject to information decay, as noted
Table 5
Commands Available in SIM
Command
Definition
attach <unit> <file>
detach <unit> | ALL
reset <device> | ALL
load <file>
boot <unit>
run {<new PC>}
go {<new PC>}
cont
step {<number>}
examine <list>
iexamine <list>
Associate file with unit’s media.
Disassociate unit’s (all units) media from any file.
Reset device (all devices).
Load binary program from file.
Reset all devices and bootstrap from unit.
Reset all devices and resume execution at the current PC {or new PC}.
Resume execution at the current PC {or new PC}.
Resume execution at the current PC.
Execute one instruction {or number instructions}.
Display contents of list of memory locations or registers.
Display contents of list of memory locations or registers and allow interactive
modification.
Store value in list of memory locations or registers.
Interactively modify list of memory locations or registers.
Save simulator state in file.
Restore simulator state from file.
Display the simulator’s event queue.
Display the simulator’s configuration.
Display the simulated time counter.
Show device’s configuration options.
Set a device configuration option.
Display a terse help message.
Leave the simulator.
deposit <list> <value>
ideposit <list>
save <file>
restore <file>
show queue
show configuration
show time
show <device>
set <device> <option>
help
exit | quit | bye
earlier. Lastly, the material is likely to be contradictory,
embodying differing revisions or versions of the architecture, as well as errors that have crept in during the
documentation process.
For Digital’s 12-bit and 16-bit minicomputers, the
typical hierarchy of documentation was the following:
■
■
■
Processor Handbook. Providing an all-inclusive
summary of the instruction set architecture, peripherals, bus interface, and software, these paperbacksize books are the most common form of system
documentation but also the least accurate.
Subsystem Reference Manual. As the programmer’s
reference manual for a particular subsystem, such as
the CPU or the disk drive, these manuals describe
the registers and functions accurately but omit
maintenance-level features and other fine points.
Subsystem Maintenance Manual. As the maintenance engineer’s manual for a particular subsystem,
these manuals describe the registers and functions
at the hardware implementation level, often including substantial abstracts from the print set. Because
of the level of detail, the maintenance manuals have
proven to be the most useful references for simulator implementation.
■
■
■
Design documents. For systems that do not have
very large-scale integration (VLSI), the only extant
design documents are the logic prints and the binary
microcode ROM listings. The prints are essential for
RTL simulation: they provide the only documentation of implementation quirks. For VLSI systems,
there are chip-level design specifications as well as
human-readable microprogram listings.
Folklore. During the useful lifetime of a system, its
users exchange information and create an informal
record, both written and verbal, of shared experiences (folklore) regarding the fine points of
operations, hardware/software interfaces, system
“personality,” and other factors. Folklore is subject
to rapid information decay, particularly once the
target system becomes obsolete.
Prior implementations. Prior simulator implementations can provide useful information, but it must be
used cautiously. Unless the prior implementation is
an RTL model, it embodies simplifications and
abstractions that are not explicitly documented. The
MIMIC sources (which are fragmentary and available only on paper) proved trustworthy, but others
did not: for example, the 1970s PDP-11 simulator
in the DECUS archives is highly misleading about
interrupts, condition codes, and other details.
Digital Technical Journal
Vol. 8 No. 3
1996
31
An important consideration is that much of the
documentation, all the folklore, and most working
systems are in the hands of individual collectors.
The Internet plays a vital role in locating material held
by enthusiasts, through news conferences such as
alt.folklore.computers, alt.sys.pdp8, alt.sys.pdp11,
and comp.emulators.misc, and more recently, through
World Wide Web sites devoted to historic systems.14–16
The sources for each simulator in SIM are listed in
Table 6.
The last step in implementation is collecting software to run on the simulator. Software collection
immediately raises the problem of media translation.
Software for historic systems resides on paper tapes,
DECtape storage systems, 200/556/800 bits-perinch magnetic tapes, disk cartridges, 8-inch floppy
disks, and so on. Few if any modern systems have these
peripherals; and few if any historic systems have modern network interconnects. Thus, media translation
usually entails linking a working version of the target
system to a modern system by means of a serial line.
KERMIT or some other simple protocol allows for a
byte-by-byte network copy from the original media to
a file on a modern system.
Once the software has been located and moved
to a file, the next issue is sources. Without sources,
diagnostics and other test programs are useless;
detected errors cannot be traced back to causes without manual decode of the binary program. The
absence of sources was a principal reason for including
symbolic disassembly and input in SIM.
The final issue in software is licensing. Even though
the target systems are obsolete and often no longer
manufactured, the operating system software may be
protected by copyrights and licenses. Most PDP-8
software is in the public domain; however, the PDP-11
and Nova operating systems are still licensed, as are
all versions of UNIX. Corporate licensing policies
rarely accommodate hobbyists; this limits operating
system distribution to legitimate (that is, business)
users. Table 7 lists the software found for each simulator in SIM.
Debug The debug path for a simulator depends
on the available software. Ideally, the simulator would
be debugged with the same software tests used
to debug the target hardware, but this software is
rarely archived. Diagnostics can provide low-level
checking, but diagnostics typically check for broken
parts in a correct implementation, rather than an
incorrect implementation. Even when diagnostics
do check architecture rather than implementation (as
in the basic instruction diagnostics on the PDP-11
system), the absence of sources limits their utility.
Consequently, the simulators were debugged mostly
with simple hand tests and then with the operating
systems.
Operating systems are both exacting and imprecise
tests of implementation correctness. Unless an
operating system takes a deliberately restrictive view
of hardware (for example, OS/8 does not use the
PDP-8 interrupt system, and RT-11 does not use any
Table 6
Sources for Simulators in SIM
Architecture
Documents
Location
PDP-8
Minicomputer Handbook
Reference manuals
Maintenance manuals
Print sets
Prior implementations
PDP-11
Minicomputer Handbook
Reference manuals
Maintenance manuals
Chip specifications
Microcode listings
Prior implementations
Nova
System Reference Manual
Reference manuals
Maintenance manuals
Prior implementations
Reference manuals
Maintenance manuals
Print sets
Private collection
Digital archive
Digital Australia collection
Digital Australia collection
Public archive17
Public archive18
MIMIC, private collection
Private collection
Digital archive
Digital Australia collection
Private collection
Private collection
Public archive19
MIMIC, private collection
Private collection
Data General archive
Private collection
MIMIC, private collection
Digital archive
Digital archive
Digital archive
18-bit PDP
32
Digital Technical Journal
Vol. 8 No. 3
1996
Table 7
Software for Simulators in SIM
Architecture
Software
Location
PDP-8
Basic instruction tests 1 and 2
Memory management test
FOCAL69
OS/8 system disk
RT-11
RSX-11M
RSTS/E
UNIX V5, V6, V7, 2.9 BSD
2.11 BSD
RDOS
No software to date
Digital Australia collection
Digital Australia collection
Digital Australia collection
Public archive18
Transcribed from real system
Transcribed from real system
Transcribed from real system
PDP UNIX Preservation Society (PUPS) archive20
Private collection
Private collection
PDP-11
Nova
18-bit PDP
optional PDP-11 instructions), the operating system will be sensitive to every error in implementation.
For example, Digital’s second-generation PDP-11
systems—the PDP-11/05, 11/40, and 11/45—
were debugged with DOS-11 and RSTS after diagnostics failed to detect certain subtle implementation
errors. Unfortunately, in an operating system, the
distance in time and space between the error and the
symptom may be enormous, and the traceable path
may be lengthy and complicated. Artifacts in the
software can also complicate debug: the OS/8 disk
image on the Internet contains a copy of BASIC that
is broken.
Results SIM implements four minicomputer architec-
tures: PDP-8, PDP-11, Nova, and 18-bit PDP. Each
simulator includes a particular CPU; basic peripherals
such as terminal, paper tape, clock, and printer; and
a selection of mass storage peripherals (see Table 8).
The PDP-8 simulator has run the FOCAL69 and
the OS/8 operating systems. The PDP-11 simulator
has run the following operating systems: RT-11 V4
and V5; RSX-11M V4; RSTS/E V8; UNIX V5,
V6, and V7; and BSD V2.9 and V2.11. The Nova
simulator has run the RDOS V7.5 operating system.
No system software for the 18-bit PDP systems
has been found. The simulators were exercised on an
AlphaStation 3000/600 workstation (approximately
120 SPECint92); the performance is given in Table 9.
Figures 2, 3, and 4 show screen shots from the various
simulators running their principal operating systems.
In Defense of Computing’s History
As professional engineers who have been lucky
enough to witness the computer revolution, the
authors believe that the industry has a duty to keep
early machines alive. There are practical reasons, such
as preservation of software and data; beyond that,
there is an obligation to future generations. In 100
years, the systems from computing’s early history will
appear to be absolute dinosaurs of the past. Yet their
educational and sociological value will be considerable. A computer is a machine with a soul, and it must
be kept alive with its operating environment to show
its abilities and the contemporary state of the art.
Acknowledgments
Max Burnet: I would like to thank Digital Equipment
Corporation Australia Pty Ltd for tolerating my
eccentricity and for supporting the Australian Digital
museum collection. Also the DECUS Australia NOP
(nostalgic obsolete product) SIG members for help,
encouragement, knowledge, good humor, and camaraderie on the last Wednesday of the month. My thanks
to my coauthor Bob Supnik for his continued inspiration; it is great to see a V.P. who can cut code with the
best of them. My thanks also to the contributors to the
Digital Notes files, a great source of folklore. Therein
lies a treasure trove of solutions from people who are
helping each other solve the same problems.
Bob Supnik: The design, implementation, and debug
of SIM was made possible by the generous help of
many people. Craig St. Clair and Deb Toivonen of the
Digital archives located rare manuals and documents
on Digital’s 12-bit, 16-bit, and 18-bit systems. Tom
West and Don Lewine of Data General Corporation
provided documentation and support on the Nova.
Carl Friend’s private collection of Data General
hardware and software was a crucial source of documentation and software for the Nova and the RDOS
operating system. Doug Jones, Bill Haygood, and
John Wilson allowed me to use the sources to their
simulators and freely answered arcane questions about
Digital Technical Journal
Vol. 8 No. 3
1996
33
Table 8
Architectures Implemented by SIM
CPU
Options
Memory
Terminal
Paper tape
Clock
Printer
Storage
Magnetic tape
PDP-8
PDP-11
Nova
PDP-8/E
KE8E EAE,
KM8E memory extension
4–32K words
KL8E
PC8E
DK8E
LE8E
RX8E/RX01
RK8E/RK05
RF08/RS08
TM8E/TU10
J-11, Q-bus
Integral FP11
Nova 820
Multiply/divide
16 KB–4 MB
DL11
PC11
KW11L
LP11
RX11/RX01
RK11/RK05
RLV11/RL01,2
TM11/TU10
4–32K words
KSR-33, Dasher
Yes
Yes
Yes
4019
4046/4047, 4048,
4057, 4234
6026
PDP-4
PDP-7
PDP-9
PDP-15
CPU
Options
PDP-4
PDP-7
T177 EAE,
T148 memory
extension
Memory
Terminal
Paper tape
4–8K words
KSR-28
Integral
T75 punch
Yes
T62
4–32K words
KSR-33
T444 reader
T75 punch
Yes
T647
T24 drum
PDP-9
KE09A EAE,
KX09A memory
protection
KP09A power
4–32K words
KSR-33
PC09A
reader- punch
Yes
T647E
RF09/RS09
PDP-15/30
KE15 EAE,
KM15 memory
protection
KP15 power
4–128K words
KSR-35
PC15 readerpunch
Yes
LP15
RF15/RS09
RP15/RP02
TC59/TU10
Clock
Printer
Storage
Magnetic tape
TC59/TU10
the hardware. In addition, Bill provided a working
OS/8 system disk, and John copied several PDP-11
operating system disks off a working PDP-11/34.
Megan Gentry was an important source of PDP-11
folklore, debugged some of the subtlest problems, created the Makefile, and provided the first and most
frequently used distribution site. Ben Thomas
provided the character-by-character I/O routines
for VMS. Chris Suddick helped debug the PDP-11
floating-point code. Warren Toomey and the enthusiasts at PUPS (the PDP UNIX Preservation Society)
in Australia allowed me access to their archive of early
UNIX releases. Leendert Van Doorn debugged
the PDP-11 simulator with UNIX V6, and Franc
Grootjen with 2.11 BSD. Larry Stewart provided the
initial impetus to the project, and Ken Harrenstein
made an important contribution to preservation
by implementing a DECsystem-10 simulator. Last,
but not least, Max Burnet generously provided
documentation and software from the Digital
34
Digital Technical Journal
Vol. 8 No. 3
1996
Australia collection, answered questions based on his
30 years of experience with Digital’s systems, and
made connections with and introductions to the
worldwide community of historic machine hobbyists
and enthusiasts.
References and Notes
1. As managing director of Digital’s Australian subsidiary
from 1975 to 1982, Max Burnet created and operated
the PDP trade-in program.
2. M. Burnet, “An Update on the Museum Treasures,”
DECUS Australia Symposium Proceedings, August
1993.
3. M. Burnet, “The ’94 Update on the Museum Treasures,” DECUS Australia Symposium Proceedings,
August 1994.
4. M. Burnet, “The Last Great PDP-11,” DECUS
Australia Symposium Proceedings, August 1995.
Table 9
Simulator Performance
Simulator
Simulated
Instructions
per Second
Real
Instructions
per Second
Ratio
PDP-8
PDP-11
Nova
1,800,000
440,000
1,700,000
400,000
500,000
750,000
4.5:1
.88:1
2.26:1
ucoder> pdp8
PDP-8 simulator V2.2b
sim> att rk0 os8.dsk
sim> boot rk0
.DA 08-APR-96
.DIR
08-Apr-96
COPYIT.SV
DIRECT.SV
CCLX .SV
PIP
.SV
FOTP .SV
ABSLDR.SV
BASIC .SV
BATCH .SV
BCOMP .SV
BITMAP.SV
BLOAD .SV
BOOT .SV
BRTS .SV
CHEKMO.SV
COMPAF.SV
CREF .SV
EDIT .SV
EDITS .SV
EPIC .SV
F4
.SV
FRTS .SV
FUTIL .SV
HELP .SV
LIBRA .SV
LIBSET.SV
LOAD .SV
LOADER.SV
MATST .SV
MDTST .SV
OCOMP .SV
OPTF4 .SV
PAL8 .SV
2
7
24
11
8
5
11
10
26
5
10
5
24
15
5
13
10
6
14
20
26
26
5
11
5
16
12
9
14
8
13
19
95 Files In
09-Mar-93
11-Oct-92
25-Feb-93
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Aug-93
11-Aug-93
11-Oct-92
11-Oct-92
11-Oct-92
PASS2 .SV
PASS2O.SV
PASS3 .SV
RALF .SV
RESORC.SV
RUNOFF.SV
SABR .SV
SCROLL.SV
SET
.SV
SRCCOM.SV
TECO .SV
VERSN3.SV
BUILD .SV
BASIC .OV
BUILD6.SV
BUILT .SV
HELP .HE
HELP .HL
HELP .OC
FORT7 .LD
JMPTST.SV
JMPJMS.SV
RK8ENS.BN
INST1 .SV
INST2 .SV
FORT .FT
FORT .LD
FORT2 .LD
FORT2 .FT
DOS
.SV
SHELL .SV
FORT3 .FT
20
5
8
19
10
24
24
17
20
5
32
10
33
16
33
33
1
72
4
2
3
3
1
14
11
1
2
2
1
2
2
1
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
11-Oct-92
12-Oct-92
18-Oct-92
18-Oct-92
18-Oct-92
07-Sep-93
18-Oct-92
18-Oct-92
30-Oct-92
01-Dec-92
01-Dec-92
17-Jun-93
09-Jul-93
09-Jul-93
22-Jun-93
25-Jan-94
25-Jan-94
26-Jun-93
FORT3 .LD
CLOSE .SV
FORT4 .FT
FORT4 .LD
FORT6 .LD
FORT5 .FT
FORT5 .LD
FORT6 .FT
METSC .SV
METSC2.SV
EMAT .SV
EMDCT .SV
EMTST .SV
SINST1.SV
ADDER .SV
FORT7 .FT
CLEAR .LS
CLEAR .CF
CLEAR .SV
CLEAR .PA
CLEAR .BN
DEMO .
DOS
.PA
DOS
.BN
DOS
.LS
SHELL .PA
SHELL .BN
SHELL .LS
BASIC .WS
FOO
.PA
FOO
.BN
3
2
1
2
2
1
2
1
10
10
9
14
10
14
13
1
2
2
2
1
2
28
4
1
10
1
1
2
1
1
1
06-Jul-93
10-Jul-93
11-Jul-93
04-Aug-93
09-Aug-93
09-Aug-93
09-Aug-93
09-Aug-93
11-Aug-93
11-Aug-93
11-Aug-93
11-Aug-93
11-Aug-93
11-Aug-93
11-Aug-93
30-Aug-93
13-Jan-94
13-Jan-94
13-Jan-94
13-Jan-94
13-Jan-94
21-Mar-95
25-Jan-94
25-Jan-94
25-Jan-94
25-Jan-94
25-Jan-94
25-Jan-94
10-Mar-94
31-Mar-94
31-Mar-94
980 Blocks - 2212 Free Blocks
.
Simulation stopped, PC: 01207 (KSF)
sim>
Figure 2
PDP-8 Simulator Running OS/8
Digital Technical Journal
Vol. 8 No. 3
1996
35
ucoder> nova
NOVA
sim>
sim>
sim>
simulator V2.2b
att dp0 rdos.dsk
set tti dasher
boot dp0
Filename?
NOVA RDOS Rev 7.50
Date (m/d/y) ? 4 8 96
Time (h:m:s) ? 16 26 0
R
list/e sys-.SYS5.LB
17216
SYS.SV
56320
SYS.LB
20240
SYS.OL
30720
SYSGEN.SV
23040
R
disk
LEFT: 2158
USED: 2706
R
D
SD
D
C
SD
05/24/77
12/14/95
04/30/85
12/14/95
05/02/85
13:18
16:21
14:49
16:21
22:20
05/31/85
12/14/95
05/31/85
12/14/95
05/31/85
[001017]
[005057]
[000746]
[005272]
[001401]
0
0
0
0
0
MAX. CONTIGUOUS: 2054
Simulation stopped, PC: 41740 (LDA 1,4,3)
sim>
Figure 3
Nova Simulator Running RDOS
5. A. Ahi, G. Burroughs, A. Gore, S. LaMar, C.-Y. Lin,
and A. Wiemann, “Design Verification of the HP 9000
Series 700 PA-RISC Workstations,” Hewlett-Packard
Journal, vol. 43, no. 4 (1992).
6. W. Anderson, “Logical Verification of the NVAX CPU
Chip Design,” Digital Technical Journal, vol. 4,
no. 3 (1992): 38–46.
7. R. Calcagni and W. Sherwood, “VAX 6000 Model 400
CPU Chip Set Functional Design Verification,”
Digital Technical Journal, vol. 2, no. 2 (1990):
64–72.
8. A. Hutchings, “The Evolution of the Custom CAD
Suite Used on the MicroVAX II System,” Digital
Technical Journal, vol. 1, no. 2 (1986): 48–55.
9. M. Kantrowitz and L. Noack, “Functional Verification
of a Multiple-issue, Pipelined, Superscalar Alpha
Processor— the Alpha 21164 CPU Chip,” Digital
Technical Journal, vol. 7, no. 1 (1995): 136–144.
10. D. Siewiorek, C. Bell, and A. Newell, Computer
Structures: Principles and Examples, “The IBM
System/360, System/370, 3030, and 4300: A Series
of Planned Machines That Span a Wide Performance
Range,” and “PMS Notation” (New York: McGrawHill, 1982).
11. R. Brunner, ed., VAX Architecture Reference
Manual, chapter 9, “Compatibility Mode” (Bedford,
Mass.: Digital Press, 1991).
12. This simulator has since been withdrawn from the
network.
36
Digital Technical Journal
Vol. 8 No. 3
1996
13. R. Rustin, ed., Debugging Techniques in Large
Systems, R. Supnik, “Debugging Under Simulation”
(Englewood Cliffs, N. J.: Prentice-Hall, 1971).
14. For information on and pictures of Data General
minicomputers, see C. Friend’s web page at
http://www.ultranet.com/~engelbrt/carl/museum
/index.html.
15. For information on and pictures of many historic
computers, see J. Jaeger’s web page at http://
www.msn.fullfeed.com/~cube/collect.htm.
16. For information on and pictures of many historic
computers, see P. Pierce’s web page at http://
www.teleport.com/~prp/collect/index.html.
17. For documentation and relevant links, see D. Jones’s
web page at www.cs.uiowa.edu/~jones/pdp8/. For
his simulator, cross assembler, and core images, see
ftp://ftp.cs.uiowa.edu/pub/jones/pdp8.
18. For information on his simulator and OS/8 disk
image, see W. Haygood’s web page at ftp://
sunsite.unc.edu/pub/academic/computer-science/
history/pdp-8/emulators/haygood.
19. For more information on J. Wilson’s simulator (executable only), see his web page at ftp://
ftp.update.uu.se/pub/ibmpc/emulators.
20. For more information on the PDP-11 UNIX archive,
see
the
PUPS
home
page
at
http://
minnie.cs.adfa.oz.au/PUPS/index.html.
ucoder> pdp11
PDP-11 simulator V2.2b
sim> att rk0 rtrk.dsk
sim> boot rk0
RT-11SJ (S) V05.04
.
.da 8-apr-96
.dir
08-Apr-96
NL
.SYS
2 18-Sep-89
RT11SJ.SYS
80 18-Sep-89
PTESTX.MAC
23 27-Jan-94
BINCOM.SAV
24 27-Sep-88
DIR
.SAV
19 27-Sep-88
LIBR .SAV
24 27-Sep-88
LINK .SAV
49 27-Sep-88
FORMAT.SAV
24 27-Sep-88
PBCOPY.SAV
2 16-Feb-89
ODT
.OBJ
8 05-Oct-89
SIPP .SAV
21 27-Sep-88
IOP
.SAV
11 24-Apr-89
TT
.SYS
2 18-Sep-89
DM
.SYS
5 18-Sep-89
DX
.SYS
4 18-Sep-89
LS
.SYS
5 05-Oct-89
LP
.SYS
2 18-Sep-89
PIP
.SAV
30 27-Sep-88
LD
.SYS
8 26-Dec-90
LC
.SYS
2 01-Jan-80
UCL
.CCL
4 07-Oct-90
MTPIP .SAV
28 27-Feb-87
MLIB .SYS
300 20-Dec-90
XPC
.SAV
16 25-Jun-91
PTESTX.OBJ
8
49 Files, 1432 Blocks
3330 Free blocks
RT11FB.SYS
SPOOL .REL
GVI
.SAV
DUP
.SAV
IND
.SAV
MACRO .SAV
RESORC.SAV
ODT
.SAV
SYSLIB.OBJ
SYSMAC.SML
DATE .SAV
SWAP .SYS
DL
.SYS
DP
.SYS
RK
.SYS
MT
.SYS
SP
.SYS
HANDLE.SAV
MAC
.SAV
UCL
.SAV
STARTS.COM
MTROL .SAV
HELP .SAV
DESS .SAV
94
11
5
49
58
61
25
8
55P
61
3
27
4
3
3
9
6
7
61
13
1
17
132
18
18-Sep-89
14-Apr-87
18-Apr-90
27-Sep-88
27-Sep-88
27-Sep-88
27-Sep-88
05-Oct-89
05-Oct-89
16-Mar-89
02-Feb-89
27-Sep-88
18-Sep-89
18-Sep-89
18-Sep-89
18-Sep-89
18-Sep-89
16-Feb-89
27-Sep-88
22-Dec-89
19-Jan-94
27-Feb-87
20-Dec-90
09-Mar-88
.sho dev
Device
-----NL
TT
DL
DM
DP
DX
RK
LS
MT
LP
SP
LD
LC
Status
-----Installed
Installed
Installed
Not installed
Not installed
Installed
Resident
-Not installed
Installed
Installed
Installed
Installed
Installed
CSR
--000000
000000
174400
177440
176710
177170
177400
176500
172520
177514
000000
000000
177514
Vector(s)
--------000
000
160
210
254
264
220
470 474 300 304
224
200
110
000
200
.
Simulation stopped, PC: 146506 (ASR R5)
sim>
Figure 4
PDP-11 Simulator Running RT-11
Digital Technical Journal
Vol. 8 No. 3
1996
37
Biographies
Maxwell M. Burnet
Max Burnet has been with Digital in Australia for 29 years.
During that time, he has sold, serviced, or marketed all the
machines in the collection. He managed the Digital
Australia subsidiary for seven years. He was a salesman
in Boston during 1971 and managed to replace an IBM
1620 at Tufts University with a PDP-10. He is currently
the oldest surviving “techie” in the Sydney office and
makes many corporate presentations in Australia. He
manages the Australian DECUS Society, the Subsidiary’s
local content and export obligations with the Australian
Government, and the local Product Assurance Group.
He has collected a museum of early Digital machines and
is known around Sydney as “Museum Max.” He received
a B.Sc. (honours) from Melbourne University.
Robert M. Supnik
Bob Supnik has been with Digital in the United States
for 19 years. He joined the Mass Storage Group and then
moved into Semiconductor Engineering, where he successively managed the last PDP-11 implementation (the J-11),
Advanced Development, the first single-chip VAX implementation (the MicroVAX chip), and the VAX Microprocessor Group. He also wrote or contributed to the
microcode of every single-chip VAX microprocessor. In
1988, he started the Alpha program, which he managed
through launch of the first products in 1992. He then
became technical director, first of Engineering and then
of the Computer Systems Division. In 1996, he became
vice president of Research and Advanced Development.
He has B.A. degrees in mathematics and in history from
MIT, and an M.A. in history from Brandeis University.
38
Digital Technical Journal
Vol. 8 No. 3
1996