Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!ut-sally!husc6!bloom-beacon!think!ames!ptsfa!ihnp4!alberta!sask!zaphod!dvlmarv!watmath!watmum!smvorkoetter
From: smvorkoetter@watmum.UUCP (Stefan M. Vorkoetter)
Newsgroups: comp.sources.d
Subject: Re: Using a PC for a terminal
Message-ID: <1030@watmum.UUCP>
Date: Sun, 21-Jun-87 14:40:21 EDT
Article-I.D.: watmum.1030
Posted: Sun Jun 21 14:40:21 1987
Date-Received: Tue, 23-Jun-87 05:22:03 EDT
References: <1149@carthage.swatsun.UUCP> <8601@tekecs.TEK.COM>
Reply-To: smvorkoetter@watmum.UUCP (Stefan M. Vorkoetter)
Organization: U. of Waterloo, Ontario
Lines: 53

In article <1790@Shasta.STANFORD.EDU> kaufman@Shasta.stanford.edu (Marc Kaufman) writes:
>In article <1017@watmum.UUCP> smvorkoetter@watmum.UUCP (Stefan M. Vorkoetter) writes:
>
>>I am using an AT Clone, running a VT102 emulation package (Terminal Emulator
>>and File Transfer 2.40a), and it is having no trouble at 19200 baud, using
>>only XON/XOFF (no hardware flow control)...
>
>My teeth itch when I read this.  Let's get it straight.  The ability to
>read individual characters at a speed of 19200 bits per second is NOT THE
>SAME as the ability to asimilate characters at the rate of 1920 Characters
>per second.  Got that?  If you need/use XON/XOFF protocol, you are NOT
>keeping up at the speed in question.  We are talking about the ability to
>process characters WITHOUT flow control at a given speed.  BTW: just
>because your VAX, etc., is set to send characters at a (bit) speed of
>19200 bits per second, is no reason to assume that is is sending 1920
>Characters per second... you have to do some timing studies to determine
>what is really happening.


The point is, the program can and does assimilate characters at 19200 bps.  The
only time it sends XON/XOFF is when its 4000 character buffer is full.  I have
used it with EMACS with flow control ENABLED, and it works no problem, because
it never has to send an XOFF because a full screen update is less than 4000
characters.

There is a reason to assume the characters are coming in at 19200 bps because
I am using a Sytek box, which sends me the characters in 19200 bps bursts.  I
have seen other programs drop characters in the same situation.

If the AT/Terminal Emulator combination could not keep up, plain XON/XOFF
protocol wouldn't help a whole lot since several characters could still come in
after the XOFF was sent.  Some programs cannot keep up at this rate because one
character is still being processed when the next comes in.  Eventually (5 or 6
characters down the line) things get far enough behind so that an overrun error
results.

BTW: On buffering: When I press CTRL-S (or No Scroll), the program sends XOFF
to the host.  Any characters in the buffer will be read in and displayed.  This
can cause aggravation.  HOWEVER, if I press CTRL-NumLock (or FN-Pause on a
PCjr) then the program itself pauses.  Characters keep coming in from the host
and piling up in the buffer.  If the buffer becomes full, an XOFF is sent to
the host automatically.  Thus you get full scrolling control, and still no loss
of characters.  Even though the program is paused, the serial drivers keep 
going (they are interrupt driven).  I can even to a Print Screen in the middle
of incoming characters; everything stops, the screen gets printed, and no
characters are ever lost.

To the above flamer (with the itchy teeth): Don't assume someone who says 
something that makes no sense to you doesn't know what they are talking about.
I am quite comfortable in the picky details of serial communications.  After
all, I wrote the program in question.  Got that?

~