Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!mnetor!seismo!rutgers!ames!ucbcad!ucbvax!LF-SERVER-2.BBN.COM!jr From: jr@LF-SERVER-2.BBN.COM (John Robinson) Newsgroups: comp.emacs Subject: Re: 9600 baud problems (was Re: when using termcap, get it right!) Message-ID: <8707061522.AA07395@ucbvax.Berkeley.EDU> Date: Mon, 6-Jul-87 11:22:59 EDT Article-I.D.: ucbvax.8707061522.AA07395 Posted: Mon Jul 6 11:22:59 1987 Date-Received: Tue, 7-Jul-87 04:41:13 EDT References: <1373@bobkat.UUCP> Sender: daemon@ucbvax.BERKELEY.EDU Distribution: world Organization: The ARPA Internet Lines: 29 >> One problem that no one has pointed out is that the EIA-232-D >> definition does not have any hardware flow control defined. I don't know about 232D (which is less than a year), but 232C does talk about half-duplex operation, as I remember. Here it is mandatory to watch the request-to-send/clear-to-send protocol, so that the two modems can coordinate their sending and receiving. The modems, for their part, have to turn their carriers on and off in response to what the computers/terminals do. Hardware flow-control can be based loosely on this model (Await CTS when you want to send; don't assert DTR [or else RTS] when you don't want to receive). Most UART chips can be wired so that they won't send unless they see CTS, providing the send direction automatically. When it works, hardware flow control is nice. It is faster (the terminal has to do some work to throw away all that padding - in fact, the VT101 works so hard that NO amount of padding is enough at 9600 baud) and it is not affected by termianl modes - it just keeps going even in raw mode. However, because they associate the control leads with half-duplex, most modems can't pass their value transparently to the other end, so hardware flow-control won't work over modems. I wonder if anyone has ever made an intensely interactive application like emacs work over a half-duplex line! /jr jr@bbn.com or jr@bbnccv.uucp Without life, there wouldn't be chemical companies.