gwyn@Brl@sri-unix (09/07/82)
From: Doug Gwyn <gwyn@Brl> Date: 4 Sep 82 22:50:57-EDT (Sat) VT100s absolutely MUST have DC3/DC1 (^S/^Q) reserved for their use in flow control. They generate these automatically, sometimes when you might be surprised that they have to slow down the incoming data. There are many other terminals with this same requirement. By the way, all Digital Engineering VT640 Retro-Graphics users should be aware that early firmware (pre-1.4, I think) would lose count of the DC3s and fail to send an DC1, sooner or later, thereby locking the terminal. A new microcode ROM fixes this glitch.
lee@Utexas-11@sri-unix (09/08/82)
From: Bill Lee <lee@Utexas-11> Date: 7 Sep 1982 at 1209-CDT Au contraire. What you should have said is that VT100s really like to have DC3/DC1 (^S/^Q) reserved for their use in flow control, since they tend to lose if they don't. However, I am using a screen editor with a VT100 with the DC3/DC1 flow control turned off and it works fine. This is on a System 3 Vax 780 (relatively unloaded) at 9600 baud. The main trick appears to not try to scroll (and especially don't try to smooth scroll) with the DC3/DC1 turned off. For a screen editor that doesn't scroll (which is where you probably want to use ^S anyway) the VT100 works fine without ^S/^Q reserved for flow control. p.s. VT100s are such losers that no one in their right mind would buy one anyhow. They are unforgiveably slow and almost as dumb as an ADM3A. The keyboard is one of the worst I have ever used. For the kind of money that DEC charges for VT100s you can buy many other terminals that do a much better job. p.p.s. If you disagree strongly with any of the above, please disregard. The last thing I want is to start a raging ^S/^Q or VT100 debate (at least until the chown, sizeof/alignment, \r versus \n, et. al. arguments die down a bit). -------
bob (09/09/82)
As a new subscriber, I didn't get the first article re Emacs and VT100's. However, I thought I might as well add my two bits worth anyway: Whenever you type a ^S on the VT100, the silly beast thinks "ahah, I've sent an XOFF, so therefore I never need bother send another until I send an XON, because, of course, the host wouldn't DARE to send any characters to me until then...". Now this works fine if the host really does stop sending characters upon receipt of the ^S. When you're in Emacs, however, flow control is not used--the driver pads wherever necessary with NUL's, and ^S is typically bound to some function, like search-forward. What all of this amounts to is that if you use a ^S command within an emacs session, and don't use a subsequent ^Q command, then output generated after you leave Emacs will be garbled (at 9600 baud, anyway). Obviously, this is a bug in the VT100--a trivial fix is for the VT100 to not set the "^S sent" flag when the user types it, but only when it is sent for flow-control reasons. One silly little fix you can use is to bind the two exit functions (pause-emacs and exit-emacs) to two two-character sequences beginning with ^Q. What can I say, it works!
chris.umcp-cs@Udel-Relay@sri-unix (09/11/82)
From: Chris Torek <chris.umcp-cs@Udel-Relay> Date: 8 Sep 82 18:56:56-EDT (Wed) VT100s and their look-alikes are all very slow terminals. They cannot even write text onto the screen at 19200 baud. Therefore they tend to send lots of ^S/^Qs. However, they have a handy "feature": nulls are not put into the FIFO; they are ignored as soon as they come in through the serial line. This means that a carefully written driver for Emacs can prevent the terminal from sending ^S/^Q by writing enough nulls after any operation to let the operation finish. The standard Gosling Emacs has a driver for VT100s that works fine for up to 9600 baud, and uses the special features of the terminal pretty well. I modified ours in an attempt to make it work with 19200 baud but as it turns out this was pointless. The Vax doesn't respond fast enough to the ^S from the terminal and the FIFO will overflow even if you're just printing lots of text. (Now we have an Emacs driver that works at 19200 baud on terminals that don't work at 19200 baud!) Anyway, the point of this whole letter is that you just have to write lots of padding to VT100s at 9600 baud if you want to prevent ^S/^Qs.
gwyn@Brl@sri-unix (09/12/82)
From: Doug Gwyn <gwyn@Brl> Date: 9 Sep 82 20:51:45-EDT (Thu) Probably the VAX isn't responding fast enough to the ^S because of using a silo polling technique on the DZ11 rather than character interrupts. I explained in an earlier Unix-Wizards note several reasons to not use the silo alarm + polling method in the dz driver; add this reason to the list.