2 Feb
2022
2 Feb
'22
12:44 a.m.
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
>
>
>
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: <mailto:bqt@softjar.se> bqt(a)softjar.se || Reading
murder books
pdp is alive! || tryin' to stay hip" - B. Idol
_______________________________________________
HECnet mailing list -- <mailto:hecnet@lists.dfupdate.se>
hecnet(a)lists.dfupdate.se To unsubscribe send an email to
<mailto:hecnet-leave@lists.dfupdate.se> hecnet-leave(a)lists.dfupdate.se
>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: <mailto:hecnet@lists.dfupdate.se>
hecnet(a)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 <
<mailto:hecnet@lists.dfupdate.se>
hecnet(a)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 --
<mailto:hecnet@lists.dfupdate.se>
hecnet(a)lists.dfupdate.se To unsubscribe send
> an email to
<mailto:hecnet-leave@lists.dfupdate.se>
hecnet-leave(a)lists.dfupdate.se
> > _______________________________________________
> HECnet mailing list --
<mailto:hecnet@lists.dfupdate.se>
hecnet(a)lists.dfupdate.se To unsubscribe send
> an email to
<mailto:hecnet-leave@lists.dfupdate.se>
hecnet-leave(a)lists.dfupdate.se
2 Feb
2 Feb
1:13 a.m.
New subject: KG11 emulation probably defective -->some first results
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
--
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
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
>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>
1:27 a.m.
New subject: KG11 emulation probably defective -->some first results
By the way, I do agree that it looks like you spotted the problem, in
that the KG11 seems to just do a single cycle when it should process a
word. Now you just need to figure out why it goes wrong in that way. :-)
Johnny
On 2022-02-02 01:13, Johnny Billquist wrote:
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:
--
Johnny Billquist || "I'm on a bus
|| on a psychedelic trip
email: bqt(a)softjar.se || Reading murder books
pdp is alive! || tryin' to stay hip" - B. Idol
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
--
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
>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>
2:25 a.m.
New subject: KG11 emulation probably defective -->some first results
On Feb 1, 2022, at 7:27 PM, Johnny Billquist
<bqt(a)softjar.se> wrote:
By the way, I do agree that it looks like you spotted the problem, in that the KG11 seems
to just do a single cycle when it should process a word. Now you just need to figure out
why it goes wrong in that way. :-)
Johnny
I think I see the problem, but how the KG11 diagnostic can pass at all is quite beyond
comprehension.
In the data register write, the emulation clears the DONE flag, then if SEN (shift enable)
is set, it begins the checksum update. In normal mode (not single step) it loops on the
"do a step" operation until DONE is set again.
So far so good.
How does DONE get set? In function cycleOneBit, an internal counter PULSCNT is compared
with the count that belongs to the currently configured mode: 6, 8, 12 or 16 depending on
the polynomial. When PULSCNT reaches the limit (more precisely, when it is >= the
limit) DONE is set.
The trouble is that PULSCNT is cleared only by reset and by status register write. It is
NOT reset at the end of a normal byte or word operation. That means that every operation
after the first one will only do one bit, unless the host writes SR after each byte or
word.
The solution seems to be to add a clear of PULSCNT after a byte or word has been
consumed:
static void do_poly (int unit, t_bool step)
{
if (kg_unit[unit].SR & KGSR_M_DONE)
return;
if (step)
cycleOneBit (unit);
else {
while (!(kg_unit[unit].SR & KGSR_M_DONE))
cycleOneBit (unit);
kg_unit[unit].PULSCNT = 0; /* *** ADDED *** */
}
}
paul
1024
days inactive
1025
days old
3 comments
3 participants
participants (3)
-
Johnny Billquist -
Paul Koning -
R. Voorhorst