Q: what terminal emulations would you want supported?
Stan
Hello,
If you were designing a terminal emulation program
for embedded developers, what are the most common
terminal emulations you would support in the program?
ANSI 3.64? (outdated, use ISO6xxx?)
DEC VT-100? (others like VT-52, 220, 320, 420, ...?)
WYSE?
Televideo?
others...?
Thanks in advance!
Stan
Return address is invalid to help stop junk mail.
Remove the X from my email address to reply back.
car...@xylogics.com
In article <5i1p56$ndv$1...@europa.frii.com> stan...@frii.com (Stan) writes:
> If you were designing a terminal emulation program
> for embedded developers, what are the most common
> terminal emulations you would support in the program?
>
> ANSI 3.64? (outdated, use ISO6xxx?)
No such animal. ANSI X3.64 is just a list of controls which could be
used in any number of applications. It includes controls for
typesetting -- like line spacing and character spacing -- which can't
reasonably be duplicated on a terminal, and wouldn't be compatible
with any software anyway.
When people say "ANSI terminal," they're usually PC owners talking
about Microsoft's ANSI.SYS, which is a small and rough subset of the
standard ANSI command set.
> DEC VT-100? (others like VT-52, 220, 320, 420, ...?)
I'd recommend at least VT220 emulation. True VT100 doesn't have
function keys. If you want something near a VT100, do VT102 instead.
VT52 is nice because it's similar to many, many other terminals, like
the Beehive Superbee and the H-19. If you do VT52 (and it's trivial),
then you've got 99% of those others as well. On the other hand, it's
not that important for support these days.
> WYSE?
WY-75 seems to be a popular one. I'm not exactly a big fan, though.
I'd add Tektronix 4010 (or better yet 4014) to the list. This is a
really simple emulation to do if you have graphics available, and it's
compatible with just about every CAD-type package that's available.
Don't forget character set support. This is independent from the
emulations you choose to do. You should have support for at least ISO
8859/1.2 Latin-1 and probably the DEC Special Graphics set. You may
also want support for some of the other ISO 8859 character sets if you
want to distribute this program internationally. And, for those who
use PCs (ugh), you may also want support for the non-standard "IBM PC"
character set.
--
James Carlson <car...@xylogics.com>, Prin Engr Tel: +1 508 916 4351
Bay Networks - Annex I/F Develop. / 8 Federal ST +1 800 225 3317
Mail Stop BL08-05 / Billerica MA 01821-3548 Fax: +1 508 916 4789
Frank da Cruz
In article <3345b5c4....@news.alt.net>, Peter <z...@dserve.com> wrote:
: In 1997, I would say just VT100.
:
: With all respect to the others, the other systems are about as dead as
: the VDUs which used them.
:
That's pure opinion. Come sit at the Kermit help desk for a day and see
how many terminal emulations are still in heavy use and heavy demand.
: But you may be aiming for a highly specific market in which case there
: might be other relevant ones.
:
VT220 and above, for example, allow the use of languages other than English;
if you call the rest of the world a highly specific market :-)
Frank da Cruz
In article <odn2reg...@donald.xylogics.com>, <car...@xylogics.com> wrote:
VT220? VT52? Heath 19? Wyse? Tek 4010? Tek 4014? ISO 8859-1?
DEC Special Graphics? Other ISO 8859 sets? The IBM PC character set?
Hey, it's MS-DOS Kermit:
http://www.columbia.edu/kermit/
Of course, the original poster said "embedded". The typical embedded system
has severe memory restraints -- often as little as 4K, 8K, 16K... You're not
going to fit all that into a tiny space. MS-DOS Kermit's assembly code is
about as tight as you can get, and was developed and debugged over 15 years.
Terminal emulations (anything beyond the VT52 level) are amazingly hard to get
right. You might consider licensing the MS-DOS Kermit source code if your
embedded system is Intel 808x based.
- Frank
Frank da Cruz
In article <3349f864...@news.netcomuk.co.uk>,
Peter <z...@dserve.com> wrote:
:
: >how many terminal emulations are still in heavy use and heavy demand.
:
: ago.
:
And so extrapolating from a sample of 1...?
Don Yuniskis
In article <3349f864...@news.netcomuk.co.uk>,
Peter <z...@dserve.com> wrote:
>>That's pure opinion. Come sit at the Kermit help desk for a day and see
>>how many terminal emulations are still in heavy use and heavy demand.
>
>How many people use Kermit? Last time I used it was about 10 years
>ago.
Ah, well... there may be a few diehards in the UN*X camps -- though it
offers very little more than cu(1) :> I got tired of the 25%
throughput penalty that kermit's file transfer imposes vs. something
like Zmodem -- or even UUCP with a protocol spoofing modem.
The idea of "porting" kermit to an embedded platform is *laughable*!
It's far too big of a resource pig for what it would buy you. A
VT-100 style terminal emulator is *not* a big project -- assuming
you already have the communications subsystem in place (UART, etc.)
and hooks to move characters to the display and from the keyboard.
You can write a tiny grammar to cover all the escape sequences
(assuming you're too lazy to hard code it). Toughest part is
putting timeouts on the ESC characters (since that usually needs
some amount of driver/O.S. support)...
--don
car...@xylogics.com
In article <5i6305$h...@baygull.rtd.com> d...@rtd.com (Don Yuniskis) writes:
[...]
> (assuming you're too lazy to hard code it). Toughest part is
> putting timeouts on the ESC characters (since that usually needs
> some amount of driver/O.S. support)...
Timeouts on the ESC characters? I hope you're referring to possibly
adding a longish delay after sending ESC from the keyboard "Esc" key
for compatibility with broken curses implementations.
Otherwise, this would be a bad thing to do. VT-series terminals
operate by running a single state machine over the input, not by doing
a read-character/call-function type of implementation. If you can't
handle a LF in the middle of a CSI, then the implementation is broken.
Frank da Cruz
In article <5i6305$h...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
: In article <3349f864...@news.netcomuk.co.uk>,
: Peter <z...@dserve.com> wrote:
: >>That's pure opinion. Come sit at the Kermit help desk for a day and see
: >>how many terminal emulations are still in heavy use and heavy demand.
: >
: >How many people use Kermit? Last time I used it was about 10 years
: >ago.
:
: Ah, well... there may be a few diehards in the UN*X camps -- though it
: offers very little more than cu(1) :>
When did you last look at UNIX C-Kermit, fifteen years ago? cu does not:
. Transfer files
. Include a script programming language
. Translate character sets
. Make Telnet or Rlogin connections
: I got tired of the 25%
: throughput penalty that kermit's file transfer imposes vs. something
: like Zmodem -- or even UUCP with a protocol spoofing modem.
:
Then you should have taken 30 seconds to look at the documentation. Anyone
who still thinks that Kermit is slower than Zmodem, see:
http://www.columbia.edu/kermit/perf.html
: The idea of "porting" kermit to an embedded platform is *laughable*!
:
Then why have so many companies done it? Kermit is embedded in every kind
of device you can think of, ranging from calculators to fast-food restaurant
cash registers to cell-phone relay stations to fiber-optic multiplexers.
: It's far too big of a resource pig for what it would buy you.
:
And you know this how?
Anybody who wants to know the actual information about Kermit software
and protocol is invited to visit the Kermit website:
http://www.columbia.edu/kermit/
- Frank
Don Yuniskis
In article <5ibhnl$1sh$1...@apakabar.cc.columbia.edu>,
Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
>In article <5i6305$h...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
>: In article <3349f864...@news.netcomuk.co.uk>,
>: Peter <z...@dserve.com> wrote:
>: >>That's pure opinion. Come sit at the Kermit help desk for a day and see
>: >>how many terminal emulations are still in heavy use and heavy demand.
>: >
>: >How many people use Kermit? Last time I used it was about 10 years
>: >ago.
>:
>: Ah, well... there may be a few diehards in the UN*X camps -- though it
>: offers very little more than cu(1) :>
>
>When did you last look at UNIX C-Kermit, fifteen years ago? cu does not:
Well, *bozo*, perhaps you should check your mailing list archives.
I think you'll find several messages from me re: the 190 port
(I think) of C-Kermit. I gave up on mailing them to you because
I have *other* things to do with my life besides fix slipshod code!
> . Transfer files
Right. I guess it's too much to expect a cu(1) user to type 'rz' and
let 'sz' send from the other end!
> . Include a script programming language
Aside from using it to set the kermit(1) operating parameters, I've
found very little use for it.
> . Translate character sets
I regularly corrrrespond with folks around the world and *still*
haven't found a need for this! If I need to look at something
written for a different locale, I just tweek environment variables...
> . Make Telnet or Rlogin connections
Gee, what's wrong with 'telnet' or 'rlogin'? :>
>: I got tired of the 25%
>: throughput penalty that kermit's file transfer imposes vs. something
>: like Zmodem -- or even UUCP with a protocol spoofing modem.
>
>Then you should have taken 30 seconds to look at the documentation. Anyone
>who still thinks that Kermit is slower than Zmodem, see:
>
> http://www.columbia.edu/kermit/perf.html
I've read all the docs supplied with the (190) sources, thankyouverymuch!
I've tweeked all the parameters, etc. sz/rz still gives me consistently
better performance than kermit's protocol. I've also tried using
kermit protocol on *other* (i.e. DOS) products and seen the same
performance differences, etc.
>: The idea of "porting" kermit to an embedded platform is *laughable*!
>:
>Then why have so many companies done it? Kermit is embedded in every kind
>of device you can think of, ranging from calculators to fast-food restaurant
>cash registers to cell-phone relay stations to fiber-optic multiplexers.
>
>: It's far too big of a resource pig for what it would buy you.
>:
>And you know this how?
From looking at the sizes of the *stripped* executable, uh, d'uh...
When was the last time *you* looked at other options? When was the last
time *you* designed an embedded product?? When was the last time *you*
wrote a device driver to pump characters into/out of a UART, NIC,
etc. instead of simply relying on the services provided within stdio, etc.?
Not *all* "embedded products" have 100K to set aside to support a
"file transfer protocol", etc.
File sizes (unstripped):
kermit 400K
sz 30K
rz 30K
Sure, rz and sz just deal with file transfer whereas kermit has
"on line help" (have you fixed all the typos I sent you yet? :>)
support for setting two gazillion options, command line expansion,
etc.
Hint: why not write a 'sk' and an 'rk' and see how well *they*
perform (size, speed, etc.).
--don
Frank da Cruz
In article <5ibrqa$2...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
[ what he thought was a scathing attack on Kermit... ]
We don't need to rehash all of these old items from many years ago -- the
endless debates about Kermit vs Zmodem are on record at your favorite
newsgroup archives. The bottom line: no matter which one you believe is
faster, Kermit works everywhere that Zmodem works, but the reverse if far
from true.
: > . Include a script programming language
:
: Aside from using it to set the kermit(1) operating parameters, I've
: found very little use for it.
:
: > . Translate character sets
:
: I regularly corrrrespond with folks around the world and *still*
: haven't found a need for this! If I need to look at something
: written for a different locale, I just tweek environment variables...
:
"I don't use this feature" is not proof that nobody uses it. "I speak
English" is not proof that everybody else in the world does too.
: > . Make Telnet or Rlogin connections
:
: Gee, what's wrong with 'telnet' or 'rlogin'? :>
:
They can't be scripted, they don't transfer files, they don't translate
character sets. People (other than you) use these features.
: >: The idea of "porting" kermit to an embedded platform is *laughable*!
: >:
: >Then why have so many companies done it? Kermit is embedded in every kind
: >of device you can think of, ranging from calculators to fast-food restaurant
: >cash registers to cell-phone relay stations to fiber-optic multiplexers.
: >
: >: It's far too big of a resource pig for what it would buy you.
: >:
: >And you know this how?
:
: From looking at the sizes of the *stripped* executable, uh, d'uh...
:
So this means you can tell the difference between a protocol and the code
that implements it? C-Kermit is big because it does a lot more than
transfer files.
At the other end of the scale, the Kermit program for the 8051 controller is
900 lines of assembly code. The nice thing about the Kermit protocol is
that it has numerous features that can or can not be implemented, and whose
use is negotiated at transfer time. Thus an implementation can be quite
compact if it is willing to sacrifice certain features.
: Not *all* "embedded products" have 100K to set aside to support a
: "file transfer protocol", etc.
:
: File sizes (unstripped):
: kermit 400K
: sz 30K
: rz 30K
:
Here's a snippet from the 8051 Kermit docs (begin quote):
... As an example my test unit has 32k of ram memory and a small bootloader
rom that is switch off after loading into ram. PSEN is or'd with RD so that
code can be executed in ram, hence the close range of rom to ram with no
overlap. My monitor is from 0000h to 1fffh. 2000h to 2fffh is for floating
point routines and extended math functions. The kermit code is loaded at
3000h to 33ffh and the data for kermit is at 3400h to 35ffh...
(End quote)
33ffh - 3000h = 03ffh = 1023 decimal
35ffh - 3400h = 01ffh = 511 decimal
Total Kermit size: 1534 bytes
- Frank
Don Yuniskis
In article <5idlqg$cd6$1...@apakabar.cc.columbia.edu>,
>[ what he thought was a scathing attack on Kermit... ]
Not at all. Simply my opinions -- since they had *my* name on the bottom
-- based on *my* observations of the *performance*, etc.
>We don't need to rehash all of these old items from many years ago -- the
>endless debates about Kermit vs Zmodem are on record at your favorite
>newsgroup archives. The bottom line: no matter which one you believe is
>faster, Kermit works everywhere that Zmodem works, but the reverse if far
>from true.
A 252188 byte file transfered from kermit (188) on a BSDi box to
XTALK's kermit and ZMODEM protocol handler on a DOS box.
KERMIT ZMODEM
234 221 seconds
1077 1141 CPS
So, only a *slight* penalty for a random file (this was a .DWF file)
Since it's possible that XTALK poorly implements the KERMIT protocol,
try the same thing except from kermit (188) on that *same* BSDi box
to kermit (190) on a FBSD box running on the same iron as above:
KERMIT ZMODEM
233 230 seconds
1082 1096 CPS
Again, close enough to be indistinguishable. Any (small) differences
may be attributable to the fact that I had to drop my connection
in order to boot FBSD. So, it's possible that I'm talking to a different
modem, etc.
Now, the same file then gzip(1)-ed and sent to XTALK's handler.
The resulting file shrinks to 214486 bytes
KERMIT ZMODEM
245 196 seconds
875 1094 CPS
Since this is the typical way I use a file transfer program (i.e. to
exchange heavily compressed files), that 25% adds up.
Again, since the folks at XTALK might not know how to write kermit
protocol well, try kermit (188) to (190) on UN*X boxes against
sz/rz on those same boxes:
KERMIT ZMODEM
245 205 seconds
875 1046 CPS
Still looks like 25% to me!
Kermit and ZMODEM were both set up for 1K buffers. Binary mode, 4 windows
to kermit. Hopefully, that's a fair (RAM) resource comparison -- though
I can't say if the number of outstanding packets (4 in Kermit and I think
ZMODEM is hardwired at 7??) effectively increases the amount of memory
each protocol uses, etc.
>: > . Include a script programming language
>:
>: Aside from using it to set the kermit(1) operating parameters, I've
>: found very little use for it.
>:
>: > . Translate character sets
>:
>: I regularly corrrrespond with folks around the world and *still*
>: haven't found a need for this! If I need to look at something
>: written for a different locale, I just tweek environment variables...
>:
>"I don't use this feature" is not proof that nobody uses it. "I speak
>English" is not proof that everybody else in the world does too.
If you would reread the text of my statements, you'll see that I did
NOT make any claims about who else may/may not use it, etc.
>: > . Make Telnet or Rlogin connections
>:
>: Gee, what's wrong with 'telnet' or 'rlogin'? :>
>:
>They can't be scripted, they don't transfer files, they don't translate
>character sets. People (other than you) use these features.
Look, the above statement says "Make telnet and rlogin connections"
*It* doesn't say anything about scripting those sessions, transfering
files, translating character sets, etc. There are other facilities
available to achieve all of those things -- telnet and rlogin are
designed to make *connections*. ftp, fsp, etc. handle file transfers.
perl, sh, expect, tcl, etc. handle scripts. When will kermit
have a thesauraus module added to it?? :>
>: >: The idea of "porting" kermit to an embedded platform is *laughable*!
>: >:
>: >Then why have so many companies done it? Kermit is embedded in every kind
>: >of device you can think of, ranging from calculators to fast-food restaurant
>: >cash registers to cell-phone relay stations to fiber-optic multiplexers.
>: >
>: >: It's far too big of a resource pig for what it would buy you.
>: >:
>: >And you know this how?
>:
>: From looking at the sizes of the *stripped* executable, uh, d'uh...
>:
>So this means you can tell the difference between a protocol and the code
>that implements it? C-Kermit is big because it does a lot more than
>transfer files.
Sheesh! You *really* have a problem reading what is written! My (above)
statement says: "It's far too big of a resource pig fro what it would buy
you". To answer your terse "and you know this how", I replied that
I know it's a resource pig by looking at the size of the executable
(since I consider a program's *size* to be at least one example of the
amount of resources that it uses, I figure that's a valid justification
of my assertion!). I don't see where that statement made any claims
about "the difference between a protocol and the code that implements it".
Granted, it does "a lot more than transfer files". But, look at the title of
the thread: the original poster wanted a terminal emulator for an
embedded product. *You* suggested he look at (presumably, *LICENSING*)
the kermit(1) code. There was no mention of "protocols", etc. (IIRC)
in the original post. I believe protocols came into the discussion
when *I* mentioned that I got tired of the 25% performance penalty
I encountered with kermit(1).
Now, as far as terminal emulation is concerned, one could assume that the
original post was looking for something that would allow his product to
generate magic keys in certain circumstances (i.e. perhaps he has a
joystick or arrow keys and would like them to generate keysequences
that match some "standard" terminal, etc.). Likewise, for any function
keys, etc. I don't really see how kermit is going to help there since
curses(1) handles the mapping to KEY_LEFT, KEY_HOME, KEY_F(), etc.
Of course, his product may (also?) have a display capability and
he wants it to interpret incoming escape sequences and decode them
to set cursor position, sgr(), etc. IIRC, I don't see where kermit
does this at all! Kermit causes the user's display to be driven
with cursor positioning commands, sgr()'s, etc. -- but, curses
handles that, also.
So, as a TERMINAL EMULATION, what exactly is your suggestion
intended to contribute to this guy?
>At the other end of the scale, the Kermit program for the 8051 controller is
>900 lines of assembly code. The nice thing about the Kermit protocol is
>that it has numerous features that can or can not be implemented, and whose
>use is negotiated at transfer time. Thus an implementation can be quite
>compact if it is willing to sacrifice certain features.
I assume you are referring to the kermit *protocol* as 900 lines of code.
I suspect [XYZ]modem would be similarly sized. (neglecting the inherently
non-portable aspects of fgetc(), fputc(), etc.).
>: Not *all* "embedded products" have 100K to set aside to support a
>: "file transfer protocol", etc.
>:
>: File sizes (unstripped):
>: kermit 400K
>: sz 30K
>: rz 30K
>:
>Here's a snippet from the 8051 Kermit docs (begin quote):
>
>... As an example my test unit has 32k of ram memory and a small bootloader
>rom that is switch off after loading into ram. PSEN is or'd with RD so that
>code can be executed in ram, hence the close range of rom to ram with no
>overlap. My monitor is from 0000h to 1fffh. 2000h to 2fffh is for floating
>point routines and extended math functions. The kermit code is loaded at
>3000h to 33ffh and the data for kermit is at 3400h to 35ffh...
>
>(End quote)
>
> 33ffh - 3000h = 03ffh = 1023 decimal
> 35ffh - 3400h = 01ffh = 511 decimal
>
>Total Kermit size: 1534 bytes
So, 1K of text and 500 bytes of data -- just for the protocol handler
How does this satisfy the original poster's request for a terminal
emulator? Does it translate keystrokes into escape sequences?
Or, does it recognize escape sequences and decode video attributes
from them, cursor positioning, etc.?
Or, is it just a file transfer protocol -- which, IIRC, has NOTHING
to do with terminal emulation... (how many *terminals* can you name
that use kermit, zmodem, xmodem, sealink, etc. to talk to their
associated hosts???)
--don
Don Yuniskis
In article <odragnu...@donald.xylogics.com>, <car...@xylogics.com> wrote:
>In article <5i6305$h...@baygull.rtd.com> d...@rtd.com (Don Yuniskis) writes:
>[...]
>> (assuming you're too lazy to hard code it). Toughest part is
>> putting timeouts on the ESC characters (since that usually needs
>> some amount of driver/O.S. support)...
>
>Timeouts on the ESC characters? I hope you're referring to possibly
>adding a longish delay after sending ESC from the keyboard "Esc" key
>for compatibility with broken curses implementations.
Typically, ESC must be followed by the remaining characters (well, at least
the *next* character) in a multicharacter escape sequence within a one second
window to be recognized as an ESCape sequence as opposed to the ESCape
key itself. I haven't seen many (small) embedded systems that implement
a "complete" tty driver with support for things like MIN and TIME.
>Otherwise, this would be a bad thing to do. VT-series terminals
>operate by running a single state machine over the input, not by doing
>a read-character/call-function type of implementation. If you can't
Yes, but will (for example) a VT-100 wait "forever" after receiving
an ESC for the balance of the escape sequence? Hmmm... I guess it
*could* since it doesn't have anything *else* to use the ESC for...
(which is different from curses trying to distinguish ESC from,
for example, KEY_LEFT)
>handle a LF in the middle of a CSI, then the implementation is broken.
Hmmm... I didn't realize LF was ignored in a CSI. I had assumed
that *all* characters (except flow control) were expected *literally*
in these sequences!
--don
Frank da Cruz
In article <5ie1da$k...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
: In article <5idlqg$cd6$1...@apakabar.cc.columbia.edu>,
: Frank da Cruz <f...@watsun.cc.columbia.edu> wrote:
: A 252188 byte file transfered from kermit (188) on a BSDi box to
: XTALK's kermit and ZMODEM protocol handler on a DOS box.
: KERMIT ZMODEM
: 234 221 seconds
: 1077 1141 CPS
: So, only a *slight* penalty for a random file (this was a .DWF file)
:
: Since it's possible that XTALK poorly implements the KERMIT protocol,
: try the same thing except from kermit (188) on that *same* BSDi box
: to kermit (190) on a FBSD box running on the same iron as above:
: KERMIT ZMODEM
: 233 230 seconds
: 1082 1096 CPS
:
: Again, close enough to be indistinguishable. Any (small) differences
: may be attributable to the fact that I had to drop my connection
: in order to boot FBSD. So, it's possible that I'm talking to a different
: modem, etc.
:
: Now, the same file then gzip(1)-ed and sent to XTALK's handler.
: The resulting file shrinks to 214486 bytes
: KERMIT ZMODEM
: 245 196 seconds
: 875 1094 CPS
: Since this is the typical way I use a file transfer program (i.e. to
: exchange heavily compressed files), that 25% adds up.
:
But, since ZMODEM works on this connection, then Kermit with "full
unprefixing" will also work. I should point out that the current version
of C-Kermit is 6.0.192 and you can pick it up at:
http://www.columbia.edu/kermit/ck60.html
With this version in hand, just give the FAST command prior to transfer
and it will unprefix most control characters (give this command to the
file sender). (The FAST command actually uses a fairly conservative form
of unprefixing, but you can make it less conservative -- which, again, is
probably safe on this particular connection since Zmodem works there --
with SET PREFIXING MINIMAL.)
: So, as a TERMINAL EMULATION, what exactly is your suggestion intended to
: contribute to this guy?
:
Something along the lines of: a good terminal emulator is not something you
can knock off in a week, or a month, nor is it something that will fit into a
few K of memory -- especially if it is for a fairly high-level terminal like
VT320, Wyse 60, SCOANSI, etc -- the ones most people want. Even a good VT100
emulator is not that easy to find: run your 10 favorite VT100 emulators
through VTTEST and see how they score.
Probably the most compact and most high-performance and faithful VT100, 102,
220, 320, ANSI, and Wyse emulator has already been written in 8086 assembly
language -- it's in MS-DOS Kermit, and it can be licensed for embedding in
commercial products. It has been debugged through heavy use by millions of
people over the past 15 years.
- Frank
car...@xylogics.com
In article <5ie3v9$k...@baygull.rtd.com> d...@rtd.com (Don Yuniskis) writes:
> >Timeouts on the ESC characters? I hope you're referring to possibly
> >adding a longish delay after sending ESC from the keyboard "Esc" key
> >for compatibility with broken curses implementations.
>
> Typically, ESC must be followed by the remaining characters (well, at least
> the *next* character) in a multicharacter escape sequence within a one second
> window to be recognized as an ESCape sequence as opposed to the ESCape
> key itself. I haven't seen many (small) embedded systems that implement
> a "complete" tty driver with support for things like MIN and TIME.
I haven't seen any terminals or terminal emulators that do this. This
is generally a necessary function on the *host* side, not the
*terminal* side of communications. The data sent to terminals is
quite a bit different from the data sent to hosts. The worst part of
the data sent to hosts is that ESC is unfortunately used by a number
of applications, and this makes 7-bit C1 sequences ambiguous without a
timer. No such ambiguity exists on the terminal side of things.
> >Otherwise, this would be a bad thing to do. VT-series terminals
> >operate by running a single state machine over the input, not by doing
> >a read-character/call-function type of implementation. If you can't
>
> Yes, but will (for example) a VT-100 wait "forever" after receiving
> an ESC for the balance of the escape sequence? Hmmm... I guess it
> *could* since it doesn't have anything *else* to use the ESC for...
> (which is different from curses trying to distinguish ESC from,
> for example, KEY_LEFT)
Yes, it does wait forever. There's no reason for the host system to
send a "bare" escape to a terminal -- ever. It would have no meaning.
> >handle a LF in the middle of a CSI, then the implementation is broken.
>
> Hmmm... I didn't realize LF was ignored in a CSI. I had assumed
> that *all* characters (except flow control) were expected *literally*
> in these sequences!
No, it's not at all ignored, nor is it treated as a literal. If you
send, for example, the sequence "ESC [ LF C", then the terminal will
move the cursor down one line (scrolling if necessary) and then to the
right one position (stopping at the right margin if necessary).
That's why you have to implement it with a centralized state machine,
rather than distributed read routines. The C0 sequences are still
active in the middle of an ANSI control sequence.
(And ignoring this fact is why so many of the PC-based emulators that
are available are very poorly done and not quite compatible. If the
implementors at least tested against "vttest," this common bug would
be caught.)
Flow control is done at a conceptually lower layer. It can appear
anywhere in the "data," and should be handled separately by the input
driver. (Though I suppose a careful implementation could also do it
in the central state machine.)
car...@xylogics.com
In article <334c8cb1....@news.netcomuk.co.uk> z...@dserve.com (Peter) writes:
> >Timeouts on the ESC characters? I hope you're referring to possibly
> >adding a longish delay after sending ESC from the keyboard "Esc" key
> >for compatibility with broken curses implementations.
>
> Not having a timeout means that ESCape characters could never be sent
> to the application, e.g. to exit from menus etc.
That's a host function, not a terminal function. Hosts never send a
bare escape to a terminal. It's not a legal command for anything.
Jerry Leichter
| >Timeouts on the ESC characters? I hope you're referring to possibly
| >adding a longish delay after sending ESC from the keyboard "Esc" key
| >for compatibility with broken curses implementations.
|
| typically tens of ms, on the ESC character, so that e.g.
|
| ESC [ M
|
| (sent without any large gaps) is interpreted as such (I made up that
| ESCape sequence, BTW) whereas someone typing
|
| ESC
|
| (done with a finger, so obviously followed by a long gap) is taken as
| a single character which is to be passed on to the application.
Incorrect, in every possible way.
a) People can, and do, type keys one after another very quickly.
b) No ANSI terminal guarantees anything about how quickly it will send
the constituents of an outgoing escape sequence. In practice,
they *usually* send them quickly, but this is certainly not
guaranteed.
c) No ANSI terminal, and no application, can possibly guaranteed the
performance of the comm line between the terminal and the host.
If the comm line is simply slow - seems hard to believe now,
but 300 bps = about 30 cps used to be common for modems. People
can easily type that fast in bursts. Today, *everything* but
hardwired connections is packetized. What happens when ESC
goes in one packet, and the rest of the sequence in the next -
and the second packet gets delayed, or lost?
| Not having a timeout means that ESCape characters could never be sent
| to the application, e.g. to exit from menus etc.
Correct. Properly designed applications should not rely on timeouts to
distinguish between ESC and escape sequences. Thus, they should not use
bare ESC to mean *anything*. Such usage is incompatible with the ANSI
definitions.
Yes, this is a common design. Yes, it works 99.9999+% of the time with
no problems. But it *will* fail every once in a while, and when it
does, the fault is the application designer's, not the terminal or
terminal emulator or host interface designer's. The relevent standards
date back to, what, 1974? If you insist on ignoring them, it's at your
own peril.
(BTW, it was exactly to try to wean people from such interfaces that the
DEC VT200 and later terminals removed the ESC key from the keyboard.
Yes, you can still generate ESC, but it takes a deliberate action.
There are plenty of other function keys available. Pick one!)
-- Jerry
Don Yuniskis
In article <5iejer$133$1...@apakabar.cc.columbia.edu>,>In article <5ie1da$k...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
[stats of kermit slower than zmodem on transfer of gzip'ed file snipped]
>But, since ZMODEM works on this connection, then Kermit with "full
>unprefixing" will also work. I should point out that the current version
>of C-Kermit is 6.0.192 and you can pick it up at:
>
> http://www.columbia.edu/kermit/ck60.html
(groan) Sorry, I don't have the time to do another port :-/ It's
more than a full-time job just keeping all the *other* software
packages running, configured, etc. :-(
>With this version in hand, just give the FAST command prior to transfer
>and it will unprefix most control characters (give this command to the
>file sender). (The FAST command actually uses a fairly conservative form
>of unprefixing, but you can make it less conservative -- which, again, is
>probably safe on this particular connection since Zmodem works there --
>with SET PREFIXING MINIMAL.)
Can I do something like PREFIXING OFF (sorry, I'm not on a UN*X box
currently so can't recall the exact kermit commands) with the
190 version? I'll have to dig up my .kermrc and see what it
spells out currently...
And, for what scenarios does kermit have to be more conservative than ZModem?
(sorry, poorly phrased). In other words, why are you qualifying your
statements with "since ZMODEM works there"? In which of these (dialup)
conditions would ZMODEM *not* work yet kermit provide me a workaround?
>: So, as a TERMINAL EMULATION, what exactly is your suggestion intended to
>: contribute to this guy?
>:
>Something along the lines of: a good terminal emulator is not something you
>can knock off in a week, or a month, nor is it something that will fit into a
>few K of memory -- especially if it is for a fairly high-level terminal like
>VT320, Wyse 60, SCOANSI, etc -- the ones most people want. Even a good VT100
>emulator is not that easy to find: run your 10 favorite VT100 emulators
>through VTTEST and see how they score.
That, of course, depends on what the original poster was looking for.
I use a *real* VT-100 since I find most (fill in the blank)
emulators have *some* quirks and if I'm designing a product that
is advertised to work with a VT-100, I want to be damn sure that
it *does* work with a VT-100 (and I don't particularly care if it
bombs out with some noname clone/emulator/etc.).
Actually, I reread the original post and it appears the original
poster was NOT (necessarily) looking to write a terminal emulator
for use in an embedded product (as I had ASSuMEd :-( In fact, he
was looking for info on what terminal emulations to support *if* you were
writing a terminal emulator for use by embedded systems, etc. I
*guess* that's another beast entirely...
To answer that question, I would say "VT-100" (assuming you want to
pick *just one*). Keeping in mind that many embedded products have to
talk to legacy systems, etc. So, even a VT-220 could be "too new".
--don
Tim Shoppa
In article <5ie3v9$k...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
>In article <odragnu...@donald.xylogics.com>, <car...@xylogics.com> wrote:
>>adding a longish delay after sending ESC from the keyboard "Esc" key
>>for compatibility with broken curses implementations.
>
>the *next* character) in a multicharacter escape sequence within a one second
>window to be recognized as an ESCape sequence as opposed to the ESCape
>key itself.
Huh? This is a rather bizarre behavior, and one I've never
found with any real terminal.
>>Otherwise, this would be a bad thing to do. VT-series terminals
>>operate by running a single state machine over the input, not by doing
>>a read-character/call-function type of implementation. If you can't
>
>Yes, but will (for example) a VT-100 wait "forever" after receiving
>an ESC for the balance of the escape sequence?
Yes, it will.
Come on guys, there are enough crappy terminal emulators out there
already. Please don't go pontificating about how you think a
VT-100 *ought* to work - just find a real one and figure out how
it *actually does* work.
I've spoken with several companies selling PC-clone DOS/Windows terminal
emulators where it's clear that nobody at the company has even
bothered to compare the behavior that a real VT100 has. MS-DOS
Kermit is one of the very few that does emulation right.
Tim.
Tim Shoppa
In article <334c8cb1....@news.netcomuk.co.uk>,
Peter <z...@dserve.com> wrote:
>
>>Timeouts on the ESC characters? I hope you're referring to possibly
>>adding a longish delay after sending ESC from the keyboard "Esc" key
>>for compatibility with broken curses implementations.
>
>typically tens of ms, on the ESC character, so that e.g.
>
> ESC [ M
>
>(sent without any large gaps) is interpreted as such (I made up that
>ESCape sequence, BTW) whereas someone typing
>
> ESC
>
>(done with a finger, so obviously followed by a long gap) is taken as
>a single character which is to be passed on to the application.
>
>to the application, e.g. to exit from menus etc.
Again, clearly spoken by someone who has never used a real VT100.
A real VT100 exhibits no timeout on the escape character or sequences.
Anyone who says otherwise is itching for a fight.
Tim.
Jeff Kenton
sho...@alph02.triumf.ca (Tim Shoppa) writes:
>Again, clearly spoken by someone who has never used a real VT100.
>A real VT100 exhibits no timeout on the escape character or sequences.
Agreed. You can type the standard escape sequences by hand if you like,
as fast or as slowly as you choose.
--
-------------------------------------------------------------------------
= Jeff Kenton (617) 894-4508 =
= jke...@world.std.com =
-------------------------------------------------------------------------
Jeffrey Altman
In article <5igi6p$f2g$1...@nntp.ucs.ubc.ca>,
Tim Shoppa <sho...@alph02.triumf.ca> wrote:
: Come on guys, there are enough crappy terminal emulators out there
: already. Please don't go pontificating about how you think a
: VT-100 *ought* to work - just find a real one and figure out how
: it *actually does* work.
:
: I've spoken with several companies selling PC-clone DOS/Windows terminal
: emulators where it's clear that nobody at the company has even
: bothered to compare the behavior that a real VT100 has. MS-DOS
: Kermit is one of the very few that does emulation right.
:
: Tim.
Tim:
On behalf of Joe Doupnik, Frank da Cruz, and myself, thanks for the
compliment. We at the Kermit Project try extremely hard to get this
stuff right, not just by collecting and reading physical manuals
for the terminals we emulate but also by comparing the output of
our software against the real thing.
There does seem to be some confusion in this thread caused by the
differences in escape sequence handling in ANSI X3.64 based terminals
such as the VT 100 and above as compared to the ASCII terminals
including WYSE, Televideo, DataGeneral, HP, etc.
ANSI X3.64 defines an escape sequence using a method very similar to
those used in implementing packets over networks or other
communication mediums. All sequences begin with ESC or CSI and end
with a limited number of INTERMEDIATE and FINAL characters.
Therefore, sequences may be of arbitrary length and state machines
may be easily constructed without the need for timeouts, even if the
terminal doesn't support the command which is being sent.
ASCII terminals use a C0 character to begin the sequence (ESC or RS
are popular) followed by an ASCII character sequence. However,
there is no way to know when the sequence terminates unless the
terminal implements the command.
Timeouts for processing ESC sequences are an application hack that
was implemented to get around the use of the ESC character as a
valid command by itself before these same applications attempted
to handle terminal based cursor movement commands. The general
solution for applications to avoid this application based escape
timeout problems is to never send an incomplete ESC sequence over
a network especially one that implements the Nagle algorithm for
traffic reduction.
Jeffrey Altman * Sr.Software Designer * Kermit-95 for Win32 and OS/2
The Kermit Project * Columbia University
612 West 115th St #716 * New York, NY * 10025 * (212) 854-1344
http://www.columbia.edu/kermit/k95.html * kermit-...@columbia.edu
Tim Shoppa
In article <5igl61$s88$1...@apakabar.cc.columbia.edu>,
Jeffrey Altman <jal...@watsun.cc.columbia.edu> wrote:
>In article <5igi6p$f2g$1...@nntp.ucs.ubc.ca>,
>Tim Shoppa <sho...@alph02.triumf.ca> wrote:
>: Come on guys, there are enough crappy terminal emulators out there
>: already. Please don't go pontificating about how you think a
>: VT-100 *ought* to work - just find a real one and figure out how
>: it *actually does* work.
>:
>: I've spoken with several companies selling PC-clone DOS/Windows terminal
>: emulators where it's clear that nobody at the company has even
>: bothered to compare the behavior that a real VT100 has. MS-DOS
>: Kermit is one of the very few that does emulation right.
>
>compliment.
You guys deserve every compliment there is!
>We at the Kermit Project try extremely hard to get this
>stuff right, not just by collecting and reading physical manuals
>for the terminals we emulate but also by comparing the output of
>our software against the real thing.
Unfortunately, in the crappy-emulator world a vicious cycle has
already begun. People write emulators that emulate what they think
a VT100 *should* do, not what a VT100 really does. Then application
writers assume that because features are present in some of these
emulators, that these features are available on the real terminal.
The worst offender I've found is a commercial editor that requires
VT100 users to hit F5 through F10 to access certain abilities
that are rather necessary - such as exiting the editor. Despite
repeated phone calls to the company, I've yet to convince them that
a VT100 doesn't have F5 through F10 function keys. They claim that
because some popular Windows-based emulators implement these function
keys in VT100 mode, a real VT100 must as well. Arrggghhh!!!! I'm
tempted to deliver a half-dozen true VT100's to their corporate
offices via catapult.
Tim. (sho...@triumf.ca)
Don Yuniskis
Tim Shoppa <sho...@alph02.triumf.ca> wrote:
>In article <5ie3v9$k...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
>>>Timeouts on the ESC characters? I hope you're referring to possibly
>>>adding a longish delay after sending ESC from the keyboard "Esc" key
>>>for compatibility with broken curses implementations.
>>
>>the *next* character) in a multicharacter escape sequence within a one second
>>window to be recognized as an ESCape sequence as opposed to the ESCape
>>key itself.
>
>Huh? This is a rather bizarre behavior, and one I've never
>found with any real terminal.
Sorry, I was talking from the viewpoint of the *other* end of the wire
(i.e. having written code that had to distinguish ESC from KEY_LEFT)
This is, in fact, how curses differentiates between ESC and KEY_LEFT, etc.
When *emulating* a (true) VT-100 keyboard, there are many applications
that (unfortunately) *expect* there to be no delay between the characters
in a multibyte escape sequence. A VT-100 does not introduce a delay
so faithfully reproducing a function key, arrow key, etc. requires
a true terminal emulator to do likewise. Doing this on a PC in damn
near *any* kind of terminal emulator is not possible (to *guarantee*)
even if you code things in assembler. Unless you are prepared to
disable interrupts, etc. since the disk cache, scheduler, etc. could
easily preempt you and introduce a delay...
I've often thought of coding such an application just to be able
to NOT have to lug VT-100's around. But, doing so in a truly portable
way is more work than it's worth -- considering the fact that you couldn't
even trust the BIOS since it can't be fully characterized, etc.
Easier to build something that does what you want. And, if faced with
*that* alternative, it's easier to just throw a VT-100 in your trunk!
:>
>>>Otherwise, this would be a bad thing to do. VT-series terminals
>>>operate by running a single state machine over the input, not by doing
>>>a read-character/call-function type of implementation. If you can't
>>
>>Yes, but will (for example) a VT-100 wait "forever" after receiving
>>an ESC for the balance of the escape sequence?
>
>Yes, it will.
>
>Come on guys, there are enough crappy terminal emulators out there
>already. Please don't go pontificating about how you think a
>VT-100 *ought* to work - just find a real one and figure out how
>it *actually does* work.
I have two of them sitting beside me and just need to scrounge up
a null modem cable, thankyouverymuch! I distrust damn near *all*
terminal emulators...
--don
Frank da Cruz
In article <5iemgp$p...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
: In article <5iejer$133$1...@apakabar.cc.columbia.edu>,: >In article <5ie1da$k...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
:
: [stats of kermit slower than zmodem on transfer of gzip'ed file snipped]
:
: >But, since ZMODEM works on this connection, then Kermit with "full
: >unprefixing" will also work. I should point out that the current version
: >of C-Kermit is 6.0.192 and you can pick it up at:
: >
: > http://www.columbia.edu/kermit/ck60.html
:
: (groan) Sorry, I don't have the time to do another port :-/ It's
: more than a full-time job just keeping all the *other* software
: packages running, configured, etc. :-(
But you don't have to -- it's most likely already done for you. I keep
referring to this Web page because it lists (among other things) several
HUNDRED prebuilt UNIX binaries, and quite a few of them already in "install
package" form (Linux, AIX, etc).
: Can I do something like PREFIXING OFF (sorry, I'm not on a UN*X box
: currently so can't recall the exact kermit commands) with the
: 190 version? I'll have to dig up my .kermrc and see what it
: spells out currently...
:
There is a coarse control available in version 6.0 only:
SET PREFIXING { ALL, CAUTIOUS, MINIMAL, NONE }
by which Kermit picks out selected control characters to prefix/unprefix,
and there is a fine-grained control available in 5A(189) and later:
SET CONTROL { PREFIX, UNPREFIX } { ALL, <list> }
By which you can can control the prefixing of each control character.
And then there is is the FAST command (6.0 only), which does an implicit SET
PREFIXING CAUTIOUS along with selecting a big packet and window size -- in
other words tuning Kermit for fast transfers in one simple command.
: And, for what scenarios does kermit have to be more conservative than ZModem?
:
Going through a terminal server or to a host that has limited buffer space
and/or inadequate flow control. Using a modem connection that is not error
corrected. Using a lossy network connection on the New Internet. Using a
long-distance connection that has long delays. Using a noisy (non-error-
corrected) connection. Using a connection that is not transparent to every
single control character (52 of them) -- and that includes just about every
terminal server. Transferring files over a Telnet connection when the server
does not know it's a Telnet connection (and so does not prefix 0xFF). Using a
half-duplex connection (there are such things). And on and on and on.
: (sorry, poorly phrased). In other words, why are you qualifying your
: statements with "since ZMODEM works there"? In which of these (dialup)
: conditions would ZMODEM *not* work yet kermit provide me a workaround?
:
See above. The most typical example is this: You are logged in to the host
through a terminal server, whose escape character is (say) Ctrl-^ (ASCII 30)
(or any other control character). Another less obvious example, but it
happens: you are dialed up using a Hayes-like modem that does not implement
guard time around its escape sequence (because the manufacturer did not want
to pay the license fee). If you file contains +++, the modem pops back to
command mode.
Only a very small subset of all the connections people make are totally
transparent.
- Frank
Frank da Cruz
This is becoming kind of a silly discussion. Obviously a VT terminal
emulator should send CSI blah sequences (such as generated by VT100 arrow,
PF, keypad keys) in one shot, e.g. in a single write() operation (in C
terms). As Don points out, there is no guarantee that a write() (or whatever
we are using) won't be interrupted by the OS. But that's not the half of it.
If I plug a real VT100 into my modem, dial a terminal server, and then
log in to UNIX and run "vi", I'm just as likely to have the "atomic" arrow-key
sequences busted up before they reach vi as I would be if I were using a
terminal emulator that didn't even make the effort to group these characters
together in the first place.
Of course in Kermit software, we do the grouping. But that doesn't guarantee
that the thus-grouped sequence won't be de-grouped before it reaches its
destination, e.g. by the TCP or IP layer on a network or terminal server
connection. Even if it isn't, vi itself might be swapped out after it reads
the ESC but before it reads the [ (or whatever). Even on a hardwired direct
serial connection. Even with a real VT100.
- Frank
Don Yuniskis
In article <5igibq$f4b$1...@nntp.ucs.ubc.ca>,
Tim Shoppa <sho...@alph02.triumf.ca> wrote:
>In article <334c8cb1....@news.netcomuk.co.uk>,
>Peter <z...@dserve.com> wrote:
>>
>>>Timeouts on the ESC characters? I hope you're referring to possibly
>>>adding a longish delay after sending ESC from the keyboard "Esc" key
>>>for compatibility with broken curses implementations.
>>
>>typically tens of ms, on the ESC character, so that e.g.
>>
>> ESC [ M
>>
>>(sent without any large gaps) is interpreted as such (I made up that
>>ESCape sequence, BTW) whereas someone typing
>>
>> ESC
>>
>>(done with a finger, so obviously followed by a long gap) is taken as
>>a single character which is to be passed on to the application.
>>
>>Not having a timeout means that ESCape characters could never be sent
>>to the application, e.g. to exit from menus etc.
>
>A real VT100 exhibits no timeout on the escape character or sequences.
Funny, I was about to say you've obviously never *written* anything
that is intended to behave like a (true) VT-100. There are two sides
to this issue and you persist in looking at only one side.
Peter's statement says "that ESCape characters could never be sent to the
application". He doesn't make any claim about how a VT-100 times out
on escape sequences...
*If* you are writing a piece of code that has to pretend to be a VT-100,
it must not only *decode* escape sequences sent to it in the manner in
which a VT-100 would, but it must also GENERATE multiple character
sequences in the *SAME* manner that a true VT-100 would! There
are many products in the market place that pretend to be VT-100's
AND DON"T HAVE CRT'S IN THEM!!! Yet they are VT-100 terminal emulators!
In particular, they may, for example, have a modem in them, go off hook
at a particular time, dial a number, wait for a connection and then talk
to a piece of LEGACY software/hardware that was written to talk to
*true* VT-100's via hardwired RS-232C lines. You *can't* change any
of the hardware or software on that end of the line. Why? Because
it's either no longer available (company is out of business, etc.),
too expensive to maintain, already "qualified" (i.e. regulatory
agency apporvals which would be a nightmare to have to recertify
just to change the terminal interface), etc. And, buying surplus
VT-100's and gutting the keyboards to tie in to your "black box"
is an unrealistic (i.e. silly!) option.
So, you want your terminal emulator to *really* match the characteristics
of a VT-100 even though there's no human operator involved. Your
product will examine the data stream sent to it -- similar to looking
for a "Login: " in a UUCP script -- and then issue a canned sequence
of keystrokes in *exactly* the same manner as a VT-100 with a human
operator that was knowledgeable of the syntax expected by the application.
So, if the application expects all of the characters in a multibyte
character sequence to be adjacent in time (without intervening
pauses), you must reproduce them in that manner. Since it is possible
for an application to be written to talk to a VT-100 and *use*
the ESC key as an independant key (perhaps the application disallows
all of the function/arrow keys, etc.!), then you must be able to reproduce
this, too. If an application uses *both* ESC and, e.g. KEY_LEFT,
then you must ensure that you generate these key sequences in the same
manner that a VT-100 would WITH A KNOWLEDGEABLE HUMAN OPERATOR
(i.e. a human operator would deliberately pause after ESC if the next
keys were known to be easily confused with a function key sequence,
etc. Why would they know? Because, over the years of use of that
legacy system, folks have been bitching about how the shitty
application gets confused if you type ESC [ A to do something
and it instead interprets it as ESC [ A -- you'd be amazed at how many
crappy applications are out there!). One way of doing this is to invent
a "pause" key code for your keystroke sequencer. So, you would
code this as ESC PAUSE [ A. Another way is to bury the PAUSE in the
ESC *implicitly* so ESC generates ESC PAUSE while KEY_LEFT generates
ESC [ A (IIRC). The advantage of this latter approach is that it
mimics the algorithm used by the application to differentiate
ESC from any keystroke sequences which contain ESC. So, you are
less likely to have errors in your implementation if you had to
remember to explicitly insert a PAUSE everywhere you generated an ESC.
--don
Jeffrey Altman
In article <5igr8o$d...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
<everything said deleted>
before anybody else continues this thread, lets all take our
VT100 off the shelf and performing the following:
place the terminal in local echo mode
press the ESC key
go to for a meal
press [
press C
or any other valid cursor movement sequence (they are easy to see the effect)
and then lets report whether or not VT terminals use timeouts.
Since I have already performed this test, the answer is they don't.
And since the terminal doesn't care how long it takes a user the type
the escape sequence as long as it is valid, neither should an application.
Don Yuniskis
In article <5igl61$s88$1...@apakabar.cc.columbia.edu>,
Jeffrey Altman <jal...@watsun.cc.columbia.edu> wrote:
>
>was implemented to get around the use of the ESC character as a
>valid command by itself before these same applications attempted
>to handle terminal based cursor movement commands. The general
Yes!
>solution for applications to avoid this application based escape
>timeout problems is to never send an incomplete ESC sequence over
>a network especially one that implements the Nagle algorithm for
>traffic reduction.
Hmmm, I have yet to see a VT-100 with a 10Base* connection! :>
(we *were* talking about VT-100's, weren't we?)
--don
Don Yuniskis
In article <5ih99b$cg2$1...@apakabar.cc.columbia.edu>,
Agreed!
>Obviously a VT terminal
>emulator should send CSI blah sequences (such as generated by VT100 arrow,
>PF, keypad keys) in one shot, e.g. in a single write() operation (in C
>terms).
Well, I'm not even sure that a VT-100 satisfies that criteria! For
example, my suggestion of what might happen if the VT-100 detected
a flow control/pacing request in the middle of the sequence (i.e. after
the ESC but before subsequent characters). The whole aspect of "time"
in multicharacter sequences is a royal PITA (been there, done that...)
>As Don points out, there is no guarantee that a write() (or whatever
>we are using) won't be interrupted by the OS. But that's not the half of it.
>
>If I plug a real VT100 into my modem, dial a terminal server, and then
>log in to UNIX and run "vi", I'm just as likely to have the "atomic" arrow-key
>sequences busted up before they reach vi as I would be if I were using a
>terminal emulator that didn't even make the effort to group these characters
>together in the first place.
>
>Of course in Kermit software, we do the grouping. But that doesn't guarantee
>that the thus-grouped sequence won't be de-grouped before it reaches its
>destination, e.g. by the TCP or IP layer on a network or terminal server
>connection. Even if it isn't, vi itself might be swapped out after it reads
>the ESC but before it reads the [ (or whatever). Even on a hardwired direct
>serial connection. Even with a real VT100.
Yes, but you're still thinking about "mainframes", desktops, etc.
Remember, embedded products outnumber desktop/PC/mainframes by an order
of magnitude! (think about it...) In 20 years, I can count the number
of "desktop"/"mainframe"/etc. applications I've written on one hand.
*But*, I'd need more than all my extremities to count the number of
embedded applications I've worked on. And, *most* of them have had
UARTs in them running proprietary/handcrafted MTOS's. (Heck, even
the remote control I use for my television, VCR, CD player, etc.
has a UART in it!). When you are talking to a piece of
*equipment* (i.e. a "thing" vs. a "PC", "mainframe", etc.), it's
almost 100% certain that the "thing" doesn't have a VM system
that swaps pages out to disk, etc. (this article *was* posted to
comp.arch.embedded, after all! And the original post specifically
asked about a terminal emulator for use by designers/developers
of embedded products...). Often, they have RTOS's -- at the very
least, low latency MTOS's (none of these long latencies you'd
encounter in some sluggish kernel like a UN*X box). For example,
I have one scheduler that ensures a 15 uS context switch on
a 6MHz Z80 :-/ (scaling that to a 200MHz pentium would yield a
figure of < 500 nS -- if you *could* scale things that naively :>)
So, those things are explicitly designed to guarantee specific
response times, etc. Real time == determinism (by definition).
For example, a UN*X box can drop TCP/IP packets by the thousands
and still run fine (though with admittedly bad network performance).
But, many of these embedded products can't drop a single character
received by a UART because there is usually not a human being sitting
there to "try again" -- nor is there often a protocol which allows
a NAK to be returned, etc. (the point of this being that you
spend a LOT of time looking at silly little details because they
can often cause your product to fail miserably).
For example, I recently inherited a product that had a sloppy
communication protocol designed in. I had very little control over
the protocol since one end had already been nailed down and
cast in silicon. The product would sometimes sit in an endless
loop reissuing the same request to it's counterpart in the
transaction -- and then, (due to it's inability to break an
unlucky error cycle begun at the start of the transaction) it
would garble the result code, determine it to be in error
and restart the process again (kinda like missing a start bit
on an asynchronous character sent 8N1 in a continuous bit
stream... the UART will never resynchronize itself until
the stream is interrupted).
So, I guess my point is to not restrict your assumptions/analysis
to "traditional" computing environments -- since they constitute
a very small number of applications (relatively speaking). If
you assume a terminal (emulator) is only applied in those settings
then you're likely to find *embedded* applications in which it
fails profoundly!
--don
Don Yuniskis
In article <5ih3ur$931$1...@apakabar.cc.columbia.edu>,
Jeffrey Altman <jal...@watsun.cc.columbia.edu> wrote:
>In article <5igr8o$d...@baygull.rtd.com>, Don Yuniskis <d...@rtd.com> wrote:
><everything said deleted>
>
>before anybody else continues this thread, lets all take our
>VT100 off the shelf and performing the following:
I thought we already established this?
>or any other valid cursor movement sequence (they are easy to see the effect)
>and then lets report whether or not VT terminals use timeouts.
>
>Since I have already performed this test, the answer is they don't.
>And since the terminal doesn't care how long it takes a user the type
>the escape sequence as long as it is valid, neither should an application.
I don't see "applications" running *in* the VT-100. Reread your statement:
just because the VT-100 will wait forever for an escape sequence, doesn't
mean an *application* -- which is NOT a VT-100 -- should wait forever
for a multicharacter key sequence! (note the difference between sequences
*interpreted* by the VT-100 vs. keys *generated* by the VT-100 -- data
flows two ways!)
An "application" (running in a mainframe, PC, embedded product or
a pay telephone!) can chose to deal with characters *from* a VT-100
in whatever way it damn well pleases! *If* an application wants
to differentiate between ESC and KEY_LEFT, it can make whatever
it considers as a "valid attempt" to do so. There's very little
the VT-100 can do to change it's mind!
The fact is, there are *lots* of existing systems that *do* exactly
this. Just because it's "bad practice" doesn't make it go away!
Since you can't typically change those systems (ask a hospital
to replace it's billing system because your new blood analysis
equipment doesn't think it's "good practice" to have to send
ESC to the data entry program that logs charges for each patient...
they'll quickly find another vendor who's equipment is quite
comfortable sending ESC, KEY_LEFT, etc.) you have to ensure that
you mimic a real VT-100. Thankfully, you *can* fully characterize
how a VT-100 will behave in all possible circumstances -- it's
small enough and a closed system. Spend a week or two with an
ICE and you'll know how the firmware works in gory detail!
Unlike terminal emulators, VT-100's don't have to worry about some
spurious interrupt from a mouse, disk drive, NIC, etc. coming in and
stealing the CPU when it wants to send out the next character
in (for example) KEY_LEFT. So, the equipment which is listening
to that VT-100 (or, embedded product which mimics a VT-100) can
very well expect the ESC to be immediately followed by the balance
of the character sequence. It may not be a robust design, but
it works, is in place and try to convince a hospital (e.g.)
administrator that he should spend his scarce dollars replacing
this design with something more elegant. And, while you're at it,
you could try to convince him to abandon DOS because of it's
640K memory limit. Or, the X86 family of processors because of
their silly 64K segments. As with each of these, if you want
to sell to that market, you adapt to their needs.
--don
car...@xylogics.com
In article <5ihd1q$h...@baygull.rtd.com> d...@rtd.com (Don Yuniskis) writes:
> >solution for applications to avoid this application based escape
> >timeout problems is to never send an incomplete ESC sequence over
> >a network especially one that implements the Nagle algorithm for
> >traffic reduction.
>
> Hmmm, I have yet to see a VT-100 with a 10Base* connection! :>
> (we *were* talking about VT-100's, weren't we?)
Actually, I happen to use a lot of these. They're just VT-100s
attached to terminal servers.
As for the silly debate over deliberately delaying after sending ESC
from the Escape key, I've never seen that be a problem with an
application. What is *consistently* a problem is the reverse --
getting all the characters to go out to the application in a single
shot, with no delays that confuse moderately broken applications.
We terminal server manufacturers have *attempted* to make this work
right. (In fact, my previous job was with Data General writing the
firmware for the Dasher line of terminals. I'm intimately aware of
the fun things involved.) Unfortunately, we can't always do this.
One of the major faults we run into is with modern modems, which are
also buffering data and sending it in blocks. It's not at all
uncommon for a modem's V.42 implementation to have an interactive-
traffic hack which attempts to forward a single character on an idle
like but then buffers subsequent characters (a la TCP's Nagle
algorithm). Thus, the timing is often broken before we even see the
data.
There are two solutions:
1. Don't use ESC in your application. This isn't much of a
solution, since users are already trained to do otherwise.
2. Use a VT-200 (or higher) series emulation and set it to
send 8-bit C1 controls. This is a much better solution.
If your application isn't hopelessly broken, it should
already be (optionally, of course) internally converting
"ESC chr" to (chr+0x40) for 7-bit C1 controls, and this
should work seamlessly with no time-outs on ESC.
Don Yuniskis
In article <odybar8...@donald.xylogics.com>, <car...@xylogics.com> wrote:
>In article <5ihd1q$h...@baygull.rtd.com> d...@rtd.com (Don Yuniskis) writes:
>> >solution for applications to avoid this application based escape
>> >timeout problems is to never send an incomplete ESC sequence over
>> >a network especially one that implements the Nagle algorithm for
>> >traffic reduction.
>>
>> Hmmm, I have yet to see a VT-100 with a 10Base* connection! :>
>> (we *were* talking about VT-100's, weren't we?)
>
>Actually, I happen to use a lot of these. They're just VT-100s
>attached to terminal servers.
No, that's a VT-100 attached to a terminal server! There are a helluva
lot of serial ports out there that *aren't* attached to terminal servers,
PC's, mainframes, etc.
>As for the silly debate over deliberately delaying after sending ESC
>from the Escape key, I've never seen that be a problem with an
>application. What is *consistently* a problem is the reverse --
>getting all the characters to go out to the application in a single
>shot, with no delays that confuse moderately broken applications.
How many embedded applications have you dealt with? (re: comp.arch.embedded)
In how many different industries? Stop thinking that the world is
laptops, desktops and/or mainframes. You'd be *amazed* at how many
processors are sitting in your house DISCOUNTING the *single* x86 in your
PC! Granted, few of *those* need terminal emulations. But there are
a LOT of applications out there where the RFQ says:
Here's an existing system. It cost us $shitlo.ad and
it's here to stay. Successful bidder will interface
to said system and provide the following new services
in a standalone device intended to...
The option of "Gee, Mr. Potential Customer, I can really give you a
low-cost solution if we just rewrite your application to do things
'right'" will almost *surely* get you disqualified from the bidding.
>We terminal server manufacturers have *attempted* to make this work
>right. (In fact, my previous job was with Data General writing the
>firmware for the Dasher line of terminals. I'm intimately aware of
>the fun things involved.) Unfortunately, we can't always do this.
But this assumes there is a terminal server involved at all!
>One of the major faults we run into is with modern modems, which are
>also buffering data and sending it in blocks. It's not at all
>uncommon for a modem's V.42 implementation to have an interactive-
>traffic hack which attempts to forward a single character on an idle
>like but then buffers subsequent characters (a la TCP's Nagle
>algorithm). Thus, the timing is often broken before we even see the
>data.
Or, what if the modem needs to retrain "coincidentally" between
two inopportune characters? :>
Yes. If you put *anything* in the middle (terminal server, modem,
etc.) that can implicitly/explicitly modify the "model" that you
are expecting to see (i.e. "a VT-100"), then all bets are off.
A good deal of effort is expended making bogus bridge adapters
for these specific embedded products just so they can "move into
the 90's" (there's a LOT of 1970's technology still widely used
in many industries -- especially industries that are scrutinized
by folks like FDA...)
>There are two solutions:
>
> 1. Don't use ESC in your application. This isn't much of a
> solution, since users are already trained to do otherwise.
Alternatively, don't use "magic keys"! Perhaps this is even
*harder* to avoid since I suspect they are more widely "understood"
by casual users than a bare ESC might be.
> 2. Use a VT-200 (or higher) series emulation and set it to
> send 8-bit C1 controls. This is a much better solution.
> If your application isn't hopelessly broken, it should
> already be (optionally, of course) internally converting
> "ESC chr" to (chr+0x40) for 7-bit C1 controls, and this
> should work seamlessly with no time-outs on ESC.
Grrrr... you're still thinking desktop/mainframe. Most embedded
products just have 98% of what they *need* (:>) to get the job
done. If the protocol says "ESC [ A" does "this", then they
expect *three* characters and they expect them to be: "ESC [ A".
They *might* allow the UART to be configurable; they might
hardwire it at a particular baudrate and character format, etc.
The UART may be a single general purpose output bit and a tight
loop of code that shifts bits onto that bit for one bit time, etc.
I've designed products where the duration of a BREAK carried
information! (Yes, it's an incredible hack but you typically are
working with a very skimpy set of resources, and very tight
design criteria, etc.)
If we want to drop comp.arch.embedded from the cross-posts and just
talk about desktop/mainframe applications, that's fine. You'll
get no argument out of me: using time to distinguish keystrokes
(i.e. using time in a protocol) is a royal PITA. In desktop
applications, it's amazing that it hasn't "gone away" yet (since
desktop apps tend to be more fluid and "current"). It's a little
harder to convince a manufacturer to recall several (tens of) thousands
of a particular device so you can swap ROMs to "fix" a feature
that "sounded good at the time" but is now a hassle to live with.
Imagine retrofitting all Dasher's to change N-key rollover to
single key rollover, etc.
--don
Roger Ivie
In article <5igpt7$d...@baygull.rtd.com>, d...@rtd.com (Don Yuniskis) writes:
> A VT-100 does not introduce a delay
> so faithfully reproducing a function key, arrow key, etc. requires
> a true terminal emulator to do likewise. Doing this on a PC in damn
> near *any* kind of terminal emulator is not possible (to *guarantee*)
> even if you code things in assembler.
Are you saying your whiz-bang multihundred MHz Pentium can't keep up
with the 2MHz 8080 in a VT100? And I thought _I_ had a rosy picture of
life in the CP/M era...
--
-------------------------+-----------------------------------------------
Roger Ivie | "Inside every PC-DOS system is a powerful,
iv...@cc.usu.edu | flexible MS-DOS system just waiting to be
http://cc.usu.edu/~ivie/ | set free" -- Mike Higgins
| Computer Language magazine, 3/85
car...@xylogics.com
In article <5ij3g0$1...@baygull.rtd.com> d...@rtd.com (Don Yuniskis) writes:
> How many embedded applications have you dealt with? (re: comp.arch.embedded)
Oh, only several dozen.
Are ad hominem attacks a reasonable way to discuss these problems?
> >right. (In fact, my previous job was with Data General writing the
> >firmware for the Dasher line of terminals. I'm intimately aware of
> >the fun things involved.) Unfortunately, we can't always do this.
>
> But this assumes there is a terminal server involved at all!
Duh. I was responding to a previous posting which mentioned that even
if you do modify your code to attempt to get all the characters in a
7-bit C1 sequence to go out as a contiguous block, there are often
still devices in the communications path which can break lame attempts
at (mis-)using timing information.
> > 2. Use a VT-200 (or higher) series emulation and set it to
> > send 8-bit C1 controls. This is a much better solution.
> > If your application isn't hopelessly broken, it should
> > already be (optionally, of course) internally converting
> > "ESC chr" to (chr+0x40) for 7-bit C1 controls, and this
> > should work seamlessly with no time-outs on ESC.
>
> Grrrr... you're still thinking desktop/mainframe. Most embedded
No, I'm not. The point is that if you're a developer working on such
applications, you should at least be trying to move away from a broken
model -- one that has been well-understood to be broken since the
70's. Perhaps someday there will only be a few systems which are
broken in that way. That won't happen if you persist in doing things
the same way.
Dave Baldwin
car...@xylogics.com wrote:
: No, I'm not. The point is that if you're a developer working on such
: applications, you should at least be trying to move away from a broken
: model -- one that has been well-understood to be broken since the
: 70's. Perhaps someday there will only be a few systems which are
: broken in that way. That won't happen if you persist in doing things
: the same way.
There are a lot of applications that have never encountered an ANSI escape
sequence or a VT-100, where the ESC key was never used to send anything
from the terminal or console, where the only time it was sent was to
indicate a break or exit from the current routine. Until I got an
internet connection five years ago, I had never used a VT-anything
terminal or emulation. All PC or Lear-Siegler or Televideo. On PC's in
particular, even with ANSI.SYS loaded, the cursor keys do not send escape
sequences. It's not that the model is broken, it's that there is more
than one model and other models will persist.
--
-=-=-=-=-=-=-=-=-=-=-=- Check out DIBs and TCJ -=-=-=-=-=-=-=-=-=-=-=-=-
Dave Baldwin: dib...@netcom.com | The Computer Journal 1(800)424-8825
DIBs Electronic Design | Home page "http://www.psyber.com/~tcj/"
Voice : (916) 722-3877 | Hands-on hardware and software
TCJ/DIBs BBS: (916) 722-5799 | TCJ/DIBs FAX: (916) 722-7480
-=-=-=-=-=-=- @#$%^&* I can't even quote myself! Oh,well. -=-=-=-=-=-=-
car...@xylogics.com
In article <dibaldE8...@netcom.com> dib...@netcom.com (Dave Baldwin) writes:
> : No, I'm not. The point is that if you're a developer working on such
> : applications, you should at least be trying to move away from a broken
> : model -- one that has been well-understood to be broken since the
> : 70's. Perhaps someday there will only be a few systems which are
> : broken in that way. That won't happen if you persist in doing things
> : the same way.
>
> There are a lot of applications that have never encountered an ANSI escape
> sequence or a VT-100, where the ESC key was never used to send anything
> from the terminal or console, where the only time it was sent was to
> indicate a break or exit from the current routine. Until I got an
> internet connection five years ago, I had never used a VT-anything
> terminal or emulation. All PC or Lear-Siegler or Televideo. On PC's in
On some of those older terminals, the ambiguity does *not* exist,
because the cursor and function keys don't send sequences which begin
with ESC. On others, it has been an endemic problem.
I was addressing the ESC timing problem with respect to VT-100 and
other ANSI-type terminals. Other terminals have other issues. (I
*could* tell you a tale about requiring special 1 or 2 character
hold-offs in XON/XOFF processing due to the 036 and 037 sequences, but
I don't want to hear the sound of the net community simultaneously
retching.)
> particular, even with ANSI.SYS loaded, the cursor keys do not send escape
> sequences.
Really? As I understand that system, ANSI.SYS is just a screen
driver. It does nothing at all with what the keyboard sends. If it
is true that PC based systems don't send ESC sequences for function
keys, then there can be no ambiguity with the ESC key.
> It's not that the model is broken, it's that there is more
> than one model and other models will persist.
If you're using something that claims to be an ANSI-based application,
then it certainly should understand both 7 and 8 bit C1 sequences.
That's the point. ANSI defined these things from the very beginning.
That some authors are ignorant of those definitions has been a nagging
problem.
Terminals, like, say, the VT-52 or H-19, which both use ESC as a
single key and as a prefix for function keys are simply broken. You
have the choice either to not use ESC in your application or to
implement ugly and unreliable hacks like time-outs.
The point is that there are other ways of using ANSI terminals which
avoid these problems entirely.
Shawn Barnhart
[Newsgroups line trimmed to comp.terminals]
It's been interesting reading the debate about what is/what isn't proper
VT100 eumlation. I've got a quesiton, tho..
Has anyone ever actually disassembled the ROMs from a VT100? While I'm sure
DEC wouldn't be pleased, it would be an excellent way to figure out just
what a VT100 really does/doesn't do properly. Be even more fun to actually
try to reuse the code in an emulator, although that would most certainly be
naughty.
--
Shawn Barnhart s...@mercury.campbell-mithun.com
Jerry Leichter
| Has anyone ever actually disassembled the ROMs from a VT100? While
| I'm sure DEC wouldn't be pleased, it would be an excellent way to
| figure out just what a VT100 really does/doesn't do properly.
Man, would *that* ever be the hard way to learn anything! The code had
to be very tight - memory was *expensive* in those days. Everything is
really packed together. Do you really think you stand a better chance
of finding what doesn't work properly - i.e., bugs - from a disassembly
than the designers did from commented source?
If you *really* want to go through this kind of exercise, by the way,
start with the VT102, not the VT100. DEC long ago defined "VT100
compatibility" in terms of the VT102, not the VT100. Also, the VT102
had a number of bugs fixed. I knew of some odd ones in the VT100 - the
details escape me - it's been years - but as I recall, if you use the
escape sequence that manipulates the keyboard lights, it doesn't check
that the light number is legal, and values larger than 4 will write to
memory that contains other stuff. You could do things like cause the
alarm bell to ring continuously, or make the keys auto-repeat
immediately at a very high rate. All the known bugs were fixed in the
VT102; I don't recall any being reported later.
BTW, I'll let you in on an interesting secret: DEC had a VT100
standard. (DEC was big on standards and architectures. There was
actually a standard that specified how architecture standards were to be
written!) In fact, a friend of mine wrote the thing. It looked very
much like the VT100 documentation, but much longer, more detailed, and
precise. To make sure it was *really* precise, he described all the
algorithms in fragments of Pascal. It was possible to extract all the
Pascal fragments, add a main routine, and run the thing, producing a
VT100 emulator. (The performance was terrible, but that wasn't the
point.)
| Be even
| more fun to actually try to reuse the code in an emulator, although
| that would most certainly be naughty.
Yup. I don't even know *who* would go after you: DEC sold its
terminals business a couple of years back. I have no idea whether
rights to the VT100 went with the sale.
-- Jerry
Don Yuniskis
<car...@xylogics.com> wrote:
>d...@rtd.com (Don Yuniskis) writes:
>> How many embedded applications have you dealt with? (re: comp.arch.embedded)
>Are ad hominem attacks a reasonable way to discuss these problems?
Not at all, it was merely intended to draw the discussion back to
comp.arch.embedded
>> >right. (In fact, my previous job was with Data General writing the
>> >firmware for the Dasher line of terminals. I'm intimately aware of
>> >the fun things involved.) Unfortunately, we can't always do this.
>>
>> But this assumes there is a terminal server involved at all!
>
>Duh. I was responding to a previous posting which mentioned that even
>if you do modify your code to attempt to get all the characters in a
>7-bit C1 sequence to go out as a contiguous block, there are often
>still devices in the communications path which can break lame attempts
>at (mis-)using timing information.
But, *my* point is that many embedded devices talk DIRECTLY to those
devices. In fact, some of them exist *solely* as bridges to make a
"broken device" *look* like a "new device" (i.e. "protocol converters")
In other instances, the two devices (the "broken device" and the
device which must interface to it) sit in the same environment
often hardwired together) in some cases, *bolted* together.
>> > 2. Use a VT-200 (or higher) series emulation and set it to
>> > send 8-bit C1 controls. This is a much better solution.
>> > If your application isn't hopelessly broken, it should
>> > already be (optionally, of course) internally converting
>> > "ESC chr" to (chr+0x40) for 7-bit C1 controls, and this
>> > should work seamlessly with no time-outs on ESC.
>>
>> Grrrr... you're still thinking desktop/mainframe. Most embedded
>
>No, I'm not. The point is that if you're a developer working on such
>applications, you should at least be trying to move away from a broken
>model -- one that has been well-understood to be broken since the
>70's. Perhaps someday there will only be a few systems which are
>broken in that way. That won't happen if you persist in doing things
>the same way.
Who's "doing things the same way"? I've got a hardwired connection to
a device that I'm "stuck with". By your definition, it's "broken".
They (whoever owns/maintains it) won't fix it and I sure as hell
can't change how *it* works. Do I just throw up my hands and say
"it can't be done" when asked to design a box that has to talk
to that other system? Especially when it *can* be done? How am
*I* contributing to the proliferation of these broken systems?
*MY* system isn't broken.
If you reread my posts on this subject, you'll see that I *don't*
advocate using "time" in any protocol (except "special" ones)...
--don