30 Aug
2009
30 Aug
'09
1:58 p.m.
Greetings all;
In my continued efforts to try and get my 11/34a functioning I decided to
set up my logic analyser and trap ALL of the 56 Unibus signal lines to see
if I could spot anything that was being held asserted when it shouldn't.
For reference, my 11/34a is set up like:
1 M8266 -------------------------------------------|
2 M8265 -------------------------------------------|
3 M9301 YJ-----| FLIPCHIP
4 M7856---------------------------|
5 National Semiconductor Memory Board--------------|
6 G7232---------|
7 G7232---------|
8 G7232---------|
9 M9302--------| G7232---------|
I only have the basic front-console, so not the lovely button-filled
operators console. All the NPR jumpers are in place. All voltages check
out.
The symptoms are:
Unit powers on, RUN light comes on and then quickly goes out. When the
BOOT/INIT switch is toggled, again, RUN light on, then out. Clearly the
unit is HALTing on something, but I can't work out what and nothing seems
to appear on the console.
When I analyse the bus the unit follows what, from the Unibus design
manual, appears to be a standard start-up procedure.
- All signals float (obviously)
- All signals cleared, DCLO/ACLO/INIT asserted
- 773000 is placed on the Address lines (as configured in the bootstrap)
- DCLO negates
- ACLO negates
- INIT negates, and then immediately:
- Address lines are cleared
- SACK is asserted
I find no mention of SACK being asserted in the Unibus manual in its
start-up section. Furthermore, as my understanding goes, SACK should only
be asserted when a bus master has accepted a grant and is beginning a
transaction cycle. There is NO activity on the request/grant lines, so
nothing should be allowed to become bus master, so I think this SACK
signal should not be happening.
Can anyone with more understanding than me (which, you know, is pretty
much everyone else who owns a PDP11) confirm I'm not completely off-base
here?
I have two M7856s and have switched between them, so if it's the 7856
that's holding SACK, then both of mine are doing it. Elsewise... I think
the only thing that could be "sticking" is the processor boards, as the
memory card shouldn't be able to assert SACK since it can't become a bus
master. If this guess is correct... I'm not really sure how to begin
debugging what on the processor board is getting glued. Time to break out
those schematics?
My thanks to all for your thoughts;
- JP
31 Aug
31 Aug
10:59 a.m.
Date: Sun, 30 Aug 2009 15:58:08 -0500
From: jplist2008 at kiwigeek.com
To: cctech at classiccmp.org
Subject: Ongoing PDP11/34a resurrection attempts - stuck SACK?
Greetings all;
In my continued efforts to try and get my 11/34a functioning I decided to
set up my logic analyser and trap ALL of the 56 Unibus signal lines to see
if I could spot anything that was being held asserted when it shouldn't.
For reference, my 11/34a is set up like:
1 M8266 -------------------------------------------|
2 M8265 -------------------------------------------|
3 M9301 YJ-----| FLIPCHIP
4 M7856---------------------------|
5 National Semiconductor Memory Board--------------|
6 G7232---------|
7 G7232---------|
8 G7232---------|
9 M9302--------| G7232---------|
I only have the basic front-console, so not the lovely button-filled
operators console. All the NPR jumpers are in place. All voltages check
out.
The symptoms are:
Unit powers on, RUN light comes on and then quickly goes out. When the
BOOT/INIT switch is toggled, again, RUN light on, then out. Clearly the
unit is HALTing on something, but I can't work out what and nothing seems
to appear on the console.
When I analyse the bus the unit follows what, from the Unibus design
manual, appears to be a standard start-up procedure.
- All signals float (obviously)
- All signals cleared, DCLO/ACLO/INIT asserted
- 773000 is placed on the Address lines (as configured in the bootstrap)
- DCLO negates
- ACLO negates
- INIT negates, and then immediately:
- Address lines are cleared
- SACK is asserted
I find no mention of SACK being asserted in the Unibus manual in its
start-up section. Furthermore, as my understanding goes, SACK should only
be asserted when a bus master has accepted a grant and is beginning a
transaction cycle. There is NO activity on the request/grant lines, so
nothing should be allowed to become bus master, so I think this SACK
signal should not be happening.
Can anyone with more understanding than me (which, you know, is pretty
much everyone else who owns a PDP11) confirm I'm not completely off-base
here?
I have two M7856s and have switched between them, so if it's the 7856
that's holding SACK, then both of mine are doing it. Elsewise... I think
the only thing that could be "sticking" is the processor boards, as the
memory card shouldn't be able to assert SACK since it can't become a bus
master. If this guess is correct... I'm not really sure how to begin
debugging what on the processor board is getting glued. Time to break out
those schematics?
My thanks to all for your thoughts;
- JP
When I read "M7856" I was immediately triggered. On my website I wrote:
"Note that the M7856 module does not use, nor connect the NPG connection.
If you install the M7856 module in an SPC slot, make sure that the NPG
chain is wired on the backplane. If you do not want to "mess around" on
the backplane, you can solder a wire on the component side of the module
to connect CA1 to CB1. If you are not sure which contact fingers to connect,
use the G7273 NPG / Grant Continuity module as an example."
(If the English text could be better, I'd appreciate the comment).
I'd check that first. It took me some time to find out that the M7856 does
not have contact fingers to pass NPG.
- Henk.
12:20 p.m.
Greetings all;
In my continued efforts to try and get my 11/34a functioning I decided to
set up my logic analyser and trap ALL of the 56 Unibus signal lines to see
if I could spot anything that was being held asserted when it shouldn't.
For reference, my 11/34a is set up like:
1 M8266 -------------------------------------------|
2 M8265 -------------------------------------------|
3 M9301 YJ-----| FLIPCHIP
4 M7856---------------------------|
5 National Semiconductor Memory Board--------------|
6 G7232---------|
7 G7232---------|
8 G7232---------|
9 M9302--------| G7232---------|
I only have the basic front-console, so not the lovely button-filled
operators console. All the NPR jumpers are in place. All voltages check
out.
The symptoms are:
Unit powers on, RUN light comes on and then quickly goes out. When the
BOOT/INIT switch is toggled, again, RUN light on, then out. Clearly the
unit is HALTing on something, but I can't work out what and nothing seems
to appear on the console.
When I analyse the bus the unit follows what, from the Unibus design
manual, appears to be a standard start-up procedure.
- All signals float (obviously)
- All signals cleared, DCLO/ACLO/INIT asserted
- 773000 is placed on the Address lines (as configured in the bootstrap)
- DCLO negates
- ACLO negates
- INIT negates, and then immediately:
- Address lines are cleared
- SACK is asserted
I find no mention of SACK being asserted in the Unibus manual in its
start-up section. Furthermore, as my understanding goes, SACK should only
I am pretty sure SACK should no0t be being asserted at this point.
be asserted when a bus master has accepted a grant and
is beginning a
transaction cycle. There is NO activity on the request/grant lines, so
nothing should be allowed to become bus master, so I think this SACK
signal should not be happening.
Where are you monitoring the grant lines? Remember they are not bussed,
they are daisy-chained from one slot to the next. So an open-circuit in
one of them may mean what you're seing on the logic analyser is not what
the boards are seeing.
The M9320 terminator (as has been stated here many times before) can
assert SACK. It asserts SACK if a grant gets all the way to the
terminator -- that is if no device intercepts the grant. Unfortunately an
open-circut grant line will have the same effect.
Try remoing the M9302 (on a Unibus this short you don't need to
terminate the far end for testing) and see what happens then.
-tony
5:04 p.m.
On Mon, 31 Aug 2009, Tony Duell wrote:
Where are you monitoring the grant lines? Remember
they are not bussed,
they are daisy-chained from one slot to the next. So an open-circuit in
one of them may mean what you're seing on the logic analyser is not what
the boards are seeing.
I have my logic analyser probes on the last slot of the bus. My idea was
that if the M9302 was returning SACK, I should be seeing what the M9302 is
seeing, if I'm running off the back of its bus slot.
The M9320 terminator (as has been stated here many
times before) can
assert SACK. It asserts SACK if a grant gets all the way to the
terminator -- that is if no device intercepts the grant. Unfortunately an
open-circut grant line will have the same effect.
Try remoing the M9302 (on a Unibus this short you don't need to
terminate the far end for testing) and see what happens then.
This did not occur to me due to a combination of assumption and brain
damage. Because I knew, from experience, removing the terminator did not
"fix" the problem, I had assumed it wouldn't help.
I have removed the M9302 and SACK is still being asserted - so the M9302
clearly is not the source of the issue, but I appreciate the reminder,
nevertheless, to remove another potential culprit.
And thanks to Henk, who has solved a small mystery - my M7856 has a solder
bridge between its NPG and NPR pins on the card-edge connector. I wasn't
sure why until now!
My thanks;
- JP
5591
days inactive
5593
days old
3 comments
3 participants
participants (3)
-
ard＠p850ug1.demon.co.uk -
henk.gooijen＠hotmail.com -
jplist2008＠kiwigeek.com