Stuck bits on 11/73 Clearpoint 4MB memory - how to repair?

Jay Jaeger cube1 at charter.net
Fri Feb 12 20:55:44 CST 2016


On 2/12/2016 5:32 PM, Jacob Ritorto wrote:
> Hi,
>     Seems I have bits 4 and 3 sticking on my Clearpoint QRAM-2-SAB-1 88b
> 4MB memory in my pdp11/73.
> 
>     Can anyone offer hints as to how to identify which component is broken
> and how to go about repairing this?
> 
>     It's the only memory board in this machine, so I guess the problem
> might actually be a bus or processor board, right?  I have no other q-bus
> memory to test with, so can't do swapping / process of elimination to be
> sure.
> 
>     Here's the manual:
> http://www.arclightindustries.com/docs/Clearpoint-88B.pdf (which I probably
> should add to manx or archive.org or something).
> 
>     Here's a snippet of the VMJA diags run illustrating bits 4 and 3
> sticking.  During the next VMJA run, all addresses were showing up as
> errored instead of just the ones ending in xxx000xx, so I guess it's
> getting worse!
> 
> @173000g
> 
>                               Starting system
> BOOTING UP XXDP-XM EXTENDED MONITOR
> 
> XXDP-XM EXTENDED MONITOR - XXDP V2.5
> REVISION: F0
> BOOTED FROM DL0
> 124KW OF MEMORY
> NON-UNIBUS SYSTEM
> 
> RESTART ADDRESS: 152000
> TYPE "H" FOR HELP !
> 
> .R VMJA??
> VMJAB0.BIC
> 
>  CVMJAB0  ECC/PARITY MEMORY DIAGNOSTIC
>    11/83 CACHE AVAILABLE
> SWR = 000000  NEW = 000040
> 
> 
>                CSR MAP
> 
> CSR     0 1 2 3 4 5 6 7 8 9 A B C D E F
> MEMTYPE P
> 
> 
> CSR NUMBER 0 CONTROLS TOO MANY BANKS
>   2044K OF Q-BUS PARITY MEMORY
>   2044K WORDS OF MEMORY TOTAL
> 
>                         MEMORY CONFIGURATION MAP
>                              16K WORD BANKS
>                 1       2       3       4       5       6       7
>         012345670123456701234567012345670123456701234567012345670123
> ERRORS
> MEMTYPE PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
> CSR     000000000000000000000000000000000000000000000000000000000000
> PROTECT PP
>             1       1       1       1       1       1       1
>             0       1       2       3       4       5       6
>         456701234567012345670123456701234567012345670123456701234567
> ERRORS
> MEMTYPE PPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPPP
> CSR     000000000000000000000000000000000000000000000000000000000000
> PROTECT
>         1
>         7
>         01234567
> ERRORS
> MEMTYPE PPPPPPPP
> CSR     00000000
> PROTECT
> MEMORY DATA ERROR
>   PC    BANK  VADD     PADD     GOOD     BAD     XOR  CSR  MTYP INT PAT
> 
> 027606   10  060000  01000000  000010  000030  000020  0     P       27
> 027606   10  060002  01000002  000010  000030  000020  0     P       27
> 027606   10  060004  01000004  000010  000030  000020  0     P       27
> 027606   10  060006  01000006  000010  000030  000020  0     P       27
> 027606   10  060010  01000010  000010  000030  000020  0     P       27

<< SNIP >>

Well clearly it is only affecting certain address bits - or the
diagnostic would not run at all - note that it is starting at 010000000,
 so that points to the memory, rather than the processor or bus, at
least as a first approximation.  No guarantees, but I'd sure start with
that as a working theory.

Another sign: this is right at the boundary between two rows.

If you can't find a schematic, you can use the address to identify the
address lines on the bus (See Table 3, page 1-5), and trace them on the
board to find the relevant row of chips.  Then use the bits the same way
to identify the specific chips.

If the chips are in sockets, you could always pull them one at a time to
find the relevant place in the array, as well.

I expect this is not the issue, but, one has to ask these things, just
in case.  Did this memory work before? I ask because this is the 19th
bit. If the backplane is a Q18 backplane, that might be a problem?
Along those same lines, make sure that jumper P07 is positioned
correctly for a 22 bit address, and that P05 and P06 are set correctly
for the memory size.

Are you seeing the parity error light when this occurs?

Anyway, once the relevant chip(s) are identified, if they are in sockets
you can swap them with other bits or the same bits in other rows to
confirm.  Otherwise you get to unsolder the suspects, and put in new ones.

JRJ


More information about the cctalk mailing list