search

simh / simh

The Computer History Simulation Project
http://simh.trailing-edge.com
Other
1.66k stars 304 forks source link

PDP11 RSX11M+ 2 DEUNA - XUB device not working. (PDP11 RSX11M+ 2 DEQNA XQ, XQB all ok) #731

Closed weffz closed 5 years ago

weffz commented 5 years ago

From testing I have done I found that a simh Unibus PDP11 RSX11M-PLUS 4.6 system with 2 DEUNA devices DECNet and BQTCP networking software that only the first DEUNA ethernet interface works - with the second XUB DEUNA failing to initialize with XUB essentially being dead in the water. The same configuration in a Qbus 11/93 system with 2 DEQNA DECNet and BQTCP works properly with both DEQNA devices - leading to the conclusion that there is an issue with the XUB simh device software.

Detail Using the prebuilt PDP11 binaries from 10th July 2019 as latest testing environment after confirming that the Unibus PDP 11/94 system with 1 DEUNA worked ok and was operational with both DECnet and the BQTCP TCP/IP networking software I decided to try out the same environment but with running with 2 DEUNA to see how the system would operate being attached to two different networks on my PC - the main Internet router plus the private network connecting to a separate router that also links to the primary router for devices on that network needing access to the internet but not from. The Unibus PDP 11/94 system I settled on for these tests was configured as follows: PDP 11/94 with 2044. KW memory, 2 DL11 lines, 1 x DZ-11 8 lines, 2 x DEUNA, 2 x UDA50, 1 x TK50 (This was a cut-down version of the original test environment that had 4 x DZ-11 with overall 32 lines but otherwise the same.)

DL11    YLA csr 176500 vec 300 
DL11    YLB  csr 176510 vec 310
DZ11    YZA csr 160100 vec 410 floating
RL11     RL    csr 174400 vec 160 fixed
DEUNA XU   csr 174510 vec 120 fixed
DEUNA XUB csr 160370 vec 450 floating
UDA50 DUA csr 172150 vec 154 fixed
UDA50 DUB csr 160404 vec 460 floating
TK50     YQ  csr  174500 vec 260 fixed

XU operational XUB non-operational

After starting this system with the RSX11M-PLUS 4.6 distribution disk I performed a sysgen with these devices then a netgen with UNA-0 & UNA-1 followed by configuring BQTCP IPGEN to configure the TCP/IP stack with 2 networks each to be initialized via DHCP. When the system started the DECnet UNA-0 line and circuit started successfully while the UNA-1 failed its initialization. Similarly TCP/IP interface IF0: started successfully and obtained a DHCP lease to 192.168.0.81 while IF1: returned a network failure message -7777 (303) with the IF1: device showing as not working.

After altering the CSR addresses for DEUNA XUB to different csr/vec combinations all I managed to confirm was that XUB device while accepting the address 160370 and had obtained vector 450 from the system correctly - other than that XUB appeared dead in the water.

Normally after the XU interface starts it outputs some diagnostic messages regarding non-supported DEUNA features (not needed for normal use) such as:

XU: unknown ancilliary command 021 requested ! XU: unknown ancilliary command 021 requested ! XU: unknown ancilliary command 01 requested !

However the device XUB has never output any messages in the running environment - so I came to the conclusion that this might be a simh DEUNA driver issue and given the minimal Issues so far received on the DEUNA it is possible that no-one else may have recently tried building a PDP-11 Unibus system with 2 x DEUNA and tried them with DECNet. It is only recently I discovered the BQTCP software and then per chance even wanted to have 2 ethernet interfaces running in the RSX11M-PLUS system . So this potential XUB simh issue might have been in existence for some time with no-one attempting to have a 2 x DEUNA PDP11 system operational.

As a test of this I decided to build another PDP11 RSX11M-PLUS system but with a different ethernet device - the DEQNA driver - creating an equivalent PDP 11/93 qbus system to the one listed above. PDP 11/93 with 2044. KW memory, 2 DL11 lines, 1 x DZ-11 8 lines, 2 x DEQNA, 2 x UDA50, 1 x TK50 Unlike the DEUNA line configuration where the address is manually defined - with the DEQNA both the CSR and vector value are auto-configured by the XQ simh device - which also defined non-standard fixed addresses for both DEQNA interfaces unlike the normal fixed/floating address combination in the unibus environment.

DL11    YLA csr 176500 vec 300
DL11    YLB  csr 176510 vec 310
DZ11    YZA csr 160100 vec 410 floating
RL11     RL    csr 174400 vec 160 fixed
DEQNA XQ   csr 174440 vec 120 fixed
DEQNA XQB csr 174460 vec 130 fixed
UDA50 DUA csr 172150 vec 154 fixed
UDA50 DUB csr 160404 vec 460 floating
TK50     YQ  csr  174500 vec 260 fixed

Both XQ, XQB operational

One aspect of this XQ, XQB auto-config I found was that the RQB device needed to be enabled only after XQ, XQB were enabled else it prevented the XQ csr value being filled and disabled XQ from working. So I revised the order of RQB , TQ config being enabled in the simh ini file to ensure that lower priority devices such as RQB, TQ were only enabled after both XQ, XQB had already been enabled to ensure that all devices were auto-configured correctly. I also made that same order change in the unibus simh ini file for the 11/94 case - but that had no apparent effect so I am unsure whether that was required. With the Qbus PDP 11/93 system that config enabling order is essential else XQ does not work.

After building a new 11/93 RSX11M-PLUS sysgen from the 4.6 distribution to its own qbus system disk I then did a netgen for both QNA-0 and QNA-1 followed by the BQTCP IPGEN for IF0: and IF1: and then started DECnet followed by TCP/IP. With the Qbus 11/93 system with 2 DEQNA interfaces both ethernet interfaces started immediately and both IP interfaces received their own IP address via DHCP from their associated routers without any problems. So - unlike the DEUNA XU, XUB driver - the DEQNA XQ XQB drivers have both been found to be immediately operational - confirming that the system configurations with DECnet and TCP/IP software are correct and that the issue with the XUB interface appears to be within the XUB simh interface.

I also created 2 separate working directories simh/worku and simh/workq on a SSD drive and had the worku directory contain its own pdp11u.exe, simu.ini and its various rz29bnu.dsk files so that it had its own working disk set. I similarly had in the workq directory its own pdp11q.exe, simq.ini and its own working set of rz29bnq.dsk disk set. Then in the unibus 11/94 system that was created as the WMGR (10.2) system, while in the Qbus 11/93 system that was the EMGR (10.1) system - in both cases their obtaining IP addresses via DHCP.

I have run up both PDP11 RSX11M-PLUS 4.6 simh systems on the same PC (in their own unique directories from their own cmd32.exe windows with the DECNet interfaces between these 2 hosts now showing the state is UP via UNA-0 and QNA-0 interfaces while each host is separately able to be accessed via telnet sessions to their configured DHCP address - further confirmation that the DECnet and TCP/IP software is fully working for the Qbus 11/93 with 2 DEQNA's while only working for the 1st DEUNA on the Unibus 11/94 system with 2 DEUNA's. Previously I only had 1 system running on that PC so could not prove out the DECNet networking without that host having another DECNet node to communicate with.

As this PC has 64GB of memory - incorporating 2 x 4GB RSX11M-PLUS systems within the same memory set causes minimal impact.

The version details from the 10th July 2019 prebuilt PDP11 binaries are as follows:

show version from 10 july pdp11 pre-built binaries displays:

sim> show version
PDP-11 simulator V4.0-0 Current
    Simulator Framework Capabilities:
        32b data
        32b addresses
        Threaded Ethernet Packet transports:PCAP:NAT:UDP
        Idle/Throttling support is available
        Virtual Hard Disk (VHD) support
        RAW disk and CD/DVD ROM support
        Asynchronous I/O support (Lock free asynchronous event queue)
        Asynchronous Clock support
        FrontPanel API Version 12
    Host Platform:
        Compiler: Microsoft Visual C++ 15.00.30729.01
        Simulator Compiled as C arch: x86 (Release Build) on Apr 21 2019 at 18:45:33
        Memory Access: Little Endian
        Memory Pointer Size: 32 bits
        Large File (>2GB) support
        SDL Video support: SDL Version 2.0.8
        PCRE RegEx (Version 8.36 2014-09-26) support for EXPECT commands
        OS clock resolution: 1ms
        Time taken by msleep(1): 1ms
        OS: Microsoft Windows [Version 10.0.18362.239]
        Architecture: x86 on AMD64, Processors: 8
        Processor Id: Intel64 Family 6 Model 158 Stepping 9, GenuineIntel, Level: 6, Revision: 9e09
        git commit id: f028802b
        git commit time: 2019-04-21T16:29:45-07:00

I am attaching the simh show device, show cpu iospace, show ethernet commands from each of the Unibus and Qbus systems - apart from the bus type the main difference being the DEQNA csr vec values versus the DEUNA xu xub csr vec values. These are in qbusissue1config.txt and ubusissue1config.txt qbusisssue1config.txt ubusissue1config.txt

As well I am attaching the simu.ini.txt and simq.ini.txt simh initialization files cleaned up from commented out lines not relevant to actual lines needed.

simq.ini.txt

set console log=./consoleq.log
set cpu 11/93
set cpu 4096K
set cpu idle
;set cpu cis
;set cpu autoconfig
set clk 50Hz
set ptr disable
set ptp disable
set rq uda50
;
set rq0 autosize
set -L rq0 RAUSER=8407200
;attach rq0 ra92-0.dsk
; = unibus 11/94 built system
attach rq0 rz29b0q.dsk
;
;set rq vector=154
;
set rq1 autosize
set -L rq1 RAUSER=8407200
attach rq1 rz29b1q.dsk
;
set rq2 autosize
;set -L rq2 RAUSER=8407200
;attach rq2 rsx11mpmq.dsk
;attach rq2 ra92-1.dsk
attach rq2 rz29b2q.dsk
;
set rq3 autosize
set -L rq3 RAUSER=8407200
;attach rq3 rd54.dsk
;attach rq3 rsx11mp0q.dsk
;attach rq3 rsxmpm.qdsk
attach rq3 rz29b3q.dsk
;do sim.ini
;
;
set rl0 locked
set rl0 RL02
set rl0 autosize
;attach rl0 bqtcpq.dsk
set rl1 locked
set rl1 RL02
set rl1 autosize
;attach rl1 bqtcp-revisedq.dsk
set rl2 locked
set rl2 RL02
set rl2 autosize
;attach rl2 cleacdq.dsk
set rl3 locked
set rl3 RL02
set rl3 autosize
;attach rl3 bqtcp.dsk
set tu disable
set tm disable
set rk disable
set rx disable
set hk disable
set rp disable
;
set lpt disable
;
;
set xqb enable
;set xu enable
;set xu type=deuna
;set xu address=17774510
;;;set xu address=17774440
;
;;;;; eth0 ethernet - expressvpn adapter (otherwise numbers are wrong)
; eth0 vmware vmnet8
; eth1 vmware vmnet0
; eth2 Local Area Network 2
; eth3 Bluetooth network connecttion 2
; eth4 WiFi
; eth5 RVS4000
; eth6 NBN;
; eth7 NAT (SLIRP)
; eth8 UDP bridge
;
attach xq eth6
;;;attach xu eth7
set asynch 
;set debug STDERR
;SET XQ DEBUG=TRACE;CSR;VAR;WARN;SETUP;SANITY;REG;PACKET;DATA;ETH
;SET XU DEBUG=ETH;TRACE;REG;WARN;PACKET;DATA
;attach xu nat:tcp=2323:192.168.11.1:23,tcp=2121:192.168.11.1:21,gateway=192.168.11.1,nameserver=192.168.11.1,dhcp=192.168.11.1
;
;set xqb enable
;set xqb type=deuna
;set xqb address=17760370
;;set xqb address=17760370
;
attach xqb eth5
;
set rqb enable
set rqb address=17760404
;set rqb address=17772160
;;set rqb vector=460
set rqb uda50
;
set rqb0 autosize
set rqb1 autosize
set rqb2 autosize
set rqb3 autosize
;1
attach rqb0 rz29b4q.dsk
attach rqb1 rz29b5q.dsk
attach rqb2 rz29b6q.dsk
;attach rqb3 rz29b7q.dsk
;
attach rqb3 rsx11freewarev2q.dsk
;
set tq enable
set tq TK50
;set tq0 format=tpc
;set tq0 locked
;attach tq0 omsi_pascal_v2_0k.tap
;attach tq0 pascal_v1_3.tap
;attach tq0 deckit.tap
;attach tq0 tcpware_2_2_4.tpc
;attach tq whitec.9trk
;show tq type
;show tq all
;
set dli enable
set dlo enable
set dli lines=2
set dlo0 7p
set dlo1 7p
;set dlo2 7p
;set dlo3 7p
;set dlo4 7p
;set dlo5 7p
;set dlo6 7p
set dli address=17776500
set dli vector=300
;attach dli 20011
set dz lines=8
set dz address=17760100
set dz vector=410
;
;
;attach dz 20001
;boot rq0

simu.ini.txt

set console log=./consoleu.log
set cpu 11/94
set cpu 4096K
set cpu idle
;set cpu cis
;set cpu autoconfig
set clk 50Hz
set ptr disable
set ptp disable
set rq uda50
;
set rq0 autosize
set -L rq0 RAUSER=8407200
;attach rq0 ra92-0.dsk
attach rq0 rz29b0u.dsk
;
;set rq vector=154

;set rq1 ra92
set rq1 autosize
set -L rq1 RAUSER=8407200
;attach rq1 ra92-1.dsk
attach rq1 rz29b1u.dsk
;
set rq2 autosize
;set -L rq2 RAUSER=8407200
attach rq2 rz29b2u.dsk
;attach rq2 ra92-0.dsk
;attach rq2 ra92-1.dsk
;
set rq3 autosize
set -L rq3 RAUSER=8407200
attach rq3 rz29b3u.dsk
;set rq3 rd54
;attach rq3 rd54.dsk
; master rsx11mpm boot build
;attach rq3 rsx11mpmu.dsk
;
;attach rq3 rz29b3u.dsk
;attach rq3 rsx11mpm.dsk
;do sim.ini
;
;
set rl0 locked
set rl0 RL02
set rl0 autosize
;attach rl0 bqtcpu.dsk
set rl1 locked
set rl1 RL02
set rl1 autosize
;attach rl1 bqtcp-revisedu.dsk
set rl2 locked
set rl2 RL02
set rl2 autosize
;attach rl2 cleacdu.dsk
set rl3 locked
set rl3 RL02
set rl3 autosize
;attach rl3 bqtcp.dsk
set tu disable
set tm disable
set rk disable
set rx disable
set hk disable
set rp disable
;
set lpt disable
;
;
set xq disable
set xu enable
set xu type=deuna
;set xu type=delua
set xu address=17774510
;;set xu address=17774440
;
;;;;; eth0 ethernet - expressvpn adapter (otherwise numbers are wrong)
; eth0 vmware vmnet8
; eth1 vmware vmnet0
; eth2 Local Area Network 2
; eth3 Bluetooth network connecttion 2
; eth4 WiFi
; eth5 RVS4000
; eth6 NBN
; eth7 NAT (SLIRP)
; eth8 UDP bridge
;
attach xu eth6
;;;attach xu eth7
set asynch 
;set debug STDERR
;SET XQ DEBUG=TRACE;CSR;VAR;WARN;SETUP;SANITY;REG;PACKET;DATA;ETH
;SET XUB DEBUG=ETH;TRACE;REG;WARN;PACKET;DATA
;attach xu nat:tcp=2323:192.168.11.1:23,tcp=2121:192.168.11.1:21,gateway=192.168.11.1,nameserver=192.168.11.1,dhcp=192.168.11.1
;
set xub enable
set xub type=deuna
;set xub type=delua
;;set xub address=17760450
set xub address=17760370
;;set xub address=17774520
;
;SET XUB DEBUG=ETH;TRACE;REG;WARN;PACKET;DATA
;
attach xub eth5
;
set rqb enable
;set rqb address=17772160
set rqb address=17760404
;;set rqb vector=460
set rqb uda50
;
set rq autosize
set rqb1 autosize
set rqb2 autosize
set rqb3 autosize
;
attach rqb0 rz29b4u.dsk
attach rqb1 rz29b5u.dsk
attach rqb2 rz29b6u.dsk
;attach rqb3 rz29b7u.dsk
;
attach rqb3 rsx11freewarev2u.dsk
;
set tq enable
set tq TK50
;set tq0 format=tpc
;set tq0 locked
;attach tq0 omsi_pascal_v2_0k.tap
;attach tq0 pascal_v1_3.tap
;attach tq0 deckit.tap
;attach tq0 tcpware_2_2_4.tpc
;attach tq whitec.9trk
;show tq type
;show tq all
;
set dli enable
set dlo enable
set dli lines=2
set dlo0 7p
set dlo1 7p
;set dlo2 7p
;set dlo3 7p
;set dlo4 7p
;set dlo5 7p
;set dlo6 7p
set dli address=17776500
set dli vector=300
;attach dli 20011
set dz lines=8
set dz address=17760100
set dz vector=410
;
;
;attach dz 20001
;boot rq0

I am yet to see any output whatsoever from the DEUNA XUB device - leading me to believe there is some disconnect within that driver that prevents the XUB device from working.

I have also tried using pdp11.exe prebuilt binaries from 2017 and 2015 in case a not so recent change to the XU driver files was the cause of it not working at all - but all prebuilt pdp11.exe binaries I have tried have the same failure mode with XUB in a Unibus system but complete success in a qbus XQ, XQB environment for an almost identical RSX11M-PLUS configuration with identical networking Software.

The conclusion so far is that there is an issue with the XUB DEUNA driver that prevents it working correctly in a PDP11/93 Unibus system

Geoff

weffz commented 5 years ago

Due to a mixup the qbusissue1config.txt & ubusissue1config.txt are the edited down simq.ini and simhu.ini files and NOT the files for each system showing the results of show dev, show cpu iospace and show ether. The missing files are attached here. qbus2deqnaconfigdetails.txt unibus2deunaconfigdetails.txt

I have also since tried enabling STDERR debug and while there is activity both both xu and xub devices the XUB device appears to stay in xu_process_local() whereas there is quite a bit of activity with xu which makes sense given it is working. However I am not familiar with the xu driver code to determine why the xub interface is not initializing correctly

Geoff

markpizz commented 5 years ago

I'll be glad to track this down, but I won't be in a position to test anything for several days.

It would be really good to see how the XU plus XUB work on the VAX780 simulator. This will help isolate whether we've got a PDP11 or an XU/XUB problem to solve.

R-Voorhorst commented 5 years ago

Oh, that works fine.

I use the Vax8600 as a Hecnet router and both interfaces are operational; una-1 routes Decnet, una-0 handles lat, tcp/ip etc. I operate a recent commit, but not the last.

VAX 8650 simulator V4.0-0 Current
    Simulator Framework Capabilities:
        64b data
        64b addresses
        Threaded Ethernet Packet transports:PCAP:NAT:UDP
        Idle/Throttling support is available
        Virtual Hard Disk (VHD) support
        RAW disk and CD/DVD ROM support
        Asynchronous I/O support (Lock free asynchronous event queue)
        Asynchronous Clock support
        FrontPanel API Version 12
    Host Platform:
        Compiler: Microsoft Visual C++ 19.00.23506.00
        Simulator Compiled as C arch: x86 (Debug Build) on Jun 19 2019 at 10:29:15
        Memory Access: Little Endian
        Memory Pointer Size: 32 bits
        Large File (>2GB) support
        SDL Video support: No Video Support
        PCRE RegEx (Version 8.36 2014-09-26) support for EXPECT commands
        OS clock resolution: 1ms
        Time taken by msleep(1): 1ms
        OS: Microsoft Windows [Version 6.1.7601]
        Architecture: x86 on AMD64, Processors: 4
        Processor Id: Intel64 Family 6 Model 23 Stepping 10, GenuineIntel, Level: 6, Revision: 170a
        git commit id: b3fa1f9f
        git commit time: 2019-06-18T08:01:45-07:00

Regards,

R.V.

markpizz commented 5 years ago

One aspect of this XQ, XQB auto-config I found was that the RQB device needed to be enabled only after XQ, XQB were enabled else it prevented the XQ csr value being filled and disabled XQ from working. So I revised the order of RQB , TQ config being enabled in the simh ini file to ensure that lower priority devices such as RQB, TQ were only enabled after both XQ, XQB had already been enabled to ensure that all devices were auto-configured correctly.

Be aware that once you explicitly set any device's bus address and/or vector you are implicitly disabling autoconfigure from then on (for all devices). Essentially all operating systems should be able to work correctly with autoconfigured device addresses. If you've got some strange statically configured software setup which requires some specific combination of device bus addresses, then you will own properly setting all device addresses and vectors.

Why did you find the need to hard set some device addresses vs merely using auto configured addresses?

weffz commented 5 years ago

After shutting down RSX11M-PLUS .

XU address=17774440-17774447, vector=120, BR5, MAC=08:00:2B:8F:36:E6 type=DEUNA, throttle=disabled XUB address=17760350-17760357*, no vector, BR5, MAC=08:00:2B:07:61:6F type=DEUNA, throttle=disabled

Every other device has a vector value assigned EXCEPT DEUNA #2 XUB which explains why it is not working !!

I have been trying a few different things today to try and narrow down where the problem is and while previously I have only ever had a 1 DEUNA RSX11M+ system - it has always been with using the 1st DEUNA XU on csr 174510 vector 120.

With just the one DEUNA on that address the XU device works fine.

Today I tried having 1 DEUNA - but as the XUB device to at least prove whether by itself the PDP11 XUB device would work.

So I configured DEUNA #2 with CSR 174510 and vector 120 (vector self assigned) and for the first time I have ever seen the one device XUB driver worked ok.

XUB: unknown ancilliary command 021 requested ! XUB: unknown ancilliary command 021 requested ! XUB: unknown ancilliary command 01 requested !

This is at least encouraging as it proves the PDP11 XUB driver works - just that there is some problem with it when you have 2 DEUNA enabled.

For as soon as you enable a 2nd DEUNA ie. XU then only the unit at the first CSR with the preassigned vector of 120 works.

So despite the suggested CSR's from config 11 were used this time (instead of from what [200,200]float.cmd from RSX11M-PLUS still only the first DEUNA was operational.

By looking into this side of things I believe I might have identified the cause of the problems with the 2nd DEUNA device where 2 DEUNA devices are enabled.

Unlike the DEQNA ethernet qbus device XQ which automatically configures CSR as well as VEC values inside simh for both XQ and XQB - with the DEUNA ethernet device XU only the first DEUNA has its CSR and VEC values assigned. While you can configure the CSR address for the second DEUNA unlike the first device (with the fixed address) the 2nd XUB (meant to have a floating address ) does not get assigned a vector from within simh.

In the real world the RSX11M-PLUS DECNet software relies on the user having configured the CSR and VEC values on the physical cards and entering those values in the netgen so when the CEX executive is loaded with the DEUNA device addresses they are configured in the system with the software using them - but unlike most other PDP11 devices in simh the vector assigned in the netgen is never written to within the simh XUB device so the 2nd DEUNA is non-operational as it doesn't know what that vector value is.

I suspect the DEQNA card is similar to the DEUNA in that its CSR and VEC are manually set on the ethernet board too and then told to the PDP11 from those switch blocks and then relies on the owner to fill these values in the netgen.

Normally when you startup PDP11 simh and initialize the devices most of them will display before you boot the operating system - then in RSX11M-PLUS as the device drivers self-configure with the vector value there must be a driver function that writes those vectors into simh device driver so that after you shutdown the operating system and in simh enter show dev all the listed devices should now display their actual CSR and VEC values as obtained from RSX11M-PLUS. I have just done that with my 2 DEUNA Unibus system and while DEUNA XU shows 17774440 vector 120 the second DEUNA is unchanged and still shows 17760350 and no vector.

XU address=17774440-17774447, vector=120, BR5, MAC=08:00:2B:8F:36:E6 type=DEUNA, throttle=disabled XUB address=17760350-17760357*, no vector, BR5, MAC=08:00:2B:07:61:6F type=DEUNA, throttle=disabled

Every other simh device now shows the correct values for their vectors except XUB.

Since each device driver needs an actual vector value to function under RSX11M-PLUS I believe this is most likely the cause why XUB doesn't work.

Either the XU driver needs to save its assigned vector values for both XU, XB or else the XU simh driver needs to fully self-configure both CSR&VEC like the XQ device does - either option should resolve the issue and assign the XUB vector.

Geoff

weffz commented 5 years ago

Why did you find the need to hard set some device addresses vs merely using auto configured addresses?

Because I didn’t know any better – I’ve not been using simh very long and used help set without understanding that setting any address would break autoconfig for the entire configuration.

That is most likely then the cause -so ideally I should never assign an address and allow autoconfig to fill-in the address/vector value in all devices.

I’ve just identified that XUB vector never gets set (after shutting down RSX and dropping back into simh) – caused I guess by my inadvertently disabling the autoconfig.

I will go and remove any address changes and hopefully this will fix things.

Thanks for this - I appreciate your help.

Geoff

weffz commented 5 years ago

Thanks to Mark (and everyone else who contributed) this issue is now resolved.

By setting any address on any of the simh devices in the ini file I inadvertently disabled autoconfig for ALL devices and in the configuration I had with 2 DEUNA unlike most other devices these needed to self-assign CSR/VEC values to work properly.This then resulted in XUB with no vector value.

After removing the address assignments simh now sets a vector for XUB and after re-doing the netgen and some con set device corrections everything now works.

Thanks all - I appreciate the help

Regards

Geoff