DEC PDP-8/e Restoration Part 3

Part 1 - Initial Dismantling and Cleaning Part 2 - Processor Checkout and Debug Part 3 - Loading and Running Binaries

Part 3 - Loading and Running Binaries

Any real further progress depends on loading some software into the computer. The first steps are to load and run some of DECs diagnostic programs to verify or otherwise that the machine is working properly. For this as mentioned earlier I generally use (Bray's) Terminal. A small advantage of using the 2 different terminal emulators is that one can be left set up to suit normal terminal I/O and the other to suit binary I/O when loading (paper-tape) software. The previous tests showed that the asynchronous interface was working properly (well I suppose the parity bit and some of the I/O instructions (IOTs) weren't verified but it's an lower likelihood failure). I loaded Bray's Terminal and set it to the appropriate COM port, 38400 baud, 8 data bits, no parity, 1 stop bit and no handshaking.

For the PDP8 to be able to input any software it needs to be running some sort of program already which can interrogate the input line, accept the software frame by frame, assemble it and load it into the correct memory locations. There is a standard DEC way of doing this which is that a short program called the RIM (Read In Mode) Loader is first entered by hand from the front panel and then this program is used to load another one called the Binary Loader. Both of these programs are loaded into the top 'page' (the last 128 decimal, 200 octal words) in field 0 of memory. Normally DEC programs do not use this page and this means that the loaders are always available for use, one exception being if memory test are run in this area. The RIM program comes in 2 variants - 1 each for the low- and high-speed readers and since our emulator is pretending to be the console reader we need to use the low-speed one. The low-speed RIM listing is as follows:

This is the shortest practical program to perform a low-speed reader tape load, and RIM format tapes have a very specific format to be used with it as shown opposite. The format uses the least significant 6 columns 6-1 of consecutive frames of tape (characters) to represent 12-bit words which may be either an address or data. Channel 8 punched indicates that the current frame is leader or trailer and is to be ignored. If channel 7 is punched it indicates that this is the first of a frame pair which is to be interpreted as an address. If channel 7 is not punched this indicates that the frame pair contains data which is to be stored at the address given by the previous address frame pair. RIM can only handle program loading into a single field but by setting the Extended address appropriately it can run in any field and load into the same field or any other.

The RIM loader program is toggled into the machine from the front panel and started. The program is now waiting for data from the emulator. We click 'Send File' on the emulator and in the pop-up window select the binary of the Binary Loader program (naturally this is provided in RIM format). The Binary Loader is read into memory and since RIM format has no way of recognising the end of the input tape the machine must be HALTed manually. The Binary Loader should now be available in memory. A quick way to check that at least something has happened is to EXAM address 7777 which should contain a JMP instruction. If so, the chances are that the Binary Loader has been loaded. There is no practical way to verify this except by trying to run it. The Binary Loader uses a slightly different, slightly more compact format of input tape and can also handle tapes which load into more than one memory field.

As a by-the-way, some of DEC's and other binary tapes have more than one section separated by leader tape. The Binary Loader will halt after each section and normally the user will restart the computer to read the next tape section; however in this case since there is no handshake the emulator will continue to send the remainder of the binary file whether or not the computer is listening so the second and subsequent sections will not be loaded. Aaron Nabil has suggested a modification to the M8655 (a more modern version of the M8650) to add flow control but I have preferred to write a short program on the PC to break such binary files into separate sections for individual loading.

The Binary Loader tape format is similar to RIM format but has the following features: A punch in channel 8 only is leader/trailer code and is ignored by the program. Punches in both channel 7 and 8 indicate a field setting with field given by channels 6-4. Like RIM, a channel 7 punch indicates that this frame pair is to be interpreted as an address. If channel 7 is not punched this indicates that the frame pair contains data which is to be stored at the current address however, unlike RIM, the address pointer is then incremented allowing blocks of data to be loaded without intervening address pairs. The whole tape is checksummed and the last 2 frames contain the checksum which is used by the Binary Loader as a coarse verification that the tape has been read correctly.

As a flyer I decided to try to load FOCAL, DEC's interactive algebraic programming language. Start the Binary Loader at address 7777. Use the emulator to 'Send File' the binary file for Focal. After a few seconds the computer should halt automatically and if the front panel display function switch is set to display the accumulator it should show zero. If this happens it demonstrates that the tape was loaded correctly and the tape checksum validated OK. The Focal tape I used was in two parts - the main program and the initialisation routine - so it required two separate loading sequences as above. Again rather surprisingly this worked fine so I closed the Bray's terminal and opened Hyperterminal and set it to the appropriate COM port, 38400 baud, 7 data bits,  parity forced on, 1 stop bit and no handshaking.

To run Focal I loaded address 0200 (Focal's starting address) and pressed Clear and Continue and was rewarded with the following output:
CONGRATULATIONS!!
YOU HAVE SUCCESSFULLY LOADED 'FOCAL,1969' ON A PDP-8 COMPUTER.

SHALL I RETAIN EXP, LOG, ATN ?:

and waited for further instructions. This is Focal's initialisation routine which allows trading off of functionality and program space.

maindec-8e-d0ab-pb	PDP-8/E  Instruction Test 1	Tests the AND, TAD, Operate and basic MQ instructions
maindec-8e-d0bb-pb	PDP-8/E  Instruction Test 2	Tests autoindexing, indirect addressing and DCA instructions plus basic interrupt handling etc.
maindec-8e-d0cc-pb	PDP-8/E  Adder Tests	Tests the adder circuitry
maindec-8e-d0db-pb	PDP-8/E  Random AND Test	Thorough test of the ADD instruction with random addresses and data
maindec-8e-d0eb-pb	PDP-8/E  Random TAD Test	Thorough test of the TAD instruction with random addresses and data
maindec-8e-d0fc-pb	PDP-8/E  Random ISZ Test	Thorough test of the ISZ instruction with random addresses and data
maindec-8e-d0gc-pb	PDP-8/E  Random DCA Test	Thorough test of the DCA instruction with random addresses and data
maindec-8e-d0hc-pb	PDP-8/E  Random JMP Test	Thorough test of the JMP instruction with random addresses
maindec-8e-d0ib-pb	PDP-8/E  Random JMS Test	Thorough test of the JMS instruction with random addresses
maindec-8e-d0jc-pb	PDP-8/E  Basic JMP/JMS Test	Basic test of the JMP & JMS instructions with random addresses
maindec-8e-d1aa-pb	PDP-8/E  MM8-E 4k Memory Checkerboard	Intended to test a 4k core memory stack under worst-case access conditions
maindec-8e-d1bb-pb	PDP-8/E  KM8-E Extended Memory Checkerboard	Similar to above but able to access up to 8 memory fields
maindec-8e-d1ea-pm	PDP-8/E  4k Memory Address Test	Checks for proper memory addressing on a 4k memory (N.B. RIM Format)
maindec-8e-d1fb-pb	PDP-8/E  Extended Memory Address Test	Similar to above but able to access up to 8 memory fields
maindec-8e-d1gb-pb	PDP-8/E  Memory Power  Off/On test	Verifies that memory corruption does not occur due to (simulated) power failure
maindec-8e-d1ha-pb	PDP-8/E  Memory and Timeshare Control Test	Tests all IOTs and function for extended memory addressing and timeshare control
maindec-8e-d2aa-pb	PDP-8/E  Teletype Control test	Tests all IOTs and data flow associated with the teletype control KL-8/E

Together these diagnostics virtually guarantee that the PDP-8/E is functioning faultlessly. Listings of most of them are available giving operating instructions and hints for faultfinding. There was a number of versions of the various diagnostics - generally the later the better I suppose (?) but it is not always possible to find either the latest or a corresponding version of the source or listing (though usually the most important part is the operating instructions!). Just a question of doing the best we can. I have had a number of failures where a basic instruction appeared to work properly during initial routines toggled in by hand but failed during a diagnostic. Naturally there are just too many possible combinations to be able to exhaustively test from the front panel. So far though I've been able to reduce a failing diagnostic to a simpler loop for single-stepping or probing.

The memory tests are designed to test DEC's core memory stacks and are less relevant for a home-made semiconductor memory however they will still verify correct operation, just not under the kinds of worst-case patterns which might affect RAM matrices. During testing all of the main diagnostics were passed successfully apart from some 'soft' memory errors in the core stack. Since this is likely the most difficult area to diagnose and work on I decided to take the core stack out meantime and run with only the 32k RAM card. The 32k RAM card itself initially threw up a number of memory errors which is a known problem with the design and is associated with the much higher speed of modern ICs. There are a number of solutions from using slower ICs to slugging some of the signals with small capacitors but I found that if the board was placed close to the processor cards at the front of the omnibus it ran reliably so meantime at least that is a workaround. I have a number of other core stacks to worry about later too!

Running the diagnostics occupied many hours and during this the processor suffered another couple of IC failures, 1 in the major registers board and 1 in the extended memory address board (which had not been used up until then). These were easily identified and repaired thanks to DEC's detailed documentation and circuit diagrams.

Page last updated by on 16^th January 2015