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] . . . . . . ... . . . . . . . . . . ... . .