delton@pro-carolina.cts.COM (Don Elton) (06/20/88)
Re: the problem of losing data when the firmware on an unenhanced //e is used for scrolling in a comm program. 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. You see, the //e enhancement kit has been on the market since March of 1985 and has been installed in every //e sold after this date and in a significant number of the //e's sold after this date. There's no decent reason not to get this inexpensive upgrade. If I add scrolling code, one way or another, it will penalize the vast majority of users using machines that can do decent scrolling as it will take up valuable program space that can be used for something more useful like new script language commands, conferencing modes etc etc. Maybe the solution is to just go ahead and use 65C02 op codes and more liberal use of MouseText to drop unenhanced //e support altogether but there's no overriding reason why this has to be done. In my experience TIC has been the program to convince many people that they need to break down and get the enhancement kit so at least people can get a general feel of the program before they get the upgrade so they can decide if it's worth it to them. In that respect it makes good marketing sense for me to advise in my docs that the enhancement kit is "strongly recommended but not absolutely required" (since you can always add nulls at the host end). I don't consider requiring the enhancement kit any more of a shortcoming though than requiring a //e as opposed to the II+ or the Apple I for that matter. Life moves on. UUCP: [ ihnp4 sdcsvax nosc ] !crash!pro-carolina!delton ARPA: crash!pro-carolina!delton@nosc.mil INET: delton@pro-carolina.cts.com Pro-Carolina: 803-776-3936 (300-2400 baud, login as 'register') US Mail: 3207 Berkeley Forest Drive, Columbia, SC 29209-4111
elliott@glacier.steinmetz (06/22/88)
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] . . . . . . ... . . . . . . . . . . ... . .