30 Jan
2022
30 Jan
'22
4:33 p.m.
L.S.
The diagnostics in XXDP for KG11 completes without problems, so far, so
good.
It limits the scope to interface problems between Decnet11MP and Simh KG11.
Reindert
-----Original Message-----
From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com]
Sent: Sunday, 30 January, 2022 16:18
To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: native Dup sync line revisited --> KG11 emulation
probably defective --> initial exploration
L.S.
Reviewing the code from J. Dundas reveals it passed a diagnostic ZKGAB0
which is a xxdp component. There are listings of maindecs, no sources and
the microfiche listing quality is quite low, so restoration of source code
is laborious at best. It also happens to be a component of Anf10 for Tops10
and any image has a quick check for the KG11 if configured to be present.
I think for now the chance that the KG11 itself is somehow corrupt is low
regarding the well specified design path followed in creation, so probably a
mismatch between Rsx11 software and the current KG11 implementation is more
probable cause. It also appears the KG11 was used in the Rsts corner for
Dup, Dp and Du and the Ibm 2780 interfaces.
The docs in simh KG11 does not reveal whether it was tested in a simulated
actual software system.
Lacking the diagnostics sources except Chk11.P11 which is very limited in
scope, XXDP might be the ultimate quickest way to test it.
Reindert
-----Original Message-----
From: R. Voorhorst [mailto:R.Voorhorst@swabhawat.com]
Sent: Sunday, 30 January, 2022 09:53
To: 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se>
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test
on pdp11 --> KG11 emulation probably defective
Apart from morons with an incurable inclination to the complex difficult
thereby shooting in the own feet like me .... ?
I do not know, but I suppose on Rsx11 the serial async Decnet lines might
use KG11 assisted crc16 generation/checking as well and the problem might be
in Rsx11M software itself, less likely, or more likely in KG11 simulation.
Johnny might know this.
As I have done the KG8 I think I am more predisposed to look at the KG11
excepting the writer of the KG11 simulation, so I will check for the
existence of a diagnostic, will see what goes wrong and propose a fix.
KG11 is not a complex device.
Best regards,
Reindert
-----Original Message-----
From: Mark Pizzolato - Info Comm [mailto:Mark@infocomm.com]
Sent: Sunday, 30 January, 2022 01:26
To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>om>; hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: native Dup sync line revisited --> revisited Dup test
on pdp11 --> problem solved: Simh KG11 emulation probably defective
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
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email
to hecnet-leave(a)lists.dfupdate.se