> On Apr 10, 2018, at 3:02 AM, Johnny Billquist <b...@softjar.se> wrote:
> 
> On 2018-04-10 01:55, Paul Koning wrote:
>>> On Apr 9, 2018, at 6:25 PM, Mark Pizzolato <m...@infocomm.com> wrote:
>>> 
>>> ...
>>> With simh as it is currently written, all of your DZ devices do need to
>>> be configured to have adjacent CSR address blocks and Vectors.
>>> They can't separately be scattered around the I/O space.
>> That conforms to the float rules, so it seems like a reasonable restriction. 
>>  It's theoretically possible to configure real hardware differently, and in 
>> some OS you can then still talk to the devices (by setting addresses 
>> manually) but it would not be a standard config and probably not supported.
> 
> While RSX certainly tries to probe CSRs and vectors according to the 
> configuration rules DEC defined, in my experience, most machines never 
> followed those rules. People just did not understand them enough, nor did 
> they ever go and change a bunch of controllers whenever some device was added 
> or removed.
> So in real life, I'd say almost every machine always had other layouts of 
> CSRs and vectors than the recommended one, and atleast with RSX, you always 
> run a SYSGEN, and have to at put in the CSR and vector manually anyhow. The 
> only time autoconfiguration was done was at the initial install of the 
> system. And later reconfiguration was totally manual.

RSTS does it differently (starting with V6B).  There, the hardware layout is 
probed at each boot.  Devices are identified by their CSR address according to 
the float rules.  Then they are "poked" to force an interrupt, and the 
interrupt vector address is determined from that.  Exceptions include the card 
readers (no way to poke them), the KG11 (no interrupt).  Programmable interrupt 
devices like MSCP controllers would still be poked, but then given a free 
vector address.  So RSTS requires float CSR conformance but doesn't care about 
float vectors, so long as the vectors assigned to the devices are all distinct.

Any non-standard addresses could be manually configured and RSTS would then 
"poke" that address instead to find the vector.

Given that RSTS supported autoconfiguration like this, I would expect RSTS 
systems generally to conform to the float CSR rules because that made the job a 
whole lot easier for customers.  But it would work either way.

        paul


_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

Reply via email to