DEC PDP-8/e Restoration Part 2

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


Part 2 - Processor Checkout and Debug

Now that the power supply has been repaired and checked for voltages within specification it's time to move on to running the processor up. The first steps are to refit the power supply rear grill, remount the power supply to the chassis (4 screws), refit the omnibuses and M935 omnibus bridge connectors and refit the power wiring harnesses then check again that the power supplies are good. It pays to take things steadily as it can sometimes be difficult or at least time-consuming to acquire spare parts if any are damaged. When this checks out OK we can refit the KC8EA programmer's panel card in the first slot of the omnibus and reconnect the yellow and blue wires to the spade connectors at the left side of the card. Note that there are 2 white plastic spacers which clip onto the top edge of the board.

One last check then apply the power. All of the bulbs on the KC8EA should light except for the RUN lamp which should glimmer slightly. (The design allows a trickle current through the bulbs in the off state which reduces the thermal shock when they are illuminated). Surprisingly only a couple of bulbs had failed and I had a few spares to replace them with. These are somewhat difficult to obtain now and although some people have replaced them with LED circuitry (as used in the later PDP-8/m for instance), bulbs of course give a more realistic appearance. Vince Slyngstad has done some research on replacement bulb sources here though the prices of the few available are a bit eye-watering! Reassembly of the front panel is a matter of reversing the initial dismantling, not forgetting to put the insulating washers under the tubular spacers on the plastic screws. Slow and steady - check after every small step.

For the initial testing I fitted the following (minimal?) board set checking power supplies / no shorts after each board:

M8330 Timing Generator Generates all machine timing signals
M8310 Major Register Control These 2 boards constitute the CPU
M8300 Major Registers
M8320 Bus Loads In last slot of last omnibus
G104 4k Memory Sense/Inhibit }
}This should be a 'matched' set of boards with the links set to Field 0
H220 4k Memory Stack
G227 4k Memory XY Drivers
M849 RFI Shield Immediately before first memory card

Note that the cpu and memory stack require H851 top connectors.

With this minimal board set the following simple test program was toggled in by hand from the front panel. The program continually increments the accumulator  then loops for a delay period. With the panel display function switch set to the Accumulator it should be seen to count (at about 20Hz). After toggling it in and before running it it's good practice to check that it has entered correctly (set address to 0000 then press EXAMine repeatedly) with the panel display function switch set to MD (Memory Data). If the program has entered correctly there is some evidence that the panel and memory are basically functional. In this case all was satisfactory. However when run the program did not produce the desired results. ;o(

Address Data Instruction Function
0000 7001 IAC Increment Accumulator
0001 2101 ISZ 0101 Increment Memory Address 2101 and Skip if it is zero
0002 5001 JMP 0001 Jump back to Address 0001
0003 5000 JMP 0000 Jump back to Address 0000

Oscilloscope testing seemed to indicate that the Timing Generator was functioning correctly at least to a first level so the fault was likely in the processor boards. The PDP-8 has both Single Step and Single Instruction capability and by stepping through the program it seemed that the ISZ instruction was jumping back to address 0000. It's possible to identify processor faults fairly accurately by single stepping and checking the display results - in this case there seemed to be a fault on the Major Register Control board - but often it's more reassuring to verify things with an oscilloscope or analyser. Access to the boards can be awkward due to some boards requiring top connectors. DEC manufactured flexible extension connectors to allow such boards to be exercised whilst mounted on an extender card but of course these are no longer obtainable.

Douglas Electronics makes a range of DEC-compatible breadboards and extender cards and can also supply the difficult-to-obtain 0.125" spacing double-sided connectors which they use. They are a particularly friendly small company used to dealing with low-volume enquiries and I was able to acquire a few different sized extender cards and sockets from them. I cut some of the sockets down to size and used ribbon cable to make up some top connector extender cables as shown below. Using these I could mount individual cards far enough clear of the others for easy probe access. The made-up sockets aren't perfect because they are open-ended so allowing for misplacement but given the coarse 0.125" spacing it is easy enough to align things adequately.

Although it seemed to have basic functionality I was a little concerned that the core memory stack might have faults which would interfere with the debug. Vince Slyngstad has made available a design, parts-kit and pcb for an omnibus-compatible 32k memory card which I have built and chose to use instead. By entering short test sequences from the front panel and stepping through them it was possible to debug the processor to the extent that it seemed to have at least basic functionality. I noticed that whilst the cards were extended using the flexible connectors the front panel controls sometimes seemed to malfunction although the processor would operate correctly when running. During front panel operation a different set of timing sequences is used and it seems that some of these were affected by (probably) the ribbon cable coupling capacitances to which the normal processor timing was immune. The original DEC extenders used flexible flat cables with printed conductors which had very low inter-trace capacitance.

During the debug a number of integrated circuits had to be replaced. Fortunately though obsolete most of these are still readily available as NOS (new-old-stock). It should be noted that for many of their applications DEC used standard ICs selected by test to have a tighter parametric spread and standard ICs may not meet this specification, however to date I have not found any problems in using whatever I could find via Ebay and the like. I also found that after some hours of operation I had several new IC failures. I think that this is likely due to moisture ingress over the machine's time in storage combined with the effects of heating during use and these failures will probably follow the usual infant mortality/bathtub effect (I hope!).

diy flexible top connector extenders

processor debug in progress
(Note - the 2 mains gangs are on separate RCDs
to allow for tripping by vintage (or faulty) kit

processor debug in progress
cpu cards connected via flexible extenders

The next step is to run the standard DEC processor diagnostics. These are much too large to try to toggle in by hand from the front panel so some method of loading them automatically is needed. When the machine was new this would be done using either the low-speed paper-tape reader on the console teletype or, if available, a high-speed paper-tape reader. Fortunately it is quite easy to replicate this using a PC and terminal emulator which can be used both as a console and to load binary programs.

This machine had an M8650 asynchronous I/O card. This is well described in the DEC maintenance manuals and Doug Jones has published a description here of the various link settings and modifications required to connect it to an RS232 interface at different baud rates. This board was originally used with a teletype on current loop and was set for 110 baud which is inconveniently slow for use with a PC. The timing is derived from a 14.418 MHz crystal, but by replacing this with a 19.6608 MHz crystal (easily obtainable - I used the cheapest from Ebay which worked fine) this can be changed to 150 baud and then, by changing some links, to 300, 600, 1200 or 2400 baud. However by bypassing some of the divider chain it is possible to obtain a standard 38400 baud which is a much more useable rate and this is what I chose (even faster speeds are also possible but not ones which are normally available on PC serial interfaces). The I/O socket has connections for both current loop and RS232 and the latter is what we need here. The I/O socket is a BERG connector but a standard 40-pin PC ribbon cable connector fits nicely so I cut a short length of this and used it to make up the PDP-8 end of a 9-pin serial cable to the PC. Note - the current loop and RS232 input lines are connected to the receive circuitry and a jumper in the connecting cable is required to select which of these is then used to connect to the data input. The board address links were already set to the standard console codes of 03/04 so no changes needed. The original 110 baud current loop used 2 stop bits but the standard for higher speed RS232 is just 1.

The machine configuration was augmented for the main debugging. As well as the I/O card I added an M837 Extended Memory / Timeshare Control card which allows memory above the basic 4k words to be accessed. I also fitted the original 4k core memory stack and set the 32k card to map in the upper 28k giving the machine its maximum 32k of memory but with the first 4k using core. As before, the cards were fitted one at a time checking for power supply problems and smoke ;o).

A terminal emulator is needed next on the PC, which one depends on which OS you are using. My workshop PC is Windows XP which runs cygwin for the times I want a unix machine (no space for multiple PCs). On XP I use the freeware Hyperterminal (not the one that comes with the OS as standard though!) for console I/O, but I still use the old-fashioned freeware Bray's Terminal Emulator for loading binaries (still seems to be around simply now called Terminal though I use an old version). Something to be aware of here is DEC's 'standards'. For normal ascii I/O DEC normally (but not always) used 7 bits with the parity bit forced on. For binary-type I/O they used the whole 8 bits with no parity. So to test things out I started Hyperterminal and set it to 7 bits plus mark parity, no handshaking, single stop bit. On the PDP-8 I entered the following program which should echo any character typed on the keyboard:

Address Data Instruction Function
0000 6032 KCC Clear keyboard flag (just in case
0001 6031 KSF See if a character has been typed
0002 5001 JMP 0001 No - keep waiting
0003 6036 KRB Yes - read it and clear the flag
0004 6046 TLS Echo it
0005 6041 TSF See if it has been sent yet
0006 5005 JMP 0005 No - keep waiting
0007 5001 JMP 0001 Yes - go round and do it again

(I know the TSF wait loop isn't really needed here but this is a debug, not a software test! ;o)). Somewhat surprisingly it all worked first time!

initial minimum configuration for processor debug

a few more cards added for main debug
note the M8650 connection to ribbon then to serial cable

signs of life - note run light!

Part 3 - Loading and Running Binaries

Page last updated by on 16th January 2015