info-kermit@ucbvax.ARPA (05/31/85)
From: Frank da Cruz <SY.FDC@CU20B.ARPA> Info-Kermit Digest Thu, 30 May 1985 Volume 2 : Number 31 Departments: C-KERMIT 4C - C-Kermit Parity More Problems on Kermit 4C? System V C-Kermit 4C Works System V 4C C-Kermit Racal-Vadic Control Fixed! C-kermit on 4.1bsd MISCELLANY - Kermit for Atari ST TRS-80 III Kermit Users Wanted PC/AT Serial Adaptor problems CP4KERMIT on Superbrain ---------------------------------------------------------------------- From: <hplabs!amdahl!drivax!alan@Berkeley> Date: Tue, 28 May 85 22:48:33 PDT Subject: C-Kermit Parity I hope that this is the right place to send this. I am using C-Kermit 4.2, and I noticed that it does not set the parity on the com. line when a set parity even/odd/mark/space command is issued. This is a problem for me because our VAX (System V) defaults differently than the other machines here (iNTEL 310 w/System V, VME/10 w/System V). Thanks, Alan Fargusson. DIGITAL RESEARCH INC. 60 GARDEN COURT BOX DRI MONTEREY, CA. 93942 [Ed. - C-Kermit certainly makes every attempt to transmit the desired parity. The question is whether the System V implementation sets the tty up in an appropriate mode to allow the C-Kermit software to do this. Some changes have been made in this area since release 4.2 -- you may find that release 4C does it right. I hope so.] ------------------------------ Date: Mon May 27 1985 10:57:27 From: Marco Papa <papa%usc-cse.csnet@csnet-relay.arpa> Subject: More Problems on Kermit 4C? I am sorry to say, but the problem reported by Yigal Arens on Kermit 4C about timeouts on large files under System V is present also in the Berkeley version. I run the following test: I tried to transfer the new ckuker.mss (34 TOPS-20 Pages) from ECLC (TOPS-20) to uscvax (Berkeley-UNIX 4.2). Everything went well until after about 160-200 dots(.) were on the screen. Then suddenly a sequence of T%T%T%T%T%T%T% started coming. Only way to get out was to abort the batch transfer. The UNIX kermit was saying it had timed out, and the TOPS-20 kermit was back to the KERMIT-20 prompt. I tried this twice with the same result. Both machines were totally unloaded (I was the ONLY user on TOPS-20 and there were 5 other users on the VAX). This seems to be a bug of the new 4C version of Kermit, not present in the preceding 4.2 version (which I used to transfer all 4C files between the above mentioned machines). ------------------------------ Date: Tue 28 May 85 13:19:16-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Re: More Problems on Kermit 4C? To: papa%usc-cse.csnet@CSNET-RELAY.ARPA Were you running the very latest release, 4C(049), circa 8:00pm EST Monday? I just used it to transfer ckuker.mss from the DEC-20 to a 4.2bsd system and didn't get a single timeout. Then I did it again. Then, just to make sure this wasn't a fluke, I sent my mail.txt file -- 205 DEC-20 pages, or 514453 characters, or 502.4K, or half a megabyte (that's about a week's worth of mail for me). There were 70 jobs on the 2060, the 15 minute load average was about 6.00; there were 8 users on the VAX-11/750, load below 1.0. The two systems are connected by a direct line between the DH11 on the DEC-20 and a DMF32 on the VAX, running at 9600 baud. The transfer took about 38 minutes; there were 6 timeouts -- one burst of three (%T%T%T), one of two, and one single timeout. I don't think a file this big could be transferred if there were some intrinsic flaw in the program. Maybe you're running a slightly older version, and were hit by a bug that has since been fixed. More likely, it's just something in 4.2bsd. We have seen terminals hang quite often on our 4.2bsd systems (the longer the system is up, the more it happens), and recently installed a patch (from Usenix?) to the DMF driver that may have alleviated the situation somewhat. ------------------------------ Date: Mon, 27 May 85 21:46:43 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) Subject: System V C-Kermit 4C Works Good news! The latest version has cleared up the problem with remote commands for System V C-Kermit. I tested them all and they now all work. Unfortunately, the dialer problems are still there for System V and Racal-Vadic modems, but progress is being made! ------------------------------ Date: Tue, 28 May 85 15:49:27 pdt From: tweten@AMES-NAS.ARPA (Dave Tweten) To: Info-Kermit@CU20B.ARPA Subject: System V 4C C-Kermit Racal-Vadic Control Fixed! I have found a fix for the System V Racal-Vadic modem problem. The problem was that tthang was dropping DTR for the modem AND LEAVING IT LOW. After I examined the code for ttopen, tthang, and ttpkt, I concluded that if ttopen needed the "close(open( . . ." magic, tthang probably did too. The magic is there, but it is surrounded by "#ifdef PCIX". I removed the "#ifdef PCIX", and the problem went away! [Ed. - Good news! Change installed.] By the way, while playing with C-Kermit 4C, I noticed that the bsd version is compiled without optimization. I tried compiling it with optimization, and it seems to work well, while generating a somewhat smaller executible file. Why no "-O" for bsd? [Ed. - You're free to add -O if you want; I'd rather distribute without it so there's one less thing to blame when things break.] ------------------------------ Date: Tue, 28 May 85 10:06:38 PDT From: Dave Flamm <flamm@AEROSPACE.ARPA> Subject: C-kermit on 4.1bsd The latest version of C-kermit still won't "make" successfully on our 4.1 bsd. It still looks for "time.h" without success. It would seem that whatever means is used for detecting 4.1 versus 4.2 is not foolproof? > I think I see the problem. It's in ckutio.c... all the nested #ifndefs > around "#include <sys/time.h>" need an additional #ifndef BSD41...#endif. > Try that and let me know if everything else is ok for 4.1bsd. Thanks! (later...) That seems to have done it. Thank you. Dave [Ed. - It looks now as if 4C pretty much works as advertised on all systems except 2.9bsd. The next issue of Info-Kermit will announce it "for real".] ------------------------------ Date: Tue 28 May 85 13:52:27-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: Kermit for Atari ST To: Info-Kermit@CU20B.ARPA I got a call from someone in Canada who said that Atari is distributing what appears to be the old Unix Kermit (command line operation only) in the developer kit for the new ST computer system, source not included. The caller wanted to know why it wouldn't transfer binary files in "image mode" -- it seems it stops sending as soon as it hits a control-Z in the file. Sounds like the file system must be in the CP/M style. It's nice that Atari is promulgating Kermit, but if they also included the source then maybe some of their developers could fix the bugs, or even adapt the new C-Kermit... ------------------------------ Date: Tue 28 May 85 13:55:52-EDT From: Frank da Cruz <SY.FDC@CU20B.ARPA> Subject: TRS-80 III Kermit Users Wanted John A Ball of the Northeast Radio Observatory Corporation, Haystack Observatory, Westford MA 01866, 617-692-4764, would like to make contact with users of TRS-80 Model III TRSDOS Kermit. ------------------------------ Date: Tue, 28 May 85 09:35:36 PDT From: Bruce_A._Cowan%SFUG-MTS%UMich-MTS.Mailnet@MIT-MULTICS.ARPA To: INFO-IBMPC@USC-ISIB.ARPA, Info-Kermit@CU20B.ARPA Subject: PC/AT Serial Adaptor problems There is a lot of misinformation going around about the serial ports on a PC/AT and their compatibility with the PC. The 16450 chip (and 8250A chip from National Semiconductor) has quite a few bug fixes compared to the 8250 and 8250B. One of those bug fixes breaks many interrupt-driven PC communications programs. The typical result is missing characters at speeds of 1200 bps and above. Now, the bug is that the 8250 pulses (low) its interrupt line when the condition causing the interrupt is satisified even if there is another interrupt condition pending. NatSemi thought that action was incorrect so they fixed it in the 8250A and 16450 - for those chips the interrupt line will stay high until ALL pending enabled interrupts are satisfied. The problem this causes with PC communications programs is that many of them assume the interrupt handler will get entered for every interrupt individually. This happened because the pulsing interrupt line would make the PC's 8259 interrupt controller think there was a new interrupt pending, so it would present it to the CPU chip immediately upon receiving the EOI (end of interrupt) for the previous interrupt. With the interrupt line not pulsing on the new chips, the 8259 doesn't think there is a new interrupt pending even though the 16450's interrupt line remains high. That is because the 8259 is in edge-triggered mode. Now, the solution is to poll either the 8250 status register or the interrupt identification register before exiting from the interrupt handler. For instance, the following logic works for the receiver data ready interrupt: Interrupt handler: save whatever is necessary while status register says data ready process data whend send EOI to 8259 restore whatever was saved exit You might now be saying "But I only enable received data interrupts so there can never be more than one interrupt pending at a time so I don't need to worry about this." Well, I thought so too, but the situation is that if the next received character is ready to be transferred to the receiver buffer register by the time the CPU reads the receiver buffer register, then the receiver data ready interrupt will remain pending. Hence you need logic like the above. (I've tried this and it does solve the problem.) There are other bug fixes in the 8250A/16450 which can cause troubles, but they are much more obscure and much less likely. They have to do with transmitter interrupts but I can't recall the details right now and I don't have my copy of the NatSemi errata sheet handy to refer to. I hope this helps all you people out there. For those who seem to think all these problems are caused by the IBM Professional Graphics Controller, please note that while it may cause some, it is not the ONLY cause, as should be evident from the above description. ------------------------------ Date: 29 May 1985 08:03:15 IST (GMT+2) To: SY.FDC@CU20B.CCNET From: PHR00JG@TECHNION.BITNET Subject: CP4KERMIT on Superbrain Hello Frank ! I was delighted with Version 4 which together with Version 2 under CMS makes the use of KERMIT even more efficient than it was before. Also I was very happy to find a version tuned to my Lobo MAX-80, although I had been happy before with the CPM-Plus version. The availability of server mode is great, and I take this occasion to thank you again. The version running on Superbrain does not generate a break. I did not look into the source code to see why, but I thought that the following listing of a tiny dumb terminal program I have written here may help clear out the problem, IF there is a problem (perhaps I missed something). Regards \ Jacques [Ed. - Jacques' code forwarded to Charles Carvalho for inclusion in the next release of CP/M-80 Kermit. No estimate when it will appear.] ------------------------------ End of Info-Kermit Digest ************************* -------