On Sep 9, 2016, at 8:17 PM, Jerry Weiss <j...@ieee.org> wrote:
>
> On Sep 9, 2016, at 6:11 PM, Noel Chiappa <j...@mercury.lcs.mit.edu> wrote:
>>
>>> If your CPU is an 11/73 (which can directly 'access' [hate that verbism
>>> :-] all of memory from ODT, unlike the 11/23 which is restricted to the
>>> bottom 256KB), try playing around with a failing location, and its
>>> alternative, directly, and see if a store of random data into one can be
>>> read back directly from the other
>>
>> Note: The 11/'73' CPU powers up with the cache enabled, even for ODT!
>>
>> So if you write xxx into some location, if you then read it back, you will
>> get
>> the correct data even if the memory location is busted - the CPU is getting
>> the (correct) data from the cache. To have your 'memory' reads and writes
>> actually go to the memory, you need to turn off the cache:
>>
>> 17777746/ 02000
>>
>> Note that starting the machine does an INIT, which will again enable the
>> cache.
>>
>
> That’s a very good piece of information, I hadn’t considered that. I have
> 11/73.
> I’ve checked the memory with ODT and can confirm the stuck bit.
>
Finally got back to this. First clipped VCC on the suspect
and confirmed that the bank and address range was the same as the original
error.
So finally pulled out the soldering iron and replaced as chip. Back to memory
test
and all is now good.
R VMJA??
VMJAB0.BIC
CVMJAB0 ECC/PARITY MEMORY DIAGNOSTIC
11/83 CACHE AVAILABLE
END PASS #QV 1
END PASS # 2
END PASS # 3
END PASS # 4
END PASS # 5
END PASS # 6
END PASS # 7
END PASS # 8
END PASS # 9
END PASS # 10
END PASS # 11
END PASS # 12
END PASS # 13
I board fixed, one to go. Thanks for the support.
Jerry
