Q-Bus Memory Diagnostics and Repair
jsw at ieee.org
Thu Sep 8 22:05:15 CDT 2016
> On Sep 8, 2016, at 12:26 PM, Noel Chiappa <jnc at mercury.lcs.mit.edu> wrote:
>> 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.
Thanks for the pointers, I’ll give that a try.
>> 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’ve been making do with the SMS 1000 manual for the basic settings as well.
>> 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).
I ran a different diagnostic w/o parity testing enabled.
SWR = 000000 NEW = 100
KT11 (MEMORY MANAGEMENT) AVAILABLE
22 BIT ADR
AVAIL MEMORY MAP:
FROM 000000 TO 3777777
ADDRESS TEST ERROR(TST1-5).
V/PC P/PC MA S/B WAS xor
007312 00007312 03561612 161612 161212 000400
007312 00007312 03561652 161652 161252 000400
007312 00007312 03562752 162752 162352 000400
007312 00007312 03563712 163712 163312 000400
007312 00007312 03565552 165552 165152 000400
007312 00007312 03565652 165652 165252 000400
CONSTANT DATA ERROR(TST6-10).
010102 00010102 03561412 000000 000400
010102 00010102 03561452 000000 000400
010102 00010102 03561512 000000 000400
010102 00010102 03561552 000000 000400
010102 00010102 03561612 000000 000400
010102 00010102 03561712 000000 000400
010102 00010102 03561752 000000 000400
010102 00010102 03562412 000000 000400
010102 00010102 03562452 000000 000400
010102 00010102 03562512 000000 000400
So it appears that bit 8 is the problem at the highest 128KB addresses.
I see stuck bits and address decoding problems.
It looks like some memory addresses return the
contents of another address. That may be what the other
diagnostic was trying to tell me as well.
I may just clip the power lead on the chip I think is faulty
to confirm I have the correct target. Hopefully
the bit ordering matches the board marking and bottom row
is the highest address of memory banks.
If that doesn’t work, then I will take you up on your offer of
memory diagnostic code.
More information about the cctalk