Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site brl-tgr.ARPA
Path: utzoo!linus!philabs!cmcl2!seismo!brl-tgr!tgr!wcwells%ucbopal.CC@ucb-vax.ARPA
From: wcwells%ucbopal.CC@ucb-vax.ARPA (William C. Wells)
Newsgroups: net.micro.cpm
Subject: Re: Continuing Saga of the ADM3a/Kaypro Termcap
Message-ID: <10284@brl-tgr.ARPA>
Date: Tue, 30-Apr-85 00:48:00 EDT
Article-I.D.: brl-tgr.10284
Posted: Tue Apr 30 00:48:00 1985
Date-Received: Wed, 1-May-85 06:11:37 EDT
Sender: news@brl-tgr.ARPA
Lines: 22

Some of you may have noticed differences in the padding number for
"cl", eg. :cl=3^Z:, cl=1^Z . I suspect that some of the problems
I have observed with the Kaypro 2x at higher port speeds (eg. 1200,
9600 baud) are related to needs for the microcomputer to do some work
each time it receives a new-line (linefeed) and/or return (CR)
character from a remote system.  Depending on the port speed and the
amount of cpu processing required by the communication program on
the Kaypro, it may be necessary to increase the padding on "cl"
(clear screen), and set or increase "dC" (number of milisec of
cr delay needed) and "dN" (number of milisec of nl delay needed).

Of course, adding padding and end of line delays to the termcap
may not be the whole solution.  Lack of data line flow control
(eg. XOFF/XON) can easily bring most communications programs to a
halt at higher speeds (by overflowing I/O buffers). In addition,
many communication and file transfer program assume a quick
response to transmission from the remote machine. That is, the
program will time out when the required response is delayed,
for example, by an overloaded time sharing system.

Bill
wcwells@Berkeley.ARPA