From: utzoo!decvax!harpo!seismo!hao!hplabs!sri-unix!chris.umcp-cs@UDel-Relay Newsgroups: net.unix-wizards Title: Padding on Ann Arbor Ambassadors &c Article-I.D.: sri-unix.4922 Posted: Sat Dec 25 07:06:58 1982 Received: Mon Dec 27 03:09:21 1982 From: Chris Torek Date: 22 Dec 82 22:29:17 EST (Wed) 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).