On Saturday, January 29, 2022 at 4:04 PM, R. Voorhorst wrote:
L.S.
With a bit time on hand and the standstill after Paul's initial test from dup to
pydecnet which appeared to be successful, I now undertook a test as Mark
liked to have it preferably.
So I did a fresh netgen on a simple configuration from simple basic install
Rsx11MP system for only a Decnet end-node with one single Dup line
communicating to a known working Pdp11 Rsx11MP Dmc circuit.
I saw no difference from what I reported initially and later with logging, as
was to be expected; my complex setup behaves exactly the same in this
respect as it does for years in a complex network setup for Rsx and Rsts, and
RT11 without network.
This is on a Windows-2008R2 server and I suspect Paul did his test on
unix/linux , however although it differs, that should be moot as far as Simh is
concerned.
There could be another difference though. Paul would probably have taken
the default route and used Ddcmp withouth KG11 support: Dup without Kdp
is the only sync line to use it, though async Decnet DL/DZ/VH might use it as
well.
As I prefer the most complex configs possible (any two of a kind where
possible as Dec used to have them), I do also employ the KG11, so for Dup
support it will be used when configured so in Decnet11MP.
On a sim it is not that effective, but in hardware in the past it did make a
difference for fast crc computing.
So I retested with no KG11 support and indeed, now the Dup works as
expected.
What appears to be strange is, that small packets up to 8 bytes are not
corrupted but the larger ones do. Maybe in Decnet11MP, the small packets
are totally preconfigured in the software program with crc inclusive and the
KG11 is then bypassed effectively, bu, that should have to be verified. At
least the combination KG11 and Decnet11MP KG11 support is defective.
So Simh Dup works in software Ddcmp packet generation, but the Simh KG11
seem to generate bad checksums and/or checks.
For the Pdp8A, I have a functioning KG8 simulation that works in Rts-8, so
there is a test reference to fall back on.
So I admit and confirm that basic Dup in simh software wise between Pdp11's
and with various counterparts (DMC) indeed works, which would make it
serve as a base for other sync line implementations like DP8-E(A).
So, you've proven to yourself that the KG11 is at least somewhat broken.
Looking back at the change history for this device, I've made changes relating
to how it glues into the PDP11 I/O space, but nothing at all about how the
device actually functions.
What else uses this device?
Is there a diagnostic?
- Mark