Problems with MS-DOS Kermit 2.29 on the Victor/Sirius: When you SEND from the host, escape back, and RECEIVE on the Victor, the host Kermit never receives the Victor's final ACK to the host's B packet. So the Victor needs a slight pause after sending the ACK to the B packet before returning to wherever it's going, to give the ACK time to escape from the port before the door slams shut on it. There's no way to type ^] on the Victor keyboard, so Victor Kermit should have a SET ESCAPE command in its MSKERMIT.INI file for some other character that can be typed on it, like Alt-tilde. ------------------------------ Date: Tue 17 Jun 86 09:22:53-EDT From: Frank da Cruz Subject: Victor/Sirius Kermit To: cuddy@UMKCVAX1, PETERSON@BYUVAX Here's a complaint from a Victor 9000 (Sirius 1) user in Israel, about version 2.29 of Kermit. I have checked his complaints on some Victors we have here at Columbia and have found that none of the symptoms he reports occur here. Can any of you reproduce these symptoms on your Victors or Sirius's, or suggest any reason why they would occur on his? I've heard that there's considerable variation among Victor machines, depending on exactly where and when they were manufactured. I also don't quite know what he means by "not using standard DOS initialization for the communication port"... Also, I suspect the last point has something to do with switch settings on his modem... Thanks for any tips you can give. - Frank --------------- Date: Mon, 16 Jun 86 16:08:05 +0300 From: Meyer Wolf Subject: Victor/Sirius KERMIT Dear Mr da Cruz: Greg Scott of the Linguistics Dept. told me I might write directly to you concerning the problems I'm having with Victor/Sirius KERMIT V2.29 6 May 86. 1. When KERMIT comes up, it issues the following warning: ?Warning Cannot open com port Enter a file handle... followed by a request Handle: After replaying this three times, KERMIT issues the message ?Not confirmed and continues as if nothing is wrong. The three numbers I reply with are 4, 3 and 2 in that order. Other numbers either crash KERMIT or disable its ability to execute DOS commands such as DIR & TYPE. The request for a file handle is probably a result of my not using standard DOS initialization programs for the communication ports; presumably KERMIT looks for some trace in the operating system and fails to find it. Can you tell me what it is? 2. The MSKERMIT.INI initialization file is recognized and executed by KERMIT when it comes up. However macro definitions included in MSKERMIT.INI are ignored. Consequently "set esc ~" does just that but "define foo set prompt Foo>" does not make the macro foo available (as executing the SHOW MACROS command confirms). Incidentally, I did not get an initialization file with the executable KERMIT file MSKV90.EXE; the IBM macro that you may have noticed is built in. 3. Unlike earlier versions of Victor/Sirius KERMIT, V2.29 insists on half- duplex when addressing a MODEM in CONNECT mode. Setting LOCAL-ECHO ON sets full-duplex, but not only locally: display from the remote machine also appears with full-duplex, i.e. doubled. Can the former defaults be restored? Thank you for your trouble. Yours, Meyer Wolf ------------------------------ Date: Mon, 30-JUN-1986 22:21 MDT From: Bryan Peterson Subject: Response to comments of Meyer Wolf, 16 June 1986 To: fdccu@cuvma Responding to each question in turn: 1. The warning about not being able to open the COM port. This is caused by some (supposedly) smart things we did to keep from smashing the COM ports too bad when we initialized them and/or changed parameters. This is done by opening the device SERIALA or SERIALB (depending on which port is currently active) with a handle and using the device control function provided by DOS to set up the parameters. The actual transfer of data to and from the port is done directly at the hardware level to insure that no characters will be lost at the higher speeds. If the appropriate device name can't be found, such as if the serial port drivers have been replaced, than a handle can be provided which is opened for the desired device already. If the device you wish to access is also the standard auxilliary device (set with the CAUX command) then handle number 3 is already open on that device and if it is the printer device (set with the CLST command) then handle number 4 is already open. But be warned, that KERMIT is expecting the device driver to handle the device control i/o in exactly the same way that the Victor-supplied drivers handle it. 2. DEFINE commands in the file MSKERMIT.INI I am not sure about this one. I tried a few simple cases and it seemed to pick up the macro definition just fine from the file. The only thing I can suggest is that maybe there is some subtle interaction during the handling of the INI file which would cause KERMIT to ignore the macro definitions under certain circumstances. That part of the code is shared with that of all other MSDOS implementations of KERMIT - I will plead ignorance at this point (in the terminology I heard once regarding the VAX VMS operating system, that's not a bug, it's an undocumented feature!) 3. LOCAL ECHO behavior. The way the local echo is handled is to put every character on the screen which is typed at the keyboard and every character that comes down the serial line. It is assumed that the remote system will not be echoing keyboard input (half-duplex operation) so they must be locally echoed. If you find that everything is being doubled, the remote system is actually operating in full duplex and you should turn local echo off - there is no need for the local system to immediately put keyboard input on the screen since the remote system will take care of that for you. I hope these items may help to answer the questions. The only one I can really speak with authority on is the first one, since I wrote the section that does the port handling along with Andreas Stumpf in Germany. If you want to change that behavior to match the device drivers you have, it will be necessary to go through the file MSXV90.ASM and modify all the port initialization and access routines. There are bits and pieces of the device control access to the device driver throughout the routines because we (I) were trying to maintain the device driver in a state that would allow it to be used by other packages without requiring a full initialization and so that the portset utility would return the true port settings after KERMIT was run. If you have any questions about the necessary changes, drop me a line and I will be glad to give any hints on where to look for the places to change. Bryan Peterson Bitnet Peterson@Byuvax ------------------------------ Date: Fri 16 Jan 87 13:07:37-EST From: Charles Lasner Subject: Victor Kermits I am connected with various and sundry Victor 9000 (AKA Sirius 1 in Europe) users and vars. We had hoped that a viable KERMIT was available for this MS-DOS-based machine which is incompatible with (and I daresay better than) the IBM PC. We eventually contacted someone within Columbia for the Sirius KERMIT and we had the ancient KERMIT for the Sirius one and MS-DOS version 1.25 with Victor I/O subsystem 2.5. A note on this version: While it is true that this version is ancient and (somewhat) obsolete since it only handles ascii files properly and can't GET anything, it turns out that it can be patched to run on a slightly newer version of MS-DOS known as version 1.25 with Victor I/O subsystem 2.61. The source file reveals this and should be updated to run 2.61 I/O as virtually no-one does anything earlier anywhere in the world. As to reasons for running 1.25/2.61: many Victor users only have 128k (original system memory without expansion boards (which go up to 898k) had 128k, newer production motherboards now have 256k in different chips (incompatible) and there is no incentive to upgrade the motherboard though it *can* be done). A perhaps worse problem: Early Victor 9000 motherboards use a bootstrap rom set now obsolete which cannot bootstrap anything past MS-DOS v1.xx systems due to Victor-enspired changes. Many (European) users have old boot chips and can't run MS-DOS 2.x even if they have the memory! It is probably true that these users will not upgrade, as they have little incentive to do so, and I presume that Columbia wants to stay neutral on this problem. My Victor 9000 had recently been bootstrap rom-wise upgraded, so I could run small MS-DOS 2.11 programs, but only had 128k. Since I only had MS-DOS v1.25/2.61, I had to spend major amounts of time convassing local users until we found someone with an old disk with 2.5 on it. (I didn't know about the patch mentioned in the source, but it was strange to be defaulting to an obsolete version) I eventually put up SIRIUS.EXE as supplied and it did work with the known restrictions, etc. I later obtained via CCnet the MS-KERMIT.BOO file for Victor 9000 and MSBPCT.BAS de-booing program. Moving the two files to MS-DOS v2.11 (and obtaining more memory to 256k) I then ran MSBASIC on the file renamed to MSKERMIT.BOO and had no problems other than waiting for MSBPCT to convert it. This successfully produced MS-KERMIT for Victor 9000 v2.28 which was a quantum leap forward. (A minor glitch, the file produced was msv90.exe, not msvv90.exe as advertised.) This version worked quite well, but had problems with wildcard GET commands which always mangled the first (even if only) file matching the filespec. The contents where fine. More recently I have obtained the latest version (A/O NOV 1986) via the same path, only using MS-DOS 2.11 for all generations. Some comments on the current version: a) when connecting, a message flashs on the screen too fast to read, presumably advising the escape character usage, etc. b) when push-ing to MS-DOS to run chkdsk or space or directory, etc., I created a strange (hard to recreate) effect whereby the receive screen was not present, even though all other functions worked. The problem is apparently, when you return from directory listings, etc., you may overlook the need to paint the screen before initiating the first transfer. c) apparently all versions can't change CWD to a: or b: (floppies), which I find a little annoying, as the unit containing MSKERMIT.INI is virtually never the unit for files. Also other commands take unit constructions: dir b:, take a:mskermit.ini, etc.