• Please review our updated Terms and Rules here

PDP-11 /04 and /34 CPU tryouts: FAIL and FAIL!

I

intabits

Experienced Member
Joined
Jan 22, 2019
Messages
148
Location
Melbourne, Australia
Having previously tested or repaired the power supplies, console interfaces and memory boards of my

PDP-11/04 and 11/34, it was time to try inserting the CPU boards into them.

Just before powering it on I noticed something on the 11/04's CPU board (M7263) that I had stupidly

neglected to look for much earlier.
Some general corrosion, but especially bad around E32, where it appears that a trace may have been

corroded away.

Tysfg2C.jpg


But after cleaning it up, and consulting the schematics, I'm 95% sure that it was a factory trace cut,

and therefore the corrosion was not quite as bad as previously feared, so I decided to power it up.

The Run light was stuck on, and I'd read that this could be the result of the NPG or BGx grant chains

being incomplete. While checking the NPG chain, I found a small broken part of the backplane
connector.

pu8DzTu.jpg


Unfortunately, it appears this break may have allowed -15v into the NPG out pin of the CPU.
So that put a halt to further testing of the 11/04 for now.

Turning my attention to the 11/34, I just plugged the power supply into the mains socket, which

resulted in sparks and melted power plug pins. So there was an obvious short circuit in the power
supply mains input. There were no issues last time it was used.

z6ZrlEF.jpg


So ended my ambitious attempt to quickly get two working PDP-11's on the same day.

I'm also wondering if the far more experienced PDP-11 people can tell me if an '04 or '34 CPU should

be operable from the console with just the following: M7263/M8266+M8265, M7847, M7859 and M9302 (and G727A grant cards)?
Or is the M9301/M9312 (or anything else) also required?

Video:-
https://www.youtube.com/watch?v=OiGnCDZpN7I
 
Can't remember for the 11/04 and 11/34 specifically, but in general, you need a terminator on the Unibus for the CPU to be happy. And that means you need an 930/9301/9312 at the end. Otherwise your grant cards just leads the signals into a black hole.
 
Yes, I was confused as to why the grant cards would be needed if no other devices were downstream of them.
But discovered in my research along the way, that the grant lines on columns C&D on the last slot (must be) wired over to the Unibus columns A&B, so that the M9302 could deal with them.

Also, the PDP-11/04 CPU (M7623) unlike others (most?), does not include SACK timeout logic, so it requires the use of the M9302 terminator with the SACK turnaround logic, as opposed to an M930 which is just a terminator.
This is so that an un-captured NPG or BGx that gets to the end of bus will cause SACK to be asserted by the M9302, and thus not hang up the CPU waiting for it.

(I'm not clear on how that doesn't cause a problem, since the CPU has received a request, responded with a grant, and received an acknowledgement to it, but there is no actual device there to continue the transaction. More reading required...)
 
Sorry to hear about your bad luck. Here is my understanding of bus grants which hopefully may help.

For a device to be able to use the bus, the following general sequence of events occurs:

1. The device asserts a bus request
2. The arbitrator responds by asserting a bus grant
3. The device asserts SACK (selection acknowledge) and clears the bus request
4. The arbitrator sees SACK and clears the bus grant
5. The device asserts BBSY (bus busy) and clears SACK – the device now owns the bus
6. The device clears BBSY when it is done using the bus

The grant that an arbitrator issues is passed from device to device until the grant reaches the device that made the request. In theory then, a grant should be acknowledged by the device that made the request, but in rare cases this does not happen and the grant is passed down the bus until it reaches the terminator at the end. In this situation, interrupt processing pretty much stops since the arbitrator will not clear the grant until it sees SACK but nothing is asserting it. Well, the “magic” DEC added to the M930 (subsequently called the M9302) was to assert SACK if a grant should ever reach it. In those circumstances, the arbitrator sees the SACK asserted by the M9302 and drops the grant – the CPU owns the bus and we are back in business.

This is a double-edged sword however, because if the grant chain is broken (for example, a device configured to pass those grants is removed from the backplane), the M9302 sees the break as a grant and asserts SACK. The arbitrator, seeing SACK, attempts to clear the grant but there really is no grant to clear, so everything hangs. This is the scenario which usually gets the most attention and why it is often stated to be sure to place grant cards in all open slots and terminate the bus with the M9302.

In reality I think, temporarily removing everything but the core modules (including the M9302) on a minimally loaded system should not introduce problems and can often help troubleshoot bus issues.
 
KM11 said:
1. The device asserts a bus request
2. The arbitrator responds by asserting a bus grant
3. The device asserts SACK (selection acknowledge) and clears the bus request
4. The arbitrator sees SACK and clears the bus grant
5. The device asserts BBSY (bus busy) and clears SACK – the device now owns the bus
6. The device clears BBSY when it is done using the bus
Click to expand...

Thanks, for the explanations.
I've read all of that in DEC documentation multiple times, but it all becomes a blur, that doesn't "stick" (at least for me), until I've immersed myself in it a bit more. For the video, I drew up several diagrams, and put them together with text explanations into a document, and then went through them in a recording. But it was getting rather long, and my presentation was a bit pedestrian, so I dropped it.

But doing all that made me quite clear on the operation up to your step 4, but wondered in my previous post what happened after that, which your steps 5 & 6 explain - Only a properly operating device will then go on to assert BBSY. (My concern so far had been just to understand the need for grant cards and an M9302)

Though I'm still wondering about a few things that owners of working systems might help me with:-

At power-up, should any of this be happening?
Shouldn't the CPU be halted at power-up?
(assuming an M7859, but no M9301/M9312 or auto-reboot provisions)

I know an M9301 jams high order address bits onto the bus to divert the CPU from locations 24&26, into locations in its ROMs, but I'm not clear on what starts the CPU to do that.
If there were no M9301 (and not core memory or battery backup) a CPU running at power on would be useless, No?

If the CPU doesn't run from power on, a broken grant chain or the lack of SACK turnaround logic should not be an issue?
In fact, a complete non-issue if there are no devices that could issue a bus request?
And should not be the cause of a RUN light on that can't be turned off?
 
At power up, there is a power up sequence/protocol on the bus as well. So if things are not working right, the CPU might get stuck.
The CPU is trying to assert control of the bus at power up. If it cannot get control of the bus...
But even after that, when the CPU is halted, the bus arbitration logic is still there.
 
bqt said:
At power up, there is a power up sequence/protocol on the bus as well. So if things are not working right, the CPU might get stuck.
The CPU is trying to assert control of the bus at power up. If it cannot get control of the bus...
Click to expand...

I don't recall seeing anything about that in my adventures.
Are you able to point me anywhere that describes that in some detail?
 
Thanks. That certainly describes it in detail!
(I've seen that chapter before, but didn't notice that section especially, probably because it wasn't topical for me at the time)
 
The power supply of my PDP-11/34, which was working fine previously, had mysteriously become a dead short on the mains power the next time I plugged it in.

Investigating the problem revealed a bad EMI filter, for which I was able to find and obtain a suitable replacement, for a good price, the same day, on EBay!

Also uncovered, an error in the DEC documentation of the PSU's input section.

After the repair, I notice a label that casts doubt on whether this is really the 11/34, and that it may have been mixed up with my 11/04.

So before plugging in the CPU boards, I'll first have to verify that the correct backplane is fitted in this machine...

https://www.youtube.com/watch?v=YK5dwtP85_s
 
Having fixed the power supply short circuit, I've now investigated the labels that caused suspicion of a mix up of parts between the 11/04 and the 11/34 (there wasn't).

So finally I could try out the CPU in the PDP11/34, but no joy.
I tried a few variations, but again, no success.

These things have been taking up too much of my time, so I'm putting them aside for now.

I have a lot of other interesting junk to show, so future videos about those will mostly be just to show them, without attempting to power them on, as that takes too much preparation and research.

https://www.youtube.com/watch?v=EWShSIkCn7w
 
You must log in or register to reply here.
Back
Top