I tried to contact Emm - the parallel.device author directly. I sent him a privmsg on #morphos few times and tried to get in touch with him by email. However without any success, so I gave up - I was a little bit busy and didn't have time to prepare whole bug report. That was my fault - next time I will simply sent a mail to morphos ml or here on MorphZone.
The bug in parallel.device concerns reset bit in control register. Now I got a few hours of spare time so I prepared more detailed report.
To prove that the bug is there it I wrote a simple tool - lpt_reset, which shows, sets and clears reset line directly by polling the hardware registers. It is available (with source) here: http://march.w.staszic.waw.pl/lpt_reset.lha
I checked my lpt_reset tool with StarLC100 printer and doing "lpt_reset set" then "lpt_reset clear" in fact causes the printer reset (printer flashes its leds and moves the carriage to the init possition) so the tool works.
Next lines are the output from a shell window:
8.Work:Dev/ParFix/lpt_reset> lpt_reset
LPT status register: 0x0d - reset line inactive
8.Work:Dev/ParFix/lpt_reset> echo "test" >par:
8.Work:Dev/ParFix/lpt_reset> lpt_reset
LPT status register: 0x00 - reset line active
As you can see, the reset line after the system start (first line) is inactive. However, sending a few characters directly to printer makes this line active, which shouldn't happen! This causes all the problems with printing. Printer gets reset signal before it even manages to print any character.
Marek Szyprowski ...... happy MorphOS, AmigaOS and Debian/Linux user ........