6 Sep
2014
6 Sep
'14
4:11 a.m.
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?
Thanks,
Josh
6 Sep
6 Sep
4:27 a.m.
the easiest way is to swap out one of the 3 memory boards at a time to
isolate it and go from there.
I can loan you an untested set if that helps, but it will be a while till I
can test them.
Paul
On Fri, Sep 5, 2014 at 11:11 PM, Josh Dersch <derschjo at gmail.com> wrote:
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?
Thanks,
Josh
7:53 a.m.
On 2014-Sep-05, at 9:11 PM, Josh Dersch wrote:
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
8: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:
Should have mentioned.. it could be a 64*64 matrix with anti-coincidence addressing to
further double it.
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.
For 8K the most probable matrix size is 128 * 64 (binary pair closest to the square
root of the size).
8:27 p.m.
On 9/6/2014 1:06 AM, Brent Hilpert wrote:
On 2014-Sep-06, at 12:53 AM, Brent Hilpert wrote:
Thanks for all the info -- the core memory overview you put together
looks to be very helpful, and when I have some time (hopefully this
evening) I'll study it a bit more in-depth and see what diagnosis I can
apply to the 11.
Thanks,
Josh
On 2014-Sep-05, at 9:11 PM, Josh Dersch wrote:
Should have mentioned.. it could be a
64*64 matrix with anti-coincidence addressing to further double it.
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.
For 8K the most probable matrix size is 128 * 64 (binary pair
closest to the square root of the size).
23 Sep
23 Sep
4:49 a.m.
On 9/6/2014 1:27 PM, Josh Dersch wrote:
On 9/6/2014 1:06 AM, Brent Hilpert wrote:
A brief update (and request for further information): I finally had
time tonight to sit down and dig into this (I've been busy and easily
distracted by new shiny objects as of late). Thanks to Brent's writeup
and DEC's documentation (both of which are well written and relatively
easy to understand) I'm pretty sure I've traced down the fault to a
diode on the core plane board (H214), contained within a DIP package
designated as a DEC 2501.
Of course, I don't have any of these going spare (and I'm not sure if
there are equivalents -- I have yet to find a datasheet). Anyone have
any information about these, have any (good) spares, or know where I
might find some replacements? I suppose I could just hack in a single
diode (assuming I can determine the specs) but that seems kind of ugly...
Thanks,
Josh
On 2014-Sep-06, at 12:53 AM, Brent Hilpert wrote:
Thanks for all the info -- the core memory overview you put together
looks to be very helpful, and when I have some time (hopefully this
evening) I'll study it a bit more in-depth and see what diagnosis I
can apply to the 11.
Thanks,
Josh
On 2014-Sep-05, at 9:11 PM, Josh Dersch wrote:
Should have mentioned.. it could be a
64*64 matrix with
anti-coincidence addressing to further double it.
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.
For 8K the most probable matrix size is 128 * 64 (binary pair
closest to the square root of the size).
6:16 a.m.
On 2014-Sep-22, at 9:49 PM, Josh Dersch wrote:
On 9/6/2014 1:27 PM, Josh Dersch wrote:
? right, I call it Shiny Object Syndrome - look! another three-letter acronym.
On 9/6/2014 1:06 AM, Brent Hilpert wrote:
A brief update (and request for further information): I finally had time tonight
to sit down and dig into this (I've been busy and easily distracted by new shiny
objects as of late). On 2014-Sep-06, at 12:53 AM, Brent Hilpert wrote:
Thanks for all the info -- the core memory overview you put together looks to be
very helpful, and when I have some time (hopefully this evening) I'll study it a bit
more in-depth and see what diagnosis I can apply to the 11.
Thanks,
Josh
On 2014-Sep-05, at 9:11 PM, Josh Dersch wrote:
> 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.
For 8K the most probable matrix size is 128 * 64 (binary pair closest to the square
root of the size).
Should have mentioned.. it could be a 64*64 matrix with
anti-coincidence addressing to further double it.
Thanks to Brent's writeup and DEC's
documentation (both of which are well written and relatively easy to understand) I'm
pretty sure I've traced down the fault to a diode on the core plane board (H214),
contained within a DIP package designated as a DEC 2501.
Of course, I don't have any of these going spare (and I'm not sure if there are
equivalents -- I have yet to find a datasheet). Anyone have any information about these,
have any (good) spares, or know where I might find some replacements? I suppose I could
just hack in a single diode (assuming I can determine the specs) but that seems kind of
ugly...
Great, thank goodness it looks like a diode problem and not a matrix-wire.
I looked into the diode packs back during the earlier discussion, the best match I found
(based on pinout) for the address-wire current-steering diode pairs (14-pin DIP) was:
TID125, TID126
http://www.datasheetarchive.com/dl/Scans-026/ScansUX10116.pdf
The DEC schematic indicates the pair-pins but doesn't seem to indicate the two
common-anode/cathode pins on the packages, the TID125/126 I think were the only type(s)
from the above page that made sense.
( DEC schematic: page 134 of 1105_RevAH_Engineering_Drawings_Jul76 from bitsavers, sheet 2
of H214-0-1 ).
There's a small chance I might have a replacement or equiv on a scrap board.
Worst case - should be able to use a couple of discrete diodes to sub for the bad ones if
you can ensure the bad ones are out-of-circuit.
24 Sep
24 Sep
4:15 a.m.
On 9/22/2014 11:16 PM, Brent Hilpert wrote:
Nice! I double-checked the anode/cathode pins (1 and 14) listed for the
TID 125/126 by tracing them out with my continuity checker on IC E22 on
the H214 and they're connected to FK2 and FL1 on the edge connector as
they should be, so the 125/126 matches the DEC 2501's pinout. I found a
seller on eBay selling them for $1.79/ea, so I bought a few extra.
(see:
http://www.ebay.com/itm/TID126-TI-IC-DIODE-ARRAY-14-Pin-DIP-RARE-New-/37030…).
When they arrive, I'll let you all know how they work out...
Thanks again for the help,
Josh
On 2014-Sep-22, at 9:49 PM, Josh Dersch wrote:
:).
On 9/6/2014 1:27 PM, Josh Dersch wrote:
? right, I call it Shiny Object Syndrome - look! another
three-letter acronym. Thanks for all the info -- the core memory
overview you put together looks to be very helpful, and when I have some time (hopefully
this evening) I'll study it a bit more in-depth and see what diagnosis I can apply to
the 11.
Thanks,
Josh
A brief update (and request for further information): I finally had time tonight
to sit down and dig into this (I've been busy and easily distracted by new shiny
objects as of late). Thanks to Brent's writeup and DEC's
documentation (both of which are well written and relatively easy to understand) I'm
pretty sure I've traced down the fault to a diode on the core plane board (H214),
contained within a DIP package designated as a DEC 2501.
Of course, I don't have any of these going spare (and I'm not sure if there are
equivalents -- I have yet to find a datasheet). Anyone have any information about these,
have any (good) spares, or know where I might find some replacements? I suppose I could
just hack in a single diode (assuming I can determine the specs) but that seems kind of
ugly...
Great, thank goodness it looks like a diode problem and not a matrix-wire.
I looked into the diode packs back during the earlier discussion, the best match I found
(based on pinout) for the address-wire current-steering diode pairs (14-pin DIP) was:
TID125, TID126
http://www.datasheetarchive.com/dl/Scans-026/ScansUX10116.pdf
The DEC schematic indicates the pair-pins but doesn't seem to indicate the two
common-anode/cathode pins on the packages, the TID125/126 I think were the only type(s)
from the above page that made sense.
( DEC schematic: page 134 of 1105_RevAH_Engineering_Drawings_Jul76 from bitsavers, sheet
2 of H214-0-1 ).
There's a small chance I might have a replacement or equiv on a scrap board.
Worst case - should be able to use a couple of discrete diodes to sub for the bad ones if
you can ensure the bad ones are out-of-circuit.
27 Sep
27 Sep
6:44 a.m.
On 9/23/2014 9:15 PM, Josh Dersch wrote:
On 9/22/2014 11:16 PM, Brent Hilpert wrote:
> On 2014-Sep-22, at 9:49 PM, Josh Dersch wrote:
>> Thanks to Brent's writeup and DEC's documentation (both of which
>> are well written and relatively easy to understand) I'm pretty sure
>> I've traced down the fault to a diode on the core plane board
>> (H214), contained within a DIP package designated as a DEC 2501.
>>
>> Of course, I don't have any of these going spare (and I'm not sure
>> if there are equivalents -- I have yet to find a datasheet). Anyone
>> have any information about these, have any (good) spares, or know
>> where I might find some replacements? I suppose I could just hack in
>> a single diode (assuming I can determine the specs) but that seems
>> kind of ugly...
> Great, thank goodness it looks like a diode problem and not a
> matrix-wire.
So, it looks like I made a mistake here. I was double-checking my work
this evening (in preparation to remove the supposedly faulty chip and
install a socket) and the diodes in the 2501 at E22 all seemed to test
out fine. I don't know how this came out bad before, I must have had a
bad contact or something with my DVM's probes. (Or I was tired and it
was late and...)
Further investigation reveals that the connection between FD1 on the
card edge connector (the XS05 signal) and pin 7 of the 2501 at E22 is
broken. This, I believe, is a matrix wire (or "magnet wire" from the
engineering drawings) meaning that I've got a broken wire somewhere in
the core mat.
I'm guessing that this means game over for this particular board. I've
looked really really closely at the solder pads around the edges of the
core mat and I don't see anything obviously hanging loose, but I could
probably use a larger magnifying glass :). Even if there was something,
I'd be nervous about making it worse, my fine soldering skills are not
up to this sort of thing...
Any suggestions? Time to start looking for a replacement H214?
Thanks,
Josh
8:53 a.m.
On Sat, Sep 27, 2014 at 12:44 AM, Josh Dersch <derschjo at gmail.com> wrote:
I'm guessing that this means game over for this
particular board. [...]
Even if there was something, I'd be
nervous about making it worse,
If the alternative is giving up on it, then why worry so much about
making it worse?
Unless you think you can make big bucks selling it on eBay, but making
it functionally
worse presumably won't affect that.
9:15 p.m.
On Sat, Sep 27, 2014 at 12:44 AM, Josh Dersch <derschjo at gmail.com> wrote:
Well, you migth get the skills to fix it later on. Or somebody else might
have a go at it. And in both vases, they mgith well be able to fix the
original problem, but not the board after you've made it worse.
-tony
I'm guessing that this means game over for
this particular board. [...]
Even if there was something, I'd be
nervous about making it worse,
If the alternative is giving up on it, then why worry so much about
making it worse?
9:11 p.m.
Further investigation reveals that the connection between FD1 on the
card edge connector (the XS05 signal) and pin 7 of the 2501 at E22 is
broken. This, I believe, is a matrix wire (or "magnet wire" from the
engineering drawings) meaning that I've got a broken wire somewhere in
the core mat.
I would just trace the tracks, both visually an with an ohmmeter, from
the edge conector pin to the core mat and from the core mat to the diode
array. Just in case.
Incidneatlly, no matter what it says on the cover over the core mat, you
can take it off quite easily without damage. Just don't drop it on the
corse.
If it is the core address wire in the mat, you may have big problems.
Some of these mats had the cores cast onto the array of wires, no
pre-made cores that were threaded with the wires. In which case,
replacing the wire might be impossible.
My first throught was 'have a go anyway. If you wreck the board, well, it
doesn't work now'. And then I thoguth that no, you should treat it with
care. Even if you don't have the skill to fix it now, you might do so i
nthe future. Or somebody else might have a go. In any case, you don't
want ot make thigns worse.
-tony
28 Sep
28 Sep
4:59 a.m.
On 9/27/2014 2:11 PM, Tony Duell wrote:
I'll double check things. My inspection is not made any easier by the
amount of dust covering this thing. I dare not attempt to clean it up,
but it makes finding faults visually pretty difficult.
Further
investigation reveals that the connection between FD1 on the
card edge connector (the XS05 signal) and pin 7 of the 2501 at E22 is
broken. This, I believe, is a matrix wire (or "magnet wire" from the
engineering drawings) meaning that I've got a broken wire somewhere in
the core mat.
I would just trace the tracks, both visually an with an ohmmeter,
from
the edge conector pin to the core mat and from the core mat to the diode
array. Just in case.
Incidneatlly, no matter what it says on the cover over the core mat, you
can take it off quite easily without damage. Just don't drop it on the
corse.
If it is the core address wire in the mat, you may have big problems.
Some of these mats had the cores cast onto the array of wires, no
pre-made cores that were threaded with the wires. In which case,
replacing the wire might be impossible.
My first throught was 'have a go anyway. If you wreck the board, well, it
doesn't work now'. And then I thoguth that no, you should treat it with
care. Even if you don't have the skill to fix it now, you might do so i
nthe future. Or somebody else might have a go. In any case, you don't
want ot make thigns worse.
I do have a semi-crazy idea: The H214 I have is 8Kx18 bits (i.e.
parity). If I were to disable parity on the control boards and reroute
one of the parity-related lines for this damaged section, maybe I could
get a complete 8Kx16?
I'll have to do a bit more research...
- Josh
-tony
4:42 p.m.
I think the H214 is 8K x 16, and the H215 is the 8K x 18.
I thought about rerouting a few times, but never attempted it.
On Sat, Sep 27, 2014 at 11:59 PM, Josh Dersch <derschjo at gmail.com> wrote:
On 9/27/2014 2:11 PM, Tony Duell wrote:
Further investigation reveals that the connection
between FD1 on the
I'll double check things. My inspection is not made any easier by the
amount of dust covering this thing. I dare not attempt to clean it up, but
it makes finding faults visually pretty difficult.
card edge connector (the XS05 signal) and pin 7
of the 2501 at E22 is
broken. This, I believe, is a matrix wire (or "magnet wire" from the
engineering drawings) meaning that I've got a broken wire somewhere in
the core mat.
I would just trace the tracks, both visually an with an ohmmeter, from
the edge conector pin to the core mat and from the core mat to the diode
array. Just in case.
Incidneatlly, no matter what it says on the cover
over the core mat, you
can take it off quite easily without damage. Just don't drop it on the
corse.
If it is the core address wire in the mat, you may have big problems.
Some of these mats had the cores cast onto the array of wires, no
pre-made cores that were threaded with the wires. In which case,
replacing the wire might be impossible.
My first throught was 'have a go anyway. If you wreck the board, well, it
doesn't work now'. And then I thoguth that no, you should treat it with
care. Even if you don't have the skill to fix it now, you might do so i
nthe future. Or somebody else might have a go. In any case, you don't
want ot make thigns worse.
I do have a semi-crazy idea: The H214 I have is 8Kx18 bits (i.e.
parity). If I were to disable parity on the control boards and reroute one
of the parity-related lines for this damaged section, maybe I could get a
complete 8Kx16?
I'll have to do a bit more research...
- Josh
-tony
5:56 p.m.
On 9/28/2014 9:42 AM, Paul Anderson wrote:
I think the H214 is 8K x 16, and the H215 is the 8K x
18.
I thought about rerouting a few times, but never attempted it.
Correct, I misspoke. What I have is an H215.
- Josh
On Sat, Sep 27, 2014 at 11:59 PM, Josh Dersch <derschjo at gmail.com> wrote:
> On 9/27/2014 2:11 PM, Tony Duell wrote:
>
>> Further investigation reveals that the connection between FD1 on the
>>> card edge connector (the XS05 signal) and pin 7 of the 2501 at E22 is
>>> broken. This, I believe, is a matrix wire (or "magnet wire" from
the
>>> engineering drawings) meaning that I've got a broken wire somewhere in
>>> the core mat.
>>>
>> I would just trace the tracks, both visually an with an ohmmeter, from
>> the edge conector pin to the core mat and from the core mat to the diode
>> array. Just in case.
>>
> I'll double check things. My inspection is not made any easier by the
> amount of dust covering this thing. I dare not attempt to clean it up, but
> it makes finding faults visually pretty difficult.
>
>
>> Incidneatlly, no matter what it says on the cover over the core mat, you
>> can take it off quite easily without damage. Just don't drop it on the
>> corse.
>>
>> If it is the core address wire in the mat, you may have big problems.
>> Some of these mats had the cores cast onto the array of wires, no
>> pre-made cores that were threaded with the wires. In which case,
>> replacing the wire might be impossible.
>>
>> My first throught was 'have a go anyway. If you wreck the board, well, it
>> doesn't work now'. And then I thoguth that no, you should treat it with
>> care. Even if you don't have the skill to fix it now, you might do so i
>> nthe future. Or somebody else might have a go. In any case, you don't
>> want ot make thigns worse.
>>
> I do have a semi-crazy idea: The H214 I have is 8Kx18 bits (i.e.
> parity). If I were to disable parity on the control boards and reroute one
> of the parity-related lines for this damaged section, maybe I could get a
> complete 8Kx16?
>
> I'll have to do a bit more research...
>
> - Josh
>
>
>
>
>> -tony
>>
>>
>>
29 Sep
29 Sep
6:10 a.m.
On 9/27/2014 9:59 PM, Josh Dersch wrote:
On 9/27/2014 2:11 PM, Tony Duell wrote:
OK -- I spent a bit of time looking at the schematics for the H215 in
pursuit of my crazy plan and I was initially puzzled -- it didn't
actually look like there's hardware on the board (or the associated
control/driver logic) to actually address 18 bits. I saw the
sense/inhibit lines for bit P0 and P1 outlined, but there are no
associated diodes on the X/Y switches.
After reading through a few different sets of documentation, it turns
out that these lines are driven by an optional parity controller, the
M7259 (which, when combined with an H215, G109 and G231 makes an
MM11-LP). The M7259 apparently contains the diodes "missing" from the
H215 to drive the parity lines. Of course I don't have this board in my
11/05, which makes me wonder why it has an 18-bit core plane to begin
with...
At any rate -- I can't find a schematic for the M7259, which would help
narrow down which edge connector pins on the H215 are used for the X/Y
selectors for the additional parity bits. I could do this by process of
elimination, but just in case someone happens to have this scanned, I
figured I'd ask...
Thanks,
Josh
Incidneatlly, no matter what it says on the cover over the core mat, you
can take it off quite easily without damage. Just don't drop it on the
corse.
If it is the core address wire in the mat, you may have big problems.
Some of these mats had the cores cast onto the array of wires, no
pre-made cores that were threaded with the wires. In which case,
replacing the wire might be impossible.
My first throught was 'have a go anyway. If you wreck the board,
well, it
doesn't work now'. And then I thoguth that no, you should treat it with
care. Even if you don't have the skill to fix it now, you might do so i
nthe future. Or somebody else might have a go. In any case, you don't
want ot make thigns worse.
I do have a semi-crazy idea: The H214 I have is 8Kx18 bits (i.e.
parity). If I were to disable parity on the control boards and
reroute one of the parity-related lines for this damaged section,
maybe I could get a complete 8Kx16?
I'll have to do a bit more research...
- Josh
-tony
6:34 a.m.
A lot of DEC memory of that era used separate parity boards. The M7259 and
the M7850 were both used for these.
It is common to have parity memory with no parity board. I don't remember
if there are any jumpers on the memory boards, but if you haven't checked
it might be worth while to look into.
DEC used to get carried away with jumpers, the 11/40 is a good example. You
can add an option of take one out and have to change a half dozen jumpers
on cpu boards.
On Mon, Sep 29, 2014 at 1:10 AM, Josh Dersch <derschjo at gmail.com> wrote:
On 9/27/2014 9:59 PM, Josh Dersch wrote:
On 9/27/2014 2:11 PM, Tony Duell wrote:
OK -- I spent a bit of time looking at the schematics for the H215 in
pursuit of my crazy plan and I was initially puzzled -- it didn't actually
look like there's hardware on the board (or the associated control/driver
logic) to actually address 18 bits. I saw the sense/inhibit lines for bit
P0 and P1 outlined, but there are no associated diodes on the X/Y switches.
After reading through a few different sets of documentation, it turns out
that these lines are driven by an optional parity controller, the M7259
(which, when combined with an H215, G109 and G231 makes an MM11-LP). The
M7259 apparently contains the diodes "missing" from the H215 to drive the
parity lines. Of course I don't have this board in my 11/05, which makes
me wonder why it has an 18-bit core plane to begin with...
At any rate -- I can't find a schematic for the M7259, which would help
narrow down which edge connector pins on the H215 are used for the X/Y
selectors for the additional parity bits. I could do this by process of
elimination, but just in case someone happens to have this scanned, I
figured I'd ask...
Thanks,
Josh
Incidneatlly, no matter what it says on the cover
over the core mat, you
can take it off quite easily without damage. Just don't drop it on the
corse.
If it is the core address wire in the mat, you may have big problems.
Some of these mats had the cores cast onto the array of wires, no
pre-made cores that were threaded with the wires. In which case,
replacing the wire might be impossible.
My first throught was 'have a go anyway. If you wreck the board, well, it
doesn't work now'. And then I thoguth that no, you should treat it with
care. Even if you don't have the skill to fix it now, you might do so i
nthe future. Or somebody else might have a go. In any case, you don't
want ot make thigns worse.
I do have a semi-crazy idea: The H214 I have is 8Kx18 bits (i.e.
parity). If I were to disable parity on the control boards and reroute one
of the parity-related lines for this damaged section, maybe I could get a
complete 8Kx16?
I'll have to do a bit more research...
- Josh
-tony
9:25 a.m.
On 2014-Sep-28, at 11:10 PM, Josh Dersch wrote:
On 9/27/2014 9:59 PM, Josh Dersch wrote:
Unless I've missed something in the way this board is organized, I wouldn't expect
to see additional X/Y addressing diodes/selectors for the parity bits. The parity bits
would typically just be two extra bit-arrays woven into the existing X/Y address wires.
If you envision the cores as being in a 3-D coordinate system, where X/Y constitute the
address space and Z is the bits in a word, the board is X*Y*Z = 128*64*18.
The two parity bits added two XY planes (planes perpendicular to the Z axis), while the
bad X address line takes out one of the 128 YZ planes (planes perpendicular to the X
axis). While you have 2*64*128 'extra' cores, and only 18*64 inaccessible cores,
the extra (parity) cores are not configured/wired in a useful way for the fault.
In principle you could hack the board to swap the bad address line with the 'last'
address line, so you were just missing 64 words at the end of the 8K but the board traces
probably aren't very amenable to such rework.
Something that might be a simple hack would be to swap two entire columns in the
X-coordinate sub-matrix, to wit: swap FD1/XS05 with FK1/XS15.
It should just be swapping two traces near the connector which goes to the addressing
board.
That should move the 64-word 'hole' from 012000 up to 036000, so the board would
provide a contiguous 15KBytes/7.5KW from 0, rather than just 5KBytes/2.5KW.
As others have suggested, I'd at least try to spot the location of the (presumed)
break in the bad address wire to assess it for potential repair first.
On 9/27/2014 2:11 PM, Tony Duell wrote:
OK -- I spent a bit of time looking at the schematics for the H215 in pursuit of my crazy
plan and I was initially puzzled -- it didn't actually look like there's hardware
on the board (or the associated control/driver logic) to actually address 18 bits. I saw
the sense/inhibit lines for bit P0 and P1 outlined, but there are no associated diodes on
the X/Y switches.
After reading through a few different sets of documentation, it turns out that these
lines are driven by an optional parity controller, the M7259 (which, when combined with an
H215, G109 and G231 makes an MM11-LP). The M7259 apparently contains the diodes
"missing" from the H215 to drive the parity lines. Of course I don't have
this board in my 11/05, which makes me wonder why it has an 18-bit core plane to begin
with...
At any rate -- I can't find a schematic for the M7259, which would help narrow down
which edge connector pins on the H215 are used for the X/Y selectors for the additional
parity bits. I could do this by process of elimination, but just in case someone happens
to have this scanned, I figured I'd ask?
Incidneatlly, no matter what it says on the cover over the core mat, you
can take it off quite easily without damage. Just don't drop it on the
corse.
If it is the core address wire in the mat, you may have big problems.
Some of these mats had the cores cast onto the array of wires, no
pre-made cores that were threaded with the wires. In which case,
replacing the wire might be impossible.
My first throught was 'have a go anyway. If you wreck the board, well, it
doesn't work now'. And then I thoguth that no, you should treat it with
care. Even if you don't have the skill to fix it now, you might do so i
nthe future. Or somebody else might have a go. In any case, you don't
want ot make thigns worse.
I do have a semi-crazy idea: The H214 I have is 8Kx18 bits (i.e. parity). If I were to
disable parity on the control boards and reroute one of the parity-related lines for this
damaged section, maybe I could get a complete 8Kx16?
I'll have to do a bit more research...
- Josh
6:21 p.m.
On Mon, Sep 29, 2014 at 2:25 AM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
On 2014-Sep-28, at 11:10 PM, Josh Dersch wrote:
pursuit of
my crazy plan and I was initially puzzled -- it didn't actually
look like there's hardware on the board (or the associated control/driver
logic) to actually address 18 bits. I saw the sense/inhibit lines for bit
P0 and P1 outlined, but there are no associated diodes on the X/Y switches.
Thanks, that makes sense and I can see from the way things are set up that
you're probably right that this isn't going to help. Ah, all those cores
going to waste :).
On 9/27/2014 9:59 PM, Josh Dersch wrote:
> On 9/27/2014 2:11 PM, Tony Duell wrote:
>
>
>>
>> Incidneatlly, no matter what it says on the cover over the core mat,
you
>> can take it off quite easily without
damage. Just don't drop it on the
>> corse.
>>
>> If it is the core address wire in the mat, you may have big problems.
>> Some of these mats had the cores cast onto the array of wires, no
>> pre-made cores that were threaded with the wires. In which case,
>> replacing the wire might be impossible.
>>
>> My first throught was 'have a go anyway. If you wreck the board, well,
it
>> doesn't work now'. And then I
thoguth that no, you should treat it with
>> care. Even if you don't have the skill to fix it now, you might do so i
>> nthe future. Or somebody else might have a go. In any case, you don't
>> want ot make thigns worse.
>
> I do have a semi-crazy idea: The H214 I have is 8Kx18 bits (i.e.
parity). If
I were to disable parity on the control boards and reroute one
of the parity-related lines for this damaged section, maybe I could get a
complete 8Kx16?
I'll have to do a bit more research...
- Josh
OK -- I spent a bit of time looking at the schematics for the H215 in
After reading through a few different sets of documentation, it turns
out that
these lines are driven by an optional parity controller, the M7259
(which, when combined with an H215, G109 and G231 makes an MM11-LP). The
M7259 apparently contains the diodes "missing" from the H215 to drive the
parity lines. Of course I don't have this board in my 11/05, which makes
me wonder why it has an 18-bit core plane to begin with...
At any rate -- I can't find a schematic for the M7259, which would help
narrow
down which edge connector pins on the H215 are used for the X/Y
selectors for the additional parity bits. I could do this by process of
elimination, but just in case someone happens to have this scanned, I
figured I'd ask?
Unless I've missed something in the way this board is organized, I
wouldn't expect to see additional X/Y addressing diodes/selectors for the
parity bits. The parity bits would typically just be two extra bit-arrays
woven into the existing X/Y address wires.
If you envision the cores as being in a 3-D coordinate system, where X/Y
constitute the address space and Z is the bits in a word, the board is
X*Y*Z = 128*64*18.
The two parity bits added two XY planes (planes perpendicular to the Z
axis), while the bad X address line takes out one of the 128 YZ planes
(planes perpendicular to the X axis). While you have 2*64*128 'extra'
cores, and only 18*64 inaccessible cores, the extra (parity) cores are not
configured/wired in a useful way for the fault.
In principle you could hack the board to swap the bad address line with
the 'last' address line, so you were just missing 64 words at the end of
the 8K but the board traces probably aren't very amenable to such rework.
Something that might be a simple hack would be to swap two entire columns
in the X-coordinate sub-matrix, to wit: swap FD1/XS05 with FK1/XS15.
It should just be swapping two traces near the connector which goes to the
addressing board.
That should move the 64-word 'hole' from 012000 up to 036000, so the board
would provide a contiguous 15KBytes/7.5KW from 0, rather than just
5KBytes/2.5KW.
Right, I'd considered that as a last-ditch sort of thing, if the wire
cannot be repaired.
As others have suggested, I'd at least try to spot the location of the
(presumed) break in the bad address wire to assess it for potential repair
first.
I'll give it another go -- as I said in an earlier mail, the wires around
the edges of the core mat are difficult to discern because of the rather
large accumulation of dust in some places. The stuff it's stuck to is so
delicate I don't want to attempt to touch it unless I have to. Also, maybe
I missed it, but is there any way to map the numbered matrix wires on the
H214 schematic to a position on the edge of the mat? For some of the wires
it's obvious what PCB trace it connects to, for others not so much. Pin 7
of E22 is one such trace, it appears to go under the mat and from there
it's difficult to trace :).
Thanks for all the help,
Josh
6 Sep
6 Sep
10: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 
4:01 p.m.
Brent,
On Sat, Sep 6, 2014 at 2:53 AM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
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
I read your linked article - very enjoyable, informative and
clearly-written piece. You really managed to pack a lot of interesting
detail into it, and the diagrams are quite good. The details on actual
physical topologies (and functional electrical layouts, with actual write /
sense amplifier designs), the weaving together of bit-planes into words and
finally modules are something I haven't come across on-line before.
A thought.. if you still have access to the hardware cited in the article,
it would be neat if you could add another column or two to the table fig.11
- one for volume, one for mass.. just for amusement purposes. ;-)
One lingering question though.. why on earth were the big iron
manufacturers still building massive core memories as recently as the late
1970s? As early as the mid-1980s, 64K of (faster!) SRAM could be bought for
around a hundred dollars. Clearly these core modules are orders of
magnitude more costly.. so why were they still being produced? It can't
only be a matter of their non-volatility?
5:01 p.m.
On Sep 6, 2014, at 12:01 PM, drlegendre . <drlegendre at gmail.com> wrote:
Brent,
On Sat, Sep 6, 2014 at 2:53 AM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
I?ll second that.
On unusual memory designs: CDC mainframes used 5 wires: two inhibit wires instead of one,
and the inhibits were split in quarters. I suspect that was to keep the inductance seen
by all the various types of drivers reasonably close, and fairly low, for speed. 1
microsecond full cycle was a whole lot faster than usual for 1964, when those systems
first appeared.
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
I read your linked article - very enjoyable, informative and
clearly-written piece.
One lingering question though.. why on earth were the big iron
manufacturers still building massive core memories as recently as the late
1970s? As early as the mid-1980s, 64K of (faster!) SRAM could be bought for
around a hundred dollars. Clearly these core modules are orders of
magnitude more costly.. so why were they still being produced? It can't
only be a matter of their non-volatility?
Through at least the late 1970s core memory was the modest performance low cost option,
with DRAM the up and coming new thing and SRAM the high cost option when speed was
required at any price. For example, the DEC PDP11/45 with core memory, and 11/55 with
SRAM ? same basic system just different memories.
In some applications, the fact that core is basically impervious to radiation was a
consideration too.
paul
29 Sep
29 Sep
2:23 a.m.
On Sat, Sep 6, 2014 at 12:53 AM, Brent Hilpert <hilpert at cs.ubc.ca> wrote:
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
Really nice write up. I'd like to add one note however.
Towards the end you state "They don't get smaller than that required by a
simple calculator, ....". However there was a very common device made from
the mid '50s to mid 70s that used a 10 x 10 array of cores; the Jukebox.
Seeburg was a major Jukebox vendor of the era. It used the "Tormat"
selection system. Basically the average Jukebox had 50 records or 100
selections (a record having two sides). One core was used per selection.
The cores were set using basic 2D selection but no decoders were needed.
Rather the front of the unit had 10 letter keys (A-H) and 10 number keys
(1-10). After coughing up a dime the user pressed a letter and a number to
select a record then a core was selected via the 10 row and 10 column
select lines.
Reading back was done when the unit was searching for its' next record.
Each core had a private winding that had one side grounded and the other
connected to a pin. As the unit scanned each pin was mechanically
contacted and the core was pulsed. A common sense line went through all
100 cores. If the sense line detected a flip a solenoid was fired that
caused the record unit to stop moving left to right (or right to left) and
grab a record and play it.
The cores used were huge. Here's a picture
http://members.home.nl/schniermanni/seeburg/matrix.jpg .
Marc
6 Sep
6 Sep
7:57 p.m.
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
Maybe, maybe not.
You ahve 8192 words of core IRIC. That's 2^13. An obvious way to address
that is as a128*64 matrix (2^6 by 2^7).
Now, if one of the '64 diriection' drives has fialed, 128 words of core
would be inaccessible. And t may well appear to be a contiguous block, it
depends on how the addressing is done.
I would certainly check the address drvers first, they ara a lot easier
to fix than core planes.
-tony
4059
days inactive
4082
days old
23 comments
8 participants
participants (8)
-
ardï¼ p850ug1.demon.co.uk -
cramcramï¼ gmail.com -
derschjoï¼ gmail.com -
drlegendreï¼ gmail.com -
hilpertï¼ cs.ubc.ca -
paulkoningï¼ comcast.net -
spacewarï¼ gmail.com -
useddecï¼ gmail.com