info-vax (12/23/82)
>From root.umcp-cs@UDel-Relay Thu Dec 23 14:43:51 1982
Mail-From: ARPANET host SANDIA rcvd at 23-Dec-82 0323-PST
Mail-From: ARPANET site UDEL-RELAY rcvd at 23-Dec-82 0430-MST
Sender: UniVax <root.umcp-cs@UDel-Relay>
To: info-vax@Sandia
Cc: unix-wizards@Sri-Csl
Via: UMCP-CS; 23 Dec 82 1:59-EST
Remailed-Date: 23 Dec 1982 1054-PST
Remailed-From: the tty of Geoffrey S. Goodfellow <Geoff5 at SRI-CSL>
Remailed-To: Info-VAX@SRI-CSL: ;
Now hold on a minute here. We are running Berkeley 4.1 Unix, have
many Ann Arbors connected to DH/DMs, running at 19200 baud, and
they *DO* need padding. Null padding works fine (though I'll admit
I'd rather have an ioctl(fd,TIOCDELAY,millisec) call). I won't
dispute the fact that those nulls go into the input buffer (and
thus could possibly overrun it): it is true. In "monitor mode" you
can see that they are stored.
HOWEVER: they DO have effect. What happens if they are not used is
that the buffer fills up with lots of escape sequences; the buffer
fills up; *NOW* you must wait. But the buffer is full... what can you
do?
Now suppose that they ARE used: you get one escape sequence, it gets
decoded, now the terminal goes off and does it (taking any arbitrary
amount of time); meanwhile, you SEND NULLS. After the AAA finishes
with the escape sequence it looks in its buffer, and races over the
nulls, and NOW you are free to send the next escape sequence. IT
DOESN'T MATTER THAT YOU OVERRAN THE BUFFER! If you are careful you
can indeed get away with this.
According to the timing information that you get with the AAA (what
little there is), you need to give the AAA time that just isn't there
at lower baud rates for such things as insert/delete line. (For the
screen clear you theoretically have to wait over 5 seconds (I think).
In actual use you need from 1/4 to 1 seconds (I think).) In any case
the padding IS necessary >>>at 19200 baud.<<< I didn't try 9600 after
removing the initial Emacs driver bugs . In the end I just rewrote
the driver.
Someone mentioned keeping the terminal out of true raw mode, so that
the 'values>=0200' delay was usable (with an appropriate mod to the
tty driver so you can get them there in the first place). While this
would work on an AA, believe it or not, I've used a terminal where
all those eight bits are necessary. It turns out that [possible bug
in Emacs termcap driver here] if you put \201 in a termcap Emacs
really sends the high bit, and that's what I ended up using. (The
reason I said 'possible bug' is that some terminals might take NUL
as a pad character but not \200, and you use \200 to get intra-
sequence padding in termcap [yes, this is sometimes necessary!], so
Emacs will send \200.)
We had at one time a tty driver (for V6) that could still do output
delays even in raw mode, by using character stuffing to fit the
delay information into the output queue. I think this is a better
solution than \2xx for delays, since it would be nice to be able to
use 8 bits AND delay (say for some strange file transfer program to
a micro, that knows how long the micro takes to write to its disk).info-vax (12/25/82)
>From RWK@SCRC-TENEX@MIT-MC Fri Dec 24 21:25:15 1982
Mail-From: ARPANET host SANDIA rcvd at 24-Dec-82 0801-PST
Mail-From: ARPANET site MIT-MC rcvd at 24-Dec-82 0859-MST
To: chris.umcp-cs@UDEL-RELAY, info-vax@SANDIA
Cc: unix-wizards@SRI-CSL, RWK@SCRC-TENEX@MIT-MC
In-Reply-To: The message of 22 Dec 82 22:29:17 EST (Wed) from Chris Torek <chris.umcp-cs@UDel-Relay>
Remailed-Date: 24 Dec 1982 2103-PST
Remailed-From: the tty of Geoffrey S. Goodfellow <Geoff5 at SRI-CSL>
Remailed-To: Info-VAX@SRI-CSL: ;
I hope all you people going on about using delays instead of padding
remember that delays simply DO NOT WORK over networks. A higher-level
protocol (such as SUPDUP) could be modified to propogate explicit delays,
but this only works if you have control over all the networks involved.
Padding works regardless of any network links.
-------