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@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]

> Sent: Monday, 31 January, 2022 08:15

> To: 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]

>> Sent: Sunday, 30 January, 2022 18:25

>> To: The Hobbyist DECnet mailing list <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@lists.dfupdate.se To unsubscribe send

>> an email to hecnet-leave@lists.dfupdate.se

>> 

>> _______________________________________________

>> HECnet mailing list -- hecnet@lists.dfupdate.se To unsubscribe send

>> an email to hecnet-leave@lists.dfupdate.se

>

 

--

Johnny Billquist                  || "I'm on a bus

                                   ||  on a psychedelic trip

email: bqt@softjar.se             ||  Reading murder books

pdp is alive!                     ||  tryin' to stay hip" - B. Idol

_______________________________________________

HECnet mailing list -- hecnet@lists.dfupdate.se To unsubscribe send an email to hecnet-leave@lists.dfupdate.se