[Simh] EXT :Re: Issue #731 - simh PDP11 RSX11M-PLUS Unibus 11/94 system with 2 DEUNA ethernet device XUB not working

[Johnny Billquist]

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: bqt at softjar.se             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol