12 Feb
2019
12 Feb
'19
12:51 p.m.
Likely some disk controllers did NOT SUPPORT crossing
64K boundaries!
No; the RK11 spec says "[the two extended memory bits] make up a two-bit
counter that increments each time the RKBA overflows".
The actual error turns out to be slightly different to my guess; there's
a spurious overflow from the low 16-bit register to these bits at 0170000. 
12 Feb
12 Feb
11:43 p.m.
SUCCESS!!
Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a
logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced,
and off she goes!
I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.
*THAT* was a really fun and rewarding hunt :-) First message in the thread was back on
Dec 30, 2018. Lots of debugging and failed DRAM repairs, then the final long assault to
this single, failed gate...
Thanks to all here for the help and resources, and particular shout-outs for Noel and Paul
who gave generously of their time and attention working through the densest bits, both on
and off the list.
I predict a long happy weekend and a big power bill at the end of the month :-)
cheers,
--FritzM.
13 Feb
13 Feb
5:34 a.m.
On Feb 13, 2019, at 2:43 AM, Fritz Mueller via cctalk
<cctalk at classiccmp.org> wrote:
SUCCESS!!
Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a
logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced,
and off she goes!
I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.
Congratulations. You have successfully performed a repair of the type done at customer
sites by highly trained DEC field service personnel. They were the ones who traveled with
an oscilloscope, a tool case including soldering iron, and a case full of replacement
chips.
One difference is that the diagnostics didn't point to the problem, which in my
experience is rather an unusual situation. Nicely done.
paul
7:56 a.m.
On 02/13/2019 01:43 AM, Fritz Mueller via cctalk wrote:
SUCCESS!!
Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a
logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced,
and off she goes!
WOW! Good detective work, that certainly was a WEIRD
problem, and not where I thought it was going to be.
Glad you got it solved!
Jon
10:20 a.m.
On 2/13/2019 1:43 AM, Fritz Mueller via cctalk wrote:
SUCCESS!!
Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a
logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced,
and off she goes!
I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.
*THAT* was a really fun and rewarding hunt :-) First message in the thread was back on
Dec 30, 2018. Lots of debugging and failed DRAM repairs, then the final long assault to
this single, failed gate...
Thanks to all here for the help and resources, and particular shout-outs for Noel and
Paul who gave generously of their time and attention working through the densest bits,
both on and off the list.
I predict a long happy weekend and a big power bill at the end of the month :-)
cheers,
--FritzM.
Congratulations. As another poster mentioned, it has been fascinating
to watch and learn, day by day, as you worked on the problem with Noel
and Paul's help.
And I learned a little bit more about my 11/45 (that it indeed had had a
processor field upgrade), which I had not looked at very closely before.
Maybe that story about FE's using Unix as a test to confirm operation
even when diagnostics said the machine was OK was not so much just a
legend?
12:03 p.m.
On Feb 13, 2019, at 1:20 PM, Jay Jaeger via cctalk
<cctalk at classiccmp.org> wrote:
...
Maybe that story about FE's using Unix as a test to confirm operation
even when diagnostics said the machine was OK was not so much just a
legend?
It still fels like a legend. My experience with DEC field service engineers is that they
used the diagnostics. In the PDP-11 era, Unix knowledge around DEC was pretty sparse,
especially early on when it could be found only in the Telephone Products Group (Armando
Stettner). RSTS would be more plausible, but I never saw that in the hads of FS engineers
either.
By and large diagnostics would find problems. I've seen a number in the 1970s,
including a messy data path failure in the 11/45 MMU where we (college students) did the
initial diagnosis while the FS engineer was on his way.
My suspicion is that things not solved by diagnostics would be escalated to the
"wizard from Maynard". And they'd probably start replacing whole
subsystems. I've seen that once, when our college RSTS-11 system (11/20, 16 DL-11
lines) was crashing on average once a day for months. DEC brought in several of those
"wizards". The "fix" was to replace the 11/20 by a "spare
part" -- an 11/45 with more memory, a DH11, and RSTS/E.
Decades later I was told that the wizards actually pinned the blame on the college FM
broadcast transmitter, about 200 feet down the hall from the computer center. That may
well be, though I didn't heard that at the time.
RSTS did get used in manufacturing, at Final Assembly & Test sites like Westminster MA
and Salem NH, where PDP-11 systems large enough to run RSTS/E were subjected to a load
test of exerciser programs running under that OS. The way it was explained to us is that
a system that would be happy with such a test would also be happy with any customer
application. It's not clear if that was because RSTS would load things more than
most, or was more finicky about hardware glitches than most, but it certainly was the
practice for quite some time. Of course, not all PDP-11 configurations could be tested
that way.
paul
4:44 p.m.
On Feb 13, 2019, at 3:03 PM, Paul Koning
<paulkoning at comcast.net> wrote:
...
My suspicion is that things not solved by diagnostics would be escalated to the
"wizard from Maynard". And they'd probably start replacing whole
subsystems.
This says that Fritz actually was a new "Wizard from Maynard" in solving this
problem. Only more so -- because he didn't have the luxury of just swapping out whole
sections of the machine with new kits, or a backup team of subsystem experts at the home
office to call on.
That confirms it's really a very impressive performance.
paul
12:54 p.m.
On Wed, Feb 13, 2019 at 2:43 AM Fritz Mueller via cctalk
<cctalk at classiccmp.org> wrote:
SUCCESS!!
Outstanding!
Put the M795 out on an extender, loaded 167777 in
RKBAR, and had a look around with a logic probe. Narrowed it down to E34 (a 7430 8-input
NAND). Pulled, socketed, replaced, and off she goes!
I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.
Nice.
I have had an RK11-C for a long time that I've never tried to power up
(I got an RKV11-D and used that on Qbus machines instead). The saga
has been interesting for me as I contemplate getting mine working in
the next couple of years. I had to look up the M795. I had forgotten
there was one dual-height module in the entire controller.
It's interesting that it was a bad 7430 in yours. I find that for
equipment of that vintage, my usual suspects are failed 7474s and
failed 7440s, probably 80% of the total. Behind that, it goes 7420s
and then maybe 7430s.
-ethan
1:02 p.m.
On Feb 13, 2019, at 3:54 PM, Ethan Dicks via cctalk
<cctalk at classiccmp.org> wrote:
...
It's interesting that it was a bad 7430 in yours. I find that for
equipment of that vintage, my usual suspects are failed 7474s and
failed 7440s, probably 80% of the total. Behind that, it goes 7420s
and then maybe 7430s.
When our 11/45 failed in the MMU in 1975, my classmate Josh Rosen traced the failing path
on the schematics. When Jim Newport the field service engineer showed up, Josh described
the diagnostics result that pointed at the failed path, and added "This is the failed
chip" (pointing to one particular chip.
Jim asked "Why that one?" Josh answered "because that is the most
expensive chip".
It turned out he was right.
paul
5:20 p.m.
On 2/13/19 1:43 AM, Fritz Mueller via cctalk wrote:
SUCCESS!!
Put the M795 out on an extender, loaded 167777 in RKBAR, and had a look around with a
logic probe. Narrowed it down to E34 (a 7430 8-input NAND). Pulled, socketed, replaced,
and off she goes!
I can now successfully boot and run both V6 Unix and RSTS/E V06C from disk.
*THAT* was a really fun and rewarding hunt :-) First message in the thread was back on
Dec 30, 2018. Lots of debugging and failed DRAM repairs, then the final long assault to
this single, failed gate...
Thanks to all here for the help and resources, and particular shout-outs for Noel and
Paul who gave generously of their time and attention working through the densest bits,
both on and off the list.
I predict a long happy weekend and a big power bill at the end of the month :-)
cheers,
--FritzM.
Congratulations.? Well Done.
I am trying to understand how the diagnostics didn't reveal this
defect.? I see in the source for the diagnostic DZRKH-F there are tests
for address in the 28K-32K range and also for the 32K boundary.
I'm trying to make sense of the M795 to get a better understanding. Any
addition data on how the 7430 failed (input bad, output bad, etc ?)
? Jerry
6:18 p.m.
On 2/13/19 5:20 PM, Jerry Weiss wrote:
I am trying to understand how the diagnostics
didn't reveal this
defect.? I see in the source for the diagnostic DZRKH-F there are tests
for address in the 28K-32K range and also for the 32K boundary.
So, to catch this defect the diagnostic would have to have a test or
tests which crossed _specifically_ the 30K boundary within a transfer.
The detailed symptom was a false overflow into the ex.mem bits on the
30K boundary, causing a skip forward in bus addresses during the transfer.
The detailed fail on the 7430 (E34 on the M795) was that it acted as if
input pin 11 was always H.
Now, all this said, I don't think I have ever run ZRKH! I *did* run and
pass the earlier ZRKA, ZRKB, and ZRKC, but somehow missed ZRKH... I'm
wondering now how different it is from ZRKC? Will have to take a look...
--FritzM.
2139
days inactive
2141
days old
10 comments
7 participants
participants (7)
-
cube1＠charter.net -
elson＠pico-systems.com -
ethan.dicks＠gmail.com -
frisbie＠flying-disk.com -
fritzm＠fritzm.org -
jsw＠ieee.org -
paulkoning＠comcast.net