PDP-11/10 repair started

tony duell ard at p850ug1.demon.co.uk
Mon Oct 5 09:31:01 CDT 2015

>    > isn't the switchable divider only present on later boards (the early
>     > ones being pretty much 110 baud only)?
> Ooh, right you are - another way to tell the early M7260 from later ones. If

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 :-) The older board set with the fixed 110 baud
port you can't trivially disable can be a pain in that respect. 

> your memory of a version with a crystal is correct, that does indeed make

I am probably mis-remembering it. Heck, it's been almost 20 years since I was
inside an 11/10 (!). I probably saw the divider and switch and assumed it was a 
crystal clock like on a DL11.


>     > May be easier than finding the right crystal to change a DL11A-E to the
>     > 'other' set of baud rates :-)
> Well, today that's not so easy (although I did stumble on a pair of the 9600
> baud crystals on eBay a while back), but back then, it was a lot easier!

Unfortunately time machines to go back then are also not easy to find :-)

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

There are (or is it were) companies who will grind special crystals for you but 
it is not cheap and not that fast.

>    > The M9302 includes logic to assert SACK if a grant (any BG or NPG) gets
>    > to it ... This causes problems with an open grant chain in that the CPU
>    > sees the SACK, tries to deassert the grant (which it hasn't asserted in
>    > the first place) and the bus is locked with SACK asserted and no grants.
> 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. 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. An device not
asserting a bus request will pass on any grants it receives (it can't know the grant
is bogus) so in the end one (or more) of the grant inputs to that M9302 terminator
will be high -- that is asserted. 

The logic on the M9302 is purely combinatorial, there is no internal 'state', In normal
operation a grant should never get that far -- a grant is asserted by the processor 
(actually the arbiter which is generally part of the processor logic) when it receives
a bus request (or NPR, as appropriate). That request had to come from some device
on the unibus, when that device gets the grant signal it will handle SACK and also
will not pass the grant on to subsequent devices (that is how the priority of devices
on the Unibus is set up). 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. 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) but anyway...


More information about the cctalk mailing list