Help with a busted MSV11-L?

[Noel Chiappa]

    > I'm trying to fix a broken MSV11-L card (M8059-KF). The symptom is that
    > it always reads back with the 020 bit set, but otherwise appears to be
    > fine.
    > ...
    > two octal 3-state-output latches (E57 and E64, an 'LS373 and an 'S373
    > respectively).
    > ...
    > the two octal latches are both TI Malaysia parts (date code 8231)
    > ...
    > it's the data latch that's bad.

So, I seem to have discovered a plague! I had another failed QBUS memory card,
an MSV11-D this time (M8044-DB). It has the exact identical symptom, except
with a different bit - 02000 this time, instead of 020.

So, since the designs are very similar, I thought 'maybe another bad S373'.
Well, they aren't quite as similar as it thought, but the culprit is indeed
apparently ... a bad S373! (Although I have to caveat that; I suppose it
could be the bus transceiver it's connected to.. but the output is always
high, which make it seem like the the driver in the 'S373 has failed.)

Anyway, this time it's a National Semiconductor part, and from a very
different date code (7947). What is it with S373's? Is this just pure chance,
that two from different makers, quite a while apart in time, were the
culprit? Or is there some issue with S373's? (I note that MSV11-D's are
apparently notorious for failing; perhaps because they use S373's a lot?)

I do have another MSV11-D with a similar fault (the 01 bit this time); once I
get it fault-isolated, I'll report if it, too, is caused by an S373 failure.


It may take a while to get it fault-isolated, though - so far, I've been
writing two- or three- instruction loops which have the picked bit set in all
the words of the program! (Because I'm too lazy to write a longer program that
sets up the memory mapping so the program can run out of 'good' memory, only
poking the 'bad' memory to test it... :-) Also, it's kind of an fun
challenge... :-)

	Noel