HECnet

hecnet@lists.dfupdate.se

3 participants
15578 discussions

Mailman Question When Using a Forwarding Service

by Rob Jarratt

Hello Everyone, Are there any Mailman experts here? The way I use my email addresses is that I have an email address provided by my ISP (Robert.jarratt(a)ntlworld.com <mailto:Robert.jarratt@ntlworld.com> ), but I use an email forwarding service to forward rob(a)jarratt.me.uk <mailto:rob@jarratt.me.uk> to my ISP mailbox. This means that I can receive email sent to rob(a)jarratt.me.uk <mailto:rob@jarratt.me.uk> , but any email I send comes from Robert.jarratt(a)ntlworld.com <mailto:Robert.jarratt@ntlworld.com> . I do put rob(a)jarratt.me.uk <mailto:rob@jarratt.me.uk> in the reply-to. Can Mailman be configured to accept emails from my outbound address, but send them to my forwarding address? I would like to do this for my subscription to the HECnet list, if possible. If I can't then so be it, but I thought it worth asking. Thanks Rob

3 years, 6 months

Re: [Hecnet] HECnet mail list move

by Rob Jarratt

Hello Johnny, I am not sure if I did get two copies of this email so I don't know if I am on the new system. I don't remember what email I would be registered under, it will either be rob(a)jarratt.me.uk (preferred) or Robert.jarratt(a)ntlworld.com. I don't want to create an account to manage myself until I know which email (if any) I am registered with in the new system. Would you mind checking for me please? Thanks Rob > -----Original Message----- > From: Johnny Billquist <bqt(a)softjar.se> > Sent: 21 January 2022 01:10 > To: hecnet(a)lists.dfupdate.se; hecnet(a)Update.UU.SE > Subject: [Hecnet] HECnet mail list move > > Ok. Since I'm a busy (and lazy) bum, this have taken way more time that it > should have. > > But here it is. The HECnet mailing list is moving. It has to. > First of all, hats off, thanks, and apologies to Bob Armstrong and Dave > McGuire. They both offered to help move the mailing list, and put time into > it. Unfortunately, I've not had time to really work on it, and in the end the > people at Update also worked on migrating all other stuff that was running > there, which included various other mailing lists as well, so the HECnet > mailing list was more or less able to be moved without any work on my part, > except for some tweaks to settings. > > So while much of Update is, for the time being, turned off, the mailing list can > live on. > > The address do change, however. As you can see. The new address is: > > hecnet(a)lists.dfupdate.se > > This is now running under mailman, which do mean that there is a web > interface for people to control their subscriptions, as well as the possibility of > digests and archives going forward. > > All current subscribers are already subscribed at the new address. If anyone > disagrees with that, they can unsubscribe, or let me know and I'll unsubscribe > them. > > I'm sending this mail to both the old and new list, so everyone should get two > copies of this mail. If you are not, check possible spam boxes, and let me > know if I should investigate something on my side. > > The web page for the list is: > https://lists.dfupdate.se/postorius/lists/hecnet.lists.dfupdate.se/ > (I think I got that right, let me know otherwise) > > 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, 6 months

Weird microcode bug in the 11/60 CPU

by pbirkel＠gmail.com

Johnny; I would be interested in hearing more about this (or any) 11/60 microcode bug :->! And how the OS (which?) worked around it. >>> Subject: [HECnet] Re: KG11 emulation probably defective -->diagnosticZKGAB0for KG11 runs without complaints. ..... There is a weird microcode bug in the 11/60 CPU, which force the OS do so some silly things in general, in order to run correctly one that one CPU. Things that are just wasting a few cycles on all other CPUs. I bet DEC had fun figuring that one out... (I don't remember the exact details now, but I could go in and read the code to find out again, if needed, unless someone else remember the specifics.) Johnny -- 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>

3 years, 6 months

DEC hardware for grabs in NL

by Wilm Boerhout

A friend of mine has a bunch of hardware that needs a new home. No charge, but it has to be picked up in Zoetermeer, The Netherlands. He asked me to post it here, if you are interested I will get him to contact you. Rgds, Wilm Servers * AlphaServer 1000A * Power supply defect, stops 1 sec after sdtartup * Status unknown * DEC 2000 Model 300 AXP, aka DECpcAXP150, aka Jensen * working (front panel damaged) * Internal disk RZ28B (2.1 G) * Internal disk RZ26L (1.05 G) * RRD44 CD drive * RX26 floppy drive, not working Storage Shelves * 2x BA356-RC (blue) * 1x BA356-SB (beige) * 5x Power supply * 2x I/O module BA35X-MH (70-31490-01) * 1x I/O module BA35X-MG * 1x BN21W-0B Y-connector Disks * 6x RZ1FC-VW (36.4 G) * 4x RZ1ED/EF-VW (18.2 G) * 3x RZ1DA/DB-VW (9.1 G) * 11x RZ1CB/CF-VW (4.3 G) * 4x RZ29B-VA/VW (4.3 G) * 2x RZ28-VA (2.1 G) Tape Drives * 1x TZ89, rack mount * 2x TZ88 rack mount

3 years, 7 months

Re: KG11 emulation probably defective -->solved (by Paul as it is) --> from the KG11 drawings; issue closed

by R. Voorhorst

Actually, the wiring is slightly more complex as the counter is reset by the bus init signal on the clr inputs, however the load signal presets the counter to a value depending on the selected polynomial. The counting in hardware is even more complex as the counter is a 1 bit binary counter combined with a 3 bit binary counter to cover the range from 8 to 12 to 16 steps clocking and varying between 10 Mhz and single stepping to develop the Done flag setting which freezes the clock generator which is a gated oscillator. But since the implementation of Simh does not follow the hardware but only replaces it with a functional equivalent, the software counting is implemented differently and then it suffices to clear the pulsecnt variable per the second proposed solution. 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: Re: [HECnet] 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

3 years, 7 months

PyDECnet T1.1

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, 7 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, 7 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, 7 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, 7 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, 7 months

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet