Re: [PARPORT] simulating a printer


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