Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!batcomputer!itsgw!steinmetz!glacier!elliott
From: elliott@glacier.steinmetz
Newsgroups: comp.sys.apple
Subject: Re: scrolling and the unenhanced //e
Message-ID: <11311@steinmetz.ge.com>
Date: 21 Jun 88 18:20:10 GMT
References: <8806201416.AA12217@crash.cts.com>
Sender: news@steinmetz.ge.com
Reply-To: elliott@glacier.steinmetz.ge.com ()
Organization: General Electric CRD, Schenectady, NY
Lines: 61

In article <8806201416.AA12217@crash.cts.com> pnet01!pro-simasd!pro-carolina!delton@nosc.mil writes:
>TIC - Talk is Cheap - currently uses firmware scrolling.  This works fine on
>the enhanced //e, the //c, and the IIgs.  Data is lost on the unenhanced //e
>if you're using over 300 baud though it's not lost at up to 19,200 baud in
>mose cases with the above named computers.  
>
>Sure TIC could add its own scrolling code and bypass the problem and it might
>do so eventually if I find a better reason than this to do my own scrolling
>but for now it's a conscious decision of how the program should work, not an
>oversight as some would have you to believe.  

I am certain this is true for many users, and will not dispute it. I
have never seen TIC, having always used my own terminal programs. The
first one was written to be specifically used on a 9600 baud
conenction to an IBX data port in an RPI campus dorm. I chose to do
all my own screen I/O for several reasons, not the least of which was
the problem of losing characters on scrolling at high speed.

I have other complaints with the firmware screen routines, though.
Even when you don't lose characters on scrolling, the 80-column scroll
is slow and ugly, and you can see the alternate rows of text splitting
and re-merging. At 9600 baud, a program falls behind quickly when
scrolling. They also do not allow me to open overlapping windows
behind which text can scroll.

My own conscious decisions about how my terminal program should
behave, then, are different than yours. In my paradigm, the user's
terminal session is of paramount importance. It should never be messed
up with extraneous text, nor should it lose any, and it should be
updated frequently and accurately, even when the program is in the
middle of a dialog box for configuring itself. The screen routines I
wrote take up less space than the emulators needed to perfectly
perform VT100, VT52, ADM3A and Apple emulation.

Admittedly, however, my ultra-fast scrolling routines (which are
self-writing code) are very, very large. My approach to the problem of
memory has been to provide a means to extend ATP by loading in
"segments" to perform special-purpose tasks.

No program is perfect for everyone; I have no doubt that there are
many people for whom TIC is a better alternative than ATP. I was not
calling TIC "indecent" as a terminal program for the enhanced //e, //c
or //gs. And you yourself state that TIC does not support my
unenhanced //e. So for now, I'll stick with ATP. (Of course, I'm
biased, since I wrote it, and also have the source handy whenever I
want to add a new feature...  :^)

And (as soon as I get GS support finished), hopefully others will have
the option of using ATP if they like it. They'll be able to write
their own segments, too. Of course, it's probably very different than
terminal programs people are used to; I've never used any but my own.
Which, I think will be good. For there is richness in variety.  And
the more, very different, tools people have available, the more likely
they will be able to find one which does just about what they want.
 .     .    .    .   .  . ... .  .   .    .    .     .    .   .   .  . ... . .

 Jim Elliott                       /    ...!seismo!uunet!steinmetz!crd!elliott
                                  /
 "Don't look, son, it's          /      Jim_Elliott%mts@itsgw.rpi.edu [school]
  a secular humanist!"          /  (or)     elliott@ge-crd.arpa	      [work]
 .     .    .    .   .  . ... .  .   .    .    .     .    .   .   .  . ... . .