Q-Bus Memory Diagnostics and Repair
jnc at mercury.lcs.mit.edu
Thu Sep 8 12:26:55 CDT 2016
> From: Jerry Weiss
> The first is an MSV11-PL 512KB-Q-Bus 22bit.
> Dead to both CSR and Memory address access in ODT.
> ... before start poking around with my scope ... can recommend a
> particular methodology to finding the fault.
Well, the CSR and RAM address detection circuits are separate (page 5 of 11
in the drawings), so since both are not responding, it has to be something in
common: perhaps something on the input side like a bus receiver (e.g. BSYNC,
pg 8), perhaps something on the output side like a control line driver (e.g.
BRPLY, same page), or some of the common circuitry that drives it (e.g. TRPLY
generation on pg. 5).
The way to tackle this is to write a two instruction loop that reads the CSR
(that will be easier to grok than RAM access); it will need a NXM trap
catcher which just does an RTI, too; and don't forget to set up the SP. Then,
pick some likely point half way along the signal path (e.g. MSEL, on the
right hand edge of pg. 5), and see if that's doing what it should. If no,
start moving back upstream; if it is OK, start going downstream from there.
> The second board is a CMV1000 that probably has a bad Memory Chip.
> I don't have either prints or a manual for this board.
Yes, either/both for this, and the sister CMV4000 (same board with 256K
chips) would be really fantastic to locate. I'm in the process of working out
what all the jumpers/mean do, and will work out which chips correspond to
which bits, and document them, like this page:
However, we're not there yet for this card, so...
> I was expecting bad and xor to be 16bit values, but they appear to be
> mostly 22bit addresses. But then again this isn't a DEC board.
That shouldn't make a difference. I can't make head or tail of the output
either; can anyone else help? (I don't use DEC diagnostics, I have rolled my
own PDP-11 memory diagnostic.)
> The board itself is labeled with bits 0-7 P0 P1 8-15 across the top
Well, that is a good hint... :-)
> Any suggestions as to which chip might be suspect?
Step A is to find out what the failing location(s) are, and what the bad data
is. So either figure out the DEC memory diagnostic output, or roll your own
(you can have mine if you like, I have Unix assembler source, or I can give
it to you in .LDA binary).
More information about the cctalk