PDP-11/10 repair started

[Noel Chiappa]

    > From: Tony Duell

    > Yes, it is a pity that the later board set (a) has the jumper to
    > disable the built-in console port and (b) has the switchable divider
    > allowing higher baud rates so you generally don't need to :-)

Well, except for those of us who don't have any 20mA gear, and want to
standardize on EIA... :-)

    > Adjusting the RC clock is not hard given a frequency counter, and it
    > doesn't have to be that precise.

The prints actually give the time for the pulse width on the two different
speed groups, so a well-calibrated 'scope should do it.


    >> So, how did the M9302 see a 'grant' to start the whole process? Noise
    >> on an open input? Or maybe it powers up in that state?

    > The grants are the only (I think) unibus signals to be active high.

Yup. A source of great confusion to me when I started working with the QBUS,
where they are asserted _low_!

I'd done a couple of DMA network interfaces on the UNIBUS, and so was totally
familiar with how it worked, and when I recently switched to QBUS (I had used
LSI-11's extensively BITD, but not done any hardware on them), that (and a
few other similar quirks) really threw me until I got a grip on them!

    > So if the grant chain is open at any point, the next device along
    > (which might be the terminator) will have a grant input which is pulled
    > high by the pull-up resistor.

Not always! Some devices (e.g. KW11-P) do have a pull-up, but others (e.g.
DL11) only have a pull-down. I looked through a couple of UNIBUS handbooks,
to see if there was a spec for how to terminate a grant line, and there
isn't, which probably explains the variance in practice.

But any which do have a pull-up will generate a bogus 'grant' when there's a
break in the grant line between them and their upstream. But my theory of
noise on an open input may not apply (unless there are devices with _neither_
pull-up not pull-down - I'l too lazy to exhaustively look at UNIBUS device
prints ;-).

    > when that device gets the grant signal it will handle SACK and also
    > will not pass the grant on to subsequent devices ... So obviously there
    > is no way the grant should get all the way to the terminator. But in
    > some cases (I think a device deasserting the request before it gets the
    > grant is one) the grant can get all the way along the bus.

Exactly. Device is requesting interrupt, but is e.g. reset at the same time
the CPU grants the interrupt - result, unwanted grant.

    > I am not sure why that was deemed to be a problem on later machines and
    > not older ones (which run quite happily with the M930 terminator at
    > each end of the bus)

I think the deal is that an un-wanted grant can cause things to come to a
halt until a 'grant timeout' (the '75 Peripherals Handbook says this is 5-10
usec) happens, so the M9302 speeds that up.

Interestingly, I think the M9302 was a _later_ solution to this problem in
the 11/34. In the early ones, there's a 'SACK Timeout Module' (M8264) which I
think performs the same function, but at the _start_ of the bus. (I say
'think' because this module is poorly documented - e.g. I don't know of
anything which definitely states which slot to plug it into.)

	Noel