[Simh] Making Ethernet DEC DELUA available to RSX11M+

[Mark Pizzolato]

On Sunday, May 31, 2020 at 10:20 AM, Phil J Fisher wrote:
> The INI file (i.e. the commands) are as below.  And referencing an earlier
> comment, yes it was stupid to use WiFi -- that was my thinking a real network
> would help and not thinking properly.  I am reasonably sure that the results
> would be (almost) identical even if I attached an Ethernet type device.  I tried
> this out and did find exactly same results at the RSX end.
> 
> *** HOWEVER, for those spotting the error in the INI file below, where a line is
> NOT commented out correctly as should have been, I did fix that and re-run
> with the same results/output (the new data for an Ethernet not Wifi also
> shown below the INI file data WHICH HAS NOT HAD THE TYPO FIXED to
> maintain consistency with previous post).

Comments were not the problem.

The problem is:

                > ; Massbus RP06's for system and spare disks (up to 8 drives)...
                > SET RHA VECTOR=254
This line. ^^^^^^^^^^^^^^^^^^^

As the documentation says, explicitly setting a  bus address or a vector
disables the autoconfiguration process that is used to correctly assign 
addresses and vectors using DEC recommended addresses and vectors.

As it turns out, RHA would normally have a vector of 254 with your 
device configuration WITHOUT explicitly setting that value.  Additionally,
most (maybe all) of the other devices in your configuration also got initial 
address and vector values by the autoconfiguration process since they 
happened to be enabled BEFORE you explicitly set the RHA vector.

Fix your problem by removing that SET RAH VECTOR line.

In the future, this will happen when you do something like this:

        PDP-11 simulator V4.0-0 Current        git commit id: f8a1e566
        sim> SET RHA VECTOR =254
        Device auto configuration is now disabled.
        Explicitly setting any address or vector value tells the system
        that you are planning a specific configuration that may not use
        use standard values.  You must explicitly specify bus address and
        vector values for any device you enable or otherwise add to the
        system configuration after this message is issued.  Changing the
        number of lines on a terminal multiplexer is such a change.
        To avoid complexities dealing with this, it is recommended that
        you configure all devices which can use standard addresses before
        changing the address or vector for an unusual device situation.
        sim>

This will let you and others (who've encountered this problem before)
avoid having to stumble into this by accident in the future.  The above 
extended message output can be suppressed if the command that 
inspires its output is invoked with the -Q switch.

> As I tried to say, my goal is to get a network operational on RSX11M+ so that I
> can do some work on various network things (TCP/IP) AND enable file transfer
> (whether over DECNET or TCP/IP is immaterial at this point) to some other
> system.  If I can get a working network adapter seen in RSX then, if that doesn't
> work on the RSX side, I am sure Johnny at least will tell me more.

The above advice will get you there (using the same binary you already have).

> New NETWORK>
> sim> sho eth
> ETH devices:
>  eth0   \Device\NPF_{0CAAD8E0-0523-432A-89C3-29377479808C} (VirtualBox
> Host-Only Network)
>  eth1   \Device\NPF_{A2D25F8C-319D-4D10-A2D1-F612E89065DC} (Local Area
> Connection* 10)
>  eth2   \Device\NPF_{EAE8073C-4368-41F5-9B70-77671D8038DE} (WiFi)
>  eth3   \Device\NPF_{2CEDB723-3207-46CB-A136-081880A0C53A} (VMware
> Network Adapter VMnet1)
>  eth4   \Device\NPF_{87E9C4CC-4570-4792-840C-D13C7E5806B0} (Local Area
> Connection* 2)
>  eth5   \Device\NPF_{3290B149-A507-49C1-86EE-EB9D894D48A1} (Local Area
> Connection* 8)
>  eth6   \Device\NPF_{A5A812CA-928E-4EA9-8738-2E125D177FF3} (Local Area
> Connection* 3)
>  eth7   \Device\NPF_{E4948FE0-C106-4D09-9310-EB0B72477D28} (VMware
> Network Adapter VMnet8)
>  eth8   \Device\NPF_{21E275FA-748D-414E-942D-E86C23FF7260} (Local Area
> Connection* 9)
>  eth9   \Device\NPF_{438585F9-46EB-4060-8674-0029AE4FAEE1} (Ethernet)
>  eth10  nat:{optional-nat-parameters}                      (Integrated NAT (SLiRP)
> support)
>  eth11  udp:sourceport:remotehost:remoteport               (Integrated UDP
> bridge support)
> sim> attach xu0 eth10
> Eth: pcap_open_live error - eth10: No such device exists (No such device
> exists)
> Eth: open error - eth10: No such device exists (No such device exists)

To attach a network interface using NAT: the following command is 
appropriate:

          sim> ATTACH XU NAT:

This will allow outbound TCP connections from the simulator.  No DECnet 
packets will be transported on a NAT connected interface.  To achieve
any incoming TCP connections to the simulator using NAT, just like on 
your home router, you will have to specify extra NAT parameters which 
open (and map) the respective ports.

Otherwise, if you merely want to allow all normal traffic (DECnet, TCP/IP, 
etc.) to/from your host system and/or other systems on your local network
(or beyond) you need to attach to a wired network interface, which in 
your case would be:

          sim> ATTACH XU eth1 (or eth4 or eth5 or eth6)

NAT IP traffic can reach beyond the host system even if you're on WiFi, 
otherwise you will need a wired LAN connection.

- Mark