PDP-11/45 RSTS/E boot problem

Thanks, Paul and Noel, for the detailed responses per usual! Looks like a few more flaky bits in a couple of additional banks. For those reading along who may be unfamiliar with the MS11-L, it is laid out as 8 physical banks, each containing 18 16K x 1 DRAMS (16 data + 2 parity bits per word. So a flaky bit in a physical bank implicates one particular chip. I have thought about that... The most efficient way I think would be to work up a simple LDA loader that would fit in a boot sector, and load a diagnostic from contiguous disk starting at the second sector. It would then be easy to blast down just the boot sector and a single desired diagnostic without imaging an entire pack. I did this last night, actually. I also added a "random" bits test that uses the program image itself as a source sequence for words to write/compare. The good news is that my enhanced diagnostics now detect failures in the same physical banks and with the same bits as those flagged by the MAINDEC diagnostic. This was a good lesson learned: all ones / all zeros is definitely not good enough when checking this sort of thing! Another thing I found interesting, though, is that the "random" test *also* found a malfunctioning bit that the address test had missed. So ones/zeros and address isn't really good enough, either. I'm technically curious, now, about the failure modes of these sorts of DRAMS. I guess in addition to stuck bits, there are also potential decode fails (show up on address test, but not ones/zeros) and some errors that have history-dependence, perhaps internal latches (show up on random data test, but not address or ones/zeros.) I'd guess also there might be potential for crosstalk, noise, and "fading bit" type issues as well? Will have to see after I make the next round of repairs if there are still additional problems that the MAINDEC flags that my simplistic diag isn't shaking out. I've also been somewhat surprised by the level of repair needed on this memory board. So far, I've seen 6 failed 4116 out of an array of 144 total, so about a 4% failure rate. Is this typical for vintage 4116, or did somebody leave my poor MS11 out in a lightning storm? :-) D'oh! Yes, thanks; I may very well have mucked that up. I'll give it another try with a little more care later today. Hmm, I saw this at least once when researching the variety of CSR formats yesterday morning; I'll have to see if I can dig it up again today. Might be just a fastbus thing? It's also hinted in paragraph 7.7.7 of the older KB11-A maintenance manual (NOT the later edition that covers both KB11-A and KB11-D): "The semiconductor memory control EHA and EHB (enable halt) flip-flops may be set under program control to assert SMCB PE HALT L if a parity error is detected. This input also asserts UBCB PARITY ERR SET L, which set the console flag and halts the CPU." This particular text is removed from the later KB11-A,D maintenance manual, and the description there seems to imply all reported parity conditions trap directly to 114. But there aren't any details in this section concerning processor revision/version etc. The logic design around all this is a bit complicated, and the fact that there are apparent discrepancies between the texts, available prints, and the actual M8106 boards I have on hand is not heartening! Yup. And, surprisingly, neither one of my M8106 has either a jumper or the indicated pull-up at that location! I'll try to send a pic later. The fact that W1 exists on the M8119 is interesting; maybe the situation is that the prints are for later revisions, and my actual M8106 are earlier? My /45 is a very early one -- serial 154! cheers, --FritzM.