- HECnet - lists @ Update

Rebooting your klh10 pseudo-RSX20F master front end

by Thomas DeBellis

For some reasons that I'll get into at some other time, putting a timeout into BOOT didn't work to get me a crash dump. So I looked at things the other way around to see what I could do to get dvdte.c to fool the PDP-10 code that the master front end had rebooted, which I have been meaning to do for some ten years now. After some trial and error, I finally got something that worked, viz: /* Ten forcing a reload? */ if (op10m_tlnn(w, (DTE_CMT_L11))) { char *fet = NULL; /* Front end type not known, yet */ if (dt->dt_ismaster) /* Is this the master? */ fet = "master"; /* Yes, remark on that */ else fet = "restricted"; /* Oh dear... Restricted DTE performance is unknown */ fprintf(dt->dt_dv.dv_dbf, /* Finally blat about it */ "[DTE: PDP-10 forcing a reload on FE%d (%s)]\r\n", dt->dt_dten,fet); /* N.B., we have *NO* code for MCB or DN60 */ dt->dt_reld11 = -1; /* Set the reload-11 button */ dt->dt_rcv_11qc = 0; /* Reset queue count; we've rebooted! */ dt->dt_secptcl = TRUE; /* Force secondary protocol */ return; /* Return, caller will invoke dte_dosecp() */ } This will let an unaltered BOOT get you a crash dump, viz: BOOT V11.0(315) BOOT>dump.exe/d [BOOT: Dumping] [OK] Number of pages written: 17734 Number of I/O requests: 203 BOOT>meamon [BOOT: Loading] [OK] After Tops-20 gets itself going, DDMP: Started Copying system dump from: TOMMYT:<SYSTEM>DUMP.EXE.1 to: TOMMYT:<SYSTEM>DUMP-21745-ILLUUO.CPY.1 [Copied dump to TOMMYT:<SYSTEM>DUMP-21745-ILLUUO.CPY.1] I haven't seen messages like this since about 1985, so it was kind of eerie watching all this low level code just...working. I have not tested the dvdte.c modification to see if it will prevent a DTEKPA BUGINF from hanging everything, but I believe it should. Maybe I'll check that after I fix what caused the crash in the first place. So I'm looking at the ILLUUO crash dump and it seems that all my fine code got smashed by the symbol table... Phooey.

3 years, 2 months

1
0
0 0

area 23 will be offline for awhile

by Mark G Thomas

Hi, Due to a combination of things, I'm going to need to take down my area 23 hecnet router, probably for a 3-6 months. Near term, I'm short on hobby time, need to do some significant network reconfiguration, and need to put back together one or several decnet worthy systems, after some rather frustrating hardware failures. Ideally, I should have more time late summer or fall, once my kid is in school and some other pressures let up. I'm not going anywhere, and appreciate the groupmembers here who have been so helpful over the years about so many DEC and non-DEC things. My current peers are as follows, though some of them are currently down. interface Tunnel50 description HECnet tunnel for Brian Hechinger (Area 52) [Version:311] interface Tunnel51 description HECnet tunnel for Ian McLaughlin (Area 42) [Version:311] interface Tunnel52 description HECnet tunnel for Cory Smelosky (Area 9) [Version:311] interface Tunnel53 description HECnet tunnel for Dave McGuire (Area 61) [Version:311] interface Tunnel54 description HECnet tunnel for Supratim Sanyal (Area 31) [Version:311] interface Tunnel57 description HECnet tunnel for Tim Sneddon (Area 12) [Version:311] interface Tunnel58 description HECnet tunnel for Mark Darvill (Area 22) [Version:311] interface Tunnel1098 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (STORTR 59.61) interface Tunnel1099 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (IAD2 59.1020) Mark -- Mark G. Thomas <Mark(a)Misty.com>, KC3DRE

3 years, 2 months

2
1
0 0

Have you been able to take a crash dump on your PDP-10? (Actually an RSX20F/DTE question)

by Thomas DeBellis

Does anybody know how I could find out what the PDP-11 front end running RSX20F is supposed to do when it is forced to reboot by the PDP-10? What else does it do besides go into secondary protocol and signal the 10 that it is alive? The klh10 micro-engine does not currently handle this and it is affecting my ability to take a crash dump. The saga is below. ------------------------------------------------------------------------ *The Background*: I ran into an unexpected issue when reworking some of the logic in TTYSRV to 'normalize' the arguments to the GETOK%. Again, the ACJ can't do much directly with a JFN as it is a small number that has no meaning outside of job context. I'm not sure that you could (easily) figure out what the JFN means with SNOOP% and PEEK%, either, because the active JSB is the ACJ's and not that of the fork pending on the GETOK%, which means you have to map that and then chase down the OFN (which might not be so bad). Since other monitor GETOK%'s which are asking about file related JFN's (say for Secure files and directories) resolve the JFN to the actual text of the file specification, having the terminal device resolved before feeding the GETOK% seemed like the right thing to do and I reworked some code, which was basically some reordering. The monitor assembled just fine, no .PSECT complaints. There are 25 pages free in section zero, but everything I've done is all in the swappable monitor (NRCOD .PSECT), so I didn't expect any problems there, either. So everything looks fine, I've done it a bunch of times before, yet: BOOT>tlinkm [BOOT: Loading] [OK] [TOMMYT mounted] VENTI2, PANDA TOPS-20 Monitor 7.1(21745)-5 Internet: Loading host names [OK] System restarting, wait... Date and time is: Friday, 8-April-2022 8:32PM Why reload? other debug Run CHECKD? no [KLH10: Illegal exec mode op, PC = 0: 0 0,0] ********** *BUGHLT "ILLUUO" *ADDITIONAL DATA: 300000000001, 000000000001, 000000000000 ********** [DTE: Unsupp sts bits 240020,,32463] [HALTED: Program Halt, PC = 1043534] Well! That's not very promising. Actually, kind of stunning. The monitor has transferred control into accumulator zero, which contains a zero, which is an illegal opcode. That can show up as an Illegal UUO (I'll get to the DTE bits in a minute). I couldn't believe it was my code, so I did the obvious thing and break-pointed it with Executive DDT (EDDT), viz: BOOT>TLINKM/L Loads the monitor, does not start it BOOT>/g141 Starts monitor Executive DDT (SYSDDT) EDDTF[ 1 Keeps EDDT locked in memory DBUGSW[ 2 Write-enable swappable monitor GOTSWM$B Breakpoint after swappable monitor loaded 147$G Normal start up When it hits the breakpoint: CALL SWPMLK$X Lock swappable monitor CALL SWPMWE$X Write-enable swappable monitor Set a breakpoint in the TLINK% JSYS entry and proceed .TLINK$B $P And... Same thing. So that means my code is effectively dark at the point of the crash because the breakpoint is never hit. It would appear that the additional 93 (decimal) words I wrote pushed something someplace, causing an address space overwrite. That is puzzling, as I would have thought that LINK would have caught that or the postlude. Whatever it is, it means that it's time for a crash dump and some quality time with FILDDT and other utilities. I dusted off MAKDMP, duly created an 8,193 page DUMP.EXE and rebooted, crashed with an ILLUUO, reloaded BOOT and started it to get the crash dump (with the /D, switch). And I got that odd DTE message and a hung machine. KLH10> load boot.sav Using word format "c36"... Loaded "boot.sav": Format: DEC-CSAV Data: 4630, Symwds: 0, Low: 040000, High: 054641, Startaddress: 040000 Entvec: JRST (120 ST: 0147, 124 RE: 0, 137 VR: 500701,,21745) KLH10> go Starting KN10 at loc 040000... [DTE: Unsupp sts bits 240020,,32463] KLH10>> halt [HALTED: FE command, PC = 772446] KLH10> Some more poking around shows that BOOT is hung in the following loop, waiting for a response from the 11 that never comes. SETEP4: MOVEI Q1,.DTMMN ;MONITOR MODE ON MOVEM Q1,DTECMD ; STORE IN COMMAND J5: MOVEI Q1,TO11DB ;RING THE BELL XCT DTCNOW ;DO IT J6: SKIPN DTEFLG ;WAIT FOR COMPLETION J7: JRST .-1 ; ... BOOT is forcing the 11 into something called by Tops-20 to be 'monitor mode'. This does not happen on the normal first boot case because at that time, the enumeration of devices has not taken place and the DTE is not known nor is it connected to the priority interrupt system. When BOOT is reloaded, the PDP-10 hardware is already conditioned and BOOT detects this. What the KLH10 DTE code sees is that a request has come in with bit 200000 high in the left half word, which is the LOAD-11 indicator. And it doesn't have code to handle that, viz: if (op10m_tlnn(w, (DTE_CMT_PWF|DTE_CMT_L11|DTE_CMT_INI))) { fprintf(dt->dt_dv.dv_dbf, "[DTE: Unsupp sts bits %lo,,%lo]", (long)LHGET(w), (long)RHGET(w)); return; } That's the message that is coming out, above. What can be seen is that the PDP-11 has not been signaled that anything has happened, so it waits for something to happen, except that now dvdte is waiting for another command which the 10 will never issue. I have seen this behavior before. Sometimes, the klh10 micro-engine can get so active that a clock interrupt from the host operating system doesn't come in time for the keep alive counter to be incremented. The 20 declares the 11 down, issues a DTEPKA BUGINF, attempts to restart it and ...everything hangs... At the time I addressed the issue with a hack: I put programmable waits into DTESRV (set via the BOOT% JSYS) and gave the micro-engine a chance to catch its breath before Tops-20 lowers the boom. So one way to address the issue is to hack BOOT not to wait forever. It's a hack, but it will get the job done. I think... The other is to change dvdte.c to do what a regular 11 running RSX20F would do.

3 years, 2 months

1
0
0 0

Announcing TCP/IP V2.10 for RSX-11M-PLUS

by Johnny Billquist

Time for a new release announcement of TCP/IP for RSX-11M-PLUS. This is version 2.10 of BQTCP/IP. It's been three months since the last official update. Some major improvements and bugfixes have been done, and it is strongly recommended that systems are updated. Some of the errors fixed could cause system crashes under the right conditions. Highlights: . Improved TCP performance . Improved telnet behavior and features . Improved ftp/ftpd behavior . Improved mail daemon . More RSX patches Detailed information on things that have been done since the last release: ARP: . Bugfix in ARP cache timer. If the time to the next event related to the ARP cache was too big, the timer stopped. IP: . Bugfix. IP packet processing could cause a crash with fragmented packets. TCP: . Improve TCP flow control. . Fix to make sure TCP socket in last-ack state will time out. . Improved TCP reception code. (Sequence and window check.) . Improved TCP probe handling and keepalive handling. . Improved TCP retransmit handling. . Changed semantics of TCP window update statistics. . Improved TCP performance by better ACK handling at packet loss. . Improved TCP window update and ack sending. . Improved TCP retransmit and congestion recovery. IFCONFIG: . Added more TCP tuning parameters to IFCONFIG. FTP/FTPD: . Fix FTPD log file lock error. Implemented retries. . Bugfix in FTP and FTPD. When block mode read of files was done, a multibuffer implementation was used which did not free memory at completion. . Added cleartext error messages in FTP and FTPD. . Changed ftp directory Unix format timestamp. MAILD: . Improved MAILD SMTP server to better handle relaying and bad host detection. . Improved MAILD mail delivery to not do parallel delivery to the same destination by several tasks. . Changed MAILD to use possibly multiple tasks for delivering new mails, since to some destinations, mail deliver can be really slow. Also changed SMTP mail receiver to accept mails from hosts even if they present bogus host names in HELO/EHLO command. . Added some more spoof notification calls in smtp mail receiver. TELNET/TELNETD: . Improve telnet option negotiation in server and client. . Added terminal type option to telnet client. . Removed binary mode from telnet client. . Added processing of SB/SE functions in telnet client. . Added processing of SB/SE functions in telnet server. . Added proper handling of terminal names in telnet server. . Added proper handling of terminal names in telnet client. Multinet: . Bugfix in Multinet. Under some circumstances, the timers would stop. LPT: . Added hardtab expansion in LPT printer despooler. . Added a simple TXT print spooler symbiont. XLISP: . Changed XLISP INET daemon functionality to use a filename based on port connection accepted on. Patch updates: . Datatrieve-11: . Fixed DTR leap year bug. . Fixed DDMF (remote DTR) server to set correct default directory. . Improve DTR programming interface to allow DECnet to work in parallel with DTR. . Updated MCR. . Added patched ACNT, PSW and SYSLOG to distribution. . Added patched NVPFSL.TSK to distribution. . Added patched HELRES.TSK to distribution. Some additional notes: As usual, I would recommend people to update as soon as possible. The changes are not critical, but will lead to a much better experience, and might avoid system crashes in rare circumstances. The patches to the TT: driver cannot be applied automatically, but requires users to apply the patches themselves, and then run SYSGEN to generate a new system. Once added, the TNC2 task can be run at login, and will define logical names for the user telling where he is connected from, if using telnet or LAT. The TT: driver patches also allows the updated MCR to give more information with the DEV command (SHOW TERMINAL in DCL). The other patches to RSX can be applied automatically by IPGEN, either if used interactively when answering YES to the question about applying RSX patches, or by running IPGEN explicitly to do the patches, with the command: @IPGEN PATCH Specific information about the patches: LAT: Fixes a memory leak, and adds the ability to read where a terminal connection comes from when using LAT, using SF.GMC. RMSDAP: Fixes a bug in getting the file protection, so the XAB gets filled in correctly for remote files. RMSDSP: Fixes that some numbers were displayed in signed octal, which should have been displayed in decimal or unsigned octal, depending on number. DCL: Added terminal attributes for COLOR. MCR: Too many fixes to be listed here... INS: Fixes that users cannot circumvent protection on common regions. HEL: Fix that users can login with session ID, or with directory, in addition to name and UIC. ACNT: Add no password change attribute to accounts. PSW: Add no password change handling. SYL (SYSLOG): Add terminal idle tracking on accounts without idle logout. ECL: If the receiving machine is very slow, and the sending machine is very fast, and the receiver announce several large buffers available, ECL cannot keep up, and drops packets. This is a problem with the DECnet flow control, as it is used in RSX. The simple solution is to allow more outstanding buffers when receiving. A more complex solution would be to change how RSX DECnet do flow control, but that would require rewriting a fair chunk of the ECL module. NMVACP: Fix handling of "show known nodes" command, which could skip some nodes. NVP: Add ability to use session ID or directory name for user identity in DECnet nodename specifications. EPM: Fix handling of ethernet multicast. NTDEMO: Fix that hosts without names should display DECnet address. As usual, the distribution is available from: ftp://mim.stupi.net/bqtcp.dsk ftp://mim.stupi.net/bqtcp.tap !!! BQTCP is also available through RPM !!! (As an additional note, if there are any problems communicating with Mim using port 21, the ftp service is also available at port 10021) The documentation is also available through ftp on Mim, or also at http://mim.stupi.net/tcpipdoc I hope people find this update useful. On a final note, Mim have moved. Mim.Update.UU.SE does not exist anymore as a domain name. The machine is now only available as Mim.Stupi.NET. 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

3 years, 3 months

1
0
0 0

Tops-20 CTY, Part 4

by Thomas DeBellis

I finally finished some initial code for the access control job (ACJ) to detect and report spying. The documentation and monitor code for TLINK% were confusing enough that I initially just write wrote some code to break out what was being sent so I could figure out how it all worked. Some random things I found of note: When a job is first created and the EXEC is getting cranked up, it calls TLINK% called to refuse links, viz: 9-Apr-2022 18:06:21 ACJ: TLINK% SAB:CLR Obj:-1 by job 10, user not logged in user, program , TTY46 The -1 argument for the object means, "My Terminal", in this case TTY46 is being conditioned to refuse links. On a batch login, I refuse links and advice, as can be seen by the below: 8-Apr-2022 23:29:18 ACJ: TLINK% STA:CLR Obj:-1 by job 11, user SLOGIN, program TERMIN, TTY21 8-Apr-2022 23:29:18 ACJ: TLINK% SAB:CLR Obj:-1 by job 11, user SLOGIN, program TERMIN, TTY21 The EXEC commands which did this are: Terminal (feature or type) NO Receive Advice Terminal (feature or type) NO Receive Links The batch job in question was MONGEN, because I'm in the middle of tweaking a few things in the TLINK% JSYS code to make my life easier in the ACJ. Since I'm impatient, from the following you can see that I did an ^Epeek to watch the batch job execute: 8-Apr-2022 23:29:21 ACJ: TLINK% ERO Obj:-1 Rem:21 by job 10, user SLOGIN, program EXEC, TTY46 The regular (non-debugging) code which displays this is less nerdy and maybe easier on the eyes, viz: 8-Apr-2022 23:29:21 ACJ: SPYING: user SLOGIN, Job 11, TTY21 by job 10, user SLOGIN, program EXEC, TTY46 Maybe I'll put in some extra code to break out whether one of them is batch or the line type. Or something. Right now, I'm just making the JSYS code in TTYSRV easier for me to work with. Some of it dates back to TENEX days and it's been modified to the extent that I found it confusing to work with (but that's me). The actual problem is that the GETOK% is called before the arguments are resolved. It is not explicitly laid out in the JSYS reference manual that, unlike the first terminal argument (which must be a terminal designator), the second can be a JFN, which is worthless outside of job context. So it needs to get converted to a line number before it gets handed to the ACJ.

3 years, 3 months

1
0
0 0

try #4: area 23 will be offline for awhile

by Mark G Thomas

Hi, I'm trying again, as I suspect maybe the mailing list has been rejecting my prior attempts due to some case sensitivity in matching submitting e-mail senders with subscriber addresses. If this message makes it, maybe someone can investigate, as I expect it might cause grief for others too. Due to a combination of things, I'm going to need to take down my area 23 hecnet router, probably for a 3-6 months. Near term, I'm short on hobby time, need to do some significant network reconfiguration, and need to put back together one or several decnet worthy systems, after some rather frustrating hardware failures. Ideally, I should have more time late summer or fall, once my kid is in school and some other pressures let up. I'm not going anywhere, and appreciate the groupmembers here who have been so helpful over the years about so many DEC and non-DEC things. My current peers are as follows, though some of them are currently down. interface Tunnel50 description HECnet tunnel for Brian Hechinger (Area 52) [Version:311] interface Tunnel51 description HECnet tunnel for Ian McLaughlin (Area 42) [Version:311] interface Tunnel52 description HECnet tunnel for Cory Smelosky (Area 9) [Version:311] interface Tunnel53 description HECnet tunnel for Dave McGuire (Area 61) [Version:311] interface Tunnel54 description HECnet tunnel for Supratim Sanyal (Area 31) [Version:311] interface Tunnel57 description HECnet tunnel for Tim Sneddon (Area 12) [Version:311] interface Tunnel58 description HECnet tunnel for Mark Darvill (Area 22) [Version:311] interface Tunnel1098 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (STORTR 59.61) interface Tunnel1099 description tunnel to Peter Lothberg <roll(a)Stupi.SE> (IAD2 59.1020) Mark -- Mark G. Thomas <Mark(a)Misty.com>, KC3DRE

3 years, 3 months

3
6
0 0

a few newbie questions

by hush

hey all! sent this earlier in the week but i think my message was dropped... new to HECnet and currently getting my machines connected- i'll be bringing along an 11/83, a uVAX3100, and a PWS600AU! i had a few questions though, and wanted to get some feedback. one of my projects has been to build a proper retrocomputing lab, a slice of my LAN with only period-correct hardware and software. part of that is networking of course, and as part of that i've been eyeing a DEChub with DECbrouter and DECswitch to connect my retrolab. based on my understanding of the DECbrouter documentation, it should be usable for both DECnet and TCP/IP, but i wanted to make sure that this is the case before i go spending any money. would there be any issues hooking this all up with modern equipment? i'm also wondering if there are any general recommendations (or recommended documentation) for system security on 11M+ and VMS. i'm planning to open my retro systems up to some friends and acquaintances to encourage exploration, so i'd like to make sure my machines are secure and reliable. appreciate any info you can provide! .hush

3 years, 3 months

1
0
0 0

PyDECnet T1.1 beta 2

by Paul Koning

Gentlepeople, I have put together a second beta for DECnet/Python 1.1. It's currently running on a HECnet backbone router (PYTHON) and on the HECnet map server (28NH). This beta update adds DAP support and "login" type objects (such as FAL). The first beta has significant performance improvements over V1.0, and a new and expanded API. You can look at CHANGES.txt in the source tree for more detail. It seems to be stable; the first beta has been running for a while now with no obvious problems. I'd like to hear if anyone currently running PyDECnet is interested in trying out this beta. If so, you can find kits here: http://akdesign.dyndns.org:8080/resources/public/index.html . I didn't have kits posted before, now they are available. You can also download them using DAP on HECnet, at PYTHON:: . :-) If you install the beta could you let me know so I know who is using it? Thanks. paul

3 years, 3 months

10
27
0 0

Anyone who knows?

by Peter Lothberg

I found some borads in a junk pile... a M7380 board, it says M7380 PDM70 control module? a MDC-II board, says andromeda systems on it Anyone who knows what it does?

3 years, 3 months

4
4
0 0

Pertec 2-connector formatted interface

by Dave McGuire

Ha, originally from Jon Wilson. Here it is: ---------------------------- Pertec Formatted Interface, compiled by John Wilson <wilson(a)dbit.com> from various drive manuals, 03-Oct-1999. Updated 17-Mar-2000. Two 50-pin cables, all odd pins are grounded, except for pins 1/3 on P2. All signals are active low. Signal source is indicated under "src" column, C=controller, D=drive. All transmitters are open-collector drivers which can sink 36 mA (e.g. 7438). All receivers are 74(LS)00 style, terminated with 220 ohms to +5 and 330 ohms to ground. Signals are active low. P1 connector: -pin- -name- -src- -description- 2 IFBY D formatter busy, set by trailing edge of IGO, clears when command finished (but you can send a new command as soon as IDBY clears) 4 ILWD C last word -- used to tell drive that this is the last word (well, byte really) to be written in this record, assert 300 nsec (min) before trailing edge of final IWSTR pulse (no particular hold requirement) 6 IW4 C write data b4 8 IGO C initiate command -- pulsed low for 1 usec (min) to start command. formatter address lines must be stable throughout the pulse and until IFBY drops. 10 IW0 C write data b0 (MSB) 12 IW1 C write data b1 14 (ISGL) D (selected drive fault on some drives, cleared by dropping and re-asserting IFEN) 16 ILOL C load on-line -- pulse starts load sequence on some drives 18 IREV C reverse 20 IREW C rewind -- 1 usec (min) pulse starts rewind, no IFBY or IDBY, so wait until IRWD=0 and IRDY=1. ignored if tape is at BOT (so IRWD and IRDY will already be as above). 22 IWP C write parity (odd) 24 IW7 C write data b7 (LSB) 26 IW3 C write data b3 28 IW6 C write data b6 30 IW2 C write data b2 32 IW5 C write data b5 34 IWRT C write 36 (IRTH2) C see IRTH1 38 IEDIT C edit 40 IERASE C erase 42 IWFM C write file mark 44 (IRTH1) C write density select on some drives, used in conjunction with IRTH1 to set write density (unless controlled by front panel), qualifies IGO on first write operation from BOT, ignored elsewhere 46 ITAD0 C transport address 0 (MSB) 48 IR2 D read data b2 50 IR3 D read data b3 P2 connector: (N.B. pins 1/3 are *not* grounds, so not paired with pins 2/4) -pin- -name- -src- -description- 1 IRP D read data parity (odd) (N.B., not a ground pin) 2 IR0 D read data b0 (MSB) 3 IR1 D read data b1 (N.B., not a ground pin) 4 ILDP D load point -- asserted whenever the tape is at the load point (or might as well be, as far as the controller needs to know -- there may be hidden repositioning) 6 IR4 D read data b4 8 IR7 D read data b7 (LSB) 10 IR6 D read data b6 12 IHER D hard error -- pulsed (during IDBY) when a hard data error (or illegal character in IRG) is seen 14 IFMK D file mark -- pulsed (during IDBY) when a tape mark is seen 16 IDENT D identification -- asserted while drive is actually reading the PE ID burst, dropped the rest of the time so it's up to the controller to catch it and remember. on 9610, this is CCG (check character gate) in NRZI mode -- sample during IRSTR to find out whether this char is a data char or part of a CRCC or LRCC check. 18 IFEN C formatter enable -- should normally assert this all the time, but drop it for 2 usec (min) to abort any command that asserts IDBY (I/O, search, but not rewind I guess) ASAP 20 IR5 D read data 5 22 IEOT D end of tape -- asserted whenever the tape is past the EOT marker, clears when you backspace past it 24 IRWU C rewind/unload (also called IOFL) -- 1 usec (min) pulse starts, same as IREW but sets drive off-line and unloads tape. F880 manual isn't clear whether you assert this signal alone or at the same time as IREW (says it "modifies" it). 9610 manual seems to say it's used alone. 26 INRZ D NRZI mode -- asserted when in 800 BPI mode on some drives 28 IRDY D ready -- tape is fully loaded (not in transition to/from off-line) and not rewinding, check this before starting any command 30 IRWD D rewinding -- asserted while tape is rewinding 32 IFPT D file protect -- asserted continuously when the tape doesn't have a write ring in 34 IRSTR D read strobe -- typical timing: pulses low for 200 nsec (min), data on IR0-7/IRP are set up 100 nsec (min) before leading edge, held for 200 nsec (min) after trailing edge, cycle time can be as low as 1.1 usec for GCR @ 100 IPS. Kennedy 9610 is different: setup=500 ns min, RSTR=340 ns min, hold=250 ns min. 36 IWSTR D write strobe -- pulsed low each time the drive is ready for another data byte to be written. timing depends on drive model -- example: IW0-7/IWP must be set up 300 nsec (min) before trailing edge, no hold requirement after. Kennedy 9610 is edge-triggered off the trailing edge, setup=500 ns, hold=250 ns. 38 IDBY D data busy -- asserted during I/O phase of read/write commands (generally starts a few msec after IFBY). 40 ISPEED D high-speed status -- asserted when command is executing in high-speed mode (starting at IDBY anyway) 42 ICER D corrected error -- pulsed (during IDBY) when a single- track dropout is successfully corrected (using the parity information) 44 IONL D online -- always asserted when online, clears within 1 usec of OFFLINE command 46 ITAD1 C transport address 1 (LSB) 48 IFAD C formatter address 50 IHISP C high speed select (also called IDEN) -- qualifies IGO (so must assert beginning 1 usec (min) before trailing edge of IGO, can drop any time afterwards) to select high-speed tape motion for this command Commands are started by setting up the IREV, IWRT, IWFM, IEDIT, and IERASE lines and then pulsing IGO. All kinds of crazy combinations of these signals are possible to get vendor-specific commands. The basic ones are: READ --- (nothing, just IGO) Reads the next record or dies trying. Data are supplied with IRSTR pulses as needed, watch ICER/IHER for errors, or IFMK etc. for other status. READ REVERSE IREV Reads the previous record, or just gives up if at BOT. As above, watch ICER/IHER/IFMK/etc. WRITE IWRT Writes a record, supplying IWSTR pulses to clock in data until the controller asserts ILWD. WRT FILE MARK IWRT+IWFM Writes one file mark. ERASE IWRT+IWFM+IERASE Erases 3" (or whatever) of tape. Used as part of a write retry sequence. SPACE FORWARD IERASE Like READ but with no IRSTR pulses. SPACE REVERSE IREV+IERASE Like READ REVERSE but with no IRSTR pulses. FMARK SCH FWD IWFM+IERASE Does SPACE FORWARD commands until file mark or EOT marker is reached. FMARK SCH REV IREV+IWFM+IERASE Does SPACE REVERSE commands until file mark or BOT marker is reached. On some drives, IEDIT modifies WRITE and READ REVERSE to allow (semi-)safely inserting records on an existing tape. READ REVERSE EDIT tells the drive to backspace slightly farther than usual into the preceding IRG, and WRITE EDIT tells the drive to turn the head current off slowly at the end of the record to avoid causing a glitch. Kennedy 9610/9660 chart: REV WRT WFM EDT ERS -command- 0 0 0 0 0 READ FORWARD 1 0 0 0 0 READ REVERSE 1 0 0 1 0 READ REVERSE EDIT 0 1 0 0 0 WRITE 0 1 0 1 0 WRITE EDIT 0 1 1 0 0 WRITE FILE MARK 0 1 0 0 1 ERASE VARIABLE LENGTH 0 1 1 0 1 ERASE FIXED LENGTH 0 1 1 1 1 DATA SECURITY ERASE 0 0 0 0 1 SPACE FORWARD 1 0 0 0 1 SPACE REVERSE 0 0 1 0 0 FILE SEARCH FORWARD 1 0 1 0 0 FILE SEARCH REVERSE 0 0 1 0 1 FILE SEARCH FORWARD (IGNORE DATA) 1 0 1 0 1 FILE SEARCH REVERSE (IGNORE DATA) 0 1 1 1 0 SELECT 800 BPI 0 0 1 1 1 SELECT 1600 BPI 1 0 1 1 1 SELECT 3200 BPI 1 1 0 0 0 SELECT 6250 BPI Streamers have a drive-dependent "reinstruct time" which is the size of the time window after completion of a command during which you can issue a new command w/o the drive having to reposition. Definitely a good idea to make the deadline if possible, if you can't then using IHISP will probably waste more time in repositioning than it will save in fast transfer speed. -- Dave McGuire, AK4HZ New Kensington, PA

3 years, 3 months

2
4
0 0

M7196

by Peter Lothberg

Anyone that has the print set of M7196 or just the pin out of the tape drive connectors? It's part of TSV05 tape subsystem. -P

3 years, 3 months

2
1
0 0

DECnet Phase V on VAX/VMS

by Trevor Warwick

I'm a recent joiner to HECnet, and wondered if anyone else has played around with Phase V software at all ? Obviously HECnet itself is a Phase IV network, but you can connect Phase V VAX endnodes using the Phase IV compatibility mode. All my systems are simulated with simh, and getting an Ethernet connection to work was very straightforward, there's just a bit more local configuration required than with Phase IV. However, I spent quite a few years at DEC working on VAX synchronous device drivers, so I was interested to see whether I could get a WAN connection going. The biggest issue was device support. DECnet-VAX Phase V doesn't support any of the older microcoded interfaces (DMC11, DMV11, KMX11 etc), and the later devices (DSV11, DSB32, DST32, etc) aren't supported by simh. The only intersection is actually the DUP/DPV11, where there was a new VMS driver (SEDRIVER) for Phase V, that replaces the individual protocol-specific drivers that were previously used with these devices. I've spent quite a long time this week dredging stuff out of memory from 30 years ago, and still failing to get a DPV11 link to come up, until I eventually realised that a) there are some significant differences between the DUP and DPV, and b) simh does not support the DPV properly (how is one supposed to know this?) ! So after changing my simulated microVAX into an 8600, and the DPV into a DUP, I've managed to get a DDCMP link to come up between this and a PyDecnet router. There still seem to be some rough edges, as it won't always come up until PyDecnet is bounced, and it's also a bit slow for interactive use, as if there's something that's only working on a retransmission, or timer expiry. Anyway, it's been a fun nostalgia exercise to get this far, I'll probably mess about with it some more. Let me know if you have any questions... TOGATH$ mcr ncl sho routing circuit ddcmp-0 adj * all Node 0 Routing Circuit DDCMP-0 Adjacency RTG$0001 at 2022-03-11-15:28:50.820+00:00Iinf Identifiers Name = RTG$0001 Status Type = Autoconfigured State = Up Neighbor Node Type = Phase IV Router Router NETs = { 49::00-1D:AA-00-04-00-D5-75:00 (LOCAL:.TWPD) } TOGATH$ mcr ncl sho modem connect line ddcmp-0 all Node 0 Modem Connect Line DDCMP-0 at 2022-03-11-15:29:33.660+00:00Iinf Identifiers Name = DDCMP-0 Status UID = 5AFC9FC0-A14A-11EC-8002-AA000400C475 State = On Interface State = Full Enabled Actual Speed = 0 Loopback Mode = Null Interface Type = Unknown Modem Type = "" Device Availability = Device Present Request to Send = Asserted Clear to Send = Asserted Data Set Ready = Asserted Data Terminal Ready = Asserted Carrier Detect = Asserted Signalling Rate Selector = Unknown Signalling Rate Indicator = Unknown Ring Indicator = Not Asserted Remote Loopback = Not Asserted Local Loopback = Not Asserted Test Mode = Unknown Characteristics Communications Port = DPV-0-0 Connection Type = NonSwitched Communications Mode = Synchronous Duplex = Full Profile = "" Modem Control = Full Modem Options = { } Encoding = Normal Clock = External Speed = 0 Alternate Speed = 0 Rate Select = High Maximum Enable Transmit Timer = 2000 Suppress Test Indicator = True Transmit Holdoff Timer = 0 Carrier Loss Timer = 15000 Minimum DTR Deassertion Timer = 2000 Maximum Disable Transmit Timer = 500 Call Accept Timer = 0 Successful Call Indication Timer = 30 Maximum DSR Deassertion Timer = 5000 Counters Creation Time = 2022-03-11-14:48:46.780+00:00Iinf Losses of Clock = 0 Cable Faults = 0 Times DCE Not Ready = 0 Transmit Enable Timeouts = 4 Losses Of Carrier = 0 Rate Fallbacks = 0 Test Indications = 0 Framing Errors = 0 Times Cable Detected = 0 Device Errors = 0 Times Reset = 4 c CTF V1.0-00 Page 1 Trace started on 11-MAR-2022 15:45:28.40 Analyzed on 11-MAR-2022 15:45:56.95 Trace File DUA1:[TREVOR]CTF$TRACE.DAT;3 Output File DUA1:[TREVOR]XX.TXT;4 -----------+----+-----+<--------DDCMP Frame-------->+--------------------------` Time |Evnt|Data | Typ QS Res Num Ctl Adr Count|Data ` hh mm ss cc| |Size | | ` -----------+----+-----+<--------------------------->+--------------------------` 15:45:28.40| Tx| 85| DAT S 77 86 1 77| 0A C5 75 C4 75 01 21 35 E` | 01 04 C3 02 EE 81 C6 01 2` | 2E 30 85 02 03 E8 C4 01 0` 15:45:28.41|Rx | 22| DAT 85 78 1 14| 05 D5 75 0A AA AA AA AA A` 15:45:28.56|Rx | 6| ACK 86 1 | 15:45:28.57| Tx| 6| ACK S 78 1 | 15:45:32.80| Tx| 85| DAT S 78 87 1 77| 0A C5 75 C4 75 01 21 35 E` | 01 04 C3 02 EE 81 C6 01 2` | 2E 30 85 02 03 E8 C4 01 0` 15:45:32.81|Rx | 62| DAT 86 79 1 54| 02 C4 75 C5 75 02 21 2E D` | 01 04 C6 01 23 01 11 30 3` | 03 E8 15:45:32.81| Tx| 25| DAT S 79 88 1 17| 02 C5 75 C4 75 01 21 09 6` 15:45:32.82|Rx | 6| ACK 87 1 | 15:45:32.94|Rx | 6| ACK 88 1 | 15:45:32.95|Rx | 62| DAT 88 80 1 54| 02 C4 75 C5 75 02 21 2E D` | 01 04 C6 01 23 01 11 30 3` | 03 E8 15:45:33.07| Tx| 6| ACK S 80 1 | 15:45:38.48|Rx | 31| DAT 88 81 1 23| 02 C4 75 C5 75 02 21 07 F` 15:45:38.48| Tx| 40| DAT S 81 89 1 32| 02 C5 75 C4 75 01 21 07 F` | 00 00 00 00 00 00 15:45:38.49|Rx | 31| DAT 88 82 1 23| 02 C4 75 C5 75 02 21 07 F` 15:45:38.49| Tx| 25| DAT S 82 90 1 17| 02 C5 75 C4 75 01 21 09 6` 15:45:38.50|Rx | 6| ACK 89 1 | 15:45:38.60|Rx | 6| ACK 90 1 | 15:45:39.72|Rx | 58| DAT 90 83 1 50| 02 C4 75 C5 75 02 21 07 F` | 00 00 00 00 00 00 01 02 1` 15:45:39.72| Tx| 25| DAT S 83 91 1 17| 02 C5 75 C4 75 01 21 09 6` 15:45:39.73| Tx| 25| DAT S 83 92 1 17| 02 C5 75 C4 75 01 21 09 6` 15:45:39.73| Tx| 80| DAT S 83 93 1 72| 02 C5 75 C4 75 01 21 07 F` | 00 00 00 00 00 00 01 02 F` | A0 13 00 30 02 30 60 F9 0` 15:45:39.73| Tx| 38| DAT S 83 94 1 30| 02 C5 75 C4 75 01 21 07 F` | 00 00 00 00 15:45:39.73| Tx| 49| DAT S 83 95 1 41| 02 C5 75 C4 75 01 21 07 F` | 00 18 00 42 70 50 00 A0 1` Buffer: XX.TXT | Write | Insert | Forward

3 years, 3 months

4
8
0 0

TOPS-20 boot camp for VMS users

by Robert Armstrong

I thought some of the HECnet crowd might find this interesting https://groups.google.com/g/alt.sys.pdp10/c/WnsETCDyTmc "TOPS-20 Boot Camp for VMS Users 05-Mar-2022" (that's this Saturday), and they'll even give you an account on a real (not simulated!) 36 bit machine, an XKL Toad. Bob

3 years, 4 months

1
0
0 0

The domain Update.UU.SE...

by Johnny Billquist

Seems to not work anymore. Not sure if it is permanent. But anyway, for anyone wanting to reach Mim, as has been announced before, she's still available as Mim.Stupi.NET. 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

3 years, 4 months

1
0
0 0

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

3
5
0 0

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

2
2
0 0

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

9
28
0 0

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

9
16
0 0

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

1
0
0 0

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

1
0
0 0

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

1
0
0 0

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

3
2
0 0

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

3
2
0 0

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

3
3
0 0

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

11
41
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

HECnet