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