[Simh] DZ11 vs DZV/DZQ11

[Johnny Billquist]

On 2018-04-10 15:19, Paul Koning wrote:
> 
> 
>> On Apr 10, 2018, at 3:02 AM, Johnny Billquist <bqt at softjar.se> wrote:
>>
>> On 2018-04-10 01:55, Paul Koning wrote:
>>>> On Apr 9, 2018, at 6:25 PM, Mark Pizzolato <Mark at 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.

Ah. Interesting. Yes, definitely differently than RSX then. RSX is 
specifically tailored to your hardware. So the system already knows what 
hardware exist, and at what CSRs and vectors. There is probing at boot 
time, but only to confirm that the configured hardware actually is 
there. Otherwise those devices will be marked offline. So, adding or 
removing hardware do not affect how the detection happen. No scan 
according to the floating space specs are done in RSX, except at the 
original SYSGEN run, where SYSGEN offers to try and detect what hardware 
you actually have. With the explicit warning that this might hang your 
system, in which case you should reboot and run SYSGEN again, but not do 
the autoconfiguration step.

And if you reconfigure the hardware, such as change the CSR address of a 
device, you either need to rerun the SYSGEN (a long and annoying process 
in -11M), or reconfigure the system (only possible in M+). So people 
tended to not change the CSR addresses, even if they added another 
device. Adding a device in RSX is a simple thing, since you can load 
device drivers on the fly in the running system anyway.

> 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.

Sounds like RSTS/E customers would have more reason to follow the 
floating CSR rules, yes. In RSX, you almost get punished if you do. :-)

   Johnny

-- 
Johnny Billquist                  || "I'm on a bus
                                   ||  on a psychedelic trip
email: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol