Restoring a PDP-8/L

[pbirkel@gmail.com]

Here's the Vout vs. Vin plot of four parts.
View attachment 1246220

Very interesting! Please elaborate on the test conditions under which these plots were obtained. In particular was the second NAND input tied to GND, to Vcc, to the first NAND input (the one under test), or something else entirely? How did you load the NAND output?

 

[jdreesen]

Still haven't found any documentation for BM08.

Would this be the BM08/L, which allows Omnibus memory to be used on the PDP8/L ?
If so I should have the documentation.

 

[pbirkel@gmail.com]

Would this be the BM08/L, which allows Omnibus memory to be used on the PDP8/L ?
If so I should have the documentation.

I'd very much like to see that that if you could share it, please. THank you!
Have been contemplating the best way to extend my 8/L memory space ...

 

[jdreesen]

Yes, found the document. Bad news in that they are a third generation photocopy and oversized .Though job to scan....
Some pics of my unit :

 

[pbirkel@gmail.com]

Thank you. So there's a large specialty backplane in front that is connected by WW to a small Omnibus backplane in the rear? If so then I'd expect to see cables from the 8/I-or-L terminating in the front backplane, which I don't. A list of module #s and positions would be useful. I imagine that the front-set might correspond for the most part with those in the BM08.

 

[jdreesen]

My unit is not tested, currently unused, and the cables from the 8/L are stored away savely. The omnibus you see currently serves as a storage space for some spare Omnibus cards.
I'll see about scanning the document, it does contain the module placement overview.

 

[pbirkel@gmail.com]

Ah, no wonder I wasn't seeing any modules towatrds the rear that looked like Omnibus memory to me. Many thanks for offering to scan your documentation. Use the highest resolution possible and "don't spare the bits"!

 

[jdreesen]

Find the BM8/L documentation appended. Note that the scanned documents were very poor quality to start with, so the result is less than perfect.
I also scanned the netlist info, but that is too large to include here..
For those just tuning in : the BM8/L is an extension for the PDP8/L, allowing it access to a full 32K memory using standard Omnibus memory.
Not too many of those BM8/L around...

 

[gwiley]

Very interesting! Please elaborate on the test conditions under which these plots were obtained. In particular was the second NAND input tied to GND, to Vcc, to the first NAND input (the one under test), or something else entirely? How did you load the NAND output?

The two inputs of the NAND Under Test were tied together and connected to a variable lab supply. The output of the gate was open, just connected to the DVM. I probably should have loaded it as described in Section 3 of the TI TTL Data Book.

Was thinking about automating this with a DAC and ADC connected to a small micro (ESP32 possibly), and calibrated, but then I'm building a tester to test parts that I'll install on boards to test on a Flip Chip tester, getting distracted from the original goal to bring up the PDP-8/L.

 

[jackrubin]

Beware - there be rabbit holes here!

 

[DougIngraham]

Warren had a plan for tester version 2. A/D converters and programmable loads so output currents could be tested. He also wanted the ability to measure pulse widths. We talked a lot about some of that stuff. In one way it seems so long ago and in another it seems like yesterday. Tester 1 is reasonably cheap and easy to build and use and can find most problems.

 

[gwiley]

Warren had a plan for tester version 2. A/D converters and programmable loads so output currents could be tested. He also wanted the ability to measure pulse widths. We talked a lot about some of that stuff. In one way it seems so long ago and in another it seems like yesterday.

Ability to measure pulses would be quite useful. I created some scope tests for the present tester where clocks and pulses are monitored manually.

GitHub - G-Wiley/Flip_Chip_test_procedures_and_vectors

Contribute to G-Wiley/Flip_Chip_test_procedures_and_vectors development by creating an account on GitHub.

github.com

These could be automated with tester hardware that could sample the pins much faster.

Tester 1 is reasonably cheap and easy to build and use and can find most problems.

That the nice thing about it. Greatly useful and quite simple.

 

[m_thompson]

We found that most M series problems were solid failures that the Flipchip Tester could detect. Just a few were weak driver transistors, so under load the output looked like an RC curve instead if a sharp edge. Since we had discovered the problem using a 'scope when the board was in the PDP, we just connected the 'scope to the flipchip when it was in the tester, and verified the failure.

It would be nice to have a Flipchip Tester that was fully analog and could fiddle with the shape of the input signals, and measure the waveform of the output signals. Making that would be a huge hardware and software effort and might never get completed.

 

[vrs42]

I'd very much like to see that that if you could share it, please. THank you!
Have been contemplating the best way to extend my 8/L memory space ...

I do have original BM08/L documentation. It is very large, yellowed, and slightly embrittled. I have taken photos, since it's a scary notion to put the pages in/on a scanner.

The most legible version is likely the one I've redrawn in Eagle. Here's a schematic PDF:

https://svn.so-much-stuff.com/svn/trunk/Eagle/projects/DEC/BM8L/BM8L.pdf

Vince

 

[gwiley]

Quick summary up to this point:

1. Large electrolytics have been reformed.
2. +5V logic supply has been thoroughly tested with up to 8.7 A load with input voltage from an adjustable lab supply. Verified the Vout vs Vin characteristic and confirmed the spike exists as others have documented. Verified the OVP crowbar trip voltage = 6.59V. Built and tested Rolands 8/L crowbar but haven’t yet installed it in the machine.
3. All of the Flip Chip modules have been cleaned and tested using the Stearns tester (ESP32 version). Made some updates to scope loop test vectors for some M-series modules with delay and pulse circuits and updated tests for some G-series modules. The updated TST files and documentation are in github.

Final power supply testing:
With the power supply removed from the chassis, finally plugged it in to AC power, actually into a KILL A WATT meter, so I know how much current this draws from the AC line.
Built the following simple test jig to connect loads to the supply outputs at the G785 edge connector.

The 8/L power supply harness connects all of the output voltages to the backplane through the double-size G785. To test the power supply, the G785 was disconnected from the backplane and plugged into the test jig.

Connected two Kunkin electronic loads and various combinations of 8 ohm 50 W resistors to the supply outputs through the jig:

• 8 ohms 50 W to +7V (Panel Lights)
• 8 ohms 50 W to +5V (Logic) already tested with a lab supply and electronic load up to 8.7 A
• Kunkin Load #1 to -15V (keys & switches, sense amplifier)
• Kunkin Load #2 to -30V (memory negative supply)
• 8 ohms 50 W to -6V (memory positive supply) later learned this needs to sink to mem neg suppy)

They all tested okay except I wasn’t able to verify the -6V memory positive supply because it needs a load between -6V and -30V, and the memory positive (-6V) needs circuitry on the G826 Regulator Control board.

Front panel board bench testing:
Lots of cleaning first. Then…

Connected a +5V supply and +9V supply to the front panel board and verified every lamp driver input from the edge connector to verify the corresponding lamp would go on and off. Found 5 bad lamps, 3 bad driver transistors and I broke a 1K resistor during the repair process.

Connected a +5V supply and -15V supply to the front panel board and verified every switch could control its corresponding output on the edge connector.

Core quick test:
Verified about 25% of the diodes using the TC1 Multi-function Tester.

Put everything back into the chassis: power supply and needed to remove the A-row of Flip Chips to fit the supply back in the chassis. Front panel board and core memory modules and A-row Flip Chips installed.

Powered up the system. The noise of 3 fans is loud. System draws 1.59 A from the AC line.

All 12 address bits seem to work; loaded 0001, 0002, 0004, 0010, etc. up to 4000. Incremented through every carry to the next higher bit: 0001 to 0002, 0003 to 0004, 0007 to 0010, 0017 to 0020, etc. up to 7777 to 0000.

Could kind of store some data to memory, but bit 4 was stuck at one and I think the MSB or next MSB might have been always zero. Not sure if this was a core problem or data path issue. Should have taken a methodical approach to work through this. Instead, thought I’d try my spare core stack because it looks much newer and cleaner. Didn’t work though. Memory data always reads 0220, so bits 4 and 7 are stuck at one. Put the original core stack back in and now it does the same thing… always reads 0220.

Time to dive in and track down what’s happening, or what’s not happening.

 

[anders_bzn]

I have restored a PDP8/L, its about 10 years now. I did this litte web-page to easier find my way around the schematics for the modules: http://www.pdp-9.net/docs/pdp-8-l/modules/index.html

 

[gwiley]

I have restored a PDP8/L, its about 10 years now. I did this litte web-page to easier find my way around the schematics for the modules: http://www.pdp-9.net/docs/pdp-8-l/modules/index.html

Yes! I’m familiar with your pages. In fact, I have your interactive module chart loaded in my browser most of the time. It’s quite useful.

 

[czunit]

I restored a pair of pdp8/L's last year, I should fire them up and see how they are doing. Didn't have a super board tester but did have a TTL chip tester which sped up finding problems a *LOT*. Most of my problems were in 7400's and 7430/40's that were used as driver/amplifier/inverters. The 7474's also were somewhat mediocre, had a few bad in boards, some in the registers, and a few in the memory controller boards.

What fun.

 

[gwiley]

I restored a pair of pdp8/L's last year, I should fire them up and see how they are doing. Didn't have a super board tester but did have a TTL chip tester which sped up finding problems a *LOT*. Most of my problems were in 7400's and 7430/40's that were used as driver/amplifier/inverters. The 7474's also were somewhat mediocre, had a few bad in boards, some in the registers, and a few in the memory controller boards.

What fun.

I remember this thread well. It was not long after I started following posts in the DEC forum. I recall one machine was well-behaved and the other not so much. But most of all I remembered thinking what fun it would be to successfully bring up a machine like that. I didn't even have all of the parts to my Omnibus machine at the time so didn't have it running.

In my 8/L it seems the problematic ICs are almost all manufactured by Signetics and Sprague. They're the ones in light-gray packages. Maybe there's something about that material.

 

[gwiley]

All 12 address bits seem to work; loaded 0001, 0002, 0004, 0010, etc. up to 4000. Incremented through every carry to the next higher bit: 0001 to 0002, 0003 to 0004, 0007 to 0010, 0017 to 0020, etc. up to 7777 to 0000.

Could kind of store some data to memory, but bit 4 was stuck at one and I think the MSB or next MSB might have been always zero. Not sure if this was a core problem or data path issue. Should have taken a methodical approach to work through this. Instead, thought I’d try my spare core stack because it looks much newer and cleaner. Didn’t work though. Memory data always reads 0220, so bits 4 and 7 are stuck at one. Put the original core stack back in and now it does the same thing… always reads 0220.

Time to dive in and track down what’s happening, or what’s not happening.

Back home again and it was time to dive into the mystery of semi-working memory. Powered it up, memory address still increments properly when pressing Dep and Exam, but could not write and read back anything from memory.

Memory Supply- is -33.29, and Memory Supply+ is -11.45. I should trim those a bit, but memory somewhat worked once so I'll leave it for now and come back to it.
Pressing Dep or Exam causes a pulse to occur on MEM START. So, the Manual Timing Generator is still working. Had planned to verify the memory timing signals as shown in the Memory Control Waveforms in the maint manual volume I.
Figured I'd trace MEM START through the Memory Control Logic to observe the timing pulses. But, the very first element in that path, an M310 Delay Line at D14 isn't passing pulses from the input. How can it be? I know I checked this board on the Stearns tester a few weeks ago because it has a yellow sticky dot on the card handle. Pulled the M310 from slot D14, and fired up the tester. M310.TST is a scope loop test. Sure enough, there's nothing on any of the delay line outputs, not even the delay input at J2. Traced the signal from the H2 input and discovered that Q3 is bad. It's a transistor inverter-buffer at the input of the analog delay line. Put the bad board in the "to be repaired" pile and grabbed a good one from the spares kit.

Hey, maybe memory will do something now. Powered up, and now bit 4 of the MA register is stuck at one whenever the address increments. Can load address 0 into MA but any increment makes MA04 go to 1. MA04 wasn't stuck before I swapped the delay board. Okay, seems like a bad major registers board. Bit 4 is in the M220 in AB05. Pulled the suspect board and it fails in the tester. This board also has a yellow sticky dot and passed in the tester a few weeks ago. Replaced it with a good one from the spares and confirmed that MA04 works now.

Tried writing and reading a few memory locations. Memory now seems to actually remember! Loaded in the simple accumulator increment program, starting at location 20:
7001 IAC
2034 ISZ 24
5021 JMP .-1
5020 JMP .-3
0000 (the delay counter)
Went for it... LA 0020, Start! The accumulator is incrementing! Woohoo, it's actually running. However, just before the AC was about to roll over from 7777 to 0000, poof! It stops, and now MB04 is stuck at one. The excitement of having a program running was fun and it's nice to know it can work, but I really need to confirm the voltage and timing parameters are correct.

The next step is to perform the Memory Alignment Procedure (sec 5.5.2). I know the Memory Supply- and Memory Supply+ voltages are off, and I should verify the timing as described in the manual. Also need to confirm whether MB04 stuck at one is a logic problem or memory problem.