HECnet

hecnet@lists.dfupdate.se

4 participants
15583 discussions

by Paul Koning

I've put the beta PyDECnet T1.1 up on area router PYTHON. That will make a more interesting test than the previous one (which was to have it running on 28NH, the HECnet mapper). It seems to be working ok, but if anyone sees strange behavior that might be connected to this node, please let me know. The code should be faster, significantly so in a few spots. I suspect that won't be all that noticeable in practice. It should also have some bugs fixed. Among them are some NICE protocol issues: there were problems with reporting adjacent node information some of the time, those should be gone in this code. paul

3 years, 8 months

Re: KG11 emulation probably defective -->solved (by Paul as it is) --> update

by R. Voorhorst

L.S. As the proposed fix by Paul is now in line with the hardware in the drawings, but differs from the initial one he proposed and I tested, I retested it with diagnostics XXDP:ZKGAB0 and real time behaviour and that works as well. Reindert -----Original Message----- From: Paul Koning [mailto:paulkoning@comcast.net] Sent: Wednesday, 02 February, 2022 15:44 To: Reindert Voorhorst <R.Voorhorst(a)swabhawat.com> Cc: HECnet <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: KG11 emulation probably defective -->solved (by Paul as it is) > On Feb 2, 2022, at 4:09 AM, R. Voorhorst <R.Voorhorst(a)swabhawat.com> wrote: > > L.S. > > So in the end I had little to do J (thanks Paul and Johnny), and the updated code by Paul fixes the problem and yes, the diagnostics still complete without complaint. A check of the engineering drawings should verify/confirm how the pulse count is actually terminated/reset in hardware. From the manual (which reproduces a bit of the schematic in support) the more precise definition is that the counter is reset by a data register load. That would make a difference in observable behavior if single step mode is used: DONE would come on after the correct number of single step operations. I'll submit a PR with that version. Thanks Reindert for verifying the fix. paul _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 8 months

Re: KG11 emulation probably defective -->solved (by Paul as it is)

by R. Voorhorst

L.S. So in the end I had little to do :) (thanks Paul and Johnny), and the updated code by Paul fixes the problem and yes, the diagnostics still complete without complaint. A check of the engineering drawings should verify/confirm how the pulse count is actually terminated/reset in hardware. Johnny confirmed with the code analysis the suspicion that KG11 was sparingly used and the bulk crc processing was probably offloaded to either Decnet11MP software or even the Dup11 hardware crc processing capabilities,. That makes the use of the one KG11 needed quite superfluous. It is only used for transmission header checking so it is interesting to see how it functions with async Decnet lines. Second is how this error in the header check propagates to a crc check of the data-body processed elsewhere, but both crc errors disappear with the fix. @Mark: do you need the another serving of the solution by Paul: 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 *** */ } } You can attribute the solution to Paul if attribution is in order as he ultimately found it. Best regards, Reindert -----Original Message----- From: Paul Koning [mailto:paulkoning@comcast.net] Sent: Wednesday, 02 February, 2022 02:26 To: HECnet <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: KG11 emulation probably defective -->some first results > On Feb 1, 2022, at 7:27 PM, Johnny Billquist < <mailto:bqt@softjar.se> 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 _______________________________________________ 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

3 years, 8 months

Re: KG11 emulation probably defective -->solved (by Paul as it is) --> rcv/xmt transmission

by R. Voorhorst

@Johhny: Funny that is, I only see KG11 involvement in the traces in the Xmit header parts, not in any Rcv header parts for the data packets, so it seems (for the Dup11 at least) complete receive packet is checked in Dup11. By the way, in which (CEX?) module in the listings on fiche does one find the crc support with/without KG11? Thanks for your analysis which clarified a lot. Reindert -----Original Message----- From: Johnny Billquist [mailto:bqt@softjar.se] Sent: Wednesday, 02 February, 2022 12:29 To: R. Voorhorst <R.Voorhorst(a)swabhawat.com>; 'The Hobbyist DECnet mailing list' <hecnet(a)lists.dfupdate.se> Subject: [HECnet] Re: KG11 emulation probably defective -->solved (by Paul as it is) The CRC for the data is offloaded to the DUP11. If it was done in software, it would loop in the KG11 again. Like I said, if the KG11 is enabled, it is used everywhere. But the fact is that the DUP11 have built-in CRC check/generation. It would be silly to not take advantage of that. If you use some other interfaces, more will be done in software. For example, the DU11, or indeed any async line, such as a DL or DZ. However, the KG11 is used both at transmit and receive time. But one KG11 is enough, since the whole packet is checked at once, and not piecemeal while the packet is being transmitted/received, which would potentially cause problems if you have multiple interfaces being active in parallel, or indeed full duplex operation. Johnny On 2022-02-02 10:09, R. Voorhorst wrote: > L.S. > > So in the end I had little to do J (thanks Paul and Johnny), and the > updated code by Paul fixes the problem and yes, the diagnostics still > complete without complaint. A check of the engineering drawings should > verify/confirm how the pulse count is actually terminated/reset in hardware. > > Johnny confirmed with the code analysis the suspicion that KG11 was > sparingly used and the bulk crc processing was probably offloaded to > either Decnet11MP software or even the Dup11 hardware crc processing > capabilities,. That makes the use of the one KG11 needed quite > superfluous. It is only used for transmission header checking so it is > interesting to see how it functions with async Decnet lines. > > Second is how this error in the header check propagates to a crc check > of the data-body processed elsewhere, but both crc errors disappear > with the fix. > > @Mark: do you need the another serving of the solution by Paul: > > 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 *** */* > > } > > } > > You can attribute the solution to Paul if attribution is in order as > he ultimately found it. > > Best regards, > > Reindert > > -----Original Message----- > From: Paul Koning [mailto:paulkoning@comcast.net] > Sent: Wednesday, 02 February, 2022 02:26 > To: HECnet <hecnet(a)lists.dfupdate.se> > Subject: [HECnet] Re: KG11 emulation probably defective -->some first > results > > > On Feb 1, 2022, at 7:27 PM, Johnny Billquist <bqt(a)softjar.se > <mailto:bqt@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 > > _______________________________________________ > > 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 || Reading murder books pdp is alive! || tryin' to stay hip" - B. Idol _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 8 months

Re: KG11 emulation probably defective -->some first results

by R. Voorhorst

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

3 years, 8 months

Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective

by R. Voorhorst

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). Reindert -----Original Message----- From: owner-hecnet(a)Update.UU.SE [mailto:owner-hecnet@Update.UU.SE] On Behalf Of Paul Koning Sent: Thursday, 23 December, 2021 20:18 To: hecnet(a)update.uu.se Subject: Re: [HECnet] native Dup sync line revisited --> preliminary tests reveals problems --> test setup? > On Dec 23, 2021, at 4:14 AM, R. Voorhorst <R.Voorhorst(a)swabhawat.com> wrote: > > Hi Paul, > > How was this tested: 11M+ to 11M+ or 11M+ to PyDecnet? M+ to PyDECnet, with Wireshark watching the traffic. I'm going to do some tracing in SIMH. It may be that the behavior depends on how the driver talks to the emulated device. paul

3 years, 8 months

Suits and old software. (was RE: Re: native Dup sync line revisited --> revisited Dup test on pdp11 --> problem solved: Simh KG11 emulation probably defective)

by Keith Halewood

If only one could get into contact with the relevant 'suit' seeking old software. A while back I mentioned Algol68RS and the VAX/VMS version of the compiler I used during my university days... And how I wish I knew where that TK50 was containing a backup I made in... 1987? Ah well. The RS version of the compiler was the work of RSRE Malvern (a Ministry of Defence unit) and the VAX code generator was written at University of Oxford. Significant bits of the RS compiler were released to the public domain as part of Ella and there's a transliterator to C available. It isn't the RS compiler though. Moreover, it is the VAX/VMS version of the compiler. I've been in contact with the two (or is it three) companies, Oxford University, Liverpool University (where I last used that compiler) and in each case, the conversation (if such a word could be used) has dwindled to nothing pretty quickly. In the case of the companies, I can only assume the suits saw no potential profit in it, assuming they knew what 'compiler', VAX, VMS or Algol68 meant. My communication with Oxford may not have gone beyond their 'call management system' and Liverpool's archives in that area don't go back that far and/or the tapes are unreadable.... or Sandra the operator burned the toast again causing halon and sprinkler damage some time in the past. Blah -----Original Message----- From: Johnny Billquist [mailto:bqt@softjar.se] Sent: 01 February 2022 02:39 To: 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 2022-02-01 03:10, Dave McGuire wrote: > On 1/31/22 8:28 PM, Johnny Billquist wrote: >>>> Because for some people, that "near zero risk" is maybe not so >>>> "near zero", and that have actual implications for actual people. >>> >>> Yes, but they've been poorly (and selfishly) prioritized. >> >> Yeah. Tell that to their kids when they are thrown into the street. > > I do see your point, but it's an increasingly hypothetical point. That might be. And I probably agree with it. But each person has to do his own assessment on that point. And it might not look the same for all. >>>> You seem to really just treat it as "there is no risk, so why >>>> aren't people just doing whatever I think they should do", without >>>> considering that for others the situation might actually look very >>>> different. >>> >>> You've jumped to a conclusion about what I think, and (with >>> respect) you're incorrect. I think risking some suit in a glass >>> building getting angry with me, or even filing a lawsuit against me, >>> is not, and will never be, more important than a piece of history >>> that stands to be lost forever. >> >> Seems you just described exactly what I tried do describe above. So >> how did I get it wrong? > > What I'm saying is that it's better to do something for the greater > good, than to "play it safe" with some hypothetical "risk" that some > suit at HPE (or whomever) will somehow come after you about > decades-old software that they've never even heard of. > > I mean, come on. Yes, the potential consequence is huge, but the > risk is vanishingly small. Yes, it has happened, I'm well aware of > that. But the risk is still vanishingly small. Dave obviously was *very* worried about potential risks that he was not willing to take. The amount of papers I had to sign before I got access should tell you something. And he have (had?) information I don't have. So I prefer to not second guess him, but just trust that he made his decisions based on the information he had, and they made sense for him. And I'll just accept that, and respect his decisions. >>>> If you've experienced that recently, then I am a little amazed. >>>> Because that means people have been hanging on to things for a >>>> *long* time, but now they don't care. Which for me sounds like an >>>> unusual situation. >>>> But of course, everything is possible. >>> >>> Then be amazed. It happened most recently just a few months ago, >>> and several times last year. This is a lot more common in the real >>> world than you've assumed. >> >> Hmm. Maybe we're talking about something else than PDP-11 software now? > > Actually it hasn't come up about PDP-11 software; it was VAX > software most recently. Ah. Yes. VAX is a different story. There things are still fresh, so it's a different ballpark. So I apologize. I was very much PDP-11 focused in my responses. VAX, in a way, seems to be falling down into the same pit the PDP-11 is in. But it's far more recent, so a lot of stuff is still around at a different scale. And of course, VMS as such isn't dead, which is kind of a different situation as well. >> Considering that I'm usually even more overlooked than you are, you >> can go with that complaint somewhere else. > > I will (sorry) but everyone who knows what a PDP-11 is knows your > name. ;) Not even that. It's not too uncommon that I get into some discussion and people have no clue. This mailing list and environment isn't exactly representative for people in general out there. Just go check on VCF (or whatever the name is, I can't even remember - vintage computing something...) >> Take PDP-8 stuff for example - I've been around the block, done more, >> seen more, and have more information and stuff than most everyone on >> those lists nowadays. But I don't actually care anymore. They can >> talk and do things as much as they want. I don't need them, and they >> don't even know I exist. Their problem. Not mine. And since it's also >> not a problem for them, it's not a problem at all. > > I'm with you on that. But passing knowledge on is important, and > far too few people do it. The excuse I hear most often is "nobody's > interested in this stuff". From my point, it's more that it's so much a club for internal admiration. People are more interested in their turf than actually finding information. Take the ftp site of Update. It's been around since the early 90s. Still, most people don't know about it. And lots of stuff have been copied out from there elsewhere, and that's where people find various bits and pieces. And a bunch of PDP-8 stuff there are things that I dragged out of numerous disks and DECtapes I have. Most of it done in the 90s. Some of it still totally unknown by others. And various software that I've written as well... >> It's only a problem when you want attention and recognition. > > Or if you just want to be kept in the damn loop once in a while. That mostly happens by accident, unless you are in the center. >> I'm daily facing the same dilemma. I have done so much improvements >> to RSX. I'd like to release V5.0, which I have sitting here. But I can't. >> I signed documents with XX2247 that limits what I can do, and I am >> not willing to break the trust Dave put in me. Even though that >> improved version have lots of stuff that would be really fun to share. >> >> Instead I'm trying to find ways of resolving the problem. Meanwhile >> it's sitting at my place, and nowhere else. > > I will run that within *minutes* of its release. Assuming I'm > still breathing, of course! Who knows when I can do it. I keep hoping... But every year, there will be fewer interested. >>>> Until the day I die... Who knows what happens then. >>> >>> Well, I'm trying to get more (and younger) people interested in >>> PDP-11s, and I'm having pretty good success at that. You could try >>> that too. >> >> I'll leave that to others. I'm busy just fixing things in RSX... >> If someone really interested comes along, I'm happy to help with >> information and guidance, but I'm not trying to enlighten people. > > Well, we do that a lot at LSSM. In particular, there's a teenage > kid who lives in Michigan who is OBSESSED with PDP-11s. He's writing > code in assembler and running it under simh. He doesn't know this > yet, but the next time his parents bring him down here for a visit, > I'm going to give him a PDP-11/73. That should be exciting. :-) Also, will be interesting if it carries over to working on real hardware as compared to simh. Johnny -- 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 _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 8 months

Unsubscribe

by Rien Timmer

Groeten, Rien Timmer

3 years, 8 months

DN60 etc. --> Anf10 family based?

by R. Voorhorst

Thomas, If I recall correctly it is Anf10 related and has it's own runtime and Chk11 for initial testing of hardware. Thus it had to fit in 28 kW; no relations to Rsx11 or even RT11. The code pieces then should be *.P11 etc. Reindert -----Original Message----- From: Thomas DeBellis [mailto:tommytimesharing@gmail.com] Sent: Monday, 31 January, 2022 21:22 To: 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 Then we are probably talking apples and pineapples. The product that I'm talking about is exclusively for the 36 bit line, requiring a DTE to get the data to the PDP-10. I think it also needed a KMC to do some offloading, so the 11/34 could keep up, but I wouldn't swear to it. There's code for a KMC, anyway. The software appears to be a complete embedded design: there are no users, no file system, minimum memory management and no task preemption. Thus, I don't believe it has any code basis in either RSX or RSTS. I wouldn't be surprised if part of it got lifted from RT-11, but I don't have an informed opinion on that. The DN60/DN65 spoke 2780, 3780 and HASP. The first two are remote job entry (RJE) 'workstations' that had card readers and line printers (no terminals). HASP is a variant that IBM did not develop, yet adopted. I believe it was wizzy because it allowed multiple concurrent streams. The job of IBMSPL was to fool the remote IBM host that a card deck was being submitted by a timesharing user and to take the resulting print output and to get it to wherever the right place was (printer, file, etc.) I don't recall a 3271, I guess you mean those green screen terminals? What a beast... I do recall using 3270, 3276 and the like when I was hacking the bisync drivers on VM to talk to IBMSPL. There was a product that you could run on Tops-20 to show up as a 3270 on an IBM box, provided the target spoke TCP/IP. I can't remember the name, but it was based on TELNET negotiating some additional options. It's a lot of work; a 3270 is not like anything you ever heard of in ÅSCII land. A number of us swore that IBMSPL was the only reasonable way to use an IBM mainframe as the 3270 was a half-duplex terminal that was all to ready to lock the keyboard if you even thought of typing ahead. The more modern emulators don't lock like that, but you are still effectively in a late 1960's half duplex paradigm. Still. Today. Really. On 1/31/22 3:00 PM, Paul Koning wrote: > What I mentioned is one or several PDP-11 products, available for RSTS and I believe RSX. There definitely is an "RJ2780 emulator" -- the official name may not be quite that. And I think there was also a 3271 emulator, though I'm not sure if that existed on RSTS. > > I have no idea what these things do, since 2780 is something I've never used. Some sort of remote job entry station? Anyway, it is the only RSTS software that uses a KG11. DECnet doesn't because on RSTS DECnet only supported devices with hardware CRC: DMC and friends and later Ethernet. I did an unsupported software DDCMP, but that does CRC in software (8 bits at a time, the classic table driven fast software implementation). That probably outruns a KG11 and in any case I never had access to that hardware. > > paul > >> On Jan 31, 2022, at 2:52 PM, Thomas DeBellis <tommytimesharing(a)gmail.com> wrote: >> >> I wanted to make sure I wasn't getting lost; are you referring to the PDP-11 software that forms part of the Galaxy IBM workstation product? It's called DN60/DN65 and also does 3780 and HASP. Is this what you're referring to? >> >> On 1/31/22 2:48 PM, Peter Allan wrote: >>> Paul Koning wrote ... >>> >>>> Correct, I was not aware it's possible to use it. The only software I have seen that uses the KG11 is 2780 emulation. >>> I am very interested in getting 2780 emulation for a PDP-11. >>> >>> Paul, or anyone else, do you know where I can get it? >>> >>> Cheers >>> >>> Peter Allan >>> _______________________________________________ >>> 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 _______________________________________________ HECnet mailing list -- hecnet(a)lists.dfupdate.se To unsubscribe send an email to hecnet-leave(a)lists.dfupdate.se

3 years, 8 months

KG11 emulation probably defective -->diagnostic ZKGAB0 for KG11 runs without complaints.

by R. Voorhorst

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>; 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

3 years, 8 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet