Re: native Dup sync line revisited --> KG11 emulation probably defective --> initial exploration - HECnet

30 Jan 2022

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' &lt;hecnet(a)lists.dfupdate.se&gt;
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 &lt;R.Voorhorst(a)swabhawat.com&gt;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