6 Sep
2014
6 Sep
'14
3:06 a.m.
On 2014-Sep-06, at 12:53 AM, Brent Hilpert wrote:
On 2014-Sep-05, at 9:11 PM, Josh Dersch wrote:
Sorry, have to back up a bit, looking at the organization for that board I see what (I
think) you were getting at. Some of the decoding is done by putting the address wires for
an axis into a sub-matrix. It may not be a driver transistor but still, the decoding can
be isolated to a wire and a good candidate for problem would be the diode pair for the
appropriate address wire, in the DIP packages on the stack board.
Yes, hope it isn't a damaged/open address wire, although it might be possible to fix
it if it's damaged outside the threading through the cores.
Hi all --
The CPU in the 11/05 seems to be behaving nicely as far as I can tell, now that the
Microcode ROMs are no longer filled with bogus data. It will run small programs I've
toggled in without issue, and so I've moved on to testing the memory.
Basic testing (via the simple address test listed here:
http://www.psych.usyd.edu.au/pdp-11/hints.html) reveals that most of the 8KW of core
(H215) and controller is working pretty well, except for a 128 byte range between
012000(8) and 012200(8). Within this range, all words read back as all zeros regardless
of what is written.
Given the nature of the fault, I tend to think that this is not an addressing problem or
an issue with the core drivers -- if it was any of these I'd expect the fault to
repeat across the memory space in a pattern, rather than being isolated to a single
contiguous block of memory. If that's true, then it seems that the core plane itself
might be at fault. Which doesn't surprise me, I'm actually surprised it works at
all -- when the /05 arrived the H215 core memory board was loose, banging around inside
the chassis.
Does my initial analysis seem reasonable? Anyone have any experience debugging one of
these and have any tips to share?
No, it is most likely an issue with a core address driver. Remember the cores are
arranged in a matrix and each column and row of the matrix will have a driver. When a
driver fails one row or one column is taken out. On one axis the failure will be a
contiguous block, on the other it would be words separated modulo the size of the first
axis.
For 8K the most probable matrix size is 128 * 64 (binary pair closest to the square
root of the size).
Given it's DEC, I presume the schematic is available for the board at issue. Knowing
the address range you should be able to pigeon-hole it down to the decoded address line
and driver of the matrix and then start testing.
The drivers have to be able send current in both directions through the address wires so
they're a little more complex than a solitary transistor, and the decoding and driving
will be mixed together to some degree, but at 8K it's not that large a matrix and
probably won't be too complex.
Note that what look like ICs in DIP packages may actually be the transistors and diodes
of the drivers (things like quad transistor packs).
My own little treatise on the organization and electronics of core memory for more
depth:
http://www.cs.ubc.ca/~hilpert/e/coremem/index.html