rh@mit-eddie.UUCP (06/25/84)
VT100's have an incredible amount of performance problems. They do require quite a bit of padding, as I have seen. They work okay at 9600 baud on our DEC-20 (probably because our Virtual Terminal System groks how bad they CAN lose), but lately I've noticed that they lose at 9600 baud on the Unix. That they have a setting for 19.2kBaud cracks me up. I should try it on the Unix sometime.... On a similar note, the Z29 from Heath/Zenith seems to have found some of the VT100's ability to lose. At first, I thought they had changed the escape sequence for CID from what the Heath19 uses, since attempts to do CID lost badly. But it's the same, just probably wants about 10 times as much padding. I haven't decided if I want to put more padding in the DEC-20's VTS for the bugger or not. If anyone knows about differences in recommended padding between the 19 and the 29, I'd be interested in hearing about them. -- Randwulf (Randy Haskins); Path= genrad!mit-eddie!rh
gwyn@BRL-VLD.ARPA (06/26/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> The VT100 requires NO padding even at 19.2Kb if you enable XON/XOFF flow control and if your so-called UNIX handles XON/XOFF correctly. Any really interesting video terminal could conceivably require flow control to keep its buffer from being overrun at high baud rates while doing time-consuming display operations, such as smooth scrolling which is a big WIN.
JTW@MIT-XX.ARPA (06/26/84)
From: "John T. Wroclawski" <JTW@MIT-XX.ARPA>
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA>
Subject: Re: VT100 and bagbiting
The VT100 requires NO padding even at 19.2Kb if you enable XON/XOFF
flow control and if your so-called UNIX handles XON/XOFF correctly.
Any really interesting video terminal could conceivably require flow
control to keep its buffer from being overrun at high baud rates while
doing time-consuming display operations, such as smooth scrolling
which is a big WIN.
Well, of course.
However, any terminal which requires XON/XOFF to perform standard
video operations at a particular speed is incompatable with emacs and
a number of other programs and is thus unusable at that speed for many
people.
In some cases you can get around this with padding, which makes the
terminal more usable. In other cases (VT125, say), you cannot ever
completely hide the braindamage.
Since it quite clearly is *possible* to make terminals that do not
need heavy padding to run at 9.6Kb with all the video operations
needed by good screen editors, I think it is only fair to say that
those manufacturers who have not managed to do so have inferior
products.
-------gwyn@BRL-VLD.ARPA (06/27/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> I don't think compatibility with EMACS is a necessary criterion for a good terminal; EMACS violates terminal usage standards left and right. Besides failing to support DC3/DC1 flow control (locally we have fixed our versions of EMACS to support it if it is being used), it likes to have the user typing the ESC key, in violation of ANSI standards.
ron@BRL-TGR.ARPA (06/27/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> But seriously folks, a terminal that runs through the various editing features at 9600 baud without any flow control is running faster and many find this a big plus. -Ron
mab@AIDS-UNIX.ARPA (06/27/84)
From: Mike Brzustowicz <mab@AIDS-UNIX.ARPA> Excuse me, but using DC3/DC1 for flow control IS a violation of the ANSI standard (remember ASCII)? Those controls were intended to control devices attached to the terminal (XON and XOFF referr to turning on and off the paper tape reader once found on many terminals). The intent was to allow the computer to control the input from the terminal (without operator intervention required), not the other way around. I'm not sure who got the idea of turning the tables on the computer, but DEC certainly had a hand in popularizing it. Not to nit-pick, but...does ANSI really say "the user shall not type escape"? If so, then ANSI standard terminals should not have an escape key (:-))! -Mike
gwyn@BRL-VLD.ARPA (06/27/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> Yes, the ESC key should be removed from ANSI X3.64-conforming terminals. The reason is that ESC indicates the start of an escape sequence and so it cannot have meaning by itself. What some people have done for things like screen editors to support user-typed ESCs is to see if the input queue is still empty a second or so after getting an ESC, and if so assuming that it could not have been the start of an escape sequence. I once modified a screen editor so that ESC ESC was taken as a user- typed ESC, and ESC-anything-else was assumed to be an escape sequence. All these kludges are caused by having an accessible ESC key. As to DC3/DC1, the old Teletypes did use them for controlling the attached paper tape units (DC1 = enable reader, DC2 = enable punch, DC3 = disable reader, DC4 = disable punch as I recall), but their meaning is just "device control". It is fairly easy to see how the DC3/DC1 flow control protocol logically evolved from this. As far as I know this in-band flow control protocol is not an ANSI standard, but it definitely is one of three industry standard asynch flow control protocols: DTR/CTS per-character handshaking (lousy over modems with most computer systems) ENQ/ACK master-slave handshaking (not suitable for real full- duplex interaction as we know it) DC3/DC1 (XOFF/XON) flow control (in both directions) My impression is that the vast majority of ASCII terminals being sold today provide DC3/DC1 flow control, usually as an option (often the DTR/CTS method is available as an alternative). This implies that it is a mistake for a programmer to expect a ^Q or ^S (DC1 or DC3) to be typed by the user. Indeed, years ago DEC published an internal standard that prohibited the use of ESC ^S ^Q (and maybe ^R ^T) as user-typed input for DEC program products. (I do not know how well this corporate standard was obeyed.) As a recent example, the Teletype model 5620 (reborn Blit) in its resident terminal mode does not transmit ^S or ^Q when they are typed on the keyboard, but it does transmit them automatically when its input buffer is nearly full and when the user puts it in SET-UP mode (i.e. DC3 is sent to suspend host transmission then DC1 is sent when the emergency is past). One could argue that user ^S ^Q should be coordinated with automatic DC3 DC1 (as on the DEC VT100), but (a) the resident terminal mode is not used for real 5620 work, and (b) the function keys can be programmed to send ^S and ^Q if desired. One of the great lossages on 4.2BSD is that DC3/DC1 flow control is not available in "RAW" mode, although the need for this support is actually dependent on the terminal hardware, not on whether or not an application program wants input canonicalization done. This non- orthogonality of the various things bundled into the meaning of "RAW" mode was fixed in the terminal driver supplied as part of UNIX System III and V. This may explain why AT&T UNIX users understand the use of DC3/DC1 flow control and BSD users think that its existence is a terminal design botch..
ron@BRL-TGR.ARPA (06/27/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> The fact the the 5620 does not transmit control-s and control-q from the keyboard is a bug. Even the manual says it is suppose to send them. One of the great lossages is that people insist on selling terminals with the assumption that you never really want to do any work on them at speeds greater than 1200 baud. Now, I can accept this moronic approach for things like teletypes and diablos because of the problems of high speed moving parts but there is no excuse in this day an age for solid state terminals to do so. My VT52 compatible terminal cost less than a VT100 and has fancier editing features and can run at 19,200Kbaud continuously without the need to interrupt the computer. C'mon, Doug. Admit that DEC does a lousy job of designing terminals. -Ron
mab@AIDS-UNIX.ARPA (06/27/84)
From: Mike Brzustowicz <mab@AIDS-UNIX.ARPA> About DC3/DC1, since they were intended to be sent by the COMPUTER to control devices on the TERMINAL, I don't see how "it is fairly easy to see how the DC3/DC1 flow control protocol logically evolved from this." The new way, although it may be a de facto industry standard, is backwards from the intended use of the codes (that is, having the TERMINAL cantrol flow from the COMPUTER is backwards). Historically, I believe this started as a stop gap measure so that the USER could stop the COMPUTER when too much information was arriving at once, and noone had MORE or anything like it. Now manufacturers are using it so that they can claim a higher baud rate for their terminals than the terminals are *really* capable of. There are a number of reasonably priced terminals that can work at high speeds, do all the nifty stuff and not require flow control or padding, so it can be done. I believe it to be a marketing ploy, and a technically poor decision, but one that, alas, those that can't pick their own terminals or machine may be stuck with. As for ESC, I believe you'll find that the use of escape for programming escape sequences (as in EMACS) predates ANSI X3.64. In ANSI X3.4 (ASCII), ESC was a prefix for transmitting "out of band" characters or sequences, which is its approximate use in EMACS. (In EMACS, it is actually prefix-META, that is, make the next character a meta character, for terminals that don't support meta chartacters, and most don't. Many EMACS versions allow one to redefine prefix meta to be some other character. Some will interpret the eighth bit of 8 bit ASCII as the meta bit.) Besides, in X3.64, aren't the overwhelming majority (like all but one, or maybe two) of escape sequences defined as, again, controlling the TERMINAL from the COMPUTER? -Mike
gwyn@BRL-VLD.ARPA (06/28/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> This attempt to distinguish one end of the RS232 ASCII link as the TERMINAL and the other as the COMPUTER, then to assign asymmetrical rules to the two ends, seems artificial when some so-called terminals are smarter than the so-called computers they communicate with. The original use of Teletype terminals did not involve computers at all, and each unit would control the paper tape reader on the other when they were communicating like that. I watched the evolution of XON/XOFF from close up (I used both Teletype and high-speed peripheral paper tape on a variety of computers). It was a perfectly natural evolution to the current use for more general flow control. Some degree of flow control is necessary no matter how fast the internal logic of a terminal is. Consider: - user opens the lid of the Diablo to change its ribbon - terminal scrolls smoothly 6 lines/second while short lines are being received at a rate of 1920 chars/second Many (maybe even most) computer system and terminal vendors have faced up to this fact by now. The "VT52 emulating" terminal with fancier editing features than the VT100 wouldn't be one of those Visual 200s, would it, Ron? Having done termcap entries for both and tried them both, I choose the VT100 any day. Not to say that the VT100 is perfect, but it is not at all the big loser that people have been saying it is.
jmoore@opus.UUCP (Jim Moore) (06/28/84)
I think that a terminal should be able to keep up with a 9.6 data stream for simple ascii text display, but it was a very bad decision to use ^S (XOFF) as a special character in emacs. XON/XOFF flow control is the closest thing to a universal standard protocol existing for serial lines.
mab@aids-unix.ARPA (06/28/84)
From: Mike Brzustowicz <mab@aids-unix.ARPA> Please be precise--RS232 and ASCII are two very different issues. And, you missed my point while seizing on the irrelevant. My point was not that the two end are or should be distinguished, but that historically, XON/XOFF flow control started from the other side, and that history is therefore NOT a good justification for the way it is now. And, it does make sense to treat the computer and the human ends of a connection differently--their capabilities in terms of data handling are VERY different, no matter what connects them. RS232 DOES distinguish between its two ends, the data terminal and the data set. Flow control at that level is done by signals on control lines. For terminal connected by RS232 directly to a computer, this allows flow control without using any characters (which one might want to be data). Modem users cann't get that because those control lines are not encoded and transmitted by the modems. I, too, watched the "evolution" of XON/XOFF from close up, from the bad old days, starting with Teletype ASR-33's. You may have found it natural, but others have not (obviously, or we wouldn't be flaming back and forth :-)). I agree that flow control is very handy, but XON/XOFF is not a very good implementation. For example, modem protocols could send signals which are out of the frequency bands used for transmitting characters to virtually connect the signal lines (Clear to Send is the RS232 signal that come to mind) at the RS232 level--not the data stream level. You will find some zealots (I'm not one) who insist that flow control belongs there and ONLY there, at least for things like opening the lid on a diablo to change the ribbon. (According to RS232, that should lower Data Terminal Ready, which should stop the data flow--sometimes that is implemented by hanging up the modem!) Another kind of flow control is for viewing large amounts of data comfortably. That is why more exists, what some editor excel at, and why some have terminal paging in their kernels (Not that I want to start THAT one again). In the end, however, if your terminal and your operating system or editor evolved so they are incompatible, you are free to change components to attain harmony again. Try 'ed'--it doesn't use any non printing charaters for editing commands. Or try a better terminal. rebind your keys in EMACS so that your favorites are free for flow control--or change your flow control characters on your terminal (make a termcap entry that will change them to nulls at start up and back to XON/XOFF at finish down--or can't your terminal be programmed like that remotely?). But please don't suggest that all the systems that predated XON/XOFF flow control (for terminals) should be retrofitted to match that de facto, poorly done standard--I don't believe that's a good idea and I doubt you'll change my mind on that. -Mike
ron@BRL-TGR.ARPA (06/28/84)
From: Ron Natalie <ron@BRL-TGR.ARPA> Hold on here. RS-232 does not distinguish between the computer and the terminal. It distinguishes between the DTE (Data Terminal Equipment, the computer, the terminal) and the DCE (Data Communications Equipment, the modem). -Ron
mab@aids-unix.ARPA (06/28/84)
From: Mike Brzustowicz <mab@aids-unix.ARPA> That's what I said. RS232 distinguishes between the two ends of ITS connection (usually between terminal and modem, and between modem and computer). Sorry if that was unclear. -Mike
gwyn@BRL-VLD.ARPA (06/28/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> Maybe I won't change your mind, but I do think that screen editors should work well with de facto industry standards for terminals.
mab@aids-unix.ARPA (06/28/84)
From: Mike Brzustowicz <mab@aids-unix.ARPA> EMACS was designed and implemented BEFORE XON/XOFF came into this usage. Rather say that de facto industry standards should work well with existing software. I don't use vi, so I don't know for sure, but I believe it works with XON/XOFF just fine. (As far as I know, it doesn't use control characters for commands. EMACS's usage of controls and metas for commands dates to its development at what is now MIT's LCS, on the ITS (Incompatible Timesharing System), using the Knight "terminals", which didn't really use ASCII.) -Mike
geoff@utcsstat.UUCP (Geoff Collyer) (07/01/84)
Doug Gwyn's comments about the USG terminal driver allowing DC3/DC1 flow control in "RAW" mode need rebutting. RAW mode (at least in v7) means eight-bit, uninterpreted I/O, so asking for DC3/DC1 flow control makes no sense since it implies that characters are being interpreted and some (DC3 and DC1) are not passed through. My main objection to DC3/DC1 flow control is that it is a negative acknowledgement scheme and certain brain-damaged terminals such as the DEC VT100 contain insufficient buffering to allow them to operate at high speed, especially when using smooth-scroll (which is too slow in the VT100). The problem is worse if the terminal driver attempts to use silo alarms rather than taking interrupts immediately upon receipt of incoming characters.
mab@AIDS-UNIX.ARPA (07/03/84)
From: Mike Brzustowicz <mab@AIDS-UNIX.ARPA> I am still under the impression that control-S was used in EMACS before XON/XOFF became popular for the use of the user stopping computer printout, (as opposed to the computer controlling terminal devices) thus it makes little sense to say that using control-s in EMACS was a bad design decision based on the pseudo standard of XON/XOFF. Does anyone know better? RMS? -Mike <mab@aids-unix>
djmolny@wnuxb.UUCP (Molny) (07/03/84)
I use Gosling Emacs under AT&T Unix Operating System with a terminal that
has a behaviour with DC1/DC3 that I find less than ideal. I decided to
bite the bullet and change my fingers' habits in Emacs to avoid typing
those two characters (no mean trick, as I use Mince at home). Besides
re-binding the Emacs functions normally called with command sequences that
include ^S and ^Q, I found that I had to turn flow control back on. My
terminal requires a good deal of time to do some screen operations and
*displays* ASCII (NUL) characters. Anyway, this line turns flow control
back on within the .emacs_pro:
(execute-monitor-command "stty ixon <$TTY")
where the TTY environment variable is set and exported (TTY=`tty`). I don't
remember why I had to use the environment variable, sorry. Also, I have not
yet tried running gmacs from within a window, just in quasi-dumb terminal
mode. (Anyone who has, please tell me what to expect. Thanks.)
--
________________
| __________ | from the green screens
| | ksh! | | of
| |__________ |
| | gmacs! | | Ronald W. Heiby
| | _________ | AT&T Technologies, Inc.
| | |dstar! | | Lisle, IL (CU-D21)
| | | | | __ ...!ihnp4!wnuxa!heiby
| --| | |_/ \_____
| --------- | /\ \_
| | \/ \+++
|TTY_______5620| / \
---------------- ( )
\___/hans@log-hb.UUCP (07/04/84)
[]
DC1/DC3 for flow control is NOT mandatory, except in DEC-os'es.
Also, the way EMACS uses C-S and C-Q in no way prevents using the same
characters for ( automated only ) flow control. However, several terminal
designers tend to take silly shortcuts when it comes to flow control,
such as stopping the TERMINAL output when typing a C-S on the keyboard..
Occasionally similar behaviour occurs on automated control....
In all cases of large institutes buying such braindamaged terminals
that I'm aware of, the manufacturers finally managed to agree on this being
wrong, and fixing it. The fixes were easy.
Further I think that it is unreasonable for a terminal that is nominally
capable of being set for a particular speed, NOT to be able to accept ANY
sequence of characters at that speed, without flow control.
An awful example is VT10X'es on VMS, where the aggregate character rate to
the terminal is slightly better at a nominal speed of 4800 than at 9600...
Also, several ( university ) designs have been produced over the past few
years, where any character sequence at any speed up to 9600 can be handled
with NO flow control. All designs in question had full VT100 compatibility
apart from speed capacity.
There is thus no longer any reason to produce terminals without full speed,
non flow-controlled, capacity.
If flow control is ever nessecary, such as over multiplexed channels,
electrical signals should be used, to preserve full code transparency.
Of course, any PROGRAM is free to use ANY pair of character sequences for
manual flow control. However, proper screen management is always to be
preferred.
The misgivings about "Typing ESC characters" can be alleviated ( for EMACS
use ) by finally making the META-SHIFT facility mandatory. This will be
done in the ISO standards efforts now underway, they tell me.
EMACS used the ESC character merely for want of a better way, and will
willingly give it up.
Finally, what little research has been put into human interfaces for editors,
seem to indicate that EMACS fares reasonably for any category of users,
and with very little learning effort at that.
The speed gained by just not having to move your fingers off the normal
keyboard is difficult to top without hard training.
The efficient use of separated keypads takes much longer to learn, however,
and will require standardizations of keyboards and codes that we are not yet,
and will hopefully never be, ready for. The sheer length of the present
suggestions for codes to be used is abominable. Also the lack of any real
structure is annoying.
--
{decvax,philabs}!mcvax!enea!log-hb!hans
Hans Albertsson,
TeleLOGIC AB
Box 1001,
S-14901 Nynashamn,
SWEDENobrien@CSNET-SH.ARPA (07/05/84)
From: Mike O'Brien <obrien@CSNET-SH.ARPA> What Geoff says is true, but I still found it necessary to put an option into VMUNIX at Rand to allow DC3/DC1 flow control in RAW mode, because the AED-512, a rather popular raster graphics unit, uses DC3/DC1 flow control as well as using an 8-bit data path. So long as it's clearly understood that this is the convention, and that DC3/DC1 will not occur in the data stream, this seems OK to me. Or to put it more baldly, either this code went in or the AED didn't run. Ordinarily I'm a purist but this was no contest.
gwyn@BRL-VLD.ARPA (07/05/84)
From: Doug Gwyn (VLD/VMB) <gwyn@BRL-VLD.ARPA> Another reason not to use silo alarms on things like DH11s & DZ11s.
guy@rlgvax.UUCP (Guy Harris) (07/06/84)
> Doug Gwyn's comments about the USG terminal driver allowing DC3/DC1 > flow control in "RAW" mode need rebutting. RAW mode (at least in v7) > means eight-bit, uninterpreted I/O, so asking for DC3/DC1 flow control > makes no sense since it implies that characters are being interpreted > and some (DC3 and DC1) are not passed through. The secret here is that the USG terminal driver doesn't have a "RAW" mode. It permits you to independently select: 7-bit(+parity) vs. 8-bit characters stripping characters down to 7 bits DC3/DC1 flow control so one can have an 8-bit data path on input and still have DC3/DC1 flow control. > My main objection to DC3/DC1 flow control is that it is a negative > acknowledgement scheme and certain brain-damaged terminals such as the > DEC VT100 contain insufficient buffering to allow them to operate at > high speed, especially when using smooth-scroll (which is too slow in > the VT100). The problem is worse if the terminal driver attempts to > use silo alarms rather than taking interrupts immediately upon receipt > of incoming characters. UNIX has problems with the VT100, but do the DEC operating systems? One difference between UNIX and the DEC RSX family OSes (including VMS) is that UNIX services interrupts entirely at interrupt priority level, while the DEC OSes do as little as possible at interrupt level and drop down to a lower level (although still higher than normal program level) for most of their processing. If the disk driver, or terminal driver, or whatever driver interrupt service routine takes a significant amount of time to finish, in UNIX that means the DC3 may not be seen by the host until the other ISR finishes, which may be too late; this is less likely to happen on other OSes. The silo alarm level should be set adaptively, so that if little traffic comes in it's set to zero so an interrupt occurs as soon as the character comes in. The V7 DH11 driver did this, but for some reason that stuff wasn't in 4.xBSD. It's trivial to put back - I did it here, but we still saw problems at 19200 baud with VT100s. Either the level wasn't getting set right, or that wasn't the problem - we did some profiling and found the system spent a fair bit of time at priority level "5" (I put "5" in quotes because on a VAX, "spl5()" sets it to a level which isn't really 5. The names of the "spl" routines are historical dregs.), most of it in the disk driver ISR. Yes, DC3/DC1 is a negative acknowledgment scheme - but a scheme requiring positive acknowledgments wouldn't have been backwards-compatible with terminals which didn't know about it. DEC (and other OS implementors) probably chose it for that reason; a terminal which didn't do flow control would still work, and a terminal which did would work. Furthermore, a user can also use ^S and ^Q to control the flow of output from the terminal (remember, RT-11 doesn't even have general multi-tasking, much less pipes, much less "pg" or "more"). Yes, the VT100 has less buffering than it should - but if the computer can stop in time (which it might do with other OSes), what's the problem? Whether smooth scroll is "too slow" is a matter of opinion; I prefer the C. Itoh CIT-101 double-speed scroll, but I can happily live with my VT100's smooth scroll. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
smk@axiom.UUCP (Steven M. Kramer) (07/10/84)
You don't really need to hack XON/XOFF into the RAW mode code. You
simply turn on CBREAK and a few modes like LITOUT to get full raw
mode except for the action of a BREAK key. A BREAK in RAW is a NULL
and elsewhere it is a interrupt char. (This works on 4BSD, I don't
know about the thrilling USG type software.)
--
--steve kramer
{allegra,genrad,ihnp4,utzoo,philabs,uw-beaver}!linus!axiom!smk (UUCP)
linus!axiom!smk@mitre-bedford (MIL)