[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference 7.286::atarist

Title:	Atari ST, TT, & Falcon
Notice:	Please read note 1.0 and its replies before posting!
Moderator:	FUNYET::ANDERSON

Created:	Mon Apr 04 1988
Last Modified:	Tue May 06 1997
Last Successful Update:	Fri Jun 06 1997
Number of topics:	1433
Total number of notes:	10312

686.0. "printer timing?" by LEVERS::LANDRY () Wed Nov 29 1989 08:36

	Anybody know the timing requirements for the Centronics parallel
	printer interface?  I'm thinking about building a printer
	buffer so I'll need this info.  There's a timing diagram in
	the back of my Star SG-10 manual but it doesn't make any sense.
	
	thanks
	chris

T.R Title User Personal
Name Date Lines

686.1 It goes like this PRNSYS::LOMICKAJ Jeffrey A. Lomicka Wed Nov 29 1989 11:48 24

T.R	Title	User	Personal Name	Date	Lines
686.1	It goes like this	PRNSYS::LOMICKAJ	Jeffrey A. Lomicka	`Wed Nov 29 1989 11:48`	24
	I dn't recall who is active low, and who is active high, but the timing (set-up, hold, etc.) is pretty forgiving. 1. Computer checks for printer busy, and waits for busy to deassert if necessary. 2. Computer asserts data on d<7:0> 3. Computer asserts strobe 4. Printer uses the strobe to latch the data, and responds by asserting busy. 5. Computer may deassert strobe after seeing busy asserted, or it may wait until busy is deasserted, I don't recall which. I would build the printer buffer to not care which. Since, on the computer side, all of these transitions are controlled by software, you can count on multiple microseconds of stable data after each strobe. The data may actually be there much longer, but I wouldn't build the buffer to count on that. Don't deassert busy if the buffer is full.

I dn't recall who is active low, and who is active high, but the timing
(set-up, hold, etc.) is pretty forgiving.


1. Computer checks for printer busy, and waits for busy to deassert if
necessary.

2. Computer asserts data on d<7:0>

3. Computer asserts strobe

4. Printer uses the strobe to latch the data, and responds by
   asserting busy.

5. Computer may deassert strobe after seeing busy asserted, or it may
wait until busy is deasserted, I don't recall which.  I would build the
printer buffer to not care which.

Since, on the computer side, all of these transitions are controlled by
software, you can count on multiple microseconds of stable data after
each strobe.  The data may actually be there much longer, but I wouldn't
build the buffer to count on that.

Don't deassert busy if the buffer is full.