Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: notesfiles - hp 1.2 08/01/83; site hp-pcd.UUCP Path: utzoo!linus!philabs!cmcl2!seismo!lll-crg!dual!qantel!hplabs!hp-pcd!john From: john@hp-pcd.UUCP (john) Newsgroups: net.micro.pc Subject: Re: Does DOS listen to LaserJets? Message-ID: <13600015@hp-pcd.UUCP> Date: Sat, 10-Aug-85 13:50:00 EDT Article-I.D.: hp-pcd.13600015 Posted: Sat Aug 10 13:50:00 1985 Date-Received: Wed, 14-Aug-85 22:27:46 EDT References: <596@alberta.UUCP> Organization: Hewlett-Packard - Corvallis, OR Lines: 28 Nf-ID: #R:alberta:-59600:hp-pcd:13600015:000:1230 Nf-From: hp-pcd!john Aug 10 09:50:00 1985 <<< <> Since even PC's have 'reaction time', a few chars are sent before DTR is <> noticed <> < < Something is very strange in your printer driver. The DTR should work < "instantly" in a normal driver. The DTR signal should be tested immediately < before attempting to send a character. The driver will loop until the < printer is ready for a new character. < 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. Many UARTS avoid this problem by providing a hardware holdoff input pin (normally the CTS* input). These UARTs would test the pin before sending a start bit and in the above case would pause before sending character N+2. Character N+1 would be stored in the receiver's input buffer until read so nothing would be lost. John Eaton !hplabs!hp-pcd!john