• Please review our updated Terms and Rules here

Reviving the PDP-12 at the RICM

m_thompson said:
Since SN7474 and SN7400 ICs seem to be a problem in these early DEC systems, we pulled all of the M113 flip-chips and tested them.
Click to expand...

Good work done! Can you please tell me more about the tester you are using to test them? I think it would be really useful to setup such a tester when I start with my machine.
 
MattisLind said:
Can you please tell me more about the tester you are using to test them? I think it would be really useful to setup such a tester when I start with my machine.
Click to expand...

A few years ago Warren Stearns built an M flip-chip tester when we were restoring a PDP-8/L and PDP-8/I. The tester had five SPI buses going to five 16-bit SPI GPIO devices. The program on his PC reads a data file for a specific flip-chip, configures the I/O pins, then sets the outputs and reads the inputs. Some programs get complicated, the one for the M220 has more than 2,000 tests. The tester works very well for a quick functional test. It is also useful for exercising boards like the M221 so we can see if the address decoders and the drive transistors are working.

Warren plans to make a PCB that will have a USB interface to the PCB and will be able to test B, M, R, and S flip-chips.
 
Interesting video. We have an ancient General Radio capacitor checker, but unfortunately it won't check the giant caps in this power supply.

Al Kossow recently put PDP-12 PM Procedures manual on Bitsavers. This manual included the power supply ripple values. We are well within the requirements, so the giant caps are probably OK.
 
Hi All;
M-Thompson, Thanks for the positive comments, I have a Solar Capacitor checker like His in the Video, I am not sure if mine is fully functional or not.. And that type would not work for checking voltage Leakage as its voltages are too high for Computer Caps..

THANK YOU Marty
 
The platen in the ASR-33 Teletype that came with the PDP-12was nearly impossible to move, so the Line Feed did not work. We removed the platen, and found that the plastic in the bearing area had swollen and was binding. We sanded, cleaned, and lubricated the bearing surface, and the platen turns freely. After reassembly we found that none of the Control Characters like Line Feed or Bell would work in Local Mode. We fiddled for quite a while, but did not find a problem. We speculated that something got bent when it could not move the binding platen.

Since the Bell had worked last week, we borrowed the M706 Teletype receiver from the PDP-8/I and connected the Teletype to the PDP-12. We loaded and ran a toggle-in program that echos the keyboard to the printer. We were a little surprised to find that all of the control characters worked OK when sent from the PDP-12. We were even more surprised when the Teletype now worked correctly in local mode.

We borrowed the console cable from the PDP-8/I and connected my laptop to the PDP-12. The terminal emulator worked correctly and echoed characters to the PDP-12 and back.

We toggled in the RIM loader and then loaded the LBAA BIN loader from my laptop. We ran the BIN loader and loaded and ran the PDP-8/I Instruction Test #1. It actually works OK!

We found a bad SN7474 E13 on the M706 Teletype Receiver flip-chip from the PDP-12. We will repair and test it next week.

We installed a standard DEC 6-pin current loop connector on the console cables for the PDP-8/S, PDP-8/L, PDP-8/I, PDP-9. This lets us plug the console cable directly into a VT-220 terminal. We put the mating connector on the cable for a VT-52, and also on Warren's current-loop to RS-232 converter. We will do the same for the PDP-12 console cable and the teletype. This lets us use a selection of terminals and a laptop as console terminals for all of the systems that are working.
 
m_thompson said:
We installed a standard DEC 6-pin current loop connector on the console cables for the PDP-8/S, PDP-8/L, PDP-8/I, PDP-9. This lets us plug the console cable directly into a VT-220 terminal. We put the mating connector on the cable for a VT-52, and also on Warren's current-loop to RS-232 converter. We will do the same for the PDP-12 console cable and the teletype. This lets us use a selection of terminals and a laptop as console terminals for all of the systems that are working.
Click to expand...

Great idea but, my goodness where did you acquire all of those pairs of DEC 6-pin connectors (both genders)?
 
Marty said:
Hi All;

M-Thompson, I am always Amazed at the progress that You make, Keep up the Good Work, and the Great Progress..

THANK YOU Marty
Click to expand...

We are making progress, but there is still a lot of work to do. The system was stored in much better conditions than the PDP-8/I, so progress on the processor is much faster. The TU56 DECtape has issues with the motor control on both tape drives. The VR12 needs the PVA layer removed from the CRT and the power supply fixed. We looked inside the RK05 and it is very clean, but we have't tried to power it yet. We have no idea what we will find when we connect the DW8E and try to use any of the Omnibus controllers. We haven't powered the PC04 paper tape reader/punch. The punch will need some attention after sitting for 32 years.
 
Warren repaired the M706 Teletype receiver so we put it back in the PDP-12 and put the borrowed M706 back in the PDP-8/I. The donor brought another M706/M707 pair, so we installed them and now have two working serial ports in the PDP-12. Theoretically we could boot OS/8 with a slightly modified serial disk emulator. Warren is making an Arduino programmable baud rate generator for this system.

We ran more diags. The random JMP, JMP-JMS, and ISZ tests work OK. The LINC Tape-Quickie test and the Memory Address test fail after a few minutes. We tested all of the M221 Memory Selectors, and they are OK so the memory address decoding is probably working OK. This may be a case where the processor is sometimes doing the wrong thing when comparing numbers, and the rest of the hardware is actually OK. Debugging this will be the project for next week.

The donor dropped off more documentation, spare parts, LINC tapes containing the DIAL operating system, and an RK05 disk pack that likely contains OS/8. We will make image copies of the LINC tapes and the disk pack.
 
We measured the power supply ripple again. The +5V: Should be: +/-250mV, is 150mV, +10V: Should be: +/-300mV, is 400mV, -15V: Should be: +/-750mV, is 600 mV, -30V: Should be: +/-3000mV, is 800mV. Close enough to continue debugging.

Warren made a dual baud rate generator from an Arduino. We can set jumpers on the Arduino and it will generate the desired baud rates for both serial ports. After some debugging, it seems to work OK.

The ISZ and Memory Checkerboard diags are failing. It looks like it is picking up and dropping bits in quite a few memory locations, all above 1000.

We measured the START MEM to STROBE FIELD 0 delay. It was set to 550ns. Exactly the default value.

Warren wrote a better memory checkerboard program. That showed the bits that were being picked up or dropped in the MQ register. We tried adjusting the STROBE FIELD 0 delay about +/- 100nS, but there was no setting that resulted in completely working memory. Changing the delay did change the location and number of bits that were picked up or dropped. Since the failing addresses were all above 1000 we tried replacing the G221 modules in slots C07 and C08. There was no change.

We loaded Warrens program into the first field and tested the second field. We also saw bits picked up and dropped.

Since many of the locations were supposed to be zeros, but contained ones, we are speculating that there is a problem with the inhibit circuits in the core. That will be the project for next week.
 
The LINK indicator light on the front panel of the PDP-12 failed two weeks ago. This is an important indicator for debugging, so we fixed it today. The indicator light bulb failed, briefly shorted, and destroyed the transistor that turns the indicator on. An new transistor and bulb, and all is well.

We have been chasing a transient problem in the PDP-12 core memory for a few weeks. We checked the timing last week, and it was OK. This time we checked the core voltage and it was a little low. We increased the core memory power supply voltage, and now the core memory works OK. Next time we will explore the high and low limits of the core voltage to find a reasonable center voltage for both core stacks.

The next step is to run all of the processor diagnostics and make sure that everything is works. If the diags run OK, it is time to fix the TU56 tape drive and see if the drive and controller work.
 
A few more hours on the PDP-12 today...

With the machine just powered on the stack 0/1 regulator output was 20.04V.
With tune3 running in field 1 and testing field 0 the stack 0/1 regulator output was 19.93.
No memory errors were reported.

When the voltage was adjust up to 22.5 and down to 19.96 we saw a few failures.
We split the voltage range and adjusted the regulator output voltage to 21.3.
No errors were observed when testing field 0 or field 1.

We successfully loaded and ran 10 passes of:
MAINDEC-08-D1B1 Memory Address test.
MAINDEC-08-D1B2 Memory Address test.
MAINDEC-08-D07B-D Random ISZ test.

We ran these diags without errors
MAINDEC-12-D0GA-A_Tape_Quickie
MAINDEC-12-D8AB Relay Register Test
 
The processor and core memory in the PDP-12 are working very well now, so we spend some time with the TC12 LINCtape controller. The TC12 is very intelligent compared to the more modern TC01/TC02/TC08, and the lobotomized TD8E DECtape controllers. The TC12 designers included lots of back-doors to make diagnostics more effective.

The MAINDEC-12-D0GA-A Tape Quickie ran OK and just tests that the TC12 registers are working.

The MAINDEC-12-D3AD-D-D Tape Control Test Part 1 of 2 ran for a long time and then displayed "LGP GP=GPC PRESET". It pointed to an M216 module that uses the SN7474 ICs that have caused lots of trouble on other modules. It tested OK, so we put it back in. We will consider replacing it anyway.

The MAINDEC-12-D3GA-D-D Tape Control Test Part 2 of 2 ran OK as long as you hold the MARK switch down. The MARK switch on the console allows a program to turn on the MARK Track flip-flop. This is not documented in the manual, but was a hand written note in the margin.

The MAINDEC-12-D3FB-PB Tape Data Test ran for a long time writing patterns to tape and verifying that they were written correctly. This means that lots of the TC12 LINCtape controller is working, as well as the TU56 tape drive. It eventually failed when it tried to verify the block numbers. We are not sure that the scratch LINK tape that we used is good. Maybe we can get the MARK-12 program working and we can reformat the scratch tape. We have just a few LINC tapes and need to image all of them before we write on them.

Two more lights on the front panel stopped working. We tested the SN7400 ICs that send the signal from the registers to the front panel, and they are OK. The bulbs are OK, so the transistor that turns on the bulb probably failed. We replaced one for the LINC light, so we know the procedure.

We are getting close to the point where we will need the VR14 display working to continue our work. Getting the display working will be quite a project. The PVA between the CRT and the shield has degraded and is nearly opaque. We will need to remove the outer CRT glass shield and replace the PVA. That will be quite a project.

Warren modified the current-loop to RS-232 adapter that he made so it will run at higher speeds. We needed to remove "C1" from the W076 console module so we could run baud rates faster than 110. After testing, it looks like 1200 baud is the best compromise between reliability and performance. Now we can load diags 10x faster. Very nice!
 
On Friday and Saturday we replaced two more transistors on the front panel for PC and MA lights. The orginal transistors worked OK for several weeks. I hope that replacing transistors isn't weekly ritual, because the process is painful.

MAINDEC-12-D0GA-A Tape Quickie tests the ability to read/write the TC12 registers in maintenance mode in PDP-8 mode. This works OK.

MAINDEC-12-D0AB CP Test-2 halts at 22. We don't have the documentation for this diag, so we don't really know how to run it.

MAINDEC-12-D0CB CP Test-3 runs OK, and the LINC mode light is always on. I guess that some of the LINC instructions are working.

MAINDEC-12-D1BA JMP Self won't load. Probably a bad paper tape image.

MAINDEC-12-D1AC Extended Memory Control runs OK if you set the right switches to the number of fields of memory, 0001.

MAINDEC-12-D3AD-D-D Tape Control Test Part 1 of 2 ran for quite a while and made interesting noises through the speaker. It eventually halted at at 3357 in test GPCNT2., but displayed an error message "LGP GP=GPC PRESET. We think that this part of the diag should be setting the GP=GPC flip-flop in the TC12, clearing it, and testing it, but the test never set the flip-flop. The documentation says that it is testing the M216 module in slot B37. We replaced the M216, but it did not change the behavior. Other tests did set the flip-flop, so we know that it works. The TC12 status register contained 4370, so bit 0010 was on and should not not be. Warren setup the 'scope to trigger on the LIP TAPE PRESET L signal to the GP=GPC flip-flop, and watched the GP EQ GPC flip-flop 1 output. Every time the diag halted at 3357 the 1 output of the GP EQ GPC flip-flop was on, should not be. The LGP GP EQ GPC (1) H signal from the flip-flop goes into the M222 in slots AB21. Warren swapped the M220 modules in slots AB18 and AB21. After the module swap the diag halted at 1215 in the test RWBSH1. Warren moved the modules back to the original locations, but the diag still halted at 1215.

The SN7474 flip-flops have cross coupled inputs and outputs. This means that if you hold the zero output to below the TTL threshold and try to change the state of the flip-flop, it will revert back to the original state. The M222 module in the TC12 has a SN7453 ICs that accepts the LGP GP EQ GPC (1) H signal from the flip-flop. We have seen lots of these unusual ICs go bad, so it could be overloading the output signal from the flip-flop and periodically making it misbehave.
 
J. Victor Nahigian donated some M221 and M222 boards for the processor and TC12 LINCtape controller. They are in pretty bad condition, but with cleaning and repairs will make nice spares.

Dan (the donor) brought over the now lubricated top of cabinet fan. He disassembled it and lubricated the dry bearings.We will reinstall it next week. He also dropped off the system logbook and more diagnostic manuals. It is interesting to see the repair history of this system since it was new. I will scan the additional diagnostic manuals and get them posted on Bitsavers.

The LICM scanned some of the missing MAINDEC documentation so we were able to run:
MAINDEC-12-D1AC-D Extended Memory Control (EXTMC12), Runs OK.
MAINDEC-12-D8CC-D_KW12A_Clock_Test Fails test #11 where the AC should be 0000 and is 7777 on the CLRB instruction.
MAINDEC-12-D8CA-D-(D) KW12 Real Time Clock Diagnostic (KW12TST) shows the same failure mode as D8CC.
MAINDEC-12-D6BA VR12 Display Test Runs, but we have no display connected. We connected the 'scope to the outputs of the VC12 display controller when MAINDEC-12-D6BA was running. Without a way to interpret the intensify signal, and no persistence in the phosphor, the resulting image was not too good. At least we know that the display controller is responding to commands and outputs signals that look reasonable.

We reran MAINDEC-12-D3AD-D-D Tape Control Test Part 1 of 2. It still fails at 3400 with the error message "LGP GP=GPC PRESET" printed.

We reran MAINDEC-12-D3GA-D-D Tape Control Test part 2 of 2. That runs fine.

I bought the matching terminator for my current probe and was able to give it a try today. When we last debugged the core we set the voltage regulator to the middle of the high and low voltage settings that caused periodic errors. They target setting is 320mA for this core. The result turned out to be 316mV for the read. Not too bad!
 
We spent the afternoon chasing the "LGP GP=GPC PRESET" in the TC12 LINCtape controller. With a logic analyzer connected to lots of the TC12 signals were were able to chase the signal that is causing the fault. We are now not sure if the signal behavior we observe is the correct behavior, and there is a fault elsewhere. More debugging time and more studying of the documentation is required.
 
You must log in or register to reply here.
Back
Top