BILLW@SU-SCORE.arpa (William Chops Westfield) (08/01/86)
Bah humbug. First of all, A terminal really need not scroll at 19.2K baud - Nothing can read that fast anyway. Anyone should be able to write a terminal emulator that can do a singlepage update at 19.2K Bps or greater. Even a VT100 emulator. I wrote a Heath terminal emulator that was so fast that it performed "essentially instant" screen updates when called with internal strings, and it used IBM PC BIOS calls for all its cursor functions (except insert/delet character), and ran on a standard IBMPC with monochrome adaptor. (People faced with cards that can't be drawn to except durring retrace, or with bitmaps, are excused...) BillW -------
G.MDP@SU-SCORE.arpa (Mike Peeler) (08/01/86)
Aw, c'mon Bill, the SAIL displays are so fast it's ridiculous, but ridiculously fast can be surprisingly pleasant. The faster, say I, the better. (Say, Bill, neat idea, putting a control-X in your signature file!) Cheers, Mike -------
G.MDP@SU-SCORE.arpa (Mike Peeler) (08/01/86)
Sorry, I just realized a potential for misunderstanding. I most definitely didn't mean that terminal emulation HAS TO BE slow, but that due to stupidity it IS slow more often than not. As I said in my second-to-last message ago, terminal emulation is no big deal... -------
henry@utzoo.UUCP (Henry Spencer) (08/07/86)
> First of all, A terminal really need not scroll at 19.2K baud - Nothing > can read that fast anyway... More telling yet, no existing display updates the light pattern on the screen that fast. The fastest refresh I'm aware of on a common device is 71 Hz on the 520ST. Suns are 66 Hz. Most terminals are 60 Hz or even (shudder) 30 Hz interlaced. Except for very unusual jobs, there is absolutely no need to scroll the screen more than once in a screen-refresh interval; the human watching will never see the intermediate state. If the screen is going to be scrolled several lines by the time of the next screen update, then one can do the scrolling as *one* multi-line jump and then fill in the empty lines at the bottom. Doing this right is not trivial, since it means looking ahead into the input stream to optimize the handling of (e.g.) a linefeed, but it is possible. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,decvax,pyramid}!utzoo!henry
wtm@neoucom.UUCP (Bill Mayhew) (08/10/86)
[By my line of reasoning, eat this...] O.k., let's see what baud rate is necessary. Presuming a 24 line terminal with 24 lines, and 9*11 dot array for characters yeilds sufficient readability, the CRT would probably be scanned at a rate of either 50 or 60 Hz, depending on your part of the world. The above rates make engineers happy, as there are lots of standard TV building blocks available. Of course, there are things like Suns and Ataris, as Henry Spencer noted. (66 and 71 Hz). On average, presume that the scan rate will be 60 Hz. While not using a word processor with attendant [ANSI ?] control strings necessary, the worst case would be needing to scroll an 80 character line. 80 char * 10 bits/char = 800 bits in 1/60 th second. Do that 60 times/second, and you'd need 48,000 baud to maintain unbroken throughput. Of course, average line length is going to be less, so one could probably get away with a lower data rate. Given that an average 80 character line might contain on average 10 words, that would correspond to a reading skill 600 words/sec or more comprehensibly stated prodigous 36,000 words per minute. I'd imagine that it would be hard to spot anything except for the grossest pattern in a file whizing by at that clip! As a final note, I don't know very many hosts that can fill an I/O channel with that much data at an unbroken pace. Once you discover said perfect termianl, I suspect the nect step will be to obtain a much faster host system (grin). Bill Mayhew Division of Basic Medical Sciences Northeastern Ohio Universities' College of Medicine Rootstown, OH 44272 USA (216) 325-2511 (wtm@neoucom.UUCP)