Package: kernel-image-2.6.8-1-386_2.6.8-3.1_i386.deb
Version: NA
I'm using a 23-year-old NEC 3530 Spinwriter printer with a parallel port
interface (most of them were serial, which work OK with Linux). It
works fine with kernel version 2.2.20. For kernel 2.4.26, if I type:
cat "This is a test" > /dev/lp0, it prints "his is a testt". In other
words the first strobe somehow misses the 1st byte but gets the second
byte. For my 2.6 kernel version, at first I couldn't get it to print at
all. But then I gave the option dma=none, etc. to the parport_pc module
and then it would erratically print about half of what cat sent to the
printer. Sometimes it would do no more than a linefeed.
What I think is happening is that the parport_pc driver is sending too
fast for the printer. The driver may not be doing handshaking right.
My PC parallel port is a fast ECP one, but the printer parallel port it
connects to is just a 23-year-old Centronics: SPP. So the driver should
wait for ACK after each byte before sending the next byte. Does it? My
printer manual shows the protocol and timings expected. It shows about
10 us between the start of adjacent bytes. Since the printer takes
20,000 us to print a character (50 chars/sec.) the 10 us spacing is
2,000 times faster than needed. My timing diagram show the next byte
being sent to the printer about 1us after the end of the ACK pulse.
The timing diagram also shows that BUSY is not asserted until the
512 bytes printer buffer is almost full. It doen't get asserted when
recieving a byte as was claimed by someone on the Internet.
There was no problem with using an old NEC serial printer since one just
sets the serial speed for 600 baud. But I can't use it anymore since it
broke. Since the serial driver works OK for old serial ports, shouldn't
the parallel port driver do likewise?
David Lawyer
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
