• Please review our updated Terms and Rules here

Pdp11/34 restoration

Roe

Experienced Member
Joined
Dec 28, 2012
Messages
240
Location
Regina, Canada
Greetings. I'm a newbie here, but I started working on pdp11 systems in 1974, I'm resurrecting an 11/34a, and I'm hoping the crowd can help me with a strange problem.

The 34 boots, front panel works, memory seems to work, ctrl/boot starts the bootstrap rom on the system console. I can manipulate memory from the front panel, and the console, no problem at all.

Here's the problem: if I enter a dead simple program from the front panel, say 000777 at mem location 1000, load address 1000, and hit ctrl/start, the system seems to start and then halts immediately. If I then use ctrl/cont, the system starts running. In other words, ctrl/start just isn't starting the system.

If I attempt to use the boot rom "S" command to start the system , for example
L 1000
D 777
L 1000
S

Things get strange. I get a junk character on the screen, the system seems to be running, but any attempt to use ctrl/halt from the front panel causes a BUS ERR light, the RUN light stays lit, and I cannot regain front panel control at all. I have to power off the system to regain control.

Does this sound familiar to anyone?

Thanks.
 
Something sounds funky with the KY11-LB programmer's console or the bus interface card. Is there any chance you have a KY11-LA and can pull the interface from the bus and see if everything works properly from the console emulator (you must have an M9301 or M9312 bootstrap).

I personally have an 11/04 made from parts, and had to wire wrap my own KY11-LA from the prints. The 11/04 was the little brother (single hex height microcoded processor) of the 11/34. I do have one card from an 11/34 and the other from an 11/34a processor and am on the lookout for any one willing to swap a spare so I can ugrade to 11/34 or 34a.

Lou
 
Cretin you got all the grant cards (G727) stuffed in slot D on all the unused sockets? And the MPG or what ever it is bypass on the C slots, pins CA1 to CB1? Do you have the 11/34 manual? I just tried keying 000777 into location 1000 then hit start on my 11/34 and it ran no issue but that was using the keypad on the front of the system. I did not see anything happening on the con while this was happening. Was fun to do that, have to go back to trying to figure out why my stupid clock doesn’t work?
 
Further

Further

Yep. All slots are occupied, and the bus works just fine. In fact, I keyed a fairly detailed memory test into the front panel, and it ran just fine. The problem is that the machine invariably halts at the start address when ctrl/start is pushed. Hit ctrl/cont and everything works just fine.

The slot layout is

1: CPU
2: CPU
3: A/B M9312 bs/term, CDEF M7859 front panel interface
4: M7891 128kword mos memory
5: M7762 RL controller
6: CDEF M7856 dl11w
7: M7819 dz11
8: C/D G7273 dual bus grant
9: A/B M9302 terminator C/D G7273 dual bus grant



And the MPG or what ever it is bypass on the C slots, pins CA1 to CB1? Do you have the 11/34 manual? I just tried keying 000777 into location 1000 then hit start on my 11/34 and it ran no issue but that was using the keypad on the front of the system. I did not see anything happening on the con while this was happening. Was fun to do that, have to go back to trying to figure out why my stupid clock doesn’t work?[/QUOTE]
 
No, I've only got the LB front panel. And the console emulator has the START problem I described. I have virtually no spares at all...
 
Roe:

While I can’t offer an immediate explanation for your problem, a fundamental difference between a CNTRL/START and CNTRL/CONT is that the start generates a BUS INIT prior to passing control to the program. It might be interesting to determine if that’s causing an issue. The following two tests are identical except that the first performs an INIT and the second does not. You could execute each and tell us what happens.

Test 1:

001000 LAD
000005 DEP
000777 DEP
177707 LAD
001000 DEP

CNTRL/CONT


Test 2:

001000 LAD
000240 DEP
000777 DEP
177707 LAD
001000 DEP

CNTRL/CONT
 
Great idea, and you are correct; BUS INIT has problems.

Test 1 seems to run. RUN and SR DISP light up, but any attempt to HALT causes BUS ERR, RUN stays lit, and the only way to regain control is power off. Test 2 loops correctly at 1002, I can halt and continue with no problem.

Further testing shows that CNTRL/INIT from the front panel has no effect. For example, if I halt the processor, hit a key on the DL11W console, 777560 is 000200 (which s correct). If I hit CNTRL/INIT, the LED display on the front panel blinks off for about 0.2 seconds, and 777560 is STILL 000200.

I'm going to do some continuity tests on BUS INIT. Does anyone know if there is an ACK protocol on the unibus for INIT, or is it timing sensitive? If this is a signal that's supposed to pulse for affixed time, could a tweaky capacitor or something mess things up like this?

Thanks again for the pointer to BUS INIT.
 
I have verified that BUS INIT (slot D, component side, pin 10) has continuity from slots 3 to 9. Slot 1 doesn't seem to be connected, but 1 and 2 are CPU special slots, so that seems reasonable.
 
I'm going to do some continuity tests on BUS INIT. Does anyone know if there is an ACK protocol on the unibus for INIT, or is it timing sensitive? If this is a signal that's supposed to pulse for affixed time, could a tweaky capacitor or something mess things up like this?

There is no acknowledgement for a BUS INIT, at least not in the same sense as a HALT GRANT acknowledging a HALT REQUEST. I was going to suggest the possibility of some device responding inappropriately to the INIT and hanging the bus. That might explain why a subsequent halt results in a bus error condition. Your comment about the DL11W would seem to contradict that theory though, assuming you are examining 777560 through the console after the CNTRL/INIT. It still could be an interesting experiment: remove everything (including the M9302) from the backplane except for the CPU, M7859, M9312 and M7891 and test again. Do you get different results?
 
Last edited:
If you remove everything except the CPU cards, M9312/M7859 and the memory don’t you have to install grant cards in all the open slots? Also I thought the M9302terminator did some sort of magic in the last slot and the system would give a bus error without it?
Interesting thread can’t wait to see what the problem turns out to be.
 
I don't have any spare grant cards, and I'm pretty certain that if I remove the M9302 terminator, any attempt to use the unibus will just generate a bus error.
 
If you remove everything except the CPU cards, M9312/M7859 and the memory don’t you have to install grant cards in all the open slots? Also I thought the M9302terminator did some sort of magic in the last slot and the system would give a bus error without it?
Interesting thread can’t wait to see what the problem turns out to be.

I believe without the M9302 the system won't generate the bus error as there is nothing to acknowledge it. This is one easy way to test a system to see if
it works. Of course one should have the M9302 in a working system and grant cards in all unused slots. I did this with my 11/34c years ago when
I first got it to prove it worked. I then has to determine what was causing the error.
 
Well, I'll be dipped. I've pulled everything out as KM11 requested - except for the M7856 dl11w, and the machine actually runs a 000240/000076 loop.

It even boots the M9312 console emulator.

The behavior has not changed. CNTRL/INIT still doesn't clear 777560. Executing opcode 000005 still crashes the system as previously described.
 
I believe there may be a fairly widespread misconception about the “magic” that an M9302 terminator performs. What follows is a gross simplification but I tried to keep it short - yes, really :)

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, 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.
 
Cool, thanks for the explanation. Thus far I have only been self-thought on the PDP-11 systems and often my education is sadly lacking. Assuming that this grant thing is somewhat like the IRQ lines in a PC? At least on the Unibus, Qbus systems look more the line of a PC? Wonder if the advantage of the grant system is that you can have a huge number of devices in the chain where with an IRQ system you are limited by the size of the IRQ bus?
 
Thanks for the bus description, this makes it pretty clear why the unibase was called "asynchronous".

If I want to trigger a BUS INIT externally, literally by hand, can I just short the INIT pin to ground? IIRC, unibus is active low. Or should I ground it through a resistor of some kind?
 
...Assuming that this grant thing is somewhat like the IRQ lines in a PC? At least on the Unibus, Qbus systems look more the line of a PC?...

UNIBUS and Qbus closely mimic each other in terms of handling grants. (I think the significant conceptual difference between UNIBUS and Qbus is the fact that Qbus multiplexes address and data over the same lines.) I guess there are definite similarities between UNIBUS interrupt handling and IRQ's, but I'm less versed on the PC side so I'll defer a more detailed comparison to others.

...If I want to trigger a BUS INIT externally, literally by hand, can I just short the INIT pin to ground? IIRC, unibus is active low. Or should I ground it through a resistor of some kind?

I think you can safely ground the INIT line to assert it, but what I find interesting here is that issuing a BUS INIT from the CPU (via a program) and from CNTRL/INIT both seem to fail. We would need to check schematics to be certain, but I believe that each of those assert INIT independently and I think you're going to have to start checking signal lines. Perhaps this is where you're headed as well.
 
I'm probably going to be tracing signals. I've currently got both CPU cards out of the unibus, and using the front console in maintenance mode STILL won't reset the %#%#* DL11W status register. I want to force the INIT line low manually and see what happens...
 
This makes no sense at all.

I've only got three cards in the backplane now, M9312, M7859, and M7856.

BUS INIT comes up at 3.4 volts when power is turned on. With power off, I measured resistance between INIT and +5v at 120 ohms. This all seems normal to me, at least.

I put the front console in unibus master mode, talk to the dl11 with no problem, set it up with a character in the receive buffer, and manually short out the INIT line.

Nothing happens. I've tried this with two different DL11W cards. The status register remains at 200.

Does any of this make sense to anyone, because it doesn't to me. I've got a scope I could hook up to the INIT line, but I don't know how to set it up for one-shot trigger on a negative pulse.
 
I believe when a device sees INIT asserted, it first completes any bus cycle in progress. It does not actually initialize until the negation of INIT. You may want to check other signal lines, particularly BBSY, MSYN, SSYN and SACK.
 
Back
Top