Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!bionet!ames!uhccux!munnari.oz.au!murtoa.cs.mu.oz.au!otc!metro!extro!natmlab!ditsyda!evans
From: evans@ditsyda.oz (Bruce Evans)
Newsgroups: comp.os.minix
Subject: Re: patch for kernel/printer.c
Keywords: printer driver
Message-ID: <2177@ditsyda.oz>
Date: 6 Sep 89 17:40:29 GMT
References: <1614@cod.NOSC.MIL>
Reply-To: evans@ditsyda.mq.oz (Bruce Evans)
Organization: CSIRO DIT Sydney, Australia
Lines: 41

In article <1614@cod.NOSC.MIL> hall@cod.NOSC.MIL (Robert R. Hall) writes:
>With  printer driver version 1.3 and the protected mode version, after
>printing 2 pages of a 3 page file the error message 'Printer error'
>would apprear on the screen and the print job would terminate.
>The following patch is what I found neccessary to correct this problem.

I want to sort this out for 1.4b. Mail to Robert has never worked.

I don't see how the 1.3 version can give the error, although I don't
like its approach. Robert changed the error printing routine to print
the exact error status; what was it exactly? The error must be caused
by an invalid combination of the bits in 0xB0. 0x10 means printer-on-line;
it should stay on constantly during printing as far as I know. 0x20 means
not-out-of-paper; it should stay on. 0x80 means printer-ready; it should
oscillate as characters are strobed out, and the software takes account
of this. I suspect 0x10 is dropping out. ROM Bios's usually don't bother
looking at 0x10 or 0x20. This should be equivalent since the external
printer hardware is supposed to drop 0x80 when it is not ready, for
whatever reason. Maybe there is a problem with the cable.

Why does Robert's version work better? It tests the ready status in a
better way, avoiding a fixed delay. This should only affect performance.
More subtly, the possible delay becomes much longer, because more is done
in the delay loop. Finally, the on-line and paper-ready bits are ignored
while the ready bit is low. This probably allows some bad transient to be
ignored. It is a reasonable device interface to not guarantee anything
about the other bits while the "ready" bit is false; however, for the
printer I think the on-line bit has this duty.

Robert's version has a new error. When pcount goes from 1 to 0, the
interrupt handler is exited and a further interrupt is relied on to send
the output-done message. If this interrupt is lost, the message will
never be sent, because pr_restart() doesn't do anything when pcount is 0.
To fix it, I just restored the ugly busy-wait while loop from 1.3.

These problems would be more conveniently solved by ignoring most errors,
like serial drivers do. When the printer is not on line, or runs out of
paper on page 500 of 1000 (make that page 1 of 2 for me :-)), I don't
want printing to be stopped by a minor error.
-- 
Bruce Evans		evans@ditsyda.oz.au