Odd memory error in PDP-11/04
ethan.dicks at gmail.com
Wed Sep 7 20:25:50 CDT 2016
On Wed, Sep 7, 2016 at 1:46 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
> > From: Paul Koning
> > A possible reason would be that the address drivers for that bit, or
> > the address decoders in that chip, are busted. The result would be that
> > reads and writes always touch the same address in the chip.
> Oooh, good point. That's a better explanation of the symptoms than mine,
> since it answers the thing that was confusing me ("why it can be either set
> or reset with a write, but freezes in one state for reads").
Hmm... I see how that would "work"... interesting.
> A fully-populated 64KB MS11-J card has 4 rows of 16Kx1 chips...
This is a 64KB M7847 DJ with 72 (4 rows of 18) Mostek MK4027 chips...
We did lose at least one of these back in the 80s. I have 1-2 ones
needing inspection and repair. Those are far, far down the pile to
investigate. This particular board was working through the early 90s
before I stopped using it for testing COMBOARDs.
I also do have some 256KB boards,
> so if the
> machine ever runs again, the first thing to check is to see if that bit at
> 040000 (or 0100000, if it's a larger than 32KB card) is tied to that bit at
> 0; if not, it's the addressing circuitry in the chip. (Looks like E75, but it
> might be E72).
Right. I did some tests like that but I didn't capture the results
and I can't reproduce them yet.
> > From: Jim Stephens
> > Is there a hint as far as the affected hardware in that the ODT is
> > working, but the ram is not? The rom that is running ODT is also being
> > accessed for read correctly.
> Good point. So it's probably not something in the CPU that's repeating every
> 020 locations.
> Also, IIRC, that ODT code doesn't use memory, it runs entirely out of the
I think that's correct.
> Anyway, if the 020 problem is in the memory too, it's probably the A04 bus
> receiver (E55), although it might be the address latch (E88, a 7475) or the
> RAS/CAS mux (E99, 74S153). Step a would be to put a scope probe on the output
> of the bus receiver (pin 2) and see if it's hopping up and down - if that,
> that chip is OK, and the problem is further down the line.
Sure. Makes sense.
> > I don't know if the rom path to the ODT code is different than the ram,
> Yes. The ROM for the ODT is stored in the M9301 card (at least, if it's an
> 11/04, it's probably an M9301 - could be an M9312, too).
M9312, as mentioned. I have many of those. So far, I'm still using
the one that was in this machine for 35 years, but I have many others,
and several common boot ROMs (DD, RX, RL...)
> The RAM is in another card, an M7847 (MS11-J).
> > it is interesting that the console code is being fetched, along with
> > the data from the serial controller to communicate with the console
> > terminal
> Which indicates that the UNIBUS is probably OK; the console serial is on yet
> another card, the M7856 (DL11-W); the CPU, RAM, bootstrap and serial line all
> talk to one another over the UNIBUS.
Yes. That is "obvious" and I should have immediately realized that
the CPU and bus must be happy or I would have no ODT. Must be the
RAM, or at least it was before the whole thing stopped responding.
Now, it's probably the RAM and the CPU. I did swap back in my first
DL11-W and that does (still) stuff up SACK, so it has its own
problems. I have one recently working and one recently non-working
DL11-W and one that came to me with some obvious mouse damage that
might be recoverable - it's in the corner by the 40-pin connector and
I think to really clean it, I'll have to remove that connector and
clean that entire quadrant, but, again, another problem for another
time. Just getting ODT back will be a small win, then debugging the
RAM card will be another.
So far, the repair has been one 7474 on the console board. Looks like
1-2 more chips will need to be replaced, at least. I do have a few
parts of the era.
Thanks, all, who chimed in. So far, the observations and advice have
More information about the cctech