SY.FDC@CU20B.COLUMBIA.EDU (Frank da Cruz) (01/23/86)
Info-Kermit Digest Wed, 22 Jan 1986 Volume 4 : Number 5
Departments:
MS-DOS KERMIT -
Victor 9000 Support for MS-DOS Kermit 2.28
APC MS-Kermit
Info-Kermit
Olivetti M24 Kermit: VT100 Split-Screen Scrolling Problem
MISCELLANY -
MacKermit from Rice?
SuperKermit File Transfer Times
Tandem Running Guardian OS Kermit?
Novation Apple-Cat II?
----------------------------------------------------------------------
Date: Mon, 20-JAN-1986 20:31 MST
From: <PETERSONB@BYUVAX.BITNET>
Subject: Victor 9000 Support for MS-DOS Kermit 2.28
This is to announce Victor 9000/Sirius 1 Support for MS-DOS Kermit 2.28,
contained in two assembly-language files, MSXV90.ASM and MSYV90.ASM. The
support includes the full option list of baud rates (45.5 to 38400 baud),
the use of either serial port, full HEATH emulation, and restoration of the
screen to its previous condition when reconnecting to the same port after
disconnecting. The SET KEY option has not been supported since that does
not seem to be necessary with the Victor's soft keyboard.
For those who would like to get more out of the Victor 9000, there is also
a version of MSYV90.ASM which gives full Tektronix 4010 emulation. This
module provides full text, graphics, and graphics input (GIN) emulation.
The graphics are good quality, thanks to the quality of the Victor's screen,
and the graphics input appears to be adequate for most needs. However, the
text leaves a little to be desired in terms of readability. The font is
home grown (my home) and I didn't have a lot of time to put into fine tuning
the different characters for readability, but they can be deciphered with a
little practice.
There are three Victor-specific modules required to generate the Tektronix
version. These are
MSZV90.ASM - replaces MSXDMB to get the segments in the right order
MSXV90.ASM - same one used for the regular KERMIT
MSYV9T.ASM - provides the Tektronix emulation
The first module is required to get the segment containing the graphics
screen region as low as possible in memory. The Tektronix emulation mode is
entered by setting the HEATH mode off (i.e., SET HEATH OFF).
Bryan G. Peterson
PETERSONB@BYUVAX
[Ed. - Thanks! This should allow us to get rid of some of the old Victor
versions that have been cluttering up the Kermit Distribution the last few
years, and allow the Victor to benefit from new MS-DOS Kermit releases.
Since there is no .BOO or .EXE file, the program will have to be built from
the source, following the directions in the documentation. The files are
in KER:MS%V9*.* on CU20B, available via anonymous FTP on the Internet, and
from KERMSRV at CUVMA on BITNET. If anyone manages to build a working .EXE
in a place I can FTP it from, I'll add it to the distribution and make a
.BOO file from it.]
------------------------------
Date: Sun 19 Jan 86 17:30:14-PST
From: Ronald Blanford <CONTEXT@WASHINGTON.ARPA>
Subject: APC MS-Kermit
The corrected versions of MSXAPC.ASM and MSAPC.EXE are ready for ftp
from my account <CONTEXT>.
This latest version fixes a bug in which MS-Kermit incorrectly handled
the function keys on the APC during Connect mode. When programmed
using the operating system KEY command rather than from within Kermit,
only the first character would be sent when the function key was pressed,
and the rest would wait until the next keystroke. This has now been
corrected. Thanks to Ian Gibbons for the fix.
-- Ron
[Ed. - Thanks, Ron. The new files are in KER:MS%APC.*, including a new
.BOO file. The 8-bit binary .EXE file is in KB:MSVAPC.EXE. These files
are available, as usual, via anonymous FTP from CU20B on the Internet.
All but the .EXE file are also available on BITnet from KERMSRV at CUVMA.]
------------------------------
Date: Mon, 20 Jan 86 13:58 EST
From: CDTAXW%IRISHMVS.BITNET@WISCVM.WISC.EDU
Subject: Info-Kermit
I have been archiving the Info-Kermits from the MAIL files on KermSrv. I
have been putting Volume 1 - 4 into partitioned datasets with an index of
all the subject lists. This is great and very useful, but unfortunately all
the pre-volume information was not digested into any specific format so I am
at a lost for the best way to break them into smaller chunks. I was
wondering if you had any ideas on this? Do you think anyone would be
interested in the digests as partitioned datasets? I would be more than
happy to send them to you for distribution if you think it a worthwhile
thing.
Thanks again for your time,
mark
[Ed. - If anyone out there is interested in an Info-Kermit PDS, please
respond to Mark directly; if there is sufficient interest, maybe some way
can be devised to distribute it.]
------------------------------
Date: Tue 21 Jan 86 14:30:28-EST
From: PK0P@CMCCTD
Subject: Olivetti M24 Kermit: VT100 split-screen scrolling problem
I downloaded the Olivetti M24 version of Kermit-MS and noticed a problem
with split-screen scrolling in VT100 emulation mode.
I'm using an IBM PC/XT, DOS 2.1, EGA, and Enhanced Color Display. I'm also
using the ANSI.SYS device driver.
When talking to a VAX/VMS system, I noticed the problem with the VMS PHONE
facility. From PHONE, one can do DIR to see a list of users on the system,
or on another VAX/VMS system connected through DECNET. If there are more
than 18 users on the system, PHONE will do a split-screen scroll to list
them (provided the terminal is one of the VT1xx or VT2xx series). The first
time through, the list will be displayed correctly with split-screen
scrolling. If you then issue a second DIR command from PHONE, all the lines
with be displayed on top of each other on the status line (on about the 5th
line from the top). Then if you exit from PHONE, you will find your cursor
on line 1, with only a one line scrolling region! To correct the problem,
you can issue the escape sequence to reset the scrolling region, or escape
back to Kermit-MS and type:
SET HEATH ON
SET HEATH OFF (to get back to VT100 Emulation)
(Note: this is only noticeable if the VAX system has 18 or more users logged
in. PHONE does not use split-screen scrolling when it can list all the
users on one screen.)
Peter Kanaitis
Research Systems Analyst
Allegheny Singer Research Institute
Allegheny General Hospital
Pittsburgh, PA 15212
Voice: (412) 359-3180
Net: PK0P%TD.CC.CMU.EDU@TE.CC.CMU.EDU
[Ed. - Thanks for the report -- it has been passed along to Joe Doupnik to
make sure the forthcoming version 2.29 will not have the same problem.]
------------------------------
Date: Sat, 18 Jan 86 14:12:11 pst
From: Joel West <westjw%frog@nosc.ARPA>
Subject: MacKermit from Rice?
Frank,
Since I doubt you were at the MacWorld expo this week, I thought I'd pass it
along...
"The Rice University Macintosh Development Project has developed several
public domain products for Macintosh computers.
...
Rice Mac Kermit
...It will also allow you to send full applications as
well as text only documents. Eighth-bit prefixing
is supported. This program is currently in beta test.
...
Rice University
Institute for Computer Services and Applications
POB 1892
Houston, TX 77521
Unfortunately, the guy at the Rice booth didn't know much about it, and said
I had to come back and speak to the woman in charge. I never made it.
[Ed. - According to the new issue of "Wheels for the Mind" (V2 #1, Winter
1986) the status of Rice Univerity's Macintosh Kermit is "Currently on
hold". Rice has never been terribly communicative about the various Kermit
programs they've been working on -- they also have a pretty fancy TSO Kermit
written in PL/I, but which requires a proprietary support package which they
sell; hence we don't distribute it.]
If you find out any more about this (either through INFO-KERMIT or whatever
channels you have), I'd like to know. I'm a heavy Mac and Kermit user, and,
if this is better than the 0.8 C-Kermit, would be glad to add it to our
user-group distribution.
[Ed. - I'll be glad to add it if Rice sends it in.]
At this point, the most interesting issue is whether MacKermit will support
the Hierarchical File System. The main reason why some programs don't is
that they take the volume ref no, convert that to a disk volume name, and
then make a string of the form "Disk Volume:File Name". Instead, all file
names MUST be internally stored as volrefno,filename. (the volrefno now
gives a volume and directory under HFS) If you follow the rules, code can
work under old or new systems.
[Ed. - Reportedly Mac Kermit works just fine under HFS; that is, it works
as well as it does on pre-HFS systems.]
Also, MacKermit does not support out-going wild-cards. This would be real
useful.
[Ed. - Yup. So would saving the screen or lines scrolled off the top,
a mouse-positioned cursor, the ability to deal with Mac Binary format, etc.
I hope we'll be able to do some more work in this area some day.]
Joel West CACI, Inc. - Federal
westjw@nosc.ARPA
{decvax,ucbvax,ihnp4}!sdcsvax!noscvax!westjw
------------------------------
From: Chuck Forsberg WA7KGX <caf%omen.uucp@brl.arpa>
Subject: SuperKermit file xfer times
Date: 20 Jan 86 10:46:37 GMT
To answer some questions in INFO-KERMIT, I ran some tests transferring
files with a variety of protocols, including SuperKermit (Kermit with
Sliding Windows). Here are the results.
SuperKermit: Some File Transmission Time Comparisons
Chuck Forsberg 1-20-86
Two files were used for this series of tests.
A 112070 byte .EXE file produced by the Xenix to DOS cross development
system was used to test the transfer of binary files. Of the 19886
nulls in the file, many were in buffers, giving a chance to test
Kermit's run length compression.
A 11456 byte document produced by nroff contained no special characters
save CR and LF. The document used little or no indentation.
Transmissions were from a 9 mHz PC-AT running DOS 3.1 or SCO SYS V Xenix, to
a PC with a NEC V20 at the standard 4.77 mHz. Ramdisks were used on the DOS
machines. The 9600 bps transfers used a direct connection between the
adjacent machines. 1200 bps transfers used a Hayes 1200 and MI-2 212a modem
dialup. Software used was Professional-YAM 15.24, Crosstalk 3.6, and Unix
sb(1). Pro-YAM to Pro-YAM SuperKermit transfers used 3 byte block check
(CRC-16), eight bit transfers (no quoting), and compression.
Transfers with The Source used the Portland OR Uninet node. Source Kermit
transfers used 1 byte block check, eight bit transfer, and no compression.
Previous tests have indicated Telenet gives similar results on downloads
from The Source but was very much slower on uploads thanks to poor network
buffering.
.EXE File (112070 bytes)
Time Speed Conditions
2:00 9600 Xenix to Pro-YAM YMODEM-g
2:00 9600 Pro-YAM to Pro-YAM YMODEM-g
2:11 9600 Pro-YAM to Pro-YAM XMODEM/CRC
3:54 9600 Pro-YAM to Pro-YAM SuperKermit
4:10 9600 Xenix to Crosstalk XMODEM
5:20 9600 Pro-YAM to Pro-YAM Kermit (NO Windowing)
15:55 1200 Pro-YAM to Pro-YAM YMODEM-k
22:33 1200 Pro-YAM to Pro-YAM SuperKermit
25:22 1200 Pro-YAM to The Source SuperKermit
25:95 1200 The Source to Pro-YAM SuperKermit
Nroff output file (11456 bytes) (all at 1200 bps)
Time Conditions
1:49 Pro-YAM to Pro-YAM YMODEM-k
1:53 Pro-YAM to Pro-YAM SuperKermit
1:59 Pro-YAM to The Source SuperKermit
5:32 Pro-YAM to The Source Kermit (NO Windowing)
DISCUSSION
Between two directly connected microcomputers, XMODEM protocol gives
good results, 855 bytes per second throughout out of 9600 bps. The
1024 byte blocks used by Pro-YAM's YMODEM-k and YMODEM-g give a throughput
of 933 bytes per second (97 per cent efficiency).
Pro-YAM's Kermit/SuperKermit routines are based on the code developed at
The Source, which in turn is based on C-Kermit. Compared to the earlier
Unix Kermit, C-Kermit uses extra layers of processing which limit performance
at high speeds. The .EXE file should transfer in 2:49 but in fact takes
3:54. Most of this delay was enforced by the PC stopping the transfer
with XOFF flow control. A PC-AT or AT&T 6300 should be able to receive
data with SuperKermit at 9600 bps with little or no flow control.
[Ed. - Sigh... Layering is the price we pay for portability. The old
version didn't run under System III, System V, VMS, or on the Macintosh...]
SuperKermit does allow the receiver (in this case the slower PC) to overlap
serial transfers with its processing. Without SuperKermit, all the processing
must be done sequentially, resulting in a 5:20 transfer time for the same
file.
The advantage of Sliding Windows or other means of sending multiple blocks
can be seen by comparing the timing for the Xenix to Crosstalk XMODEM
download (4:10) with YMODEM-g download (2:00).
When national or global packet switched networks introduce delays,
the difference becomes significant even at 1200 bps. The 1:52 transmission
time between two SuperKermits only loses six seconds when uploading to
The Source. Regular Kermit (no windowing) takes more than twice as long
at 5:32. Standard XMODEM transfers with Compuserve suffer from similar
delays.
[Ed. - And of course you can't do MODEM transfers with The Source at all,
because an 8-bit path is required.]
The size of the sliding window has little effect on performance as long
as it is large enough to contain the outstanding packets. The maximum
possible is 31, but it appears that 8 are sufficient for normal conditions.
Of course, if the timesharing system or the network restricts the flow
of data, no amount of windowing is going to help. I did notice a slight
amount of network flow control when uploading files to The Source.
In the non window transfer with The Source, round trip delay time was
about 1.6 seconds according to my calculations (it seemed longer).
YMODEM-k under these conditions would have uploaded the .EXE file in
19 minutes compared to SuperKermit's 25 minutes. A Kermit transfer
with 1024 byte packets without windowing would have taken 27 minutes
(losing 3 minutes from the delays, gaining a minute from decreased overhead).
The benefits derived from Kermit's run length encoding form of compression
are greatly dependent on the nature of the files being transmitted. It
appears most of the difference between the 22:33 minute Pro-YAM to Pro-YAM
SuperKermit transfer and the 25:22 Pro-YAM to The Source transfer is related
to compression available in the Pro-YAM Kermit but not The Source.
However, long files downloaded from bulletin boards are often SQueezed or
compressed before transmission, reducing the value of Kermit's compression.
Most compression programs emit all 8 bit codes, resulting in an average
25 per cent Kermit efficiency loss from control character quoting.
The main Kermit inefficiency in transferring binary files is control
character quoting, which increases transmission time by 25 per cent average.
A useful Kermit extension would be a way to allow most control characters to
be transmitted without quoting.
[Ed. - Right, but this is the same quoting that allows Kermit to work in
environments where MODEM can't. Extending Kermit to allow a set of control
characters to be transmitted "bare" seems like a good idea, but since it is
just as often the intervening communication hardware or software that is
sensitive to control characters as it is the computers themselves, a great
deal of expertise -- and often "manual intervention" -- would be required
of the user. Better to pay the price of the overhead.]
A lesser source of overhead comes from the characters that frame Kermit
packets. It is unfortunate that Kermit does not provide for longer
packets.
[Ed. - But it does -- see the long packet extension, proposed in Info-Kermit
V3 #4. Some implementations will soon see the light of day.]
SuperKermit: Unfinished Business
The main item of unfinished business in SuperKermit is to determine the
best criteria with which to force a windowing transfer to abort in a timely
fashion without compromising the robustness of the protocol. A window
size of 31 means up to 3100 bytes can be sent to the wrong program if one
end of a SuperKermit transfer exits prematurely. A series of noise bursts
such as dialing crosstalk can generate dozens of spurious packets. The
normal method of stopping until the line quiets cannot be applied when
the window is open.
[Ed. - Good point! And thanks for all the work you put into getting
these measurements.]
Chuck Forsberg WA7KGX ...!tektronix!reed!omen!caf CIS:70715,131
Author of Professional-YAM communications Tools for PCDOS and Unix
Omen Technology Inc 17505-V NW Sauvie Island Road Portland OR 97231
Voice: 503-621-3406 TeleGodzilla: 621-3746 300/1200 L.sys entry for omen:
omen Any ACU 1200 1-503-621-3746 se:--se: link ord: Giznoid in:--in: uucp
------------------------------
Date: Tue, 21 Jan 86 11:52:43 EST
From: pugsly@isrnix.UUCP
Subject: Tandem running Guardian OS Kermit?
Do you know of a version of kermit for the Tandem running the Guardian OS?
Or do you know of one under development?
Thanks in advance.
David A. Roth
...decvax!pur-ee!isrnix!pugsly
...ihnp4!inuxc!isrnix!pugsly
Indianapolis,IN
[Ed. - I've received several of these messages lately. Does anyone know if
Tandem computers have more than one operating system? We have a version of
Kermit for Tandem, but I think the operating systme is called "Nonstop" --
is that the same thing? It's written in a language called TAL. Anybody
know anything about this?]
------------------------------
Date: Tue, 21 Jan 86 21:33:45 EST
From: CHRISTOPHER CHUNG <CC004065@BROWNVM.BITNET>
Subject: Novation Apple-Cat II?
Does anyone know of a way to make the Novation Apple-Cat II work with
Kermit? Is there a version of Kermit that I could get to work with my
Novation modem and my Apple //e or is there a way to modify an existing
version of Kermit to make it work with the Novation? Any help would be
greatly appreciately!
------------------------------
End of Info-Kermit Digest
*************************
-------