Moving Intelligence into the Terminal
utcsstat!wagner
smart terminal rather than just emulating a dumb one?
The sorts of things that come to mind are
- huffman encoding the data stream at the mainframe, and
unencoding at the micro end, to effect a net speedup
in data transfer rate (I hate 300 baud)
- co-operative text editors, where the screen handling is in
the micro, and the data manipulation occurs at both ends;
at the micro end for the purposes of the screen image, and
at the mainframe end for posterity
- local scrolling over a larger history than the screen size
(many modern non-dumb terminals do this now)
- the ability to negotiate, in a table-driven way, the various
signon sequences of a number of different time-sharing
services. In my mind, this includes being able to dial
in either pulse or tone, being able to wait for dial tones
and carriers, reporting intelligently where in the signon
sequence the failure occurred if it was unable to complete.
- I am sure there are more goodies that one could put into
such a package if one thought about it.
Has anyone tried to do any/all of these things?
How successful were you? Was the concept useful when all was
said and done? Would you do it differently next time? Is the
code available?
Seems this could get lengthly. I will gladly summarize mail
that I receive. People who find the summary too concise can
get more lengthly transcripts from me via mail. Reply to...
Michael Wagner, UTCS (decvax!utzoo!utcsstat!wagner)
Cmu-Cs-C@sri-unix
I haven't had much luck with mail to UUCP sites, so I hope you get this ...
Yes, there has been some work done along these lines. I am aware of 3
implementations, each using various combinations of the ideas you mention.
1. RMS@ai has added local editing (handling simple movement commands and text
insertion locally, with burst updates to the host - hopefully this improves the
host performance by improving the scheduling of the host editor - you refered
to this as co-operative text editing) and line saving (local scrolling) to
MIT's version of Emacs. The test implementation involved using Lisp Machines
as the local processors, but the protocol is suitable for microprocessors. All
of this is described in ai:rms;lep >.
2. Robert Goldberg (Goldberg@Rutgers) implemented a split editor as a part of
his thesis at Rutgers. He handled the cooperation in a different way, placing
more of the burden upon the local processor, while the host ran a simple line
oriented editor. You might contact him for a copy of his thesis, which
includes the results of many empirical text editing studies. He reported a
speedup by a factor of about 4 (without any data compression - simply from
relegating all screen updating to the local processor and remembering all the
data sent from the host).
3. Leonard Zubkoff (Zubkoff@Cmu-CS-C) has modified the firmware in our
Concept-100s to do some simple data compression and better screen handling.
Our versions of Twenex Emacs and Gosling's Unix Emacs support this terminal,
and achieve a net speed-up of about 2.5. (75 cps at 300 baud). Details are
available in a CMU Tech Report, or online through Leonard. I support some
of this protocol in my homebrew Concept emulator for my apple.
Additionally, I have been experimenting with other data compression and screen
management mechanisms, and am in the process of implementing some new ideas.
I'll let you know if they are successful.
David Anderson
(Anderson at Cmu-CS-C)
Sri-Kl@sri-unix
(I can't respond individually, as your return address is longer than
39 character. I think I say enough that everyone will be interested)
Yes. Several things such as you describe have been done:
- huffman encoding the data stream at the mainframe
Someone at MIT has an apple program that does this. I beleive it is
in the public domain. I beleive it gets about 30% compression (45cps).
Note that huffman encoding really isnt all that wonderfull for the
large number of characters that go down a typical terminal line.
Zubkoff@CMU-CS-C (? they just changed all their host names) developed
software that ran inside an HDS Concept-10x terminal (a z80) that did
compression by defining more usefull cursor control comands and by
having large fixed and dynamic dictionaries so that common or recently
used words could be sent as short (one or two) character sequences. He
was able to get compression of some 3 times (480 cps on a 1200 baud
line!!!) while editing programs containg a lareg amont of word
repitition (MACRO-10 and bliss source code, I beleive). He used all
256 possible 8 bit codes. I beleive HDS droped this, and dont know
the current status of the software.
I wrote a quick and dirty version of just the dynamic dictionary idea
and managed to get about 50% compression running files of "typical
emacs output" through it, and about 30% on normal text files.
Note that the above approachs require some non-trivial software on the
main host translating the output stream of all programs before it is
sent out the terminal line. On many systems this is impossible. On
others it is slow enough to offset the compression. In almost all
cases, it may not be "practical" since the lower connect-time cost
could be offset by higher cpu charges. Another slightly better
approach is to build the compresion into commonly used programs such
as the editor, and ignore other things.
- co-operative text editors
MIT has defined a "Local Editor Protocol". Other similatr things have
been done. I dont know whether any of this has been applied to
"popular" editor, or whether a "full featured" editor includes any of
these.
- the ability to negotiate, in a table-driven way, the various
signon sequences of a number of different time-sharing
services.
Sigh. Without abusing the ARPANet too much, I have written a program
(ReCall) for the IBM PC that does this (amoung other things) and will
be marketed. It is much smarter than "in some table driven way" in
that it allows you to login normally once, and then remembers what you
did and how the host responded so that it can do it all again when
referred to by name (as in "recall sri-unix"). The idea is extended
to allow completely unattended execution of oft repeated tasks (eg,
call up dow jones, download the stock prices of x, y, and z, logout,
and hangup). Since the program is written entirely in 8088 assembly
language and makes extensive use of the IBMs function keys, it isnt
likely to be rewritten for other computers (well, maybe the DEC rainbow).
It works very nicely, and I like it a lot (you can also use it to do
commonly done things in the middle of a session, like downloading a file)
- scrolling region bigger than the screen
almost all comercially available "smart terminal" programs for micros
have this feature. I have never found it to be particurally useful.
It is much nicer to have several pages that you can flip back and
forth between (and that arent affected by output to other pages).
Few programs seem to implement this (The above mentioned concept-100
terminal has a way of faking this feature using its definable function
keys and "windowing". I can make available the necesary code if anyone
with a concept is interested...)
Bill Westfield
BillW@SRI-KL
...!sri-unix!billw