David Campbell (campbell@torque.net)
Sat, 10 Oct 1998 09:31:51 +0800
Date sent:      	Fri, 9 Oct 1998 20:54:24 -0200 (EDT)
From:           	Arnaldo Carvalho de Melo <acme@conectiva.com.br>
To:             	Philip Blundell <philb@gnu.org>
Copies to:      	Andrea Arcangeli <andrea@e-mind.com>, linux-parport@torque.net,
               cavassin@conectiva.com.br
Subject:        	Re: [PARPORT] simulating a printer 
> On Fri, 9 Oct 1998, Philip Blundell wrote:
> 
> > >know if it' s possible to do the reverse printer handshake. To do that you
> > >should hope that the parallel port is able to use ACK and BUSY line as
> > >output and not as an input as usual (sure not using NORMAL-MODE I
> > >think...). I don' t know if it' s possible because I only know how
> > 
> > It's not on most hardware.
> 
> ok, do you know one that allows this? :) 
The following works under Win95:
a) locate three paper clips (beg / borrow / steal)
b) Insert a paper clip between ACK and STROBE (pins 1 and 10 for D25 port)
c) Short BUSY to ground (pin 11 to D25 shell)
d) Short the PAPER OUT(*) to ground (pin 12 to D25 shell)
e) Cross your fingers and read three verses from the parport KHG
f) Send a print job to the parallel port
(*) I think pin 12 is PAPER OUT
Viola! Print job disappears to the great /dev/null in the sky.
If I leave BUSY floating then I get a message saying the printer is busy. If I 
short BUSY and leave PAPER OUT floating then I get a paper out message.
Short both BUSY and PAPER OUT the print job dissappears from the queue.
Andrea, I think we now have some means of testing printer driver speed 
(without testing the printer speed :-)
This proves that the strobe pulse sent by the computer to the printer has the 
correct polarity such that when fed back in the ACK pin it will cause and 
interrupt for every STROBE pulse. The STROBE pulse is often short, 
therefore it is unlikely that a polling driver (kernel or user space) would notice 
the pulse without the aid of interrupts.
AFAIK this is impossible from a user space driver. Perhaps we need an 
ioctl() to catch IRQ pulses where a bit is set when an IRQ occurs the ioctl() 
returns the state of the bit and clears the latch.
Suggested wiring:
src	dir	dest	name
1	out	10	STROBE	to ACK
2	out	2	D0
3	out	3	D1
4	out	4	D2
5	out	5	D3
6	out	6	D4
7	out	7	D5
8	out	8	D6
9	out	9	D7
10	in	1	ACK	to STROBE
11	in	15	BUSY	to FAULT
12	in	16	PAPEROUT	to INIT
13	in	17	SELECT	to SELECT
14	out	??	AUTOLF (do we care?)
15	in	11	FAULT	to BUSY
16	out	12	INIT	to PAPEROUT
17	out	13	SELECT	to SELECT
18 to 25 are ground returns
Comments anyone??
David Campbell
=======================================================
campbell@torque.net
Current project list:
a) Maintain Linux ZIP drivers
b) Create Linux chipset specific parport drivers
c) Start on ParSCSI drivers
Any assistance to clearing this list most welcome
--  To unsubscribe, send mail to: linux-parport-request@torque.net --
--  with the single word "unsubscribe" in the body of the message. --
This archive was generated by hypermail 2.0b3 on Wed 30 Dec 1998 - 10:18:33 EST