• Please review our updated Terms and Rules here

Time to rebulid the pdp8/L

Possibly. I have a dual channel scope and may be pulling it out before the day is done. Got a link to a good analyzer on Ebay?

Meantime the computer is in screwed up land with an intermittent fault. Every once in awhile when I power it up it goes crazy. As in hitting load address increments the MA, nothing works, etc. So either a loose wire or a intermittent component. I'll start troubleshooting this. But then it goes away and the computer goes back to the normal levels of "not working".

Hm. Well at least I have one good 8/L to work/test with.
Ebay? No. Don't spend much time there anymore. Probably some available also.

Amazon: https://www.amazon.com/KeeYees-Analyzer-Device-Channel-Arduino/dp/B07K6HXDH1/ref=sr_1_10?crid=383ATKI2QGPOG&keywords=usb+logic+analyzer&qid=1646101957&sprefix=usb+logic+analyzer,aps,151&sr=8-10

Personally I use this for most debugging: https://www.dreamsourcelab.com/product/dslogic-series/ I have a 16 channel 400MHz DSlogicPlus I got a few years ago.
 
Last edited:
Thank you, ordered. Should make life a bit easier to check multiple inputs at the same time.

While waiting I think I'll order some enamel and work on checking the wire wrap on the back of the 8/L. I'm guessing this transitory issue is a result of that burned wire I had to remove. Fortunately I marked its path through the system....
 
Ebay? No. Don't spend much time there anymore. Probably some available also.

Amazon: https://www.amazon.com/KeeYees-Analyzer-Device-Channel-Arduino/dp/B07K6HXDH1/ref=sr_1_10?crid=383ATKI2QGPOG&keywords=usb+logic+analyzer&qid=1646101957&sprefix=usb+logic+analyzer,aps,151&sr=8-10

Personally I use this for most debugging: https://www.dreamsourcelab.com/product/dslogic-series/ I have a 16 channel 400MHz DSlogicPlus I got a few years ago.

FYI a pointer to the open source software ... https://sigrok.org/wiki/Main_Page
 
Thanks! I downloaded the Logic2 software and aside from timeouts (the super cheap devices have small buffers) it's working.

So far I checked the IO_Skip line when running a sample test program and it's strobing at a constant 36.676ms rate. Which is exactly what I would expect at 300 baud (~30cps) so that works. Moving forward I checked the outputs of the SKIP flip flop over on B11 and sure enough the 0 and 1 outputs are inverted from each other and are also a solid 36.676ms rate. So everything is ok to the Skip flip flop.

Moving down the line I did see something that might be odd: Checking the output of the M160 in A12 I saw that the output at R1 is ON 87% of the time. Which seems a bit off. Running the program in single steps shows a quick pulse when you press start (instruction 0), a quick pulse at 1, then a solid drop to LOW when instruction 2 is run, followed by a return to a solid high when instruction 6 is run (it should be 4 because 2 is the skip but it jumps way ahead). I haven't looked at Carry_insert (the output from the M113 at B13) but I wondered if the solid low during the skip is inserting as many carries as the computer can.

No, I tried switching A12 and A13 with known good parts earlier so it's not A12. Hm.

Might test it against my good pdp8/L to see what it does. Seems a bit odd, maybe one of the other lines is weird.
 
Hm. Rewrote my program here to run at address 1234 just to see what happens.
1234 7604
1235 6046 (write character)
1236 6041 (skip if written)
1237 5236 (wait for char write)
1240 5234 (What it should jump to on a skip) (Jump to start)
...
1242 5234 (catch instruction in case it skips +3) (Jump to start)

Sure enough, it starts up fine, outputs a character, hits 1236 ok, then hops to 1242 for the return jump back to the top. Skips three instructions, not one.

Well, at least it isn't position dependent....
 
So in the meantime I decided to check the other skip logic with some toggle in programs to see if the skips were broken. First I ran the ISZ instruction test and it stopped with PC=207, AC=0, Link=1, which is good. Runs single step and at full speed.

Then I ran the Operate instruction test. It works as well despite the fact that the 8/L doesn't have a BSW (the add produces an AC of 3641 but the link is set so it does the final skip properly). And it finishes at location 216. Runs single step and full speed.

So I believe the basic skip functionality IS working and the only problem is skips during IO.

Hm. The output of M160/A12 at R1 is fed by a bunch of items, but one of them is an AND of skip(1) and an AND of _INTDKIPENABLE/_PCENABLE/IOPCENABLE. I wonder: If one of those is stuck on or off during an IO skip could that cause the system to do a skip on every cycle of TP3? That could add 3 to every skip if it's an IO skip.

Hm.
 
If you can afford it I strongly recommend the PicoScope line of Oscilloscopes/Logic Analyzer. The 34XX series has 2 or 4 channel scopes (up to 250MHz) with a 16 channel logic analyzer and a Arbitrary Waveform Generator output (can be used to sync multiple PIcoScopes). https://www.picotech.com/

These scopes are very powerful and support decoding of many serial protocols and you can program in your own. It even support pattern recognition triggers.
 
Well, after a lot of troubleshooting and discussions on Discord I finally have the system working! Loaded the RIM loader, BIN, and FOCAL 69 with the following output:

*
*hi
?03.28
*1+1
?01.40
*type 2+2
= 4.0000*

How? Well I'll discuss that in the next message. It was complex.
 
So.... First problem was to figure out why it was jumping three addresses on a skip instead of one. First we have to understand how the skip logic works. In a perfect world a skip is supposed to set a flip flop called "SKIP" which then feeds a set of gates that triggers a CARRY INSERT from the M113 at B13 at the right time. The "right time" is key and is controlled by the big M160 at A12 which has two logic paths: One is for manual increment stuff (EX/DP, ISZ, CA Increment) and the other that does skip related stuff.

First question was this: Do normal skips work? Testing the ISZ instruction, jumps, and checking things like skip on link showed that yes, those skips work and increment the PC by one address when true. So the basic skip logic was good.

The second question was "is the skip flip flop working"? I hooked up my new handy dandy tester to 0/1 outputs and yes, it is working, even when I try to run my program that IO skips three instructions instead of one. So that works, and IO instruction skips are the only ones that jump ahead. Why?

Well, when you get an IO instruction you enter a special world called IOP land. Where there are three possible IOP instruction types and the 8 goes into a wonderful world between TS3 and TS4. Each IOP state is cycled and the system checks to see if the appropriate bits are set for it. If the bits are set, the system cycles through the instruction and does "stuff" (move to AC, move from AC, and of course skip).

I theorized that what was happening was that the logic that prevents skips from triggering a count increment to the program counter were firing on every one of those IOP steps instead of just one. This could happen if the M160 was getting an input from SKIP (1) (the flip flop) while not getting a "don't do a count if it's not in the right state". Sure enough there is a signal coming into the M160 from M115 at A14 that is a NAND of three signals: !INT SKIP ENABLE, !PC_ENABLE, and !IO_PC_ENABLE.

And when I checked my good pdp8/L with my new signal checker I could see that two of these signals were appearing as a variety of signals (representing the time states) while the third was always the same. On the bad pdp8/L I saw nothing on either of these signals.

Tracing them back I found that the signals were on the proper points in the system where they were generated, but were not showing up on the M115. For example !PC_ENABLE comes from the M113 B13 pin F1 and is generated by a NAND of TS4(1) and "F SET" (which is the Fetch state set flip flop value). Checking this at M113 B13 showed a good signal going in and out of the gate.

It was at this point my computer went insane. Nothing worked right, but I noted that hitting Load Address with 0 in the SR would do nothing but with 0001 in the SR it would increment the memory address each time I toggled LA. Something went nuts in the counter and I figured it was always incrementing.

Since I thought I knew where COUNT was coming from, I pulled M113 B13 (the final NAND gate before Carry insert). Now LA did nothing which was good. Then I plugged that in and pulled M115 at A11. Still did nothing. Then I plugged M115 A11 in and pulled the M160 at A12. Still did not count which is good. I plugged the M160 in and suddently everything worked.

THAT was the problem. My guess is the M160 had an intermittent connection to the backplane. Because it controls when count is enabled and if pins are disconnected the results are bad. My guess is pins K1 and R1 are dirty or something. When I get enough guts I'll pull it again, clean the connectors, and see if it still works.

I'll post my raw notes in the next post. They are my writing, but more detailed and probably accurate. Hope this helps someone else when they have to troubleshoot a system. For now it's running, it runs FOCAL, and that's pretty good.

Now on to fixing the other M707 which is the last thing on the list....
 
I/O issues on pdp8/l 1

IO doesn't seem to work.
M707 is bad, we know that.
M706 seems good but never gets past a skip instruction.

Possible problems:

Error in M111 D11. Swapped, no change.

Could be in the skip logic.
M111 B12 is a lot of logic here.
M160 in A13 has a lot of stuff feeding the skip flip flop.
Others feeding it are M113's and M115's.
Try switching A12 and A13. No change

Hm. Skips seem to be working as some skip on accumulator and skip on link instructions work.

M115 in C12 seems to be the NAND of IO Strobe, IO enable and Skip.

When I/O skip and I/O enable are both set, skip should be enabled.

IO_SKIP is A13K2 sourced from A33L1.
IO_ENABLE is "Big". A13J2, A35D1, B13M1,C12U2,D09J2, (ab02,3,4,5,6,7 bl2 is an input to the registers), B13M1,C12U2,D09J2

Swapped M160 at A13 again. No dice. K2 does not seem to get asserted but J2 does when running and it pulses rythmicly. K2 gets asserted only when system starts or continues.

J2 is I/O enable. K2 is I/O skip.

So we know IO/Enable is working, what about IO/Skip?
Comes from A33 L1

A33 L1 comes from three lines: Power skip, Reader skip, and TT skip.
H1,J1,K1 and F1 is some random input from outside.

All high except fir J1 low j1 is !tt int.
L1 is always high.
Hm. Something is wrong between A33/L1 and A13/K2

I see a possible wire wrap on A13 D1. ILLEGAL_REF. Oh that's nice.


Christ almighty I was getting sides 1 and 2 confused.
For the record:
Side 1 faces the front of the unit
Side 2 faces the rear.
The stuff on the bottom is accurate.
Side 2 has the +5 and ground lines.
If only one sided, it's side 2 by default (rare)

On A33, it's:
L1: I/O skip Output.
K1: PWR_SKIPg
H1: RDR_SKIP
J1: TT_SKIP
F1: to K2 of some socket.

Burned wire:
A28 B2 is the G785 main power system.
B34 B2 is the other end of the wire that burned.

Wire removed still nothing.

Note: Ran the input and output (echo program). It never sees that a keypress is done, so even the input skip is out. Can't be two bad lines, so it has to be something else here.

Is it possible that A13K2-A33L1 is broken? Maybe. Check it with a quick jumper. No, it's good with a 0 ohm resistance. So that's not it.

So what is the path for everything around here? And is it possible it's not the skip circuits but something else like the IO enable circuits?

Well, on the 707:
BH2 is I/O skip strobe
BJ2 is I/O skip
When program running and looping:
I/O skip strobe is low.
I/O skip is high
Address decoder is high.
Thus the not and would be a high output.

What if IOP1 is the problem? That's what they call the skip strobe.
IOP1 AB30 AU2 Paper tape reader
AB31 AR2 Paper tape punch
B15 H1
D02 F2-Our favorite inverter....
D31 H2--tty out
D32 D2--tty in

Edit: Oh great. After switching out two cards (C06/D06) the skip works but now it double skips.......

Actually it seems to triple skip. And that is weird, swapping C14 (the M113 that is supposed to clear the flip flop) doesn't change anything.
2/26/22:
More work. Could it be a bad wire on the IO_SKIP line? Will need to check.
Note pulled m706 still problem. Pulled A40 board (the one on the end that does power up) still problem. Pulled bus driver boards and load boards, still problem.

3/5/2022
Have a logic analyzer. Man this thing is useful. I can see that the raw Skip line is puling at a 36.676ms rate from the M707 meaning the card works (nice). I also put probes on the SKIP flip flop at M216 at B11, S1 and U1. Both report the same 36.676ms rate and are inverted meaning that the Slip flip flop, clearing circuitry, and all that garbage is working fine.
instruction 0 brief pulse low, high
instruction 1 brief pulse low, high
instruction 2 goes solid low
instruction 6 goes solid high (should be low, right?)

Moving down the line I did see something that might be odd: Checking the output of the M160 in A12 I saw that the output at R1 is ON 87% of the time. Which seems a bit off. Running the program in single steps shows a quick pulse when you press start (instruction 0), a quick pulse at 1, then a solid drop to LOW when instruction 2 is run, followed by a return to a solid high when instruction 6 is run (it should be 4 because 2 is the skip but it jumps way ahead). I haven't looked at Carry_insert (the output from the M113 at B13) but I wondered if the solid low during the skip is inserting as many carries as the computer can.

No, I tried switching A12 and A13 with known good parts earlier so it's not A12. Hm.

Might test it against my good pdp8/L to see what it does. Seems a bit odd, maybe one of the other lines is weird.

3/6/2022: Still, I think it's a problem with the SKIP ANDed with three inputs from IO. One is odd, _IO PC enable which comes from a NOT of IO Enable (M111 A35), TS4, and Pause (1) flip flop. Comes through M115 at C28.

However let's try replacing M111 A35. Tried swapping, still no dice.

3/8/22
Serious progress, then the computer went crazy again this morning. Here's the key notes:

First step was to look at the things that control adds from skips. That would be M160 at A12. Checking the output I saw that R1 was on almost all the time on the bad computer but was pulsing properly on the good computer. Focusing in I saw that SKIP(1) was fine, but INT_SKIP_ENABLE, IO_PC_ENABLE, and PC_ENABLE were all bad as follows:

So: On the bad pdp8L
Running:
t2 Red Goes low
U2 White Channel 1 Always high
T2 Green Channel 2 Always high.

V1: Always high

On the good pdp8/l
T2 Int Skip Enable Channel 0 high
U2 _IO PC ENABLE Channel 1 all sorts of pretty stuff.
V2 _PC ENABLE Channel 2 also different pretty stuff
V1 also pretty stuff.

!IO_PC_ENABLE comes from the following:
A08: In, U2
A14: In, U2 (of course)
C28: Out, D1

!PC_ENABLE
A08L In, T2
A14: in, V2 (duh)
B13: out, F1
C13: in, K1

The fact that both of them are down leads me to wonder if TS4 flip flop is being set properly.

Checked TS4 flip flop and it's clocking properly. So Time state 4 is working. I then went to see if !PC_ENABLE was receiving the TS4 signal at M113 B13 at which point the computer went insane again. Specifically:

MAJOR ERROR: I accidentally put the flip chips from the good pdp8L into A15 and B15. They were the ones that were supposed to be in A14 B14 but I had the bad pdp8l A14 and B14 up on risers.

Fuck.

Moving those two boards into the "good" pdp8/L and testing.
They work.

Moved into bad pdp8/L computer insane.

Moved boards back into original computers, I am taking a break, I am done with this for now.

Need to sit down and work on this. This happens, and I think it is due to wiring damage on the backplane.

Ok... Back.

Note when they go crazy, setting bits in the accumulator changes the increments in the MA when load address is toggled. This is something. More bits (11,10) causes bigger adds.

Start by checking location of all cards.
Right now I'm running the 8L with only one M220 to make it as simple as possible. It looks like examine and deposit work fine, and the computer will enter a run state but load address seems to be screwy in a consistient manner based on what is in the switch register at the time.
M220's are good, so it's related to the gating/switching logic.

03/09/2022
Well..... Figuring there was something insane with the count signal and knowing I have been swapping boards there I started at that point.

Pulling M160 at A12 isolated all the normal increment signals. Still happened.
Pulling the M113 at B13 stopped the count, so it was below that.
Pulling the M115 at A11 likewise did not increase the count, however plugging it back in fixed it.
Dirty connection or something at M115 A11.....
Back to the show

And look at that, now *everything* is working. Golly gee, I skip properly, increment properly, and the computer is doing everything right. Woot!
 
The second system continues to work properly: I loaded up the RIM loader, loaded the BIN loader, and loaded up FOCAL 69. Everything seems to work properly, which is nice.

Now I need to figure out what to do with two fully operational pdp8/L's. I have heard that there was work on an RX8 interface for them and I would be willing to pick that project up. I've got an operational RX02 drive which can operate as an RX02, RX01, or RX8 depending on switch settings.

Maybe I could wire both of them together and set it so that each 8/L could see the memory of the other. Would need to build the logic to implement the CDF/CIF instructions, but it should in theory be possible. Maybe.

Thoughts?
 
Now I need to figure out what to do with two fully operational pdp8/L's. I have heard that there was work on an RX8 interface for them and I would be willing to pick that project up. I've got an operational RX02 drive which can operate as an RX02, RX01, or RX8 depending on switch settings.

There is an Omnibus chassis that connects to Posibus, the DW8E. We have one in a PDP-12 with an RX8E and an RX01, so we can boot OS/8 from diskette.
 
Maybe I could wire both of them together and set it so that each 8/L could see the memory of the other. Would need to build the logic to implement the CDF/CIF instructions, but it should in theory be possible. Maybe.

You could build a dual-port RAM board and connected it to both systems. Some of the RAM would be private to each PDP-8, and some shared for message passing. Having an register to generate and answer an interrupt between the systems would be useful too. This memory bridge was supplied by DEC for lots of different machines.
 
After restoration the RICM's PDP-8/L has been sitting in our warehouse since being used as a prop in the movie Maniac. One of our young volunteers wants to make a video as a school project, so we will use the PDP-8/L to show how we approach the restoration of a vintage computer. We powered it on yesterday for the first time on 10 years, and it is really broken again. I am sure that it will need a bunch of 7400, 7440, and 7474 chips replaced.
 
After restoration the RICM's PDP-8/L has been sitting in our warehouse since being used as a prop in the movie Maniac. One of our young volunteers wants to make a video as a school project, so we will use the PDP-8/L to show how we approach the restoration of a vintage computer. We powered it on yesterday for the first time on 10 years, and it is really broken again. I am sure that it will need a bunch of 7400, 7440, and 7474 chips replaced.
I am curious why specifically the 7400, 7440, and 7474 chips fail?
 
I tested the M220 modules with the flipchip tester. Found one bad 7474 on one M220, and a bad 7453 and 7460 on another. Load Address doesn't. Examine and Deposit don't. Run lights the Fetch light and stops. Continue alternately lights Fetch and Execute. It is still really broken. Probably need to test the rest of the M flipchips.
 
It is old technology which always can breakdown again. I had to repair my 8/F four times up before it worked reliable. The flip chip tester is really a brilliant tool for the 8/i and 8/L machines and several controllers like the TC8 or TC11 for example. My 8/L is still running after restoring it two years ago. Now I have to restore at least one of my Teletypes so I can Fortran on it in the old fashioned way.
 
It is old technology which always can breakdown again. I had to repair my 8/F four times up before it worked reliable. The flip chip tester is really a brilliant tool for the 8/i and 8/L machines and several controllers like the TC8 or TC11 for example. My 8/L is still running after restoring it two years ago. Now I have to restore at least one of my Teletypes so I can Fortran on it in the old fashioned way.
Thanks Roland and Michael. It just seems surprising that it wasn't just any "old TTL" before a particular date, but very specific parts - i.e. 7400, 7440, and 7474.
I am lucky to live in Western Australia with a very dry climate. I hope this means my collection has a better chance to survive.
 
Back
Top