Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site ucbvax.ARPA Path: utzoo!watmath!clyde!cbosgd!ulysses!ucbvax!info-kermit From: info-kermit@ucbvax.ARPA Newsgroups: fa.info-kermit Subject: Info-Kermit Digest, V1 #45 Message-ID: <3944@ucbvax.ARPA> Date: Fri, 28-Dec-84 12:31:36 EST Article-I.D.: ucbvax.3944 Posted: Fri Dec 28 12:31:36 1984 Date-Received: Sat, 29-Dec-84 03:49:40 EST Sender: daemon@ucbvax.ARPA Organization: University of California at Berkeley Lines: 432 From: Frank da CruzInfo-Kermit Digest Fri, 28 Dec 1984 Volume 1 : Number 45 Special MS-DOS Kermit 2.27 Feedback Issue: 2.27 Broken (then fixed) for Z100 Display Problems on Z100 Bug in File Transfer Filename Display H19 Emulation Problem File Transfer Display Problem Fixes for NEC APC Support Module Re: Fixes for NEC APC Support Module Various Bugs Problems on Wang PC Kermit Can't Always Find COMMAND.COM TI Professional Support Mode Line Control (More) Various Bugs MS-DOS Kermit and DTR ---------------------------------------------------------------------- From: Frank da Cruz Date: 28 Dec 84 12:00:00 EST To: Info-Kermit Subject: Special MS-DOS Kermit 2.27 Feedback Issue This issue of the Info-Kermit digest is devoted to feedback received on the recent release of version 2.27 of MS-DOS Kermit, announced in V1 #43 of the digest on December 7, 1984. A few major problems were reported, which prevented certain systems from working at all (notably the Z100) under 2.27; these were promptly fixed. Remaining problems are left for the next release, 2.28. All known problems with version 2.27 are listed in the file KER:MSKERMIT.BWR which, like all Kermit files, is available via anonymous FTP from host CU20B. ------------------------------ Date: Sat 8 Dec 84 01:23:28-PST From: NEELAND@USC-ECL.ARPA Subject: 2.27 Broken for Z100 To: sy.fdc@CU20B.ARPA Just FTP'ed the new 2.27 version of MSZ100 (the .EXE file), and Kermited it (via version 2.26). It works for the most part, so I don't think anything went wrong with the file transfer. However, I've encoun- tered the following serious flaws this evening - 1.) The STATUS command immediately crashes the system - must be rebooted. 2.) The SET PORT command responds with: not implemented (which I expected) and then crashes the system; certainly one way to emphasize the 'not implemented' status. Other commands which do work include: REMOTE, PUSH, SPACE, LOCAL, HELP, DIRECTORY, GET, EXIT, RUN, FINISH, and CONNECT. /Jim [Ed. - Thanks for pointing out the problem; some fast action by Jim Knutson (UT) and Jeff Damens (CU) seems to have fixed the problem -- the fixed files are in KER:MSXZ100.ASM and KER:MSZ100.BOO, and KB:MSZ100.EXE (binary) on CU20B, as of December 11.] ------------------------------ Date: Tue, 11 Dec 84 14:19:44 cst From: knutson@ut-ngp.ARPA (Jim Knutson) To: Info-Kermit@CU20B Subject: Display Problems on Z100 MS-DOS Kermit 2.27 now seems to work on the Z100. But here remain a couple minor problems: The SPACE command doesn't echo CRLF before CHKDSK runs. This causes the prompt and command to be overwritten. The return from push assumes a screen redraw/switch. It looks funny without it since the space you type to continue does nothing. Perhaps checking to see if screen switching is taking place and then blow out a message like [Back in connect mode.] if the switch won't occur. Jim [Ed. - next release.] ------------------------------ From: ihnp4!islenet!david%Berkeley@columbia.arpa Date: 7 Dec 84 20:12:54 CST (Fri) To: Info-Kermit@CU20B Subject: Bug in File Transfer Filename Display Using MS-DOS Kermit 2.26, if I do a SEND MSWANG.BOO at the remote Kermit, then escape back to my local Kermit-MS and RECEIVE B:MSKERMIT.BOO, the status display puts the B: in front of the wrong filename: Filename: B:MSWANG.BOO AS MSKERMIT.BOO [Ed. - This same behavior persists in v2.27, and may be fixed in the next release.] ------------------------------ Date: Mon, 10 Dec 84 12:55:28 pst From: Dave Tweten To: +outgoing@AMES-NAS.ARPA, INFO-KERMIT@CU20B.ARPA Subject: MS-Kermit 2.27 H19 Emulation Problem I picked up a copy of MS-Kermit 2.27 the afternoon of Friday, December 7, as soon as I received the announcement. Over the weekend, I tried it out, and concluded that one of its advertized fixes didn't. I used 2.27 to log onto our UNIX 4.2 BSD system and "man kermit" (what else?). Kermit still has the old problem of inverse blanks beyond the end of the line following one which ends in an inverse character. Incidently, I am sure the problem resides neither in our termdef files, nor in the "more" utility. I have borrowed a real H-19 long enough to confirm that our "more" and our termcap do not produce this effect on a real H-19. I inserted fixes for the inverse video problem into MSYIBM.ASM for MS-Kermit 2.27. They seem to do the trick. They are based on my belief that a real H-19 will provide black blanks for a scroll or a clear command, regardless of whether inverse video is on. The changes are presented below as "fc" output. [Ed. - Code omitted. Next release.] ------------------------------ Date: Mon, 10 Dec 84 12:55:28 pst From: Dave Tweten To: +outgoing@AMES-NAS.ARPA, INFO-KERMIT@CU20B.ARPA Subject: MS-Kermit 2.27 File Transfer Display Problem The "non-blanking of K bytes transferred" problem (fixed in 2.27) also affected the retry count, when in server mode. When you aren't in server mode, each new command produces a whole new status display, but when you are in server mode, only the retry count is restarted - without first blanking the line. I fixed that the same way 2.27 fixed the K-bytes display - by inserting a blank-to-end-of-line call in the positioning routine. 2.27 doesn't seem to have it. Thanks again for providing an excellent product. [Ed. - Code omitted, next release.] ------------------------------ Date: Wed, 12 Dec 84 07:16:22 pst From: dual!islenet!gibbons%Berkeley@columbia.arpa To: SY.FDC@CU20B Subject: Fixes for NEC APC Support Module The problems reported with the display on the NEC APC seem to be due to an instability in the video memory that varies from one NEC APC to another. One of the two APC's that I have access to behaved just as he described, while the other showed it hardly at all. I have fixed the instability in these two APC's by adding a couple of delay loops in the module. Hopefully this will take care of the problem in all cases, although I feel a little unsettled by the difference between the two here. I have also added the two delay loops to the UART mode setting code as Ron Blanford requested. Not having the optional second serial port myself, I am unable to verify this aspect of his code. Ian ------------------------------ Date: Thu 13 Dec 84 13:43:16-PST From: Ronald Blanford Subject: Re: Fixes for NEC APC Support Module To: cc.fdc@CU20B.ARPA I've checked out Ian's fixes and added one of my own, and now all the problems have been fixed. The new versions of MSXAPC.ASM and MSAPC.EXE are on my account and available for anonymous ftp. -- Ron [Ed. - Thanks! The new files are in KER:MSXAPC.ASM, KER:MSAPC.BOO, and KB:MSAPC.EXE on CU20B, as of December 13th.] ------------------------------ Date: 14 Dec 1984 1615-EST From: (Joe Smith, Colorado School of Mines, via) LCG.KERMIT@DEC-MARLBORO To: EIBEN@DEC-MARLBORO Subject: Various Bugs 1. BUG: MS-KERMIT cannot send packets while SET LOCAL-ECHO ON. CURE: Ignore the setting of LOCAL-ECHO when transmitting packets. 2. BUG: Problems in RECEIVE FILENAME.EXT when FILENAME.EXT exists. I told KERMIT-10 to SEND MSKERM.HLP and KERMIT-MS to REC MSKERMIT.HLP when MSKERMIT.HLP already existed on the floppy. It tried to rename the incoming file, but got confused as to which name to add the "&" to. MSKERMIT said "File name: MSKERM.HLP AS MSKERMIT.HLP", then "Renaming file to MSKERMITHLP" (note no period), then aborted with "?Unable to create file". Even stranger things happen when both MSKERM.HLP and MSKERMIT.HLP exits. Then MSKERMIT says "Renaming file to MSKER&IT.HLP". The ampersand is in the wrong position, and it should have never checked for the existance of MSKERM.HLP when I tell it to store the incoming file as MSKERMIT.HLP. 3. PROBLEM: Using SET LOCAL-ECHO ON does not work too well with 2 micros. There is no automatic linefeed when the RETURN key is pressed. CURE: When a CR is typed at the keyboard while LOCAL-ECHO is on, echo it as CR and LF, and set a flag signifying that an automatic LF was sent to the screen. If the host then sends a LF while this flag is set, ignore the 2nd LF (to avoid unwanted double spacing). ALTERNATIVE: Define a new command, SET REMOTE-ECHO ON. When this flag is set during a CONNECT operation, input from the keyboard and from the modem are logically "OR"ed together and echoed to both the screen and the modem, with LF after CR. This feature will be designed to allow two micros to be used as conversational terminals, when one is in SET ECHO REMOTE and the other in SET ECHO OFF. 5. SUGGESTION: Replace HEATH19 keyword with TERMINAL-EMULATION. With proper synonyms, SET TERMINAL-EMULATION ON would be same as the command SET TERMINAL HEATH-19. I feel the phrase "TERMINAL-EMULATION" is more descriptive, and would allow additional keywords, such as VT102, VT125, and TEKTRONIX. This has been partially implemented in MSXTIPRO.ASM Better yet, SET TERMINAL TYPE HEATH-19 and SET TERMINAL ID-SEQ VT100 and SET TERMINAL WRAPAROUND OFF, etc. 6. The portion(s) of the manual showing how to bootstrap using the FORTRAN program on a DECsystem-10 are wrong. Under TOPS-10, only one logical name can be assigned to a TTY at a time; the Fortran side of the bootstrap has to be changed. Joe Smith, CSM Computing Center, Golden CO 80401 (303)273-3448 ------------------------------ Date: Mon 17 Dec 84 13:33:47-PST From: Ted Shapin Subject: Problems on Wang PC To: info-kermit@CU20B.ARPA I found what was causing the "Write fault error writing device AUX" error message. I had copied the WANG config.sys file which loaded the SER1DRVR. This driver is for a printer and interferes with using the serial port for communications. Once I removed it, MSWANG worked. The following does not work: STATUS cuases a loop sending blanks to the screen. RUN filename gives a message "unable to execute program". (This is for version 2.27.) Ted. ------------------------------ Date: Mon 17 Dec 84 13:35:12-PST From: Ted Shapin Subject: Kermit Can't Always Find COMMAND.COM To: info-kermit@CU20B.ARPA I think MSKERMIT has a problem finding COMMAND.COM when it is not in the root directory. (This applies to versions 2.27 and 2.26.) I have command.com in a separate sub-directory with the following in CONFIG.SYS: shell=c:\bin\ibm\command.com c:\bin\ibm /p If I type DIR, I get the error message "Unable to execute program". DIR will work if I use a vanilla DOS system with command in the root dir. Ted. ------------------------------ Date: Sunday, 9 December 1984 14:59:56 EST From: Joshua.Brodsky@cmu-cs-speech.arpa To: SY.FDC@cu20b.arpa Subject: TI Professional KERMIT Recently, you posted on CMU's Info-Kermit bboard that a version of KERMIT for the Texas Instruments Professional Computer is available. MSTIPRO.EXE (converted from .BOO) behaves strangely on the Portable TI-PPC. On either the desk-top or portable model it sets the initial baud rate strangely; on the desk-top it accesses the disk briefly, but on the portable is has a divide overflow and bombs. If you know any owners or users groups for the TI who use KERMIT, I would like to meet them. Lastly, I am in need of a KERMIT for the NCR Decision-Mate V. The generic MS-DOS Kermit did not work. I've heard rumors that a version already exists. If you are not aware of one, can you post this request on your next Info-Kermit digest? Thank you. -Josh (brodsky@cmu-cs-speech.arpa) ------------------------------ Date: Thursday, 27 December 1984 21:25:55 EST From: Joshua.Brodsky@cmu-cs-speech.arpa To: Frank da Cruz Subject: Re: TI Professional KERMIT Thanks for your help with TI Pro KERMIT. The Tektronix emulation is fantastic! I have forwarded a copy of MSTIPRO.EXE to the Washington DC TI Professional user group for distribution. I am still having trouble with my NCR Decision Mate V, however. Even the new generic KERMIT refused to work. In the MS-DOS documentation for the system, it refers to the COM port as \dev\aux and the error KERMIT gives is that it cannot get a handle on the communications port. I think this may be the cause. Can you think of an easy way to fix it? If not, I have heard that a version for the NCR already exists. Can you post a request for information on your next info-KERMIT bboard? Thanks a lot. -Josh [Ed. - Generic DOS Kermit 2.27 has several ways to let you try to get at the communications port - SET PORT n (n is 1 or 2 or 3 ... for COM1, COM2, COM3, ...) SET PORT DEVICE s (s is the device name, e.g. AUX, \dev\aux, etc.) SET PORT HANDLE n (n is a small integer corresponding to the DOS device handle) If you try enough of these, you should be able to hit one that works.] ------------------------------ From: Doug Brutlag Subject: Mode Line Control To: Info-Kermit@CU20B.ARPA I FTP'd the IBMPC version of KERMIT 2.27 when it was released and have found no bugs in a couple of weeks of work. I am particularly happy with how well it interacts with PROKEY allowing me to use that function for general key redefinition (as I did with 1.20) as well as defining keys in MSKERMIT.INI files. I only have one suggestion for improvement. One can remove the MODE line only with the control-] M command in terminal mode. I would suggest that there be both a SET MODE-LINE ON/OFF toggle command and that the setting of the toggle be included in the STATUS report. The main reason for the suggestion is that then one could include SET MODE-LINE OFF in a KERMIT.INI file so that the user not have to ever see the mode line if he wanted. Of course I would leave the default value of this parameter to ON so that one would specifically have to turn it off with the command or in the INI file. Is there a way to do this now without control-] M? [Ed. - On the list for the next version. For a quick fix, see below.] Congratulations on the best piece of public domain software that I have ever seen. Doug Brutlag ------------------------------ Date: Wed, 19 Dec 84 12:21:34 cst From: allegra!noao!utastro!nather@Berkeley (Ed Nather) To: noao!allegra!ucbvax!info-kermit@Berkeley Subject: Various Bugs MS-DOS Kermit v2.27 always adds the "." character to an uploaded filename if it originally had no extension. Kermit v2.27 for the IBM-PC fails to show the mode line in inverse video on the file transfer display. Apparently the DOS function 6 (write a string) does not preserve the attribute byte, set to inverse video before the call to `dos' -- so the text was displayed normally (bright on dark) but the rest of the mode line, at the far end, was inverse video. Kermit v2.27 attempts to accomodate Unix buffs who have changed the default path separator from `\' using the (undocumented) configuration command "switchar=\", thus reversing the use of `/' and `\' in MS-DOS, and almost succeeds. The directory command gets confused, however, by the switch character reversal. [BEWARE! The "switchar=" command has disappeared from MS-DOS 3.0 and may never appear again. (*sigh*)] [Ed. - Code omitted, next release.] Kermit, by default, connects to the host with the mode line displayed. This can be changed to suppress the mode line, by default, by making the following change in msterm.asm: targ termarg <4,1,80,24,cptchr,2dch,0,scntab,deftab,0,,parnon> | `---(was 0) Ed Nather Astronomy Dept., U. of Texas {allegra,ihnp4}!{noao,ut-sally}!utastro!nather ------------------------------ Date: 18 Dec 84 09:21:40 PST (Tue) To: info-kermit@cu20b Subject: MS-DOS Kermit and DTR From: Mike Iglesias Can MS-DOS Kermit toggle DTR? We have a Develcon Dataswitch that uses DTR to tell when to get a new connection to a different computer. If it doesn't have it, can it be added in a future release? [Ed. - On the list for the next release.] ------------------------------ End of Info-Kermit Digest ************************* -------