31 Jan
2021
31 Jan
'21
5:31 p.m.
Hi all --
Making some progress with the "fire sale" PDP-11/70. Over the past month
I've rebuilt the power supplies and burned them in on the bench, and I've
gotten things cleaned up and reassembled. I'm still waiting on some new
chassis fans but my curiosity overwhelmed my caution and I decided to power
it up for a short time (like 30 seconds) just to see what happens. Good
news: no smoke or fire. Voltages look good (need a tiny bit of adjustment
yet) and AC LO and DC LO looked good everywhere I tested them. Bad news:
processor is almost entirely unresponsive; comes up with the RUN and MASTER
lights on, toggling Halt, and hitting Start causes the RUN light to go out,
but that's the only response I get from the console.
I got out the KM11 boardset and with that installed I can step through
microinstructions and it's definitely executing them, and seems to be
following the flow diagrams in the engineering drawings. Left to its own
devices, however, the processor doesn't seem to be executing
microinstructions at all, it's stuck at uAddress 200.
In the troubleshooting section of the 11/70 service docs (diagram on p.
5-16) it states:
IF LOAD ADRS DOES NOT WORK AND:
- RUN, MASTER & ALL DATA INDICATORS ARE ON
- uADRS = 200 (ZAP)
THEN MEMORY HAS LOST POWER
Which seems to adequately describe the symptoms I'm seeing, but as far as I
can tell the AC and DC LO signals are all fine. (This system has a Setasi
PEP70/Hypercache installed, so there's no separate memory chassis to worry
about.) I'm going to go back and re-check everything, but I was curious if
anyone knows whether loss of AC or DC would prevent the processor from
executing microcode -- from everything I understand it should cause a trap,
and I don't see anything in the docs about inhibiting microcode execution.
But perhaps if this happens at power-up things behave differently? And the
fact that the troubleshooting flowchart calls out these exact symptoms
would seem to indicate that this is expected. But I'm curious why the KM11
can step the processor, in this case.
I'm going to wait until the new fans arrive (hopefully tomorrow or tuesday)
before I poke at this again, just looking for advice here on the off chance
anyone's seen this behavior before.
Thanks as always!
- Josh
31 Jan
31 Jan
5:38 p.m.
Did you check to make sure that power is wired correctly to the
PEP-70/Hypercache?? They are typically installed in "empty" slots and
don't have power (or anything else) routed to them.? They require some
additional jumpers to be installed on the backplane so that they get power.
On 1/31/21 2:31 PM, Josh Dersch via cctalk wrote:
Hi all --
Making some progress with the "fire sale" PDP-11/70. Over the past month
I've rebuilt the power supplies and burned them in on the bench, and I've
gotten things cleaned up and reassembled. I'm still waiting on some new
chassis fans but my curiosity overwhelmed my caution and I decided to power
it up for a short time (like 30 seconds) just to see what happens. Good
news: no smoke or fire. Voltages look good (need a tiny bit of adjustment
yet) and AC LO and DC LO looked good everywhere I tested them. Bad news:
processor is almost entirely unresponsive; comes up with the RUN and MASTER
lights on, toggling Halt, and hitting Start causes the RUN light to go out,
but that's the only response I get from the console.
I got out the KM11 boardset and with that installed I can step through
microinstructions and it's definitely executing them, and seems to be
following the flow diagrams in the engineering drawings. Left to its own
devices, however, the processor doesn't seem to be executing
microinstructions at all, it's stuck at uAddress 200.
In the troubleshooting section of the 11/70 service docs (diagram on p.
5-16) it states:
IF LOAD ADRS DOES NOT WORK AND:
- RUN, MASTER & ALL DATA INDICATORS ARE ON
- uADRS = 200 (ZAP)
THEN MEMORY HAS LOST POWER
Which seems to adequately describe the symptoms I'm seeing, but as far as I
can tell the AC and DC LO signals are all fine. (This system has a Setasi
PEP70/Hypercache installed, so there's no separate memory chassis to worry
about.) I'm going to go back and re-check everything, but I was curious if
anyone knows whether loss of AC or DC would prevent the processor from
executing microcode -- from everything I understand it should cause a trap,
and I don't see anything in the docs about inhibiting microcode execution.
But perhaps if this happens at power-up things behave differently? And the
fact that the troubleshooting flowchart calls out these exact symptoms
would seem to indicate that this is expected. But I'm curious why the KM11
can step the processor, in this case.
I'm going to wait until the new fans arrive (hopefully tomorrow or tuesday)
before I poke at this again, just looking for advice here on the off chance
anyone's seen this behavior before.
Thanks as always!
- Josh
--
TTFN - Guy
5:56 p.m.
On Sun, Jan 31, 2021 at 2:39 PM Guy Sotomayor via cctalk <
cctalk at classiccmp.org> wrote:
Did you check to make sure that power is wired
correctly to the
PEP-70/Hypercache? They are typically installed in "empty" slots and
don't have power (or anything else) routed to them. They require some
additional jumpers to be installed on the backplane so that they get power.
Yes, it's wired up (Don't know who did the installation, but I'm assuming
it was operational at some point). There are four large black jumper wires
leading from slot 18 to slot 19, matching the instructions in the PEP70
installation manual.
Thanks,
Josh
8:05 p.m.
Hi Josh,
ZAP is effectively reset for the micro-architecture, forcing the ucode address to
known/initial value. It has multiple sources throughout the processor, including tendrils
into some of trap handling hardware. (Caveat: my experience is based off extensive work
with the '11/45, but the micro-architecture as I understand it for the '11/70 is
quite similar.)
For the '45, there was a very handy "KB11-A,D Maintenance Manual", which
explained the logic of such internal signals and the board by board internal operation of
the CPU to a very useful level of detail; I'm sure similar is available for the
KB11-B,C? It's worth a read through if you haven't already, though its quite a
bit to take in.
I would imagine the next step would be to throw the RAC board out on extenders, verify
that ZAP is asserted, and if so pursue the driving source.
Do you know if you have a KB11-B or C?
Happy hunting!
--FritzM.
9:05 p.m.
On Sun, Jan 31, 2021 at 5:05 PM Fritz Mueller via cctalk <
cctalk at classiccmp.org> wrote:
Hi Josh,
ZAP is effectively reset for the micro-architecture, forcing the ucode
address to known/initial value. It has multiple sources throughout the
processor, including tendrils into some of trap handling hardware. (Caveat:
my experience is based off extensive work with the '11/45, but the
micro-architecture as I understand it for the '11/70 is quite similar.)
Yeah, ZAP seems to be the entry point at power-up as well as for trap
handling.
For the '45, there was a very handy "KB11-A,D
Maintenance Manual", which
explained the logic of such internal signals and the board by board
internal operation of the CPU to a very useful level of detail; I'm sure
similar is available for the KB11-B,C? It's worth a read through if you
haven't already, though its quite a bit to take in.
Yes, there's a similar doc. The engineering drawings include the flow
diagrams for the microcode, and the Processor Manual (
http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf)
goes into details on the rest. I started digesting all of this last night,
it's going to take awhile :).
I would imagine the next step would be to throw the RAC board out on
extenders, verify that ZAP is asserted, and if so pursue the driving source.
Yeah. I want to get the fans installed and then go triple-check all the
power signals and get the voltages dialed in nicely. But then things come
out on extenders :).
Do you know if you have a KB11-B or C?
It's a KB11-C.
Happy hunting!
Thanks, it'll be interesting for sure.
- Josh
--FritzM.
10:04 p.m.
Yeah. I want to get the fans installed and then go
triple-check all the power signals and get the voltages dialed in nicely. But then things
come out on extenders :).
Yup -- I'm surprised how picky my '45 is about +5 undervolt; it really seems
happiest with trimmed up to about 5.1 at the backplane.
Looks like E106 on the RAC (M8123) might be a good place to start (drawing RACA, lower
left.)
cheers,
--FritzM.
10:55 p.m.
On Sun, Jan 31, 2021 at 7:04 PM Fritz Mueller via cctalk <
cctalk at classiccmp.org> wrote:
I was just looking in chapter 4 of the processor manual to learn more about
how the processor clocks are generated on the M8139 (TIG) board; on page
II-4-2 (p. 136 in the PDF on Bitsavers) section 4.1.3 it says:
"The third source of timing [the other two being the crystal clock and a
diagnostic R/C network] is the manually-operated, single-step MAINT STPR
switch S4, located on the maintenance card. This switch is only enabled
when maintenance card switches S2 and S3 are both set to 1."
Section 4.2.3 confirms this:
"The maintenance card S2 and S1 switches are both set to 1 to allow single
timing pulses to be generated by MAINT STPR switch S4.... Removing the S2
or S1 input conditions the MS EN flip-flop to be cleared."
Well, what's interesting here is that on my system, switch S4 (MAINT STPR)
steps the processor with switches S1 and S2 set to *any* configuration.
Tried it with the other KM11 I have, same behavior. This being the case, I
wonder if the logic that selects the clock source is faulty, and is always
selecting the MAINT STPR input. This would definitely explain the behavior
I'm seeing. I hope the fans arrive tomorrow so I can start debugging this
:).
- Josh
Yeah. I want
to get the fans installed and then go triple-check all the
power signals and get
the voltages dialed in nicely. But then things come
out on extenders :).
Yup -- I'm surprised how picky my '45 is about +5 undervolt; it really
seems happiest with trimmed up to about 5.1 at the backplane.
Looks like E106 on the RAC (M8123) might be a good place to start (drawing
RACA, lower left.)
cheers,
--FritzM.
11:19 p.m.
On Sun, Jan 31, 2021 at 7:55 PM Josh Dersch <derschjo at gmail.com> wrote:
On Sun, Jan 31, 2021 at 7:04 PM Fritz Mueller via
cctalk <
cctalk at classiccmp.org> wrote:
I was just looking in chapter 4 of the processor manual to learn more
about how the processor clocks are generated on the M8139 (TIG) board; on
page II-4-2 (p. 136 in the PDF on Bitsavers) section 4.1.3 it says:
"The third source of timing [the other two being the crystal clock and a
diagnostic R/C network] is the manually-operated, single-step MAINT STPR
switch S4, located on the maintenance card. This switch is only enabled
when maintenance card switches S2 and S3 are both set to 1."
Section 4.2.3 confirms this:
"The maintenance card S2 and S1 switches are both set to 1 to allow single
timing pulses to be generated by MAINT STPR switch S4.... Removing the S2
or S1 input conditions the MS EN flip-flop to be cleared."
Well, what's interesting here is that on my system, switch S4 (MAINT STPR)
steps the processor with switches S1 and S2 set to *any* configuration.
Tried it with the other KM11 I have, same behavior. This being the case, I
wonder if the logic that selects the clock source is faulty, and is always
selecting the MAINT STPR input. This would definitely explain the behavior
I'm seeing. I hope the fans arrive tomorrow so I can start debugging this
:).
Ah, and page II-6-20 (p. 178) indicates that when DCLO is asserted, it
asserts:
"UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops and clears the
Timing Generator and the Cache timing."
I suppose that this is the more likely explanation for the behavior here
and that the maintenance card behavior is a side-effect of this. Time to
actually probe things, rather than speculating...
- Josh
Yeah. I
want to get the fans installed and then go triple-check all
the power signals and
get the voltages dialed in nicely. But then things
come out on extenders :).
Yup -- I'm surprised how picky my '45 is about +5 undervolt; it really
seems happiest with trimmed up to about 5.1 at the backplane.
Looks like E106 on the RAC (M8123) might be a good place to start
(drawing RACA, lower left.)
- Josh
>
> cheers,
> --FritzM.
>
>
>
>
1 Feb
1 Feb
1:03 a.m.
On Jan 31, 2021, at 8:19 PM, Josh Dersch <derschjo
at gmail.com> wrote:
Well, what's interesting here is that on my system, switch S4 (MAINT STPR) steps the
processor with switches S1 and S2 set to *any* configuration.
Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 S1:1 step by clock
phase. The other two settings should free run the microcode. So yeah, sounds like
something fishy there... The TIG card has more than a few analog components, and its not
too unusual for these to get hung up on the adjacent card and have a leg pulled or sheared
from the board.
Ah, and page II-6-20 (p. 178) indicates that when DCLO
is asserted, it asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00 (200), and stops
and clears the Timing Generator and the Cache timing."
Yup, that's one of the signals coming in to RAC E106. Probing there should indicate
which of possible sources for ZAP is actually occurring (UBCE ROM INIT H on pins 2 and 3
there).
DCLO is a classic... Make sure to 'scope it, because it sometimes has troublesome
spikes that don't show on a multimeter. If you have H742s, there are some wet
tantalums on the control board that sometimes leak and cause trouble with this.
I'm sure you are raring to go -- hope those fans show up for you tomorrow, and will be
interested to hear what you find!
--FritzM.
2 Feb
2 Feb
3:30 a.m.
On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller <fritzm at fritzm.org> wrote:
Small update; fans arrived today and they are now installed. Voltages
tested on the backplane at the points called out in the service docs, and
all voltages dialed in to 5.05V. Ripple is within tolerances -- about
200mV with some very short spikes that barely show up on my 'scope that go
to 300mV or so. Not sure if this is abnormal, I also saw these while
burning the supplies in on the bench.
Checked the AC LO and DC LO signals at all the points called out in figure
6-12 (p. II-6-22 of
http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf)
and appear to be correct. Looked at most of them under the scope and no
spikes (other than those in the ripple from the power supply.)
Tomorrow I'll get some boards out on extenders and take a look at what's
going on at the logic level.
- Josh
On Jan 31, 2021, at 8:19 PM, Josh Dersch
<derschjo at gmail.com> wrote:
Well, what's interesting here is that on my system, switch S4 (MAINT
STPR)
steps the processor with switches S1 and S2 set to *any*
configuration.
Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1 S1:1
step by clock phase. The other two settings should free run the
microcode. So yeah, sounds like something fishy there... The TIG card has
more than a few analog components, and its not too unusual for these to get
hung up on the adjacent card and have a leg pulled or sheared from the
board.
Ah, and page II-6-20 (p. 178) indicates that when
DCLO is asserted, it
asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00
(200), and stops and
clears the Timing Generator and the Cache timing."
Yup, that's one of the signals coming in to RAC E106. Probing there
should indicate which of possible sources for ZAP is actually occurring
(UBCE ROM INIT H on pins 2 and 3 there).
DCLO is a classic... Make sure to 'scope it, because it sometimes has
troublesome spikes that don't show on a multimeter. If you have H742s,
there are some wet tantalums on the control board that sometimes leak and
cause trouble with this.
I'm sure you are raring to go -- hope those fans show up for you tomorrow,
and will be interested to hear what you find!
--FritzM.
3 Feb
3 Feb
11:07 p.m.
On Tue, Feb 2, 2021 at 12:30 AM Josh Dersch <derschjo at gmail.com> wrote:
On Sun, Jan 31, 2021 at 10:03 PM Fritz Mueller <fritzm at fritzm.org> wrote:
Small update; fans arrived today and they are now installed. Voltages
tested on the backplane at the points called out in the service docs, and
all voltages dialed in to 5.05V. Ripple is within tolerances -- about
200mV with some very short spikes that barely show up on my 'scope that go
to 300mV or so. Not sure if this is abnormal, I also saw these while
burning the supplies in on the bench.
Checked the AC LO and DC LO signals at all the points called out in figure
6-12 (p. II-6-22 of
http://bitsavers.org/pdf/dec/pdp11/1170/EK-KB11C-TM-001_1170procMan.pdf)
and appear to be correct. Looked at most of them under the scope and no
spikes (other than those in the ripple from the power supply.)
Tomorrow I'll get some boards out on extenders and take a look at what's
going on at the logic level.
Another quick update: Had some time last night to poke at things. I
started with the TIG, since I wanted to see if the crystal clock was
running at all and if the right clock source was being selected. Sure
enough, TIGB XTAL H was a flat line. Nothing happening at the crystal
itself either. The crystal's casing was fairly corroded (which is
interesting, since nothing else on the board is) and after a tiny bit of
prodding one of the legs fell off, so I'm hoping that's the culprit. New
crystal ordered and when it arrives we'll see...
- Josh
On Jan 31, 2021, at 8:19 PM, Josh Dersch
<derschjo at gmail.com> wrote:
Well, what's interesting here is that on my system, switch S4 (MAINT
STPR)
steps the processor with switches S1 and S2 set to *any*
configuration.
Hmm, would expect to see S2:1 S1:0 step by microinstruction, and S2:1
S1:1 step by clock phase. The other two settings should free run the
microcode. So yeah, sounds like something fishy there... The TIG card has
more than a few analog components, and its not too unusual for these to get
hung up on the adjacent card and have a leg pulled or sheared from the
board.
Ah, and page II-6-20 (p. 178) indicates that when
DCLO is asserted, it
asserts: "UBCE ROM INIT H - forces the ROM to ZAP.00
(200), and stops and
clears the Timing Generator and the Cache timing."
Yup, that's one of the signals coming in to RAC E106. Probing there
should indicate which of possible sources for ZAP is actually occurring
(UBCE ROM INIT H on pins 2 and 3 there).
DCLO is a classic... Make sure to 'scope it, because it sometimes has
troublesome spikes that don't show on a multimeter. If you have H742s,
there are some wet tantalums on the control board that sometimes leak and
cause trouble with this.
I'm sure you are raring to go -- hope those fans show up for you
tomorrow, and will be interested to hear what you find!
4 Feb
4 Feb
1:19 p.m.
On Feb 3, 2021, at 8:07 PM, Josh Dersch <derschjo
at gmail.com> wrote:
Sure enough, TIGB XTAL H was a flat line. Nothing happening at the crystal itself
either. The crystal's casing was fairly corroded (which is interesting, since nothing
else on the board is) and after a tiny bit of prodding one of the legs fell off, so
I'm hoping that's the culprit.
Ah. One of the switches on the KM11 should enable the machine to run off the separate RC
maintenance clock on the TIG, if you want to keep going before your new crystal shows up.
4:51 p.m.
On Thu, Feb 4, 2021 at 10:19 AM Fritz Mueller via cctalk <
cctalk at classiccmp.org> wrote:
Yeah, you'd think... but it doesn't work :). I mentioned earlier in this
thread that it's stuck in single-step mode. From the schematics it looks
like the crystal clock needs to be running to clock some of the flip flops
used in the "Source Synchronizer" to select the proper clock source. My
guess is that since the clock isn't running, the flip flops are left in a
weird state.
Or there's another problem here unrelated to the crystal clock. I guess
I'll see in a day or so.
- Josh
On Feb 3, 2021, at 8:07 PM, Josh Dersch
<derschjo at gmail.com> wrote:
Sure enough, TIGB XTAL H was a flat line. Nothing happening at the
crystal itself
either. The crystal's casing was fairly corroded (which is
interesting, since nothing else on the board is) and after a tiny bit of
prodding one of the legs fell off, so I'm hoping that's the culprit.
Ah. One of the switches on the KM11 should enable the machine to run off
the separate RC maintenance clock on the TIG, if you want to keep going
before your new crystal shows up.
5:42 p.m.
On Feb 4, 2021, at 1:51 PM, Josh Dersch <derschjo
at gmail.com> wrote:
[RC maintenance clock] Yeah, you'd think... but it doesn't work :). I mentioned
earlier in this thread that it's stuck in single-step mode. From the schematics it
looks like the crystal clock needs to be running to clock some of the flip flops used in
the "Source Synchronizer" to select the proper clock source. My guess is that
since the clock isn't running, the flip flops are left in a weird state.
Oh, interesting! Noted for future reference. The TIG is not exactly straightforward...
5 Feb
5 Feb
12:45 a.m.
On Thu, Feb 4, 2021 at 2:42 PM Fritz Mueller via cctalk <
cctalk at classiccmp.org> wrote:
So I realized today that, hey, I have a burned-out 11/45 in the garage, and
it has a TIG (albeit an M8109), and it also has a 33.33Mhz crystal on it.
And because I'm impatient and can't wait for my Digi-Key order to come in,
I went out and borrowed the crystal from the 11/45's TIG and installed it
in the 11/70's. The 11/70 is now somewhat operable. I can examine and
deposit memory, at least for a short while -- after the system warms up for
30 seconds or so the Load Address switch stops functioning. (Happens
gradually, too... for 10 seconds or so it works every other time you toggle
it, then it stops entirely.) Everything else seems to work properly after
this happens, so I'm kind of curious if there's an IC on the front panel
that's gone bad, though I suppose it's still completely possible it's
something on the CPU end. I'll have to do some debugging, but it'll have
to wait until this weekend.
As an aside... The M8109 is very similar looking to the M8139... any ideas
what the functional differences are? There seems to be an extra IC and
some ECO wiring on the M8139. I'll have to take a closer look someday.
- Josh
On Feb 4, 2021, at 1:51 PM, Josh Dersch
<derschjo at gmail.com> wrote:
[RC maintenance clock] Yeah, you'd think... but it doesn't work :). I
mentioned earlier in this thread that it's stuck in single-step mode. From
the schematics it looks like the crystal clock needs to be running to clock
some of the flip flops used in the "Source Synchronizer" to select the
proper clock source. My guess is that since the clock isn't running, the
flip flops are left in a weird state.
Oh, interesting! Noted for future reference. The TIG is not exactly
straightforward...
3:29 a.m.
On Feb 4, 2021, at 9:45 PM, Josh Dersch <derschjo
at gmail.com> wrote:
The 11/70 is now somewhat operable. I can examine and deposit memory, at least for a
short while -- after the system warms up for 30 seconds or so the Load Address switch
stops functioning.
Nice!!
One handy test on '45 is to put the data display knob to bus address; if the microcode
is still running in the control panel idle loop (halt switch down or fault) the data
lights will follow along with the toggles. This is a super quick way to tell if the
microcode is still running or if it is wedged.
(The '45 and '70 microcode seem quite similar, so your '70 might have the same
feature? I haven't looked at the flow diagrams yet to know for sure.)
--FritzM.
1:02 p.m.
On Fri, Feb 5, 2021 at 12:29 AM Fritz Mueller via cctalk <
cctalk at classiccmp.org> wrote:
Thanks for the tip, I'll check that out. Before I went to bed I did a bit
more poking. Upon closer examination, the Load Address switch is still
being recognized: the Data lights get reset to 0 after it's toggled. So
the microcode is taking a jump to ADR.00 when the switch is toggled. It
looks like what isn't happening is the PCA <- BR in T5. So I have a couple
of places to look -- it's possible that the T5 clock signal is going wrong
after warming up (note that ADR.00 is the only step in the console flow
that does anything in T5, except maybe RDP.00 -- I'm not sure if that's a
"5" or a 3"). (See flow 14, p. 18 of
http://bitsavers.org/pdf/dec/pdp11/1170/MP0KB11-C0_1170engDrw_Nov75.pdf) Or
something's going wrong with the PCA <- BR operation.
I put the KM11 back in, and while single-stepping or running under the RC
clock (which is currently set to a really low clock rate, like 7Mhz, for
some reason) Load Address works fine. Seems like some component has slowed
down a bit and stops operating correctly at full speed.
Something to poke at this weekend...
- Josh
On Feb 4, 2021, at 9:45 PM, Josh Dersch
<derschjo at gmail.com> wrote:
The 11/70 is now somewhat operable. I can examine and deposit memory,
at least
for a short while -- after the system warms up for 30 seconds or
so the Load Address switch stops functioning.
Nice!!
One handy test on '45 is to put the data display knob to bus address; if
the microcode is still running in the control panel idle loop (halt switch
down or fault) the data lights will follow along with the toggles. This is
a super quick way to tell if the microcode is still running or if it is
wedged.
(The '45 and '70 microcode seem quite similar, so your '70 might have the
same feature? I haven't looked at the flow diagrams yet to know for sure.)
--FritzM.
1268
days inactive
1273
days old
16 comments
3 participants
participants (3)
-
derschjo＠gmail.com -
fritzm＠fritzm.org -
ggs＠shiresoft.com