RE: Address of second TMSCP controller

[Mark Pizzolato - Info Comm <Mark%infocomm.com@localhost>]

On Thursday, January 28, 2021 at 12:27 PM, Johnny Billquist wrote:
> On 2021-01-26 14:06, Nigel Johnson wrote:
> >
> 
> >> Thanks, Mouse.  Yes, as an FE I used to have to figure out those
> >> floating assignment from charts - some DEC systems (RSTS, RT11) could
> >> not be told where to look - they had to be in the right place. IIRC,
> >> there was a strict ranking, and to make it start looking for a device
> >> of the next rank, you had to skip the number of registers that each
> >> device took so it would get a bus timeout and then look for the next
> >> device in the list! Seems like it was intended to save core memory
> >> which was so expensive in those days!  I do remember that if you got
> >> it wrong, it would treat whatever it found as the device that should
> >> be there, used the wrong driver, and crashed!
> 
> It didn't have anything to do with core memory.
> The "problem" is that there are potentially many more address assignments
> needed to cover all kind of combinations you can think of than the address
> space available in the I/O page of the Unibus.
> 
> Just think of it. There are many different serial interfaces, and you could have
> many of each type. If you fixed the addresses for as many of each as you
> could imagine, the amount of address space you would need would be very
> large.
> 
> So a more dynamic address assignment was needed. So floating space
> essentially is a free for all. However, if you want to be able to just plug and
> play, and have software figure out what actually is installed, you then need
> some kind of a schema. And that is what the DEC designed allocation of
> addresses in the floating space address. And yes, it is essentially just putting
> a defined order on all controllers. So you probe for the first device until you
> get a bus timeout, then move to the next. Existence of any controller is just
> based on it responding to the CSRs. There never were any standard way of
> reading out the type of any controller, so it was just figured out implicitly by
> the ordering, and at which address it then responded.
> 
> But of course, this is only needed in order to do some kind of automatic
> detection of what is installed on a Unibus. If you explicitly assign addresses
> both on hardware and in software, this scheme for the floating address
> space can be totally ignored.
> 
> RSX basically do explicit address assignment, and only use autoconfiguration
> in one explicit place in the SYSGEN process, to find out what hardware is
> installed on your system, to provide some default answers for the SYSGEN
> process itself. It's not used at any other time.
> 
> I think RSTS/E made more use of the probing at runtime. Not sure about RT-
> 11.
> 
> And how you probe the I/O space is almost as the description above, but not
> quite. But if someone wants to, we could go over how it is done.

VMS essentially requires that this algorithm is used to assign device addresses.

The complete details of this process are implemented in the simh VAX and PDP11 
Simulators in the routine auto_config in module PDP11/pdp11_io_lib.c.  
A distinctly lesser cut at this is implemented in the simtools repository config11/config11.c 
module.

Given the decades of legacy behavior where device addresses are explicitly declared 
in BSD configurations, it would seem quite late in the day to think about changing
how things have always worked for BSD.

- Mark