Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!watmath!clyde!caip!brl-adm!brl-smoke!smoke!prindle@nadc.arpa
From: prindle@nadc.arpa
Newsgroups: net.micro
Subject: re: 19.2KB terminal emulation
Message-ID: <2718@brl-smoke.ARPA>
Date: Thu, 31-Jul-86 13:50:58 EDT
Article-I.D.: brl-smok.2718
Posted: Thu Jul 31 13:50:58 1986
Date-Received: Sat, 2-Aug-86 05:38:12 EDT
Sender: news@brl-smoke.ARPA
Lines: 21

Ah yes, software emulation of a smart terminal.  Rest assured that parsing
the terminal control sequences for a VT100 (ANSI Standard) terminal is non-
trivial (as comapred to a VT52 for example).  The sequences are neither of
fixed length, nor do they end in a terminating character.  Furthermore, the
actions to be taken are quite variable.  For example, receipt of the sequence
ESC [ m (or, for that matter ESC [ 0 ; 0 ; 0 ; 0 ; 0 m) causes the character
attributes to be cleared (but nothing printed on the screen); by contrast
ESC O t is a no-op (an echo of an application keypad key), but the "t" must be
printed!  A VT100 also has a myriad of un-standardized reactions which no
terminal emulator ever seems to duplicate exactly.

However, a prime consideration in handling high baud rates without flow
control is hardware capabilities of the emulating PC.  Toughest of all is
to roll up a whole screen of characters without getting hopelessly behind in
the processing of (hopefully buffered) input data.  No matter how big you
make the buffer, enough short lines received will ultimately spend so much
time rolling up the screen that data will be lost, or flow control will have
to be imposed.

Frank Prindle
Prindle@NADC.arpa