prindle@nadc.arpa (07/31/86)
Ah yes, software emulation of a smart terminal. Rest assured that parsing the terminal control sequences for a VT100 (ANSI Standard) terminal is non- trivial (as comapred to a VT52 for example). The sequences are neither of fixed length, nor do they end in a terminating character. Furthermore, the actions to be taken are quite variable. For example, receipt of the sequence ESC [ m (or, for that matter ESC [ 0 ; 0 ; 0 ; 0 ; 0 m) causes the character attributes to be cleared (but nothing printed on the screen); by contrast ESC O t is a no-op (an echo of an application keypad key), but the "t" must be printed! A VT100 also has a myriad of un-standardized reactions which no terminal emulator ever seems to duplicate exactly. However, a prime consideration in handling high baud rates without flow control is hardware capabilities of the emulating PC. Toughest of all is to roll up a whole screen of characters without getting hopelessly behind in the processing of (hopefully buffered) input data. No matter how big you make the buffer, enough short lines received will ultimately spend so much time rolling up the screen that data will be lost, or flow control will have to be imposed. Frank Prindle Prindle@NADC.arpa
G.MDP@SU-SCORE.arpa (Mike Peeler) (08/01/86)
Frank Prindle is right that "a prime consideration in handling high baud rates without flow control is hardware capabilities of the emulating PC." But I don't want anyone to be left with the idea that the software it takes to emulate a VT100 has much to do with it. It's all a matter of getting the bytes in and out. The processing to do the emulation is no big deal. I was going to briefly describe the VT100 input states, but I've now thought better of it. I'll go ahead if asked. The states number about a dozen---including VT52 mode---the code is very simple, and with obvious code/data and time/space trade-offs the data take 4 to 8K (for starters, screen + attributes is 4K). On a PC in tight assembler but no low-level mods, it was awful. On a 68K in none too fancy Pascal, it was great. The hardware and low-level drivers made all the difference. Cheers, Mike -------
sandersr@ecn-pc.UUCP (Robert C Sanders) (08/03/86)
In article <2718@brl-smoke.ARPA> prindle@nadc.arpa writes: >Ah yes, software emulation of a smart terminal. Rest assured that parsing >the terminal control sequences for a VT100 (ANSI Standard) terminal is non- >trivial (as comapred to a VT52 for example). The sequences are neither of >fixed length, nor do they end in a terminating character. Furthermore, the >actions to be taken are quite variable. [ ... ] >-- Frank Prindle Another possibility is to emulate the Heath/Zenith H19 terminal; it is a superset of the VT52, with most (if not all) of capabilities that VT100 emulators include. The escape sequences are mostly the same length (\Ex where x is the command; sometime two letters long), and are shorter than their ANSI counterparts; and the commands more closely match the hardware considerations of most micros. As a matter of fact, any body know how well the rugged H19 does at 19200? I know the keyboard leaves much to be desired, but ... I rewrote the ANSI.SYS driver in an MS-DOS machine to emulate a superset of the H19 (really the Z100 sequences), and it turned out faster because of the less storage and processing required by the program. -- Continuing Engineering Education Telecommunications Purdue University ...!ihnp4!pur-ee!pc-ecn!sandersr Let's make like a BSD process, and go FORK-OFF !! -- bob (and "make" a few children while we're at it ...)