paul@aucs.UUCP (06/16/87)
Thanks to everyone who replied to my request about setting up an interrupt
driven parallel printer routine. It seems that there is a design flaw in
many PC's that does not allow such a routine to function properly. Dave
Gilman gave a work around solution, but I preferred Ralf.Brown's suggestion.
My version now works without problems, and it does not seem to degrade PC
performance. Here's the summary.
Paul H. Steele UUCP: {seismo|watmath|utai|garfield}!dalcs!aucs!Paul
Acadia University BITNET: {Paul|phs}@Acadia
Wolfville, NS Internet: {Paul|phs}%Acadia.BITNET@WISCVM.WISC.EDU
CANADA B0P 1X0 PHONEnet: (902) 542-2201x587
****************************************************************************
From: David Fiander <dalcs!watmath!djfiander>
I wrote a parallel printer interrupt driver as well.
The strange thing was that it worked perfectly on our AT-clone
at the office, but it failed exactly the same way yours does on the PC-clone.
Could you send me copies of any usefull information you get regarding the
problem?
Thanks.
-----------------------------------------------------------------------------
From: dalcs!seismo!b.gp.cs.cmu.edu!Ralf.Brown
While I don't know about other parallel ports, I do know that there is a
design fault in the IBM MDA/Printer Adapter card. The interrupt signal is
not latched! Since the CPU only checks for interrupts at the end of each
instruction, the printer's ACK could be as short at 1/2 microsecond, and an
8088 instruction can take up to 43 microseconds to execute (IDIV), it is
quite unlikely that the interrupt will be caught.
When I wrote my first print spooler, I totally ignored the printer interrupt.
Instead, I sped up the clock tick by a factor of 32 (only passing through
every 32nd tick), and on each tick checked the status port--if ready, I sent
a single character to the printer.
----------------------------------------------------------------------------
From: <dalcs!seismo!ihnp4!drutx!rrg>
I wrote an interrupt-driven driver for my Corona PC clone, and the problem
I had was that the interrupt was driven off of ACK, not BUSY. It seems
IBM forgot a second inverter in the design of the parallel port. The ACK
signal only stays up for about 3 microseconds, so it is usually missed by
the Intel interrupt controller. My solution was to swap the BUSY and ACK
leads in the cable, and write a replacement for the status entry to BIOS to
swap the status bits back to the normal place in the response. The interrupt
now occurs on ~BUSY, just what you really want. Check out the hardware
diagram in your Tech Ref manual.
-Bob Gilman
AT&T-IS
ihnp4!drutx!rrg