PDP-11/40 #2
Restoration 2025

10/29/25

We did an initial assessment of the PDP-11/40 cabinet and CPU chassis.

• This chassis is S/N 385 so it has the older AC and DC power distribution design, and the older Programmer's Console. 

• The first power distribution backplane has two burnt connector contacts for the +5V source. The mating  power connector is missing the two +5V contacts, and the housing is burnt where the two contacts go. We don't have any spare power distribution backplanes.

• The power feed harness where it connects to the first power distribution backplane was modified to feed the PDP-11/23 backplane.  Two +5V wires need to be reconnected to the first power distribution backplane connector.

• There are only two +5V power supplies installed. If we install Unibus boards in the back of the chassis we will need to install a third H744 +5V power supply.

11/1/25

• We removed the new design 21" BA11-F expansion chassis from the short DEC cabinet and installed it in a full height cabinet. It was amusing to see a Compaq label on the cabinet. This was actually quite a bit of work to move the chassis because of the large and heavy parts.

• We installed a DEC 861C AC power controller in the bottom front of the cabinet. This controller can be remotely controlled by the key switch in the PDP-11/40 console.

• We used a new design bracket to install the programmer's console on the chassis. I guess this now makes the BA11-F a PDP-11/40 CPU chassis.

• We need to repair the AC power wiring for the fans in the power supply.

11/5/25

• Remove all of the Voltage Regulator Modules from the H742 Power Supply.

• Connect AC power the H742A Power Supply and measure the +5VDC and +15VDC outputs.

  • They were OK.

• Added upper fan tray from one of the unused PDP-11/45 expansion chassis. 

• Verify that all of the fans in the CPU chassis and Power Supply are working.

  • One upper fan and one lower fan are seized and need to be replaced.

• Install the H744 +5VDC regulators in slots A, B, and C one at a time and verify that they work OK.

  • They are OK and were adjusted to +5.0VDC

• Install the -15V regulator in slot D and verify that it works OK.

  • It was adjusted to -15.0VDC

11/8/25

We spent some time Saturday fiddling with fans. One of the upper fans was binding so we took it partially apart and sprayed it with WD40. That made a mess when it spun up, but al least it ran. It would not start after a power cycle and we didn't have tiny snap-ring pliers to take it completely apart. The two unused 21" chassis that we have been using for parts don't have any fans left, so we will need to hunt in the warehouse for another chassis that can donate fans. I know where there is a BA11 chassis...

Backplane Signal Connector Voltage Measurements

Pin Voltage

1. 0

2. 2.27

3. 0

4. 0

5. 0

6. 0

 Backplane Power Connector Voltage Measurements

Pin Voltage

1. +5

2. +15

3. 0.02

4. +4

5. 0

6. 0

7. 0

8. 0

9. 0

10. 0

11. 0

12. 0

13. -15

14. 0.02

15. 0

11/12/25

• We made another try at repairing the top front fan. We disassembled the lubricator, removed small snap ring, cleaned and lubricated shaft, and reassembled everything. It seems to be working OK now. We still need to repair the bottom rear fan.

• We removed the processor boards and processor backplane from the BA11 chassis and installed them in the PDP-11/40 chassis.

• We made a best effort to determine how the console cables connect to the processor boards.

• When we powered on the system the BUS and PROC lights lit, and nothing else. This means that the Processor has control of the Unibus, and the Unibus is active.

• There was no response to any of the switches. We need to adjust the power supply voltages and insure that the AC LO and DC LO signals from the power supply are inactive.

• We replaced the Unibus jumper with an M9312 Boot/Terminator board, but there was no change to the behavior.

11/15/25

• We adjusted the +5V supply to +5.05V at the connector on the power distribution backplane. The specification says +/-5% so we could have adjusted it a little higher.

• We verified that the AC LO and DC LO signals are inactive.

• We installed my two KM11-A debuggers so we could see what the KD11-A processor, KE11-E EIS, KE11-F FIS, and KT11-D MMU microcode is doing. It looks like the processor, EIS, FIS, and MMU execute just two microcode words and then stop. The microcode should always be running, so this is the first thing we will need to debug and repair. There is a microcode listing in the processor schematics, but it is not so easy to read.

• When the processor was first turned on the KM11-A displayed these two sequences. The PUPP is the past microcode address and the BUPP is the current microcode address. The 377 is the correct Power Up Init address, but the next microcode address should be 334, and then 335. 

  • PUPP 337 (TRP17) , BUPP 060 (EXM07)

  • PUPP 036 (CNT00) , BUPP 076 (STA01)

• The museum has another 11/35-11/40 processor board set, and I have a set in my personal collection. Maybe one of the other processor board sets will work and we can use it to test the other boards?

11/19/25

• We repaired AC wiring to the fans in the H742 Power Supply.

• We installed the DD11-DK 9-slot and the VT-11 4-slot backplanes, and installed the memory, I/O, and video boards and readjusted the power supply voltages. We connected the 9-slot backplane to the processor backplane and moved the M9312 Boot/Terminator board to the end of the 9-slot backplane.

• We verified that the cables between the programmer's console and the processor boards was correct. We marked the cables to make servicing easier.

• Turn the MCLK ENAB switch on the KM11 on, cycle MCLK to step through the microcode.

  • It looks like the KM11 with the LEDs has either a driver transistor that does not work or a bad LED. The KM11 with the light bulbs works OK.

  • The PUPP and BUPP addresses cycled through the pattern 070 (DEP07), 071 (DEP08), 072 (DEP09) and back to 070. This is part of the DEPOSIT microcode. The microcode word at 072 should have gone to word 030 instead of 070. Maybe there is a stuck bit in the microcode address generation logic?

11/22/25

• We installed the processor board set from the PDP-11/35. This is just the basic processor, no MMU, EIS, FIS, SLR, or LTC. This board set seems to work mostly OK. We can load an address OK, but when doing a deposit we almost always pick up bit 10. Maybe a problem with the data paths board or a bad connection somewhere. That will likely be the next debug project.

• The microcode board is the only one without soldered in jumpers, so we tried the one from the PDP-11/40 board set and it works OK.

11/29/25

• We installed a TU56-H DECtape drive in the I/O cabinet with the TC11 DECtape controller.

• We installed an RX02 floppy drive below the TU56. That took two tries to get it in the right place.

• We will install two RL02 disk drives below the RX02 floppy.

• We found an RL11 disk controller and I/O cable in an 11/34A in the warehouse. We will use it in the 11/40 for the RL02 disk drives.

• We know that there is a DEUNA in an 11/44 in the warehouse. We would prefer the newer DELUA, but we don't have one. The DEUNA needs LOTS of +5V. Fortunately we have 75A of +5V available in the chassis.

• We did some more debugging to see if we could find a pattern to which switches caused bits to be picked up when depositing data to memory. Swapping the M7232 KD11-A U Word board for a spare did not make any difference. We were able to read the boot ROMs on the M9213 Bootstrap/Terminator. We have ROMs for the RX02, RL02, and high-speed paper tape installed. We need to make a ROM for the TU60 cassette.

• We noticed that when the front panel stopped responding the microcode was looping in the trap microcode. Pressing START would get the microcode back to normal. Maybe one of the Unibus boards was generating an interrupt?

• We removed all of the Unibus I/O boards and replaced them with G7273 continuity cards to simplify debugging. After a few hours of fiddling the CPU would not interact with the Unibus. We think our next step will be to swap the M7231 KD11-A Data Path board for a spare. We will need to change the jumpers on the spare board from a fully optioned 11/40 to a minimal 11/40 CPU on the spare board. We will take pictures of the boards so we know where the jumpers should be.

• Mike found his DEC Universal Hex-Extender board so we can chase signals to individual chips on boards.

• We went looking for an RS-232 serial console cable. We found one in an 11/34A and took the DL11 that it was attached to. We replaced the DL11 in the processor backplane with the one from the 11/34A. It was jumpered for 9600 baud.

• We tried running ODT from the ROM on the M9213 Bootstrap/Terminator, but saw nothing on the VT220 console.

• We tried depositing ASCII characters to the DL11 transmitter buffer at 777566, but saw nothing on the VT220 console.

12/3/25

• Swap the M7231 KD11-A Data Path board for a spare that has been jumpered for a minimal processor.

• We need to check the jumpers to insure that the bus address of the DL11 in the processor backplane is set to the serial console address. When a jumper is installed it is a Zero and not installed is a One. We need to match address bits 10:03 to be 111 111 101 110 XXX. The XXX part of the address selects the register in the DL11. The jumpers for address bits A7 and A3 need to be installed.

RCSR: 777560
RBUF: 777562
XCSR: 777564
XBUF: 777566

• The M9312 Bootstrap/Terminator contains ROMs for ODT (Octal Debugging Technique) and for booting from different storage devices. ROM #23-248F1 contains ODT. We will need ROMs #23-751A9 for the RL02, #23-753A9 for the RX01 (DX) or #811A9 for the RX02 (DY), #23-756A9 for the TU56, and 23-761A9 for the TU60 (CT).

• Starting the processor at 165144 will run ODT without running a diagnostic. Starting the processor at 165020 will run ODT with running a diagnostic. 

12/6/25

• Moved the PDP-11 into the new RICM Lab space. It's still broken.

• Connected the console key to the power controller, and it works!

12/10/25

• LOAD ADRS works, but there is some odd behavior with some of the switches. Bit-4 sometimes will not turn off after it has been turned on. Maybe a bad switch?

• DEP does not deposit to memory. Bits 10 and 4 go on when you press DEP even with all switches off. After the machine was running for a few minutes all DATA bits could be turned on with a DEP.

• EXAM shows the pattern 1775700. Earlier EXAM would show alternating patterns of all zeros and all ones. The ADDRESS increments correctly with each subsequent press. Bit-4 goes off when you press EXAM enough times to cycle through that address.

• The indicators RUN, BUS, PROC, and CONSOLE are all on. Holding START with HALT on will turn the CONSOLE indicator off.

• Pressing START with ENABLE on turns the RUN and CONSOLE indicators off.

• Pressing HALT after pressing START does not change anything. Pressing START again will wake the console up.

• Examining the PSW at 777776 yields all zeros except for bit-10. I think that bit-10 on is related to to the other bit-10 issues.

12/13/25

• LOAD ADRS was consistently showing that bit-4 was always on. The switch output is pulled high, and the switch grounds the signal to make a zero. We replaced the switch with a NOS switch from a DEC field service tool kit. After replacing the switch we can EXAM and DEP the processor registers, but not the Unibus memory. We kept the broken switch in case we get desperate and are forced to repair a switch.

• We tried to toggle in a program in the processor registers, but found that data bit-10 was stuck on. That severely limited the instructions that we could use. We were unsuccessful at getting this to work. We will try again next time.

• Bit-10 works OK when we do a LOAD ADDR, but is stuck on when we do a DEP. That means that the switch is probably OK.

• When we do repeated EXAMs we can find memory locations where bit-10 is off. The bit-10 DATA LED is driven by the output of SN74174 E31 which latches the output of the SN74181 ALU on the Data Paths board. We put the Data Paths board on an extender so we could look at bit-10. The metal stiffener on the hex-extender hit the plastic guide rails on the chassis. We had to remove the stiffener to get the extender board fully seated. We looked at pin-6 D4, pin-7 R4(1), and pin-9 K4-2 CLK D H with the Rigol 'scope. We confirmed that E31 was OK by doing repeated EXAMs and finding locations where bit-10 was on and off. We were surprised to see that there was lots of activity on pin-9 each time we pressed EXAM. The activity would come in bursts that would repeat several times and then stop. When the activity on pin-9 stopped the values on the input and output pins of E31 matched. It looks like the problem with bit-10 is upstream of IC E31. We will ask for some help from the PDP-11/40 experts on where to look for the stuck bit-10 problem.

• Looking at E31 was a mistake.

12/17/24

• Ashlin made a video of his 11/40 doing a LOAD ADDR, DEP, and EXAM. I made a spreadsheet with his microcode sequences and compared them with our 11/40. For LOAD ADDR the sequence matches. For an EXAM it skips microcode address 057. After studying the microcode flow charts we found that it should skip 057 for register addresses and execute 057 for non-register addresses. That means that the microcode sequences are the same as on Ashlin's 11/40.

• We looked at the SN74153 E34 on the Data Paths board to see what the K1-4 DMUX10 H signal is doing. It does change so it is not stuck. The S1 signal is high and the S0 signal is low, so the C input on pin 4 is selected. That signal is K1-4 D10 (1) H. Pin 4, the C0 input, changes state during a LOAD ADDR or EXAM, so it is not stuck. The states of Pin 4 and Pin 7 match when the console is idle. So the SN74153 E34 is probably OK.

•  We looked at the SN74174 E31, part of the D REG, pins 6 & 7 for the input and output, and pin 9 for the clock signal. We can see lots of data on pins 6 & 7, the CLR signal on pin 1 is always high, and we see lots of CLK signals at about a 200nS period. The last CLK latches the data on pin 6 to pin 7. When we do a DEP the input data on pin 6 is always high for the last CLK signal.

12/20/25

• It looks like all of the parts on the Data Paths board that are used for LOAD ADDR are also used for DEP. We were surprised to find that the 16x Scratchpad Registers on the Data Paths board are implemented with 4x Intel 3101A SDRAM chips. That is supposed to be Intel's first commercial product. When we DEP to a Register bit-10 is always on, so we suspect that the problem might be in the Intel 3101A SDRAM chips that are used to implement the registers. We looked at the input, output, CS, and W signals and were confused by what we were seeing.

• We looked at E34, the 74153 that is the DMUX for bits 10 & 11 again. The output on pin 7 matches the LED for Data bit-10. After and EXAM the S1 & S0 signals on pins 2 & 14 are 10. This selects the C0 input from pin-4, which is the K1-4 D10 (1) H signal. The K1-4 D10 (1) H signal matches the state of the LED.

• When we deposit all zeros into one of the scratchpad registers LED-10 goes on and the K1-4 D10 (1) H signal is high.

• Look at the A and B inputs to the 74181 E31, part of the ALU, to and the M & S0..S3 inputs. We should be able to determine which input(s) were being used and what ALU function was selected. Then we can trace the signals further back.

• We selected a memory address and then single-stepped the DEP microcode. It all worked OK until 071 was displayed on the PUPP lights and 072 was displayed on the BUPP lights on the KM11.  I guess that means that it had just completed step 071 and it will execute 072 next. Step 071 is a NO-OP so we are not completely clear on exactly what it was doing at this point and what caused bit-10 to be turned on when it should have been a zero.

• We single-stepped the DEP code again, except with the REG address of 777700 and data of 175777 so bit-10 was off. At step 066/067 the correct switch data was displayed and bit-10 was off. When step 071/073 was displayed 177777 was displayed for the data instead of 175777, so it picked up bit-10.

• One more time. When 066/067 was displayed both the Address and Data showed the switch data. At step 071/073, 177777 was displayed for the data instead of 715777, so bit-10 turned on again.

• The Console Switch data traveled from the Switches, to the Unibus Data Lines, to the D MUX, to the B REG, to the B MUX, to the ALU, to the D REG. The D MUX<Unibus<Console Switches path is used with the DEP function and seems to work OK. We need to check the B REG, B MUX, ALU, and D REG to see where bit-10 was turned on.

12/24/25

• We had a Discord Channel open with Ashlin so we had real-time technical support from a PDP-11/40 expert.

• We set the switches to 777570, the address of the Switch Register, and pressed LOAD ADDR. The address in the switches was displayed in the ADDRESS LEDs, all OK so far. We set the switches to 000777, which is a br.-1 instruction. We set the ENABLE/HALT switch to ENABLE, and pressed the START switch. The CONSOLE LED turned off indicating that it was running a program not the Console microcode. Setting the ENABLE/HALT switch to HALT caused the CONSOLE LED to go on, indicating that the program stopped and it was running the Console microcode. We set the MCLK ENAB switch on the MK11 to off, and single-stepped the microcode while it ran the br.-1 instruction. It looks like the processor is correctly executing the instruction. Lots of the processor hardware needs to be functional for this to work, so this is a really good sign.

• We duplicated the DEP 000070 to 000007 sequence that Ashlin posted in a video on VCFed. When we are at microcode step 071 we see 000007 in the ADDRESS and 002070 in the DATA LEDS. We should see 000070 in the data LEDs, so we are picking up bit-10 in the data.

• We set the target address to 777700 (Register 0) and set the data switches to 125252 so bit-10 is off. At microcode step 066 the address is 777570 (switches) and the data is 125252. That means that the Console Switches got onto the Unibus data lines, then to the D MUX, and then to the DATA DISPLAY. So the Unibus and part of the DMUX are OK.

• We connected the 'scope to the B REG output for bit-10 (E30 Pin 7), the D REG input (E30 Pin 6), the D REG output (E31 Pin 7) and the D REG CLK (E31 Pin 9). We triggered the 'scope on the D REG CLK signal. We stepped through a DEP microcode and at step 071 the D REG was CLKed. At that time the switches were all zeros. The input to the D REG was a 1 and it latched a 1. The data going into the D REG should have been a zero so it looks like the D REG is OK. and the problem is in the B MUX or ALU.

• We looked at the S1 & S0 (E38 pins 2 & 14) inputs on the B MUX, E38. These signals control which of the four possible input ports is gated to the output port. The data for bit-10 from the B REG comes into Port A, so we also looked at the A0 input (E38 Pin 6) and F0 output (E38 Pin 7). When port A is selected the F0 output is always high. When port D is selected the F0 output is low. We can change the A0 input by setting switch 10 and pressing DEP. The output always is high. It looks like the 74153 E38 that is part of the B MUX is bad.

• We replaced the 74153 E38 on the Data Paths board with a NOS spare from Mike's collection. When we retested the system we found that bit-10 can now be set and cleared in the registers.

• Now to find out why we can't EXAM/DEP Unibus memory. When the Unibus memory worked two weeks ago we found that the memory contents was alternating words of all zeros and all ones at power up, so we have some idea of what to expect when doing an EXAM. The Unibus memory is connected to the Data Paths board that we just fixed, so the debugging setup is the same.

• When we EXAM memory the data is always 177570 which is the constant for the address of the console switches. 

• Microword 031 loads the Constant 177570 into the BA Register, and reads the data from the Unibus. Previously R[ADRSC} that contains the target address was loaded into the BA Register. Microword 060 saves the Unibus data in the B Register. Microword 061 transfers the B Register data to the D Register.

12/27/25

• We duplicated Ashlin's microcode single-step of the EXAM function to see how our PDP-11/40 behaves differently from his.

  • RICM Ashlin's

  • Step Display Display

  • 056/055 002000/002000 002000/002000

  • 055/031 002000/000000 002000/177702

  • 031/060 002000/000000 002000/177702

  • 060/061 002000/000000 002000/000300

  • 061/030 002000/177570 002000/177570

  • 030/315 002000/000000 002000/000300

  • 315/046 002000/000000 002000/000000

  • 046/026 002000/000000 002000/000300

• Ours is behaving differently from Ashlin's and differently when running at full speed and when it is single-stepped.

• We looked at the addresses and data that go to the Unibus from the Data Paths board and found that one of the address switches was on which would put the memory board above the 18-bit address space. We corrected the setting and can now address the CSR register on the MS11-LD at 772100. When we looked at the CSR the MSYN to SSYN time in a few hundred nanoseconds. If we presses EXAM again the delay was many microseconds, so the memory board was not responding. If we read memory the red LED turned on to indicate a parity error. The CSR had bit-15 on to indicate a parity error, and an error address of 000000. That all looks good.

• Now the processor is stuck in the 026/046 loop and will not do anything when we press console switches.

• We repaired a broken trace on the hex-extender board and now the processor is behaving better. Unibus memory is working again. 

• We tried to load some simple programs, but they don't run as expected. A memory sizing program didn't halt when it got a Bus Error Trap. We found that the HALT instruction does not halt the processor.

• The microcode treated the HALT instruction as a NoOp and kept running.

12/28/25

• The machine is being finiky. Yesterday at power on it would sit in the 026/046 console microcode loop, but would not break out when a console switch was pressed. This is a hardware problem where the signal that indicates that any switch has been pressed is not being activated, or the logic that branches the microcode based on certain signals is not working.

• We reseated cables and boards, and the processor is alive again. We deposited a HALT instruction (000000) in memory at address 001000. We turned the MSTOP switch in the KM11 on and set the console switches to 000016, set the ENABLE/HALT switch to ENABLE, and pressed the START switch. The microcode stopped at 016 (FET02). We turned teh MSTOP switch off, turned the MCLK ENAB switch on, and cycled the MCLK switch. We executed microwords 001, 004, and 005. At this point it should have branched to address 122 to go to CONSOLE A and back to the 026/046 console loop. The MK11 says that it it is going to go to microword 123 (SER03) instead of 122 (CON00).

• Ashlin suggested that we look at the output of the SN74150 E81 on the IR Decode board. We put it on the (repaired) extender and connected a 'scope to pin 10 of E81. We stopped the microcode at 016 and stepped the microword to 004. At that point pin-10 of E81 was low as it should be. At microword 005 pin-10 of E81 went high, and the next microword is 133 where it should be 122. That would make both BUBC0 and BUBC3 incorrect. We repeated the test and it is reliably going to microword 133 instead of 122.

• We swapped the IR Decode board for a spare. This one halts when executing the HALT instruction. It also increments the target address by 4x instead of the correct 2x when doing an EXAM or DEP. We have one more IR Decode that we can try after we install a W1 jumper.

12/31/25

• We added jumper W1 to the third IR Decode board and gave it a try. The microcode didn't run at all, so that board is really broken.

• We have had a recurring problem where the microcode doesn't process BUT 6 where it looks for any console switch press. It turned out to be an operator error problem where we had the console power switch a little last the POWER position and it enabled the console LOCK function.

• We are back to debugging the IR Decode board where the HALT instruction doesn't work. We set the 'scope up to look at the pin-10 output BUBC0 (BUT37:20) L of the 74150 E81, and the Pin 9 input K2-5 UBF4 (1)H and the pin 16 input K3-5 (BUT37) H. At microstep 004/005 pin 9 goes low to enable the MUX, pin 16 is high which makes the pin 10 output low. This turns on the low order but for the next microcode address which makes it jump to 123 instead of 122.

• We looked at 74H53 E53 on the IR Decode board. The output on pin 8 is high when when stopped the processor at step 004/005. We started looking at the inputs and found that pins 1 & 2 were at 1.5V, so neither high or low. The signal comes from the 74H20 E66, so we need to replace it.

• We replaced the 74H20 E66 and now the HALT instruction works correctly.

• If we DEP to a register everything works OK. If we DEP to memory the processor goes into space. We stepped through the DEP microcode. The microcode went from step 072/030 to 336/317. Ashlin pointed out that these are the addresses of the TRAP ERR microcode, so it looks like the memory board drove BUS PB L signal to report a memory parity error when we deposited to uninitialized memory. It should never report a parity error on a memory write.

To the 2026 restoration blog.