Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!ut-sally!seismo!uunet!iscuva!jimc
From: jimc@iscuva.UUCP
Newsgroups: comp.sources.d,comp.terminals,comp.emacs
Subject: Re: VT100's keeping up at high baud rates
Message-ID: <546@iscuva.ISCS.COM>
Date: Wed, 17-Jun-87 17:37:11 EDT
Article-I.D.: iscuva.546
Posted: Wed Jun 17 17:37:11 1987
Date-Received: Fri, 19-Jun-87 01:34:04 EDT
References: <1149@carthage.swatsun.UUCP> <8601@tekecs.TEK.COM>
Reply-To: jimc@iscuva.UUCP (Jim Cathey)
Organization: ISC Systems Corporation, Spokane, WA
Lines: 26
Xref: utgpu comp.sources.d:798 comp.terminals:287 comp.emacs:1031

In article <17160@amdcad.AMD.COM> bandy@amdcad.UUCP (Andy Beals) writes:
>TERMINALS SHOULD NOT HAVE TO SEND FLOW CONTROL BACK UP THE WIRE.
>
>TERMINALS SHOULD HAVE LARGE BUFFERS SO THEY MAY BE OF REAL USE IN DAY-TO-DAY
>OPERATIONS.  

Yassir!  I've just finished writing a H19-like terminal emulator for one of
our products that keeps up fully at 9600 baud (doesn't sound like much?  well,
it's a graphics-only product with 38K of RAM for the video).  It's written in
C with choice bits in assembly (68000).  I ended up using a 16K input buffer
just 'cause it was there, tho' it doesn't need it that big.  What made it all
work is that I separated the input processing code from the display code, and
the input processing code notices when scrolling is getting behind, and tells
the display code to start scrolling bigger chunks when necessary.  I got lazy
and only implemented the lookahead for linefeeds, though it would have been
straightforward to extend this... Come on, terminal guys, it wasn't _that_
hard to do!

+----------------+
! II      CCCCCC !  Jim Cathey
! II  SSSSCC     !  ISC Systems Corp.
! II      CC     !  Spokane, WA
! IISSSS  CC     !  UUCP: ihnp4!tektronix!reed!iscuva!jimc
! II      CCCCCC !  (509)927-5757
+----------------+
			"With flow control like this, who is needing enemas?"