I did a little checking on the code.
If the KG11 is configured, it is used for *all* CRC computations. There
are no exceptions that I can find. However, I should point out that the
DUP11 also have built-in CRC generation. So I suspect that DECnet is
only computing the CRC for the header itself, since that needs to be
baked into the message, and the CRC for the full packet is left to the
DUP11 to add.
At the end of the use of the KG11 by DECnet, it restores the state of
the KG11 to whatever it was previously set to. The comments just say
that the device is shared, and thus the previous state is restored.
That's probably why you see the setting back to Crc-12 at the end.
Also, DECnet does not use the KG in the receive processing or transmit
processing itself. It does the CRC computation before any transmission
is done, or after all reception is complete.
So no need for multiple KG11 units.
Johnny
On 2022-02-02 00:44, R. Voorhorst wrote:
The annotated debug snippet speaks for itself.
As the KG11 passes the basic exercises normal Crc-16 operation is
assumed.
However a certain Decnet11MP KG11 support code sequence seems to
trigger one intermediate single cycle run destroying the checksum,
hence the bad header checksum.
In which way the second part of the data message is checksummed
appears to be done in software instead of with KG11 support.
Also with multiple KG11’s, only one is used, contrary to KG11
operation advice for full duplex lines (at least 2 KG11’s).
To be continued …
Reindert
-0> set deb g:\temp\Swbu12_Dup_Ddcmp_202202012330.log
Debug output to "g:\temp\Swbu12_Dup_Ddcmp_202202012330.log"
Debug output to "g:\temp\Swbu12_Dup_Ddcmp_202202012330.log" at Tue Feb
1 23:30:51 2022
PDP-11 simulator V4.0-0 Current git commit id: 885277e1
Swbu12> sh deb
Debug output enabled to "g:\temp\Swbu12_Dup_Ddcmp_202202012330.log"
Device: KG Debug=REG;POLY
Device: DUP Debug=PKT;XMT;RCV
Swbu12> set kg deb=cycle
Swbu12> c
>KG0: rd SR 000200, PC 140204
>KG0 rd BCC 000000, PC 140206
*>>KG0: wr SR 000133, PC
140212 Prime with Crc-16
sum of initial data packet 0x81*
*>>KG0 poly LRC-16 16 Only way to set Bcc to a value*
*>>KG0: rd SR 000313, PC 140214*
*>>KG0: wr DR 060300, data 060300, PC 140220*
*>>KG0: cycle s BCC 000000 DR 060300*
*>>KG0: cycle e BCC 000000 DR 030140*
*>>KG0: cycle s BCC 000000 DR 030140*
*>>KG0: cycle e BCC 000000 DR 014060*
*>>KG0: cycle s BCC 000000 DR 014060*
*>>KG0: cycle e BCC 000000 DR 006030*
*>>KG0: cycle s BCC 000000 DR 006030*
*>>KG0: cycle e BCC 000000 DR 003014*
*>>KG0: cycle s BCC 000000 DR 003014*
*>>KG0: cycle e BCC 000000 DR 001406*
*>>KG0: cycle s BCC 000000 DR 001406*
*>>KG0: cycle e BCC 000000 DR 000603*
*>>KG0: cycle s BCC 000000 DR 000603*
*>>KG0: cycle e BCC 100000 DR 000301*
*>>KG0: cycle s BCC 100000 DR 000301*
*>>KG0: cycle e BCC 140000 DR 000140*
*>>KG0: cycle s BCC 140000 DR 000140*
*>>KG0: cycle e BCC 060000 DR 000060*
*>>KG0: cycle s BCC 060000 DR 000060*
*>>KG0: cycle e BCC 030000 DR 000030*
*>>KG0: cycle s BCC 030000 DR 000030*
*>>KG0: cycle e BCC 014000 DR 000014*
*>>KG0: cycle s BCC 014000 DR 000014*
*>>KG0: cycle e BCC 006000 DR 000006*
*>>KG0: cycle s BCC 006000 DR 000006*
*>>KG0: cycle e BCC 003000 DR 000003*
*>>KG0: cycle s BCC 003000 DR 000003*
*>>KG0: cycle e BCC 101400 DR 000001*
*>>KG0: cycle s BCC 101400 DR 000001*
*>>KG0: cycle e BCC 140600 DR 000000*
*>>KG0: cycle s BCC 140600 DR 000000*
*>>KG0: cycle e BCC 060300 DR 000000*
>KG0: wr SR 000111, PC 140224
*>>KG0 poly CRC-16
16
To regular Crc-16 word mode*
*>>KG0: rd SR 000311, PC 140226*
*>>KG0: wr DR 140014, data 140014, PC 140272 Add
bytes 0C C0*
*>>KG0: cycle s BCC 060300 DR 140014*
*>>KG0: cycle e BCC 030140 DR 060006*
*>>KG0: cycle s BCC 030140 DR 060006*
*>>KG0: cycle e BCC 014060 DR 030003*
*>>KG0: cycle s BCC 014060 DR 030003*
*>>KG0: cycle e BCC 126031 DR 014001*
*>>KG0: cycle s BCC 126031 DR 014001*
*>>KG0: cycle e BCC 053014 DR 006000*
*>>KG0: cycle s BCC 053014 DR 006000*
*>>KG0: cycle e BCC 025406 DR 003000*
*>>KG0: cycle s BCC 025406 DR 003000*
*>>KG0: cycle e BCC 012603 DR 001400*
*>>KG0: cycle s BCC 012603 DR 001400*
*>>KG0: cycle e BCC 125300 DR 000600*
*>>KG0: cycle s BCC 125300 DR 000600*
*>>KG0: cycle e BCC 052540 DR 000300*
*>>KG0: cycle s BCC 052540 DR 000300*
*>>KG0: cycle e BCC 025260 DR 000140*
*>>KG0: cycle s BCC 025260 DR 000140*
*>>KG0: cycle e BCC 012530 DR 000060*
*>>KG0: cycle s BCC 012530 DR 000060*
*>>KG0: cycle e BCC 005254 DR 000030*
*>>KG0: cycle s BCC 005254 DR 000030*
*>>KG0: cycle e BCC 002526 DR 000014*
*>>KG0: cycle s BCC 002526 DR 000014*
*>>KG0: cycle e BCC 001253 DR 000006*
*>>KG0: cycle s BCC 001253 DR 000006*
*>>KG0: cycle e BCC 120524 DR 000003*
*>>KG0: cycle s BCC 120524 DR 000003*
*>>KG0: cycle e BCC 170253 DR 000001*
*>>KG0: cycle s BCC 170253 DR 000001*
*>>KG0: cycle e BCC 074125 DR 000000*
>KG0: rd SR 000311, PC 140274
*>>KG0: wr DR 000401, data 000401, PC 140272 Add
bytes 01 01*
*>>KG0: cycle s BCC 074125 DR 000401 Bug triggered? Single step
instead of 16 steps*
*>>KG0: cycle e BCC 036052 DR 000200 This destroys the checksum*
>KG0: rd SR 000311, PC 140274
>KG0: rd SR 000311, PC 140242
*>>KG0: wr SR 000301, PC
140242 Switch to Crc16
single byte mode*
*>>KG0 poly CRC-16 8*
*>>KG0: wr DR 000001, data 000001, PC 140244 Add
last byte 01 from 1e part of data message*
*>>KG0: cycle s BCC 036052 DR 000001*
*>>KG0: cycle e BCC 137024 DR 000000*
*>>KG0: cycle s BCC 137024 DR 000000*
*>>KG0: cycle e BCC 057412 DR 000000*
*>>KG0: cycle s BCC 057412 DR 000000*
*>>KG0: cycle e BCC 027605 DR 000000*
*>>KG0: cycle s BCC 027605 DR 000000*
*>>KG0: cycle e BCC 133703 DR 000000*
*>>KG0: cycle s BCC 133703 DR 000000*
*>>KG0: cycle e BCC 175740 DR 000000*
*>>KG0: cycle s BCC 175740 DR 000000*
*>>KG0: cycle e BCC 076760 DR 000000*
*>>KG0: cycle s BCC 076760 DR 000000*
*>>KG0: cycle e BCC 037370 DR 000000*
*>>KG0: cycle s BCC 037370 DR 000000*
*>>KG0: cycle e BCC 017574 DR 000000*
>KG0: rd SR 000301, PC 140246
>KG0: rd SR 000301, PC 140254
>KG0: wr SR 000311, PC 140254
*>>KG0 poly CRC-16 16 Back to Crc16 word mode and read faulty Bcc *
*>>KG0 rd BCC 017574, PC 140310*
>KG0: wr SR 000133, PC 140314
*>>KG0 poly LRC-16 16 Load withnew residual result? Logic?*
*>>KG0: rd SR 000313, PC 140316*
*>>KG0: wr DR 000000, data 000000, PC 140322*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*>>KG0: cycle s BCC 000000 DR 000000*
*>>KG0: cycle e BCC 000000 DR 000000*
*/>>KG0: wr SR 000200, PC 140324 Why
Crc-12. Illogical./*
*/>>KG0 poly CRC-12 6/*
DBG(1288653094)> DUP PKT: Line0: >>> XMT Packet len: 22
DBG(1288653094)> DUP PKT: Data Message, Count: 12, Num: 1, Flags: SQ,
Resp: 1, HDRCRC: BAD, DATACRC: BAD
DBG(1288653094)> DUP XMT: Line:0 0000 *81 0C C0 01 01 01* */_7C 1F_/*
01 2A 04 03 40 02 02 00 ......|..*..@... *How is the data part
chscksum generated? Not via KG11.*
DBG(1288653094)> DUP XMT: Line:0 0010 00 0F 00 00 */_3F
AE_/* ....?.
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se]
Sent: Monday, 31 January, 2022 10:22
To: hecnet(a)lists.dfupdate.se
Subject: [HECnet] Re: KG11 emulation probably defective -->diagnostic
ZKGAB0 for KG11 runs without complaints. --> Crc on Rsx11 async lines
It's supposedly used for everything that needs a CRC where the
hardware device itself don't provide it.
Basically, the CRC16 computation is a service in the DECnet executive
environment. As such, anything that needs a CRC16 computation done
calls this same service. And that service then makes use of the KG11
if it has been configured to do so.
No reason to have multiple implementations of this computation. The
DECnet executive is a pretty neat thing in RSX. It's like an operating
system of its own inside RSX, with its own scheduler, memory
management, and various services.
Johnny
On 2022-01-31 09:50, R. Voorhorst wrote:
By the way, Johnny, was KG11 also used on serial
async Decnet11MP
lines or was that always software?
Reindert
-----Original Message-----
From: Johnny Billquist [mailto:bqt@softjar.se
<mailto:bqt@softjar.se>]
Sent: Monday, 31 January, 2022 08:15
To: hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>
Subject: [HECnet] Re: KG11 emulation probably
defective -->diagnostic
ZKGAB0 for KG11 runs without complaints.
I agree that it would be nice to confirm that
this works in real
hardware, but I also find it unlikely that it
wouldn't.
While DEC was not perfect, I would expect that
they actually had
tested this before releasing the software.
Johnny
On 2022-01-31 01:51, R. Voorhorst wrote:
> @Dave:
>
> It would only be worth the time and energy to
prove if current
> Decnet11MP in combination with KG11 would
work in a Dup to Dup or Dmc
> connection, which in hardware take a serious
effort.
> In virtual reality it is far more easy to
arrange such things.
> Unless I cannot find a bug quickly enough,
then it could be helpful
> to request you to check on it.
>
>
> Thanks though for the time being.
>
> Reindert
>
> -----Original Message-----
> From: Dave McGuire
[mailto:mcguire@neurotica.com
<mailto:mcguire@neurotica.com>]
> Sent: Sunday, 30 January, 2022 18:25
> To: The Hobbyist DECnet mailing list
<hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se>>
> Subject: [HECnet] Re: KG11 emulation probably
defective -->diagnostic
> ZKGAB0 for KG11 runs without complaints.
>
> On 1/30/22 12:21 PM, Mark Pizzolato - Info
Comm wrote:
>> On Sunday, January 30, 2022 at 5:34 AM,
Reindert wrote:
>>> 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.
>>
>> We really don't know how robust the
diagnostic is and if it
>> exercises the same details that are used
by the DDCMP
implementation.
>>
>> You could run the DDCMP case with KG11
debugging enabled and
>> identify what
> it is doing precisely and then go back and
see if the diagnostic is
> doing the same stuff...
>
> I have a KG11-A board; if it would be
helpful, I can install it
> in a
> PDP-11 at LSSM perhaps this week.
>
> -Dave
>
> --
> Dave McGuire, AK4HZ
> New Kensington, PA
>
_______________________________________________
> HECnet mailing list --
hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe
send
> an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
>
>
_______________________________________________
> HECnet mailing list --
hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe
send
> an email to hecnet-leave(a)lists.dfupdate.se
<mailto:hecnet-leave@lists.dfupdate.se>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se <mailto:bqt@softjar.se> || Reading
murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
<mailto:hecnet@lists.dfupdate.se> To unsubscribe send an email to
hecnet-leave(a)lists.dfupdate.se <mailto:hecnet-leave@lists.dfupdate.se>
_______________________________________________
HECnet mailing list -- hecnet(a)lists.dfupdate.se
To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se