28-Jan-87 09:16:07-EST,4666;000000000001 Mail-From: OC.LASNER created at 28-Jan-87 09:16:04 Date: Wed 28 Jan 87 09:16:04-EST From: Charles Lasner Subject: Testing of MSVDM2 DECMATE II MS-DOS KERMIT To: sy.fdc@CU20B.COLUMBIA.EDU Message-ID: <12274524354.138.OC.LASNER@CU20B.COLUMBIA.EDU> Subject: Performance of DecMate II Kermit (MS-DOS) To: sy.fdc@CU20B.COLUMBIA.EDU Various tests of MS-DOS KERMIT reveal some problems and limitations that should be fixable in another release. Many limitations stem from the obvious departure of MS-DOS KERMITs in general from the "sacred" PC-DOS KERMIT, but the DecMate II demands a better fate considering how much is "built-in." A) problems with hanging up. It appears that this Kermit can hang up with all control characters failing to work when "get"-ing a file. Only <^C> does anything, and that is to echo "^C" and keep hanging 'til you do total bailout hardware reset (with the internal SETUP interrupt key or more drastic actions) and re-boot MS-DOS. B) problems exist with REMOTE DIRECTORY command when used with IBM-PC-DOS KERMIT Server at other end of wire local connection. The command does correctly give up with <^C> bailout back to MS-KERMIT prompt, but it often makes server start to create the temporary file $KERMIT$.TMP and then report " @-" as the entire directory print out and give another prompt. If you quickly give another REMOTE DIRECTORY command (while slow floppy-based PC-KERMIT server is still serving up the temporary file), you can even get several null responses to more commands (by the way, PC-KERMIT correctly reported the failure to send $KERMIT$.TMP). These tests were conducted at 9600 and 1200 baud with no change; it also does occasionally work. To confirm the hardware connection, the DecMate II was also tested with K278 Kermit. That KERMIT had no problem "get-ing" multiple files and was not flakey at all; switching to MS-DOS kermit produced consistently flakey operation with this connection. CP/M KERMIT for DECMATE II also works fine in "get-ing" files from the PC-DOS server. Since the path to all communications is the 6120 (which runs K278 by itself), and the Z80 and 8086 use the same interface to talk to the 6120 when running CP/M or MS-DOS, it seems the culprit is some problem with MS-DOS KERMIT software. C) when erasing commands to the MS-KERMIT prompt, they don't backspace over the eradicated characters (they act on it ok however, it's purely visual cosmetics that are wrong). D) server mode can also hang up when reversing the roles of server and served KERMITs (also using Victor 9000 Kermit as the local KERMIT instead of PC-DOS as local Kermit) with regard to <^C> "numbness." E) MS-KERMIT for DECMATE II does respond to the setup mode for default baud rate and to changes "on-line" induced by user SETUP changes in firmware/slushware of same properly. This has limitations as a) it can't report the current baud rate which can be figured out (if you're sneaky or have access to DEC's notes on the subject) and you thus must use SETUP to find out what it is. b) the SETUP mode only allows five popular baud rates, not the full complement of what can be done from the 6120 point of view. I have hand-patched K278 Kermit for the 6120 alone to arbitrarily do any rate the hardware is capable of, which is the usual collection of rates from 50-19200 baud. I don't know if MS-DOS can "tell" the 6120 to change the rates, but it would be nice if DEC told us how... F) bells and whistles wish list. It would be nice to see some terminal enhancements to this Kermit, ala the PC-DOS version and its terminal tricks such as buffering the screen to roll it back later, etc. This does not seem to be anything so hardware specific that it can't be done by nothing more complicated than buffering the characters sent to MS-DOS's screen handler. The LK-201 DEC keyboard has more than enough doo-hickeys (read function keys, and numeric pad extension keys, and the famous "gold" key, but I prefer to call them doo-hic keys). Please note that in theory, this Kermit should terminally emulate just about anything the RAINBOW kermit can do, as they are similar environments with built-in robust terminal emulation provided by the firmware; it would be nice to see vt-220 emulation firmed up as in some other rainbow kermits. All tests conducted on 256k XPU board DecMate II with rev. 11 roms and slushware version 412 and hardware roms version 19N. The software is CU20B::KER:MSVDM2.BOO de-"boo"-ed with MSBPCT.EXE on 17-JAN-87 on the DECMATE II; there is no MSBASIC here! Charles Lasner (OC.LASNER@CU20B) -------