Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!cbatt!cbosgd!ihnp4!chinet!randy
From: randy@chinet.UUCP (randy)
Newsgroups: net.periphs,net.micro,net.wanted
Subject: Re: update on **real** 19200 CRT
Message-ID: <464@chinet.UUCP>
Date: Fri, 8-Aug-86 10:43:04 EDT
Article-I.D.: chinet.464
Posted: Fri Aug  8 10:43:04 1986
Date-Received: Sat, 9-Aug-86 11:22:43 EDT
References: <671@mordred.purdue.UUCP> <71@winfree.UUCP>
Reply-To: randy@chinet.UUCP (Randy Suess-)
Organization: chi-net, Public Access UN*X, Chicago IL
Lines: 21
Keywords: scrolling speed
Xref: watmath net.periphs:1174 net.micro:15308 net.wanted:9378

In article <773@ho95e.UUCP> wcs@ho95e.UUCP (Bill Stewart 1-201-949-0705 ihnp4!ho95c!wcs HO 2G202) writes:
>The general concensus has been that not many PC-priced things can
>emulate a terminal at 19200 without doing *any* flow control, and that
>the primary limitation is the time to bitblt the whole screen up one
>line.  I'm curious as to the type of application that really needs this
>capability.  

	My main problem with buffered flow control term programs is this.
When you do a ls, or a cat of a large file and are looking for a 
particular line.  A couple of screenfulls go by, and you see what
you want to peruse.  Hit the ctrl s and watch 6 more buffered screens
go by!  Same thing with the intr char.  I wish the comm programs would
give the option of doing *no* buffering.  Then keyboard commands would
be a little more interactive.

-- 
.. that's the biz, sweetheart...
Randy Suess
chinet - Public Access UN*X
(312) 545 7535 (h) (312) 283 0559 (system)
..!ihnp4!chinet!randy