12 Dec
2021
12 Dec
'21
1:41 a.m.
L.S.
This is the follow-up from the Dup-without-Kdp in character mode discussion
somewhat earlier, where I stated it was not supported per the specifications
in Simh comments and Mark P had some comments about that it was supported.
During a moment of spare time, I reactivated a triple node Rsx-11M+ test
set, used for specific Decnet testing for Phase-I to IV. These triple nodes
were setup for using every possible device for Decnet communications,
amongst them the native (non-kdp) Dup. This one in multipoint mode is
character based and is driven through a Rsx Ddcmp software driver to
participate in Decnet communications.
If Simh Dup simulation is supported in native character mode, this would
establish sufficient proof for a well-functioning character based
synchronous line.
When the Dup line is interfaced to a Dmc line, the test reveals flapping
line behaviour: line up - circuit fault - line down; when trying to
transfer data an immediate circuit fault appears.
When the Dup is interfaced to another Dup, there is packet exchange so
basically it should be able to work. However, although there are no problems
with the lower length (8) signaling packets, the moment 22 char packets are
transferred, the receiver complains about bad header as well as bad data crc
checksums, so the packets are somewhat mangled. It prohibits to start
Decnet communications.
It looks like this in the snippet below:
DBG(10561953465)> DUP RCV: Line:0 0000 81 0C C0 00 01 01 1D DF 01 28 04 01
40 02 02 00 .........(.. at ...
DBG(10561953465)> DUP RCV: Line:0 0010 00 0F 00 00 1D 46
.....F
DBG(10561953465)> DUP RCV: rxnexttime=10561870955 (-20000 usecs)
DBG(10561953465)> DUP PKT: Line0: <<< RCV Packet len: 22
DBG(10561953465)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ, Resp:
0, HDRCRC: BAD, DATACRC: BAD
DBG(10561955696)> DUP PKT: Line0: >>> XMT Packet len: 8
DBG(10561955696)> DUP PKT: Control: Type: 2 (NAK) Reason: 1 (HCRC), Flags:
SQ, Resp: 0
DBG(10561955696)> DUP XMT: Line:0 0000 05 02 C1 00 00 01 85 A9
........
DBG(10561955696)> DUP XMT: rxnexttime=10561953465 (-541 usecs)
DBG(10561955696)> DUP PKT: dup_svc(dup=0) - 8 byte packet transmission
complete
Per Mark P's comment that some kind of filtering takes place in non-kdp dup
mode, that might indicate that the source of the problems could be located
in that corner.
That behaviour needs to be examined.
So it looks that basically character mode Dup is (was meant to be)
supported, but that it needs to be tuned; this functional mode was probably
not tested in the past as the accent was on Ddcmp processing within Simh
for Dmc/Dmr and Kdp/Dup device setups.
Reindert