[Simh] Making Ethernet DEC DELUA available to RSX11M+

Mon Jun 1 12:45:29 EDT 2020

Thanks Mark.  Now sorted.  And btw, I could seem to get network up and running on both the Win10 SimH and the SimH running on my VirtualBox VM (under CentOS 6).

Phil.

-----Original Message-----
From: Simh <simh-bounces at trailing-edge.com> On Behalf Of simh-request at trailing-edge.com
Sent: 01 June 2020 17:00
To: simh at trailing-edge.com
Subject: Simh Digest, Vol 197, Issue 1

Send Simh mailing list submissions to
	simh at trailing-edge.com

To subscribe or unsubscribe via the World Wide Web, visit
	http://mailman.trailing-edge.com/mailman/listinfo/simh
or, via email, send a message with subject or body 'help' to
	simh-request at trailing-edge.com

You can reach the person managing the list at
	simh-owner at trailing-edge.com

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Simh digest..."

Today's Topics:

   1. Re:  Making Ethernet DEC DELUA available to RSX11M+
      (Mark Pizzolato)

----------------------------------------------------------------------

Message: 1
Date: Sun, 31 May 2020 11:38:10 -0700
From: Mark Pizzolato <Mark at infocomm.com>
To: "phil.fisher at peejayeff.co.uk" <phil.fisher at peejayeff.co.uk>,
	"simh at trailing-edge.com" <simh at trailing-edge.com>
Subject: Re: [Simh] Making Ethernet DEC DELUA available to RSX11M+
Message-ID:
	<03006E3FC39B5A48AB9DBCCC101090A8D605738BF2 at REDROOF2.alohasunset.com>
Content-Type: text/plain; charset="utf-8"

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

------------------------------

Subject: Digest Footer

_______________________________________________
Simh mailing list
Simh at trailing-edge.com
http://mailman.trailing-edge.com/mailman/listinfo/simh

------------------------------

End of Simh Digest, Vol 197, Issue 1
************************************