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

[Mark Pizzolato]

On Tuesday, July 30, 2019 at 8:18 PM, 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.

You have found a bug, which hadn't been encountered before due to most 
folks counting on autoconfigure working to setup addresses and vectors.

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

XQ and XQB don't currently have manually settable ADDRESS and VECTORs.
If these devices are enabled they get these settings via autoconfigure.  The 
Qbus Ethernet controllers had a single switch which selected either the 
primary device address (17774440) or the secondary board address (17774460), 
so enabling XQ enables the first bus address and enabling XQB enables the 
second bus address.

The DEQNA devices have a vector which is programmed by the Operating 
System device driver.  The autoconfigure logic tracks this info identically to 
how the operating system will be programming the interrupt vector.  This is
done to avoid collision with other devices which may have vectors that are 
set by autoconfigure by actually reflect switch settings on the other device's
board.

> 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.
> 
> In my case it was the manual assignment of XU CSR that disabled system wide
> autoconfig - preventing XUB auto-vector assignment - but I have confirmed
> that by setting the CSR address of another device before XU is enabled that
> neither of XU & XUB will have their vectors assigned.

Manually setting any device ADDRESS or VECTOR will disable autoconfigure and 
thus any device which is enabled after autoconfigure has been disabled will 
have to manually set both the ADDRESS and VECTOR to function properly.

> 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:
> 
> 1. it could be made possible to set vectors for XU, XUB manually with a "set
> XU(B) vector=xxx" command. (The simplest solution?) OR 2.  

This was the original intention, and changing one line in the source from:
  { MTAB_XTD|MTAB_VDV|MTAB_VALR, 0, "VECTOR", NULL,
To:
  { MTAB_XTD|MTAB_VDV|MTAB_VALR, 0, "VECTOR", "VECTOR",
will fix the bug.

> The XU, XUB device driver could be modified to assign the vector through 
> to simh as it is assigned by the OS. (the consistent approach) OR

This would change the programming paradigm for all operating systems which 
supported these devices.  The simh goal is to run the original unmodified 
operating systems and other software that originally ran on these systems.

> 3.Exempt XU XUB autoconfig from being overridden - just like XQ, XQB address
> assignment autoconfigure is always enabled as it is not possible to manually
> assign CSR address values for XQ, XQB devices.
> OR
> 4. Workaround = Always ensure XU, XUB are enabled while autoconfigure is
> enabled - preventing the problem from occurring.
> 
> I'm notsure why it is expected that simh PDP device be autoconfigured always
> - especially where it appears as though almost every PDP device will work
> correctly without it - excepting where 2 DEUNA's are present.
> 
> I started with simh mostly for nostalgic reasons - I worked with PDP11's
> between 1981 and just prior to 2000 when they were phased out in favour of
> Unix hosts - and I treated the simh pdp11 build as I would have when I built
> 11/24, 11/34, 11/84 and finally 11/94 systems with a mix of fixed and floating
> addresses and following the normal assignment "rules" for CSR and vector
> assignment.
> 
> Given a choice I would prefer that simh behaves more like a real PDP-11 and
> also allow complete manual configuration - including both CSR and manual
> vector assignment. Some of the current devices allow vector assignment most
> just vector auto-assignment from the OS - with XU allowing neither in manual
> config mode.

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.