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