m

30 Jan 1988 13:02 PENTTI[ 1, AB] PAGE 1-1 COMPUTER MEMORANDUM * STANFORD UNIVERSITY * COMPUTER MEMORANDUM *

Date: January 25, 1980

To: Tom Rtndflelsch and whoever 1s Interested From: Penttl Kanerva Subject: THE HEATH MODEL Hl9 VIDEO TERMINAL AS A TVEDIT TERMINAL

I spent a weekend at SUMEX checking out the Heath (Zenith) terminal. Eric Schoen had already made it work with TVEDIT, although editing was cumbersome without the EDIT key and without well-placed keys for moving the cursor. For my part, I tried to figure out a way to make up for these deficiencies. Many of my comments should apply also to and other display text editors that control a screen from a host over relatively slow asynchronous lines.

DUSCUSSION NOTE. The Heath terminal has two command sets, the Heath and ANSI sets. The Heath command sequences are shorter, but the ANSI commands can do more because they can Include numeric arguments that serve as repeat counts. For example, it Is possible to delete 17 lines with one ANSI command (ESC ['17 M), whereas 17 Delete Line commands (ESC M) are required 1n Heath (forward windowing in TVEDIT begins with the deleting of 17 lines). However, the terminal 1s not programmed to take full advantage of the repeat count: Deleting 17 lines with one ANSI command takes the same time as deleting them with 17 Heath commands! This memo and Eric Schoen' s additions to the display package have been written In terms of the Heath command set. If the terminal were programmed to execute a repeated command 1n one pass, the ANSI set would be the more economical of the two.

I will discuss first what can be done without modifying the terminal 1n any way whatever. The biggest problem is the KEYBOARD. The best way around is to use the function keys In the top row and the keys of the right-hand pad for TVEDIT commands. In Heath Alternate Keypad Mode (see pp. 21, 72, and 73 of the manual) these keys generate the following escape sequences, with two sequences (three for the 7 key) shown for keys affected by the (see top of next page). Because many of the sequences already have meanings 1n TVEDIT, keyboard input needs to be translated before it 1s passed on to the main program. This can be done by a keyboard package similar to the display package, allowing the main program to be the same for all terminals. *

30 Jan 1980 13:92 PENTTI[ 1, AB] PAGE 2-1

ESC E ESC S ESC T ESC U ESC V ESC W ESC J ESC P ESC 0 ESC R [fl] [«.] [«] [f4] [fs] [ ERASE][ blue] [red] [gray] ESC 0 or ESC 0 ESC A ESC N ESC ? W ESC ? x ESC ? y [7] [8] [9] ESC D ESC H ESC C ESC ? t ESC ? v ESC ? v [4] [5] [6] ESC L ESC B ESC M ESC ? q ESC ? r ESC ? s [1] [2] [3] ESC ? p ESC ? n ESC ? M [0] ["] [ENTER]

The keyboard package would watch for escape sequences, convert them Into predefined editing commands, and would pass all other input to the main program intact. For example, were the 4 key of the pad to move the cursor left, the package would have to convert ESC f t into ESC <" But then ESC Itself becomes a problem. For example, typing ESC followed by P, to Insert a page mark, would be converted to whatever command the blue was assigned. The problem can be handled by forgetting the altogether and by assigning the fl key to escape (the Input package would convert ESC S to ESC). This wastes the ESC key but avoids confusion. The function keys could be assigned as follows, with the shift key, when it applies, interpreted as two escapes: ESC ESC D DEL ESC ESC A ESC B ESC J ESC S ESC 0 DEL ESC T ESC 0 ESC [fl] [f2] [f3] [f4] [fs] [ERASE] [blue] [red] [gray]- ESC ESC I ESC ESC ♦ ESC ESC X ESC I ESC t ESC X [7] [8] [9] ESC ESC < ESC ESC W ESC ESC > ESC < ESC W ESC > [4] [5] [6] ESC ESC I CR ESC ESC \ ESC ESC D CR ESC I CR ESC \ ESC D CR [1] [2] [3] ESC ( ESC W ESC ) [0] [.]- [ENTER] The assignments are not necessarily optimal for TVEDIT, but they mostly *

30 Jan 1980 13:02 PENTTI[ 1, AB] PAGE 3-1

agree with what 1s written on the key caps. It would be quite easy to edit with these keys even without the EDIT key. The second problem Is SPEED. The insert- and delete-line functions are the slowest. They take almost exactly one millisecond per affected line (1f the cursor 1s oh the second line from the top, all but the top line are affected). By comparison, the Datamedia Elite 2500 takes 2/3 ms. per affected line to Insert but hardly any time at all to delete a line. (Teleray takes about three times as long as Heath.) To make up for the slow speed, the terminal has a 128-character Input buffer. When the terminal falls badly behind, as 1t can with TVEDIT at 2400 baud, It transmits XOFF (tS) to the host, and when it begins to catch up again, it transmits XON (tQ). The host is supposed to stop transmitting to the terminal as soon as 1t receives XOFF and start again when it receives XON. This looks fine on paper but it has its problems. Not all operating systems and networks conform to the convention, and even if they did, characters get garbled in transmission. It is therefore safer, for now at least, not to rely on XOFF and XON but to use fill characters In conjunction with slow functions. (This is how time Is made available for the slow functions of the Datamedia.) NUL 1s the only character that can be used as time fill on the Heath terminal. All other characters go Into the input buffer. The display package needs to be modified to use NUL for fill. The slow functions of the terminal (over 1 ms.) that are used by TVEDIT are Clear Display, Erase to End of Page, Insert Line, and Delete Line. You should be aware of two more poblems that are not Immediately obvious: The priority of keyboard service is too low, and the many extra functions and modes—ones not used by us--can cause trouble. Keyboard service now comes second to display service. When the display Is busy, the keyboard is read and up to eight characters are queued, but the characters are not transmitted to the host until the terminal's 128-character Input buffer is empty. (On the Teleray, the keyboard is ignored altogether when the display is busy.) This means that you cannot always stop a runaway program. If the program in the host 1s in a loop and keeps sending line Inserts, your typing CTRL-C does no good because the terminal is too busy to transmit It. Heath Company should be told about this problem and asked to fix it. Key- board Input should be read and TRANSMITTED before display commands are executed. With a large number of "extra" commands, some quite potent, line noise can wreak havoc. Commands that make anything about the terminal to be transmitted to the host--Cursor Position Report, Identify as VTS2, Transmit 25th Line, and Transmit Page--are the most dangerous, because to the editor what comes down the line looks like the user's typing. The keyboard package could be made to filter out the cursor position report and the VTS2 response, but there 1s no. good way to detect a page that 1s on the move, which is the most dangerous of the four. This has happened so often on IMSSS Datamedlas that we have removed the transmit- line and transmit-screen functions from all of them. *

30 Jan 1980 13:02 PENTTI[ 1, AB] PAGE 4-1

If the operating system responds to XOFF and then does not receive a matching XON (because of noise on the line or because tS was typed by the user), the system will appear dead. The user may attempt all sorts of things to get a response. If he (or she) eventually types tQ, not only will the system come alive again, but his all sorts of things will have been executed by the host! The plethora of modes can be confusing. Line noise, again, can disable the keyboard or change the baud (both equally disconcerting because the user is cut off) or change the key pad or switch to ANSI or some other mode (which 1s merely annoying as It is still possible to type to the system and get help). We should be ready for a good number of trouble calls from such causes. Even with the Datamedlas we get them when the terminal or modem 1s not plugged In or when the keyboard plug 1s loose or the terminal 1s In half duplex or 1n tape mode. People will learn, but It will take time and patience.

RECOMMENDATION

By modifying a small part of TVEDIT, the editor can be made to work quite well with the Heath Model Hl9 Video Terminal. I will be glad to help a competent programmer make the changes. The terminal 1s not a match to the Datamedia Elite 2500 (even the Datamedia Elite 3888-based emulation of the 2500 isn't), but It is reasonable as a less expensive alternative. I don't expect to see anything better from commercial vendors in 1980 at Heath prices or anything appropriate below those prices.

I would discourage attempts to modify the terminal, unless it were programmed to emulate a known design, for example, the Datamedia Elite 2500 as configured for Stanford, including the idiosyncrasies and bugs of the 2500. John Glll of Information Systems Lab (Stanford) has done that with the Hazeltine 1508 (affectionately known as the Hazelmedia or Datatine). But writing a good emulator takes time (Glo Wiederhold started to pursue the Hazeltine modification over a year ago) because the people who can do it are already busy. John also created a new terminal design that 1s more economical of communications than any I have seen so far. It 1s available for the Hazeltine 1500 and the Hazeltine Modular One. John's design will be a new terminal type at IMSSS and possibly other DEC sites at Stanford. Adding the EDIT key would not help much without other changes to the keyboard. The keys that move the cursor need to be placed properly. If keyboard Input is queued, the state of the edit key needs to be stored with each character that 1s queued, and so the eighth bit would have to be loaded from the microprocessor rather than being generated at the UART. So the keyboard should be either left alone or totally redone. If the terminal 1s made Into a Datamedia, the keyboard could be made Into a Datamedia (SUMEX) keyboard. Changing the speed to asymmetric 1200/150 baud might need to be done here at Stanford. 30 Jan 1980 13:02 PENTTI[ 1, AB] PAGE 5-1

PROSPECTUS Ever since microprocessors, terminal design has gone downhill. Microprocessors make designing seem easy because implementation 1s so easy. We now have too many commands, the commands are too slow, and the command sequences are too long. I have already talked about how unnecessary commands can get in the way. I should add that terminal-Independent programs must be based on simple commands, ones that can be found on many terminals. As to speed, commands are slower now than they were five years ago when they were done in the hardware. Long command sequences waste the capacity of communication channels. My tests with TVEDIT on the Datamedia 2500 show that about 45% of the characters transmitted are display commands. On the Datamedia the commands are control characters and hence take (most of them) just one character. Let us use 188 characters as a base representing transmission to the Datamedia: 55 text characters and 45 command characters. If two-character escape sequences must be transmitted 1n place of control characters, as in the Heath terminal and in many others, we must transmit 55 + 2*45 = 145 Characters (actually a few less, say 140, because direct addressing of the cursor 1s not doubled 1n length). The ANSI standard (see pp. 81-90 of the manual) makes almost everything three times as long as necessary: It requires ESC [ before it begins to say anything. As a result, what takes 188 characters on the Datamedia takes 55 + 3*45 * 198 characters on an ANSI terminal, with the effect of reducing a 1208-baud phone line to 638 baud! (The repeat count of the ANSI commands 1s of no help 1f the terminal executes the commands by repeating a unit operation, e.g., deleting a single line, the required number of times as on the Heath terminal. Channel capacity and time are then wasted In fill characters.) Command sequences used to be short when command decoding was done in the hardware. We do not need many long commands but a few short ones. That 1s the essence of John GUl's design. Because of better commands (ASCII control characters are used for the most common commands, and commands that have a repeat count are executed in one pass--see Note on p. 1), transmission 1s reduced to about 88 compared to Datamedia' s 100. My impression is that the industry 1s headed in the wrong direction. In the name of 'more' we are getting more complicated designs, and devices that are more difficult to control. What this tells me 1s that we (Stanford) should try to influence the design of even simple terminals. If we Started now, we could, 1n a year or two, have Inexpensive terminals with large character sets (256 or 512 characters) and with several useful display attributes (underline, bright, and reverse video). Many terminals already have these attributes, but they are usually implemented In a way that makes them useless 1n text editing (reverse video on the Heath terminal 1s right for text editing). The character sets and the display attributes could be done easily with today's technology, but not by modifying a terminal I know of. Our present terminals will be used for another five years, but the Heath terminal should not be our choice In 1982. pk/tv