Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84; site faron.UUCP Path: utzoo!linus!faron!kbb From: kbb@faron.UUCP (Kenneth B. Bass) Newsgroups: net.micro.pc Subject: Re: Does DOS listen to LaserJets? Message-ID: <326@faron.UUCP> Date: Wed, 14-Aug-85 10:43:50 EDT Article-I.D.: faron.326 Posted: Wed Aug 14 10:43:50 1985 Date-Received: Thu, 15-Aug-85 22:12:44 EDT References: <596@alberta.UUCP> <13600015@hp-pcd.UUCP> Reply-To: kbb@faron.UUCP (Kenneth B. Bass) Organization: The MITRE Coporation, Bedford, MA Lines: 23 Summary: In article <13600015@hp-pcd.UUCP> john@hp-pcd.UUCP (john) writes: > This must be a case of software inertia in action. Actually I think the "few >chars" that are sent is caused by using a double buffered UART with software >testing of the DTR status. When a printer receives character # N that fills >its buffer it then signals DTR that it is full. But by the time this happens >the CPU's UART has already started shipping out character N+1 and the CPU >has reloaded the UART with character N+2. The CPU will not see the new DTR >status until it is ready to send character N+3. >John Eaton >!hplabs!hp-pcd!john This is a problem I've encountered practically every time I've had to interface any two serial devices. That is, the problem of flow control. There does not exist (to my knowledge) any explicit standard that puts a maximum on the number of characters a device must be able to receive after it signals the transmitter to stop (and vice-versa). I worked with a microcomputer development system once that would send out up to 80 chars. after receiving an XOFF; the modem that it was connected to apparently couldn't handle more than 2 chars. after sending the XOFF. "It ain't necessarily so" linus!faron!kbb