• Please review our updated Terms and Rules here

PDP-11/05 restoration blog

thunter0512

Veteran Member
Joined
Sep 27, 2020
Messages
1,247
Location
Perth in Western Australia
I recently rescued a PDP-11/05 in a low-profile chassis. The poor machine was exposed to extreme moisture levels, dust and other filth and was infested by millipedes and spiders. I took it home and started the journey to clean, repair and restore it.

The key was missing, so I immediately placed an order on Ebay for a replacement key for A$29.95 (about US$20.00): https://www.ebay.com/itm/324778106688

Some ham-fisted individual has been in the machine before me and broke one of the sockets on the top of the backplane. There were a few chassis bolts missing, some were the wrong length and other were completely loose.

After opening the machine, I pulled all the backpanel PCBs:
  • M7260 – Processor Data Path and UART,
  • M7261 – Processor Control Logic and Microprogram,
  • G110 – Memory Control,
  • G231 – Memory Driver,
  • H214 – 8K Core Stack,
  • M930 - Terminator
Next I picked out and killed anything that moved and then vacuumed out the worst of the filth including dead insects, dust and decayed foam.

I then removed the front panel assembly noting that the plastic decal was mostly detached from the assembly held by decayed double sided sticky tape. Luckily it was otherwise undamaged and I managed to gently pull it off the metal body. I also removed the front panel PCB with the switches and LEDs from the assembly. The switches were filthy but cleaned up well using first a moist cloth and then some isopropyl alcohol.

I then used a relatively soft short haired pain brush to gently loosen all dust and other debris from all the PCBs taking particular car with any mod wires. I then used compressed air to blow all the loose stuff off again taking particular care with any components which might be damaged by the compressed air. I was very carefully with the H214 Core Stack keeping the compressed air far away and directing it away from the transparent acrylic sheet covered core matt so as not to damage the fragile core.

I used some isopropyl alcohol to clean all the PCB edge contacts and any areas which had some grime which wasn’t removed by brush and compressed air.

I removed the microswitch assembly from the front panel and cleaned it with moist paper towels.

Next I removed and cleaned the power supply PCB from the U-shaped power supply chassis disconnecting the AC inlet and the DC outlet Mate-N-Lok connectors. By undoing for bolts I could carefully lift out the U-shaped power supply chassis with the attached mains transformer and power supply fan. I had to carefully feed the 9 pin DC supply Mate-N-Lok connector through the arch shaped hole in the power supply chassis after removing the flexible grommet to create a little more space to get the connector fed through.

Using the hot air nozzle of my soldering station set to 100 degrees C I gently warmed the decayed double sided sticky tape left on the plastic front panel decal and rubbed it off without damaging the decal or point. I then carefully tried a solvents in one corner of the decal trying to find one which does not attack the paint. The first one was isopropyl alcohol and after applying some tiny drop and immediately wiping it off I saw a little colour on the white tissue. I then tried the same with kerosene and there was no paint coming off. Encouraged I left a little more kerosene on the paint and after maybe 10 seconds wiped it off without any colour on the tissue. The kerosene nicely dissolved the remaining latex based glue on the decal but did not attack the paint.

The key for the keylock arrived and I removed the keylock and soaked it in kerosene to remove decades old hardened grease. After some soaking I used compressed air to blow out the kerosene and residual grease and finally reoiled the lock.

Using brush and compressed air I cleaned all the power supply components, the main PDP-11/05 chassis and backplane and front panel. I then wiped over all parts with soapy water on a microfiber cloth and subsequently used compressed air to drive any moisture out. One hour in the sun made sure that everything was completely dry.

Now as all the parts were clean I moved everything into my small electronics lab to start the “bring-up” of the system.

After taking photos and carefully marking the 4 large electrolytic capacitors I removed all and slowly reformed them using a lab-supply current limited to 50mA. I slowly stepped up from 1V in 1V increments to the rated voltage of the capacitor. I paused at each step until the current dropped to 1mA or less.

The two large capacitors had some double-sided stick foam between them and the power PCB supply PCB to prevent the capacitors insulation from being punctured by protruding solder pins and shorting. Sadly moisture got into this foam and badly corroded PCB tracks in that area. I cleaned the mess with acetone and then sand papered it so that it would accept fresh solder. I then used copper wires and generous amounts of solder to restore the affected PCB tracks.

I re-fitted the 4 now reformed capacitors to the power supply PCB and with the PCB outside of the chassis, connected the 3 centre-tapped secondary leads coming from the transformer.

The power supply obviously required mains power. At first, I struggled with the mains power to the transformer. It turned out that the mains power is directly switched by two flimsy microswitches mounted to the front panel. One of the key lock operated microswitches did not reliably switch on until I slightly bent the switch lever. On other systems there is often a power relay or a more substantial switch to handle the mains power. Using just a microswitch was a surprise to me.

Once I had reliable mains power, the fans were running and the power supply nicely produced +15V, -15V but the +5V rail was only about +1.2V. With the excellent description of the circuit and trouble shooting chart in “DEC-11-H05AA-B-D PDP-11-05, 11-10 Computer Manual.pdf” from Bitsavers, I eventually identified D9 – a 2.4V Zener as the culprit. After replacing it the +5V rail became +5.25V which was close enough.

I then used very large wire wound 15 Ohm and 5 Ohm resistors on the +15V, -15V and +5V rails directly connected to the 9 pin DC Mate-N-Lok connector to load test the supply. The voltages were stable with or without the resistive load. A multimeter set to AC Voltage showed minimal ripple.

With good stable power I then started reassembly of the machine. Fitting the power supply PCB back into the power supply chassis turned into a very frustrating 2 hour struggle as the stiff cables and Mate-N-Lok connectors interfered with the two smaller electrolytic capacitors on the power supply PCB. I wrote about this and the solution in another thread: PDP-11/05 DC Regulator Module (5409728) cable routing

Briefly, the fix was using spacers to raise the transformer by about 4 – 5 mm so that the primary side Mate-N-Lok connector could be pushed underneath the edge of the transformer.

I reattached the cleaned decal to the metal front panel body using double sided 6 mm wide sticky tape. I then fitted the front panel assembly to the PDP-11/05 chassis.

With none of the PCBs plugged into the backplane I power on the system. Both Fans were blowing and all 16 the front panel LEDs were lit.

I then applied a very thin layer of Deoxit Gold to all PCB connector edges to ease insertion and removal and plugged all 6 PCBs back in. With some trepidation I powered the system on. Luckily there was no smoke or bang. I immediately checked all 3 power rails and there were at their nominal voltage and stable.

Using the front panel switches I deposited data patterns into core memory and was able using the examine switch to confirm that the correct values have been stored and that they remained stored across a power cycle. I finally entered the bootstrap loader as documented in the manual, verified that it was correctly entered and finally run and single stepped it.

It looks like the system is operational at a basic level. The only serious debugging required was the faulty Zener for the +5V rail.

I have not yet attempted to interface to the serial port as apparently that is not operating with RS232 levels, but with TTL levels. I will rig up a little converter circuit to deal with the conversion.

Once I have serial comms working I will be able to run diagnostics.

Now I am trying to find some simple serial output and input programs to toggle in.

Here are some photos (click on the photos to see them full size):

PXL_20240808_065110539.jpg

PXL_20240806_045246773.jpg

PXL_20240806_053656959.jpg

PXL_20240807_100551619.jpg

PXL_20240807_100604794.jpg

PXL_20240808_064652095.jpg

PXL_20240808_064659708.jpg

PXL_20240808_064735042.jpg

PXL_20240808_064945406.jpg

PXL_20240808_065004349.jpg
 
Last edited:
I have connected up a USB to TTL serial converter to the TTL serial pins in the back of the PDP-11/05. My laptop runs TeraTerm at 300 bps and is connected via the USB to TTL serial converter to the 40 pin Berg socket in the back of the PDP-11/05. Via the front panel I toggled in a small program which dumps the character set to the serial port. This produced continuous output on TeraTerm.

I then tried a small program which echoes back any received character to the terminal. This behaved strangely as the characters echoed were different from what was typed. While trying to understand what is happening suddenly the PDP-11/05's RUN light went off. Eventually I worked out that there is a regression in the core subsystem and now Bit 10 is stuck high even when you load it with zero.

I checked the power rails and they are still stable at their respective nominal voltages. I powered the PDP-11/05 off for about 30 minutes to let everything cool down. During all the testing the top lid was fitted, but the side panel which gives access to the PCBs inserted in the back-plane was not fitted, so it is conceivable that something got warm even though it is winter here in Australia and my electronics lab is quite cool. Nevertheless the stuck bit remained even after everything had a chance to cool to the ambient temperature of about 20 degrees Celsius.

I had similar problems with my LAB-8/e and PDP-8/e, so am confident that I can fix this provided the problem is not in the actual core mat.
 
I have connected up a USB to TTL serial converter to the TTL serial pins in the back of the PDP-11/05. My laptop runs TeraTerm at 300 bps and is connected via the USB to TTL serial converter to the 40 pin Berg socket in the back of the PDP-11/05. Via the front panel I toggled in a small program which dumps the character set to the serial port. This produced continuous output on TeraTerm.

I then tried a small program which echoes back any received character to the terminal. This behaved strangely as the characters echoed were different from what was typed. While trying to understand what is happening suddenly the PDP-11/05's RUN light went off. Eventually I worked out that there is a regression in the core subsystem and now Bit 10 is stuck high even when you load it with zero.

I checked the power rails and they are still stable at their respective nominal voltages. I powered the PDP-11/05 off for about 30 minutes to let everything cool down. During all the testing the top lid was fitted, but the side panel which gives access to the PCBs inserted in the back-plane was not fitted, so it is conceivable that something got warm even though it is winter here in Australia and my electronics lab is quite cool. Nevertheless the stuck bit remained even after everything had a chance to cool to the ambient temperature of about 20 degrees Celsius.

I had similar problems with my LAB-8/e and PDP-8/e, so am confident that I can fix this provided the problem is not in the actual core mat.
I have had significant issues with my 11/05's serial connection. I grabbed the M9312 rom board from my 11/34A and booted into the diagnostics rom. while not specifically designed for the 11/05, It works just fine if you need a way to quickly bootstrap the machine. I could tell that the machine was running the code but it was outputting garbage and the TTL serial did not allow for any character input. The clock that runs the UART (I believe this is the main system clock) was incorrectly adjusted after spending 10+ years in a garage. The UART Clock adjustment is on the Data Path / UART board. I suggest checking the baud rate.

I was able to get properly generated serial output. I had a bit of a problem. I can't actually get bits into the UART. I'll try again tomorrow to get TTL serial working bidirectionally on mine to hopefully help with yours.
 
The 11/05 has a jumper on the 40 pin connector that selects rs232 or current loop. Might be good to verify the jumper configuration.
 
The 11/05 has a jumper on the 40 pin connector that selects rs232 or current loop. Might be good to verify the jumper configuration.
Thanks for the suggestion, but I can't see any jumper selection feature on the 40 pin connector to choose RS232 vs current loop.
There appears to be TTL and current loop available concurrently.
 
It will likely take me one extra day to get some more information. A friend of mine also has an 11/05 in the BA11-D box and we plan to take a look at them tomorrow among other projects.

Given that all of these systems use identical cards in different configurations, I'm happy to pull measurements from my system.
 
Sorry I sent you on a pad path... 11/05 doesn't have hardware for rs-232.
Do you have the keyboard current loop shorted? You need to for TTL to work.
If its not shorted the UART will see a constant break.
 
Sorry I sent you on a pad path... 11/05 doesn't have hardware for rs-232.
Do you have the keyboard current loop shorted? You need to for TTL to work.
If its not shorted the UART will see a constant break.
No! That would explain why the TTL signal was never making it into the UART!! Im going to try this out as soon as I get home!!
 
I need to stop posting today. I'm wrong. Too little sleep. Current loop should be open.

Your console out is working.
SO from the UART goes to a 7408 to drive the TTL out. (no inverter)
The TTL in goes to a 7413 then to a 7408 to the UART. (1 inverter)
So output is not inverted but input is.

You need to invert the signal going to console TTL in.

Why would DEC not use the same signaling level for this?????
 
I need to stop posting today. I'm wrong. Too little sleep. Current loop should be open.

Your console out is working.
SO from the UART goes to a 7408 to drive the TTL out. (no inverter)
The TTL in goes to a 7413 then to a 7408 to the UART. (1 inverter)
So output is not inverted but input is.

You need to invert the signal going to console TTL in.

Why would DEC not use the same signaling level for this?????
I’ll give it a shot as well. I’m not sure if having CL open is causing this (based on this no) but I was under the assumption that it was just causing the UART in to be all 1’s or 0’s. I’ll try this afternoon to make it work with what I have on hand, I should have an inverter!
 
I think the Retrocmp page is really great but showing the right-side-up then upside-down pinouts confuses me a lot. Firstly I take the pinouts in the table is as looking at the back of the computer panel. If it is upside down, why is the 'A B' label on the left side in the photo, wouldn't it be more logical to be placed on the right side?
 
Depends on whose logic you're following :-}.
Quote: "The flat cable's red #1 wire must be oriented to the left. On my 11/05, I marked this side with an "A B" label."
 
Thanks Paul...
I annotated Retrocmp's diagram with the four corner pins as I read the table, but if this is not correct I will delete this image so as not to further confuse things:
PDP-11_05_SCL_connector_is_this_correct_or_not.png
(Not trying to hijack Tom's fabulous resto thread)
 
Well, you have it upside down from: https://github.com/jaylogue/pdp-1105-console-usb-adapter/blob/master/docs/pdp-1105-scl-connector.pdf
1723278302354.png
The accompanying photo there shows the red cable mark to the right:
1723278522503.png

Which is vertically flipped from (and what you have) https://www.retrocmp.com/how-tos/in...interfacing-with-a-pdp-1105-sorting-the-wires

1723278368634.png

The accompanying there shows the red cable mark to the left:
1723278597879.jpeg

These two descriptions *do* seem to be at variance with each other. I suspect that some of the confusion arises from whether the pin-layout of the cable-end or the panel-socket is being specified. The logic isn't at issue AFAICS. Jay seems to have the cable oriented backwards WRT the connector given that the red mark is at the right.

http://www.bitsavers.org/pdf/dec/pdp11/1105/1105_RevAH_Engineering_Drawings_Jul76.pdf, page 182, shows this (see other notes on that page!):

1723279448285.png


This is consistent with Retrocmp and NOT with your annotated photo. Retrocmp describes this as "upside down" because normally the "A" row on an IDC connector is uppermost. DEC makes a point to ensure that a THIS SIDE UP label is applied to the "B" row because of the variant orientation. The Retrocomp table therefore describes the cable-end, not the panel-socket. If you swing Jay's table 180 degrees around then it matches the panel-socket (pin "A" ends up to the lower-left); it would be less confusing if his PDF made that point!
 
Last edited:
Thanks Paul, that is a great explanation! (and now I realise I've exceeded the time limit and can't delete the photo 😦 - but, your followup definitely points out my misunderstanding - thanks again)
 
Just to clarify, the correct pin-out as see when viewed on my PDP-11/05 is Pauls first image in post #16 (https://forum.vcfed.org/index.php?threads/pdp-11-05-restoration-blog.1249299/post-1399770).

Just to reinforce the message, I repeat Paul's correct image here:

Serial port pinout on back of PDP 11-05.png

The corresponding pin-out description is here (from Joerg's website and confirmed on page C-1 of the 11/05 manual):

serial port pins.png

I have confirmed that the TTL pins listed above are working. I use pin B as GND, pin D as Serial Out (TTL) and pin RR as Serial In (TTL).

On my machine the TTL transmit path works as expected. The TTL receive path receives characters, but the received characters are not what was sent. I will investigate the receive problem once I have resolved the core issue.
 
Bit 10 being always one looked like it might be a problem with the inhibit logic and driver. Using a hex extender card I was able to probe the signals on the G110, but unfortunately the problem is not in the inhibit logic and driver. I have also checked what is driven onto the bus during deposit and examine. The working Bit 9 behaves exactly like the "stuck" bit 10.

I conclude that this "stuck" bit 10 problem is not at all caused by the 3 core boards (G110, G231 and H214).

Here are photos of my test setup (click on the photos to see the full size):

PXL_20240810_033829563.jpg

PXL_20240810_132150915.jpg
 
With core I see correct data being written from the Unibus to core and also correct data being read from core to the Unibus. Nevertheless somehow the CPU sees incorrect data when examining core (bit 10 stuck high) or when executing programs causing the program to halt (Run light off).

Interestingly I can execute a tiny program from Scratch Pad Memory (registers R0 and R1):

177700: 000240 ; NOP
177701: 000777 ; BR .-1

Scratch Pad Memory locations increment by one not two like core!

When executing the two instruction program from Scratch Pad Memory, the Run light stays on.
When executing the same program from core the Run light goes off.

It is time to look deeper into what the M7260 (Processor Data Path) is doing.
 
Last edited:
Back
Top