On 2019-07-31 19:52, Paul Koning wrote:
On Jul 31, 2019, at 1:34 PM, Geoff Conway <gcon...@bigpond.net.au> wrote:
...
There is a reason for mentioning the OS side of things and while in the real
world the majority of PDP11 peripherals are set by switchpacks on the cards
(been there done that) - the device code for that peripheral (if it's
intelligent?) would (presumably) read those register values and load them into
itself so it knows what addresses to respond to. In sysgen/netgen (whichever
being relevant) the CSR/vector values for every peripheral are then manually
entered by a human and the system/DECNet built.
That depends on the OS.
Right.
I think most OS know the floating CSR rules and use that to identify the
devices; you specify CSRs manually only if your address settings don't conform.
With RSX, it's sortof a hybrid, with a hard leaning towards manual
configuration.
RSX actually only have one piece who knows anything about the floating
CSR rules, and that is a piece of software called the Autoconfig
Detection, which is only run when you do a SYSGEN on the baseline
installation system. So when you do your initial installation for the
first time, the system offers you the option of running the
autodetection of your hardware, and make use of that for the SYSGEN.
After that, you will never see that program again, and RSX will never
again care about the floating CSR rules, autoconfiguration or detection
or anything.
Similarly with vectors: the OS may implement the float vector rules to compute the vector
addresses for the devices. Or it may do what RSTS does, which is to "poke"
each device at boot time to make it interrupt, then remember what the vector address was.
So RSTS requires float CSRs in order to autoconfigure devices but doesn't mind what the
vectors are so long as they are all unique.
Again, in RSX this can be done on the initial installation, but will
never happen after that. And yes, for that one time, it's done by trying
to poke the controllers to make them create an interrupt, and then
figure out which vector they actually did use.
...
The 3 exceptions are all the 3 devices I included in my simh qbus configuration and when
I entered the "show dev" command prior to booting the OS disk all of those simh
devices had CSR values but no vectors - devices DEQNA=XQ/XQB; KDA50=RQ/RQB and finally
TK50=TQ.
Prior to entering the OS they had <no vector> against them and after the OS was
booted into a fully configured system and then finally shutdown those same 5 simh
device then had their vectors assigned.
Why ?
After reset, the vector address is not set. Once the OS programs the vector
address by appropriate commands to the device, it remains in effect until
cleared. Shutdown (on the OS you are using) apparently doesn't do a reset so
the vector remains set to what the OS assigned.
Yep.
...
Other cards I have experience of (ACC X.25 card) I believe also had
programmable vectors (yet to be confirmed) so while that mechanism certainly
won't be in an older card like the DEUNA it is in the newer
For SIMH purposes the discussion is about DEC peripherals: for those the three
mentioned are the only ones with programmable vectors. Sure, the idea makes a
lot of sense in newer devices and it's not surprising that some non-DEC boards
would have adopted the same feature.
Definitely. I sortof wonder if there might be something with the network
booting that made DEC choose to have a set of dip switches for the
vector of the DEUNA. The DEQNA did not support network booting to the
same degree, so it might have been less of an issue.
But I might just be totally wrong as well, and the vector could have
been programmable on the DEUNA as well. I wonder why they didn't, in
that case.
Johnny
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: b...@softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
Simh mailing list
Simh@trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh
