Lots of things to comment. Why do these things get so long?
On 2019-07-31 19:34, Geoff Conway wrote:
On Wednesday, 31 July 2019 22:02 Johnny Billquist wrote:
On 2019-07-31 05:18, Geoff Conway wrote:
I spent a few hours yesterday investigating how the XU, XUB and XQ, XQB
devices interact within simh with respect of having CSR and vectors assigned
with or without autoconfig enabled.
Unlike every other device the DEUNA XU & XUB behaviour in not auto-
assigning the vectors within simh as the OS assigns them appears to be
inconsistent with every other PDP device I've used so far in simh - and is the
only device that won't work if autoconfig has been disabled before their
vector value has been autoconfigured in simh as there is no way to manually
assign the needed vector for either of XU & XUB.
If you cannot assign a vector, then there is a bug there.
Essentially, it is an absolutely requirement that you can set the vector, if you
are configuring manually, as that is what you'd do on the real hardware.
Yes agreed there is a bug - Mark earlier found what is missing - the ability to
set the vector value in simh config for the XU/XUB device - there is a change
needed to MTAB contents which basically enables the set xu(b) vector=xxx
command.
Good. So we can close that part down. simh had a bug in the ability to
set a vector on Unibus ethernet controllers. Bug fixed. Problem gone.
End of discussion. :-)
In short, if you grab a real DEUNA or DELUA, there are two dip-switches with
8 or 10 switches each. One is used to set the CSR, the other is used to set the
vector.
Agreed - they are the older cards if it has switchpacks for CSR and vector.
I'm not sure I would classify them as "older" vs "newer". It's a
question of how the programming model works on that controller.
The DEUNA is an old card and while it has its VEC set by switchpack obviously
it cannot have programmable (by OS) vector setting - that is reserved for
certain.(read on for elaboration please) newer cards.
Yes. Obviously, the vector can only come from one place.
In comparison XQ & XQB devices set their simh vectors as they are assigned
by the PDP11 OS - in my case RSX11M-PLUS. While the OS drivers all include a
mechanism that passes that vector to the simh driver routine - relying on an
XQ, XQB driver routine to set the XQ, XQB vector values within simh.
First of all, disregard the PDP-11 OS aspect. That is not relevant here.
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. The human knows the rules for
fixed floating csr/vec assignments for the various devices and their
combinations and will decide on the values - although if autoconfig is enabled
simh might set different floating values. Generally the simh config11 utility
will provide a list of csr values for the overall configuration but it will not
specify VEC vales for fixed(known) and floating. The human needs to come up
with an overall list of assigned CSR/VEC values for all peripherals in the
system.
In the majority of cases then simh will know both the csr and vector values of
its peripherals with a few exceptions.
No. It does not work like that. There are no way of reading the vector
from the card, no matter how intelligent the software is.
What can be done, and what the autoconfiguration software does, is that
it tries to trigger an interrupt, and then tries to figure out which
vector was actually used for the interrupt, by having *all* interrupt
vectors populated with different information in order to figure out
which vector was used. This can obviously fail for two simple reasons:
1) There is no way of trigger an interrupt from the software.
2) The vector programmed is the same as something else that is already
being used. The autoconfiguration software cannot install the catchall
interrupt handles on vectors that are already in use by something.
SYSGEN/NETGEN is where the human enters addresses and vectors. They are
not verified against the actual hardware, since there is no way of doing
that.
The autoconfig in simh is a way in which the hardware can get
configured. It is totally disconnected from the PDP-11 software.
And the autoconfiguration rules for the Unibus (or Qbus) gives rules for
both CSR addresses and interrupt vectors. So simh should be able to
assign values for both for all devices.
A human don't need to come up with an overall list. The
autoconfiguration rules are strict and gives a full answer for what
addresses to use for both CSRs and vectors. It's up to the human if they
want to follow that, or if they want to come up with their own values.
The 3 device exceptions I am talking about are in simh driver names the DEQNA
(XQ/XQB) or WHA/WHB (DECNet DLX driver names as from con dis cont att command
but derived from DECNet and configured in DECNet
The other 2 exceptions are the UDA50/KDA50 MSCP controllers with sim driver
RQ/RQB with OS DUA/DUB controllers, as well as the simh TQ device (TK50 tape
drive TMSCP controller) with OS driver name MUA.
They are actually not any different, except that you do not set any
vectors on the hardware through any dip switches or similar. You still
have to decide what vectors they should be using, and then it's the same
story as with any other controller.
In the main all of the other peripherals in simh Qbus config have their CSR/VEC
known to simh and these are fed into the sysgen/netgen manually by a human. The
human should decide the sysgen/netgen parameters based on which combination of
peripherals are being used.
Obviously.
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.
Yes, since they are not set in simh directly. Just as they are not set
on the actual hardware.
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 ?
Because according to Mark - " Actually only the "newer" devices have OS driver
programmable vectors. These include XQ (DEQNA/DELQA) and the RQ (MSCP-RQDX,UDA,...) and TQ
(TMSCP).
All other devices had vectors either unchangeable or with switches on the
board."
Put in a simpler way. The vectors of these controllers are programmable.
So they get set by the PDP-11 software.
And because I am just so fortunate (sarcasm!) to have configured these 5
instances and observed their vector value being fed through the OS device
driver TO simh devices I was aware of how their vectors were being filled.
The older devices clearly don't have that mechanism -which includes the DEUNA
as yes the real device has switch packs for CSR and vector so the information
flow there is from the card TO the OS for both CSR and vector. So obviously
suggesting that was a mistake.
I misremembered as well, and thought the vector was programmable on the
DEUNA/DELUA, but it was not. Simple mistake. Easy to correct once it was
figured out. Problem being then that simh didn't allow the user to set
the vector. A bug that now has been fixed then.
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
It's not a new vs old thing. The DELUA is a very new controller. Still
have the same programming model as the DEUNA (which actually also is a
pretty new controller).
Rather few controllers have programmable vectors.
Second, the DEQNA/DELQA only have two fixed configurations on the real
hardware. You cannot set arbitrary CSR address or vector on them, so it
makes total sense that this cannot be set in simh either. You essentially only
have one switch on the real hardware to say if this is controller #0 or
controller #1. And that's it.
The only addresses I have seen DEQNA show are the (preassigned) 174440 (XQ)
and 174460(XQB) - which is set when they are each enabled. No other addresses
available or relevant. But XQ/XQB also has programmable vectors (which I had
already seen the evidence of.)
Yes. Like I said. There can only be two DEQNA. And they have fixed
configurations. But yes, my mistake, the vector is programmable. But the
CSR can only have one of two addresses.
Whereas the XU &XUB ethernet devices can only have their vector values
assigned when auto-config is enabled which then assigns both CSR and
vector values. whereas other devices only auto-assign the CSR address and
rely on the OS vector assignment toset the simh vector within the simh driver
routine. If autoconfig is disabled when XU &XUB are enabled while their CSR
values can be assigned manually their vectors cannot which means that
when we return to simh after shutting down the OS we will find that both XU
& XUB devices still do not have vectors associated with them.
The OS vector assignment have nothing to do with this. We're talking about
simh configuration. With the exception of devices which have software
configured vectors (UDA-50 being the one I can think of), it's all set in simh,
and any PDP-11 OS have nothing to do with this - apart from the 3 device
exceptions
The only point of this paragraph was to (probably redundantly) explain that the
bug associated with XUB also effected XU as currently XU simh device is missing
the ability to manually set the vector as is XUB.
Right. The above mentioned bug.
The OS vector assignments are a human deciding on based on the known "rules" and then
entering values in sysgen and netgen that will be the same as configured simh values - with any
simh <no vector> devices having a vector value entered in sysgen or netgen that is in
accordance with the DEC fixed/floating vector assignments..
The "no vector" thingy in simh is a bit of an abnormaly. It's a kind of
state that cannot exist on real hardware.
So what happens in simh in this case is a weirdo no matter what. And it
would appear that if simh is in autoconfiguration mode, it will assign
addresses at start then, while if not, they do not have a vector, even
when the PDP-11 is running, which is weird.
But if it assigned some vector for devices with a programmable vector, I
don't know. It might. But that would then always be overwritten anyway.
But for a controller without programmable vectors, the controlled is
then catatonic if you are not in autoconfigure mode.
Any device in simh with a "no vector" will not get a vector matching
whatever has been done in SYSGEN or NETGEN, since simh have no way of
knowing what was done in SYSGEN or NETGEN. And SYSGEN/NETGEN also cannot
know the vectors set in simh reliably, as mentioned earlier.
Essentially, both sides needs to be set, independently, but using the
same values, for things to work. The one exception being devices with
programmable vectors, for which you should not be able to even set a
vector in simh.
The PDP-11 cannot set, or even tell, what the expected vector should be.
It is set on dip switches on the hardware, and the OS merely expect
interrupts to happen at whatever vector you configure on the software side,
but the software do not have any way of telling the hardware what vector is
expected.
Of course it doesn't. The human sets the vectors - if they are a compatible set when
they are loaded into sysgen/netgen and the resulting system built and booted all the
vector values will be accepted as they are assigned by the appropriate driver. If the
vector value chosen is wrong then when the assign vector attempt occurs it will be
rejected. The human sets the hardware card in the real cases where the boards have
vector switchpacks or where the device is an exception the vectors are defined by the
human and only in those cases loaded into the equivalent simh device by a driver
routine so that XQ/XQB/TQ/RQ/RQB simh devices will then be able to display their
vector values. How else are those devices with <no vector> set prior to boot
able to show dev and display their assigned vec values after the OS is shutdown and
you are back to simh.
Nothing will reject the "wrong" vector.
As for the devices with programmable vectors, those controllers also
obviously have vectors. It's just that you cannot set or change them
from simh. However, simh can certainly show the vector that have been
programmed into them.
It is the human that decides what vector values to enter into the sysgen &
netgen but the values already obtained from simh for most devices (excepting
DEQNA/TK50/KDA50 - all of the CSR values should have come from simh as that is
where they are either autoconfigured or set manually by a human.
All vectors (minus the exception devices) are loaded into sysgen/netgen -
basically the same values you would load onto switchpacks or autoconfigured by
simh
Yes, in the end, the human decides all CSR addresses and vectors. He can
do it by applying the autoconfiguration rules, or pick values totally
random on his own. Don't really matter.
And no values "come from simh" in the strict sense. They come from the
human, who enters them on both sides. However, with simh, the human can
let simh run through the autoconfiguration algorithm, and read the
values out, and use those for SYSGEN/NETGEN. But they are not fed
directly from simh into SYSGEN/NETGEN (unless you then count the probing
attempts by the PDP-11 autoconfiguration software that, based on the
autoconfiguration rules tries to detect what hardware is available).
You are confusing how things happen.
Unfortunately the 5 exception devices happen to all be in my system and their
vectors are set by the human filling in the sysgen and netgen data - which are
then (usually) assigned by the OS when the driver asks for that vector to be
assigned. Usually it will be granted but if the human picks the wrong vector it
may clash and the OS will reject the assignment request. I think that is how it
works.
Now in most cases while the OS driver knows the CSR VEC values simh only knows
about what addresses that have been assigned and for devices with switchpacks
it will also know the vector value.
It's really simple: You configure simh with CSR addresses, and it
appropriate cases a vector.
You then boot the PDP-11. The PDP-11 OS will install interrupt handlers
for the device drivers it installs, and they will use whatever vector
have been configured in the PDP-11 OS. Totally independent of what you
might have been doing in simh.
The PDP-11 OSes usually contains checks that you don't install two
different device drivers with the same interrupt vectors, since that
would obviously be a bad thing. But this is all totally within the
PDP-11 OS, and totally independent of what you might have done in simh.
Finally, if you have a controller with a programmable vector, everything
works exactly the same, with the only difference being that you do not
set anything in simh.
For the DEQNA TK50 & KDA50 they as mentioned previously have programmable
vectors which allows the driver code to write to the low level simh driver for that
device and write the vector value to the driver field containing the vector. The
simh driver for the KDA50/UDA50, TK50 and DEQNA have to know the vector else the
device won't be able to call the correct vector when the interrupt occurs.
Of course. And those controllers also have a vector. No different from
any other device. The only difference is that you cannot set it through
a command in simh.
The other device get their CSR/VEC from their simh config as autoconfig or manually
set by a human. In the real world the microcode within the peripheral will read the
CS & VEC switchpacks and self-configure its registers to respond to the CSR
address as well as setting itself to respond at the vector as well.
Most controllers don't even have any microcode. The dip switches are
directly connected to gates in the hardware which goes either to a
comparator for the CSR address, or the data bus gated with the interrupt
acknowledge for the vector.
But that is actually pretty irrelevant low level details anyhow. In the
end, it's just that there is a CSR address and an interrupt vector.
Through whatever magic, it causes the CSR to be accessible at a certain
address in the Unibus address space, and at interrupt, you will end up
getting an interrupt at a certain vector.
As XU &XUB are the only devices that require autoconfig (and there is no
override to re-enable autoconfig for just XU, XUB) then to eliminate this
inconsistency there are a few options:
I would not expect only ethernet to require this.
In the real world, *every* controller needs to have it's CSR address
programmed by dip switches or jumpers. simh just gives you a convenient
way of not having to do this step, which you always had to do on the real
hardware.
And almost every controller also required you to set the vector.
Except XQ/XQB/TQ/RQ/RQB simh devices
That was what the "almost" was there for.
It's actually three types of controllers. The fact that you might have
more than one instance of any of these types don't make them more. :-)
The three types are the MSCP controllers, TMSCP controllers, and the
Qbus ethernet controllers.
Finally you would install your OS. In the OS you then also had to configure
the system with the same information that you had already set on all the
hardware. Since a few controllers have predefined values for the first
controller, this was usually enough to bring up the initial installation system,
so you could then continue with the system generation for the full system.
And as long as the chosen addresses/vectors agree with fixed/floating device
rules you should end up with a working environment. Get the CSR or vector wrong
then the system may hang or even crash.
Yes and no.
If you start from scratch, you set up a system with all the devices it
should have, you then pick all addresses according to the floating
address rules. You then boot the installation system, and you can even
run the autoconfigure software that will probe and find out what
hardware you have, and you run your SYSGEN, and you will have a correct
system that boots and runs.
If you then add a device, and assign addresses according to the floating
space rules, your system will most likely not work.
If you are fortunate, it works well enough for you to run a new SYSGEN,
but it might not even do that.
simh then have a feature where it will assign CSR addresse and vectors
automatically, according to the autoconfiguration rules DEC defined.
Using this, you do not need to manually configure each device in simh.
However, the obvious risk with this is that if you add a single device, your
whole system might stop working because lots of devices suddenly change
their address. Which is why in most real life situations, people did not care
about the DEC autoconfiguration rules.
Which PDP11's had that feature ?- I can't recall seeing it in 11/94 system -
but then we already had a long standing fixed/floating configuration when I
updated the processor to the 11/94 (from 11/84). But then I doubt I would have
looked for autoconfig as we wanted minimal changes with the upgrade to reduce
risk of breaking the systems.
What feature?
Autoconfiguration according to the DEC autoconfiguration rules is a
manual process on real hardware. There is no way any PDP-11 could do
that for you.
Your last sentence is essentially summarizing the point I am trying to
make the whole time. People did *not* follow the DEC autoconfiguration
rules, because it would require you to change the configuration of lots
of hardware as soon as you added anything, breaking all existing
software. People did not do that.
Instead you just picked some free address in the floating address space,
and assigned any newly added devices there.
Which is part of the reason I dislike the simh leaning so much towards
autoconfiguration.
1. it could be made possible to set vectors for XU, XUB manually with
a "set XU(B) vector=xxx" command. (The simplest solution?)
That would be the obvious, correct way of doing it.
And that is what is recommended by Mark also as he found the missing element
value in MTAB that would enable the set vector command for the DEUNA devices as
it was meant to have.
Good.
You seem to think that autoconfigure does something more than it actually
do.
I prefer manual configs - completely. Best way to manage the system especially
when there are clashing priorities that autoconfig might break. I would like
simh to behave completely like a real PDP-11 and allow all peripherals to be
set how their real life device would behave - nothing more.
I was asked why I didn't use autoconfig as an answer to modding DUB vector
assignment - I had missed that part of the PDP11 simh user guide else I might -
but I prefer manual.
And I totally agree with you on this one.
While it is not essential that the XU simh driver be modified to either
support manual vector assignment or for the simh XU routines to set their
internal vector based on the OS assigned value - either enhancement would
be helpful in it allowing continued manual address assignment of simh
address values for the PDP11.
You cannot set the address or vector based on the OS assigned values.
Those values are not visible to simh.
The only source of CSR/vector values is the human that decides what they should
be in accordance to DEC fixed/floating rules - as long as that produces a
viable system configuration.
Only source is human - agree.
In accordance with DEC fixed/floating rules - don't agree. Most of the
time, hardware was not configured based on that.
Having run the sysgen /netgen and had each driver request their assigned vector
and been granted that vector - with the exception simh devices having
programmable vectors XQ/XQB/TQ/RQ/RQB simh devices which are set by the OS
driver mechanism that writes those vector values to the simh device driver so
those exceptions know what their vectors are and as long as the OS grants the
vector the system is ok. The human may also get it wrong too.
With every other device (in real world their csr/vec is set by switchpacks)
they are set on each device and the controller on that board reads the
switchpack and then knows to respond to the set CSR and use the assigned vector
as interrupt.
Driver's don't request vectors. The device driver database have a vector
(and a CSR address).
When the system boots, device drivers gets loaded and installed.
The loader first reads the code and database into memory. It then checks
if the vector is already taken. It also does a simple check to see if
there is something responding at the given CSR address.
If the vector is already taken, or of nothing responds on the CSR
address, the device driver loader will refuse to install the device
driver. So it will be loaded into memory, but not installed into the
system. If the vector is free, and the CSR have something that responds,
the driver gets installed, at which point the vector is set up, and the
device driver gets called at a startup entry point.
When the driver have been loaded and installed, it then starts running.
And with a device like a MSCP controller, it then starts the
initialization process with the controller, and as a part of that
initialization, the vector will also be programmed into the controller.
And the device driver also reads that vector out from the device driver
database.
The device driver database is a structure created by the SYSGEN process.
The technical name for it in RSX is the DCB (device control block).
And the CON command in RSX-11M-PLUS can modify the DCB.
Being able to assign CSR address and vector values to the PDP11
peripherals and then boot off a distribution disk and running a sysgen to
build a complete PDP11 RSX11M-PLUS system adds to the sense of
achievement so fixing the simh XU driver to fix this issue that breaks manual
simh configs is preferred so as to allow manual configs with DEUNA device(s)
present. While I see value in simh autoconfig I'd also like to still be able to
fully manual config the simh PDP11 system just as the real PDP11 systems do.
I'm still not entirely clear what the problem you hit was, but anyway, I think
I've summed up now how I think things should work.
I'll explain
[...]
Essentially, the bug already sorted out now then.
A silly bug, made more confusing because the way autoconfiguration works
in simh...
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
