• Please review our updated Terms and Rules here

PDP-8 core memory troubleshooting

T

thunter0512

Veteran Member
Joined
Sep 27, 2020
Messages
858
Location
Perth in Western Australia
On the LAB-8/e I have been working on (until now most power supply repair and deep clean) I finally assembled a fairly minimal set of boards.
When I powered up this configuration no smoke came out which was pleasing (especially for the owner of the machine).

About 50% of the front-panel lights were dead as confirmed with a multimeter.
I ordered 50 lamps from Mouser but I am in Australia so I am lucky if I see them by the end of next week.

I re-arranged the remaining working lights so that I have 4 address lights and 9 data lights.
This allowed me to do some basic manual memory testing via the deposit and examine switches.

Unfortunately not all is well - bits 4 and 8 behave strange when I verified previously deposited bit patterns. The other bits appeared fine during the limited testing I did (all zeros, all 1s, alternate 01s, alternate 10s and walking zero and walking 1).
Bit 4 is always zero but sometimes (mostly) when it should be 1 instead bit 8 is 1 - even though it is meant to be zero. The bits 4 and 8 interact in some way meaning possibly there is a common component fault.

I have 8 kWords of core implemented via the following boards:

G111C memory sense inhibit
H212 core
G233E memory X/Y drivers

The G233E has a strange bow in the upper middle section other than that there is no obvious damage to the 3 boards. There is no obvious heat damage on the G223E so I am at a loss explaining that bowing. Has anybody else see this?

Could you please advise on how best to isolate the cause of the memory fault?

As the 3 boards are connected via four H851 top-connectors it is not trivial to probe any signals. So I am struggling to come up with a sensible way of debugging the boards.

Also could you please recommend what documents to read to get a better understanding of the core memory implemented by these 3 boards?

Thanks for any help or suggestion.

Best regards
Tom Hunter
 
It is also possible the problem is not in the memory. It could be the memory buffer register or bus drivers on the Major Registers board. What is really helpful is having a friend who will let you try your boards one at a time in their working machine. When you find a board that does not work you have a place to start. If the machine has sat for years you could have multiple problems which tends to make debugging more difficult.

What I have done is to tack solder a piece of wire wrap wire to the point I want to look at. It is far from convenient but without having 3 extenders or some sort of ribbon cable to replace the top blocks it is probably the easiest way.

Best wishes!
 
Last edited:
I too vote for the problem being external to the core. If a single bit or word was bad that would be one thing. But to have a bad bit all thru memory sounds like something else.
 
tradde said:
I too vote for the problem being external to the core. If a single bit or word was bad that would be one thing. But to have a bad bit all thru memory sounds like something else.
Click to expand...

My working assumption is that the problem is in the 3 board core memory set (MM8EJ).
Everything else seems OK as far as I can tell.

I am hoping someone can suggest a good debugging approach for the MM8EJ or recommend any document which would help.
I have downloaded all the PDP-8 documents from Bitsavers and work my way through them.

I forgot to say, the bit numbers I refer to, are in the for me more familiar order with LSB being bit zero.
DEC’s ordering with MSB being bit 0 and LSB being bit 11 confuses my ageing brain too much. :)

Thanks and best regards
Tom Hunter
 
You can’t assume that if something looks like it is working, that it is.

There may be a buffer in a signal line that is not working, so internally to the CPU things are working - but externally they are not.

What you need to do is ‘divide and conquer’. Look at the MA and MB register values (and those from the memory extension registers if present) between the CPU and memory for various address and data combinations. Test WRITE first followed by READ later when looking for patterns. If the WRITE doesn’t work properly, you can’t hope to get the READ to work!

If you can point me at some readable schematics for the machine you have, I may be able to suggest some further tests. I have checked some schematics on bitsavers - but (unfortunately) they are unreadable for this purpose.

When working on an ‘8’, I print out a picture of the front panel and have it available at the point of work. This solves the 0/11 and MSB/LSB problem!

Dave
 
When I first started repair on my PDP8E, I had multiple problems. This can really stir the pot of confusion. First of which was the power supply. After repairing that, I still had quite a bit of odd behavior. How I approached it was get help from Jack Rubin, Vince and Daver. First order of business was to replace all the filter capacitors on each board. Then I borrowed one of Vince's modern memory board from Jack to replace the core memory I had (still hoping to repair them). Then knowing that the memory was good, I used the schematics and maintenance books DEC-8E-HR1C-D VOL1, DEC-8E-HR2C-D VOL2 and DEC-8E-MM3C-D VOL3. You can find these on bit savers. The circuit descriptions are excellent, but there is a lot or reading and re reading involved to gain an understanding of how things work. After I started to search the circuits, I leaned on Daver for some help. I don't know whether Vince has a memory board available, or not, but that might be a good starting point, then do some reading, break out the test equipment and post results with any questions you may have, I'm sure you will have them, I did. Mike
 
That seems like a long while ago now - but you did prevail...

I assume the 'T' is all wrapped up for winter now?!

Dave
 
Actually.....no. I generally drive it through the winter. I try not to use it when there is salt on the roads. We just received a few inches of snow today and it is fun to drive it in fresh snow. Yet most Model T driving has ended. My attention has turned back to the computers. I've been working on my SOL-20 and the CP/M 2.2 machine, yet I have not forgotten about the PDP8E. I have an old Friden printer that I connected to the CP/M machine, so far the communication is one way, computer to typing machine. I want to add the reverse, then maybe later get it to work with the PDP8E. Anyway, there is quite of bit to keep this old man amused. Mike
 
I agree with the excellent advice and observations above: it might well be something other than the memory boards themselves and degradation of some of the components in the system is likely.

But we should also note that this is ferrite core memory, so it is possible for a row, column or block of bits to be affected by a problem with, for example, the XY drivers, sense amplifiers, or damage to those very delicate fine copper wires (I assume they are still protected by the clear plastic cover). Looking at a H212 there are 12 fields of cores, possibly, then, one for each bit, with 12 sense wires). Things might be more apparent when you have a full set of lamps (but I am not sure by how much). An oscilloscope will be useful.

The strange bowing on the one board sounds irksome; you are sure it has not stressed any tracks, solder joints or components?

The bitsavers copies of the schematics do tend to be a bit fuzzy (I just had a look for one on this subject); but they can (at least for me) look better (but still some of the detail can still be illegible) if you wait for your viewing app to "catchup" when zooming in (they behave like "progressive JPEG" I guess). Still, bitsavers is an amazing and valuable resource!

On my eBay "watch list" are what appear to potentially be some original LAB-8/E and PDP-8/E drawings (awaiting a lottery win):

https://www.ebay.com/itm/Digital-Equipment-Corporation-Schematics-from-the-1970s/312544095690

I have been tempted to make a cheeky offer for them...

I have seen DEC schematics like these in person (in the distant past) and the ones I have seen were quite a large format...
 
daver2 said:
You can’t assume that if something looks like it is working, that it is.

There may be a buffer in a signal line that is not working, so internally to the CPU things are working - but externally they are not.

What you need to do is ‘divide and conquer’. Look at the MA and MB register values (and those from the memory extension registers if present) between the CPU and memory for various address and data combinations. Test WRITE first followed by READ later when looking for patterns. If the WRITE doesn’t work properly, you can’t hope to get the READ to work!

If you can point me at some readable schematics for the machine you have, I may be able to suggest some further tests. I have checked some schematics on bitsavers - but (unfortunately) they are unreadable for this purpose.

When working on an ‘8’, I print out a picture of the front panel and have it available at the point of work. This solves the 0/11 and MSB/LSB problem!

Dave
Click to expand...

Thanks Dave,

The MM8-EJ core memory schematics are here: http://www.bitsavers.org/pdf/dec/pdp8/pdp8e/MM8-EJ_Engineering_Drawings_May73.pdf

The complete engineering drawing for the 8/e are here: http://www.bitsavers.org/pdf/dec/pdp8/pdp8e/PDP-8E_Engineering_Drawings_RevAD_Dec72.pdf

I still strongly suspect the 3 core memory boards. Not so much the actual core memory board itself but firstly the sense/inhibit board and secondly the X/Y board.

Thanks and best regards
Tom Hunter
 
All of the address (MAx and EMAx) and data lines (MDx) go to / come from the respective core cards so the first thing is to identify the connector pins associated with each signal and to 'tack' a few floating wires onto each (a few at a time). Then perform a console write to a specific address with specific data and see what you get on your attached flying leads.

You will also need to monitor some of the control lines.

Be aware that some of the 8881 buffers may be bust, so writing data using (say) MD0L may not appear correctly on AK1. Either this could be due to the major register buffer in the '8' being faulty (not correctly driving MD0L) or it could be that E10 pin 13 is driving MD0L when it shouldn't (also check the 'enable' input to the 8881 in this case to see whether the buffer was erroneously enabled). Failing that, move back to the MD register and the MD buffer back on the major registers card(s) and test again.

There is a bit of 'suck it and see' what you get to start with...

Dave
 
kb811 said:
...or damage to those very delicate fine copper wires (I assume they are still protected by the clear plastic cover)
Click to expand...
Kids today... In my day we could practically read the bits with a compass, they were so big. :p

bigfatcores.jpg
 
I have now a full set of front panel lights for the Lab-8/e and was able to do more testing of the MM8-EJ core.
The PDP-8/E Maintenance Manual Vol 1 (Sept 1973) has a detailed section about the core circuit design. I mostly understand it after reading it twice.
I have narrowed down some of my stuck bit problems to the G111C Sense/Inhibit board ICs E10 (7439) and E14 (DEC 384).
While probing some of the signals I see weirdness on some of the troublesome bits while depositing all zeroes or all ones via the front panel.
I also see some mysterious hacks to the inputs of the 74h40s (E11, E15, E18, E22, E25, E29) where pins 1 and pins 12 (these are effectively INHIBIT H qualified by FIELD H) have either been left floating (by cutting tracks) or re-routed via some wire. I have not yet analysed the rerouted bits, but leaving any inputs floating seems like a bad idea. Leaving INHIBIT H floating is definitely bad. Either way this may have been an incomplete ECO or an earlier attempt to fix the board.

Questions:

1) where would I find a description of the ECOs for the MM8-EJ or specifically the G111C ?
2) where would I be able to find DEC 384 ICs which seems to be a quad 2-input OR ?
3) why do DEC engineer show a 2-input OR as a 2-input NAND where both inputs are inverted?
4) has anybody else got a G111C and if yes could you please make a high resolution photo of both sides of the board and post it here or send it to me as a PM?

Thanks and best regards
Tom Hunter
 
>>> 1) where would I find a description of the ECOs for the MM8-EJ or specifically the G111C ?

http://www.pdp8online.com/miscdocs/DECOLOG.pdf

>>> 2) where would I be able to find DEC 384 ICs which seems to be a quad 2-input OR ?

I can find DEC384A and SP384A ICs on eBay from a couple of sellers.

>>> 3) why do DEC engineer show a 2-input OR as a 2-input NAND where both inputs are inverted?

There are two schools of thought as to how to draw schematic diagrams... The first school of thought is to draw the physical symbol for the logic gate - so a 7400 would be drawn as a 2 input NAND gate always. The second school of thought is to draw the logical symbol for the intended function and signals. This may mean that what is drawn is not the same as the physical entity itself. You need to read a good book on logic design :)...

Dave
 
m_thompson said:
The RICM has the same core stack. Any idea what it is from?
https://www.ricomputermuseum.org/Home/interesting_computer_items/magnetic-core-memory
Click to expand...
No. I actually contacted your group several years ago (most likely in 2009) and asked you the same question, but don't believe I heard back.

It came from my job at St. Potato's College (click the link for an amusing story about the name). It could have come from any old equipment that pre-dated me there (1976), either in use or or stuff donated and scrapped out for parts. It is very low density and an odd arrangement of 20 x 50, and neither yours nor mine shows any sign of having ever been assembled into a larger stack. I think that means that it was either a spare part or was a very small standalone memory. I think we can dismiss it being from IBM equipment as by the time IBM got into electronic computers, pretty much every part had "IBM" on it somewhere. Similarly, Wang Laboratories put their name on their memory boards.

If it was a standalone module and not part of a stack, it was either registers (but 20 x 50 is an odd size, even if you include parity checking - 50 18-bit registers? 20 48-bit registers?) or microcode storage. But if it was for microcode, for what? It is still very low density. My guess is registers.

The only pictures of anything similar are from a computer wallpaper site, where photos 4 (probably), 20 (possibly) and 21 (definitely) are of the same board design.
 
I recall my Dad (IBM DP 1952-84) telling me IBM went ahead and used core memory before acquiring the patent, fully expecting to be sued (by Wang?), but they knew the value of getting to market using it far exceeded any lawsuit settlement. History turned out to be right for them.
 
daver2 said:
>>> 1) where would I find a description of the ECOs for the MM8-EJ or specifically the G111C ?

http://www.pdp8online.com/miscdocs/DECOLOG.pdf

>>> 2) where would I be able to find DEC 384 ICs which seems to be a quad 2-input OR ?

I can find DEC384A and SP384A ICs on eBay from a couple of sellers.

>>> 3) why do DEC engineer show a 2-input OR as a 2-input NAND where both inputs are inverted?

There are two schools of thought as to how to draw schematic diagrams... The first school of thought is to draw the physical symbol for the logic gate - so a 7400 would be drawn as a 2 input NAND gate always. The second school of thought is to draw the logical symbol for the intended function and signals. This may mean that what is drawn is not the same as the physical entity itself. You need to read a good book on logic design :)...

Dave
Click to expand...

Hi Dave,

Thanks for the ECO list. ECO "G111-D0005 Problem 1" is what I was referring to in my post late last night. I now see that nothing was left floating, instead there is a trace on the component side of the PCB between pins 1 and 12 of the 74H40s I thought were left floating. The trace was underneath the IC so was not visible.

I now realise that sourcing of components for repairs is not entirely trivial nor cheap. :-(
Buying components via Ebay yields mixed results. Some are outright fakes others may or may not work. I was hoping to find the DEC 384s from a reputable supplier.

Thanks again for your help and advice.

Tom Hunter
 
1944GPW said:
I recall my Dad (IBM DP 1952-84) telling me IBM went ahead and used core memory before acquiring the patent, fully expecting to be sued (by Wang?), but they knew the value of getting to market using it far exceeded any lawsuit settlement. History turned out to be right for them.
Click to expand...

MIT owned the patent for core memory, but in fact were sued by RCA. "[Mike] Haynes, as a Ph.D. student at the University of Illinois, applied magnetic cores to implement logic and later established the magnetic core research efforts at IBM, the company that ultimately benefited the most from the invention." (http://courses.csail.mit.edu/6.972/Core Report.html)

Also: "In 1948, An Wang implemented the first magnetic cores to store information in a computer."

Edit: Oops! I stand corrected - Wang also had a patent. From https://www.computerhistory.org/revolution/memory-storage/8/253 :
"In 1955, Wang sold the rights for his core memory patent to IBM for $500,000, which he used to found the highly successful Wang Laboratories."
but "In 1964, after years of legal wrangling, IBM paid MIT $13 million for rights to Forrester’s patent—the largest patent settlement to that date."

:)
 
You must log in or register to reply here.
Back
Top