delton@pro-carolina.cts.COM (Don Elton) (06/22/88)
I think Jim Elliott has missed something when he says that all a program need do to avoid losing data on an unenhanced //e is to use interrupts. TIC has used (required in fact) interrupts since day one. You don't lose data on the unenhanced //e because the scrolling is slow. It's not that much slower than the scrolling on an enhanced //e. You lose characters on the unenhanced //e because someone (the guy that wrote the firmware code) decided that the //e wasn't going to be used in an interrupt environment so they didn't worry about the fact that they turned off interrupts with an SEI command for long periods of time during scrolling. Unless you write your own scrolling code or use undocumented entries etc you'll lose data during these time periods at any decent baud rate. TIC has supported up to 19,200 baud since day one by using interrupts. There's no good reason to go around saying that a given program is "Silly" or not "Decent" just because you think something should be done differently. If you think something should be done differently then do it, don't try to insult others who have gone the other way after careful consideration of the alternatives. It's also a bit overboard to condemn software for a limination that affects so few users as to be almost totally insignificant for them and totally insignificant for the vast majority as well. For example, I wouldn't comdemn AppleWorks for not being able to work with DOS 3.3 files directly either. 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