paul@aucs.UUCP (06/11/87)
I am having difficulty in getting an interrupt driven parallel printer
driver to work (the way I think it should). I've done all the necessary
initialization and changing of interrupt vectors, but when a character is
output (via the output/strobe toggle sequence, no interrupt occurs to
indicate that the printer is ready to accept another character. The
only time the interrupt routine seems to get called is when I take the
printer off/on line, which is useless for the most part. I want to
avoid polling the printer as much as possible.
The XT Technical Reference Manual says that an interrupt occurs when
pin 10 (busy) transitions high to low. As far as my understanding
of a parallel printer adapter, this should happen after every character
is output. I have written an interrupt driven routine for a QX-10 and
it worked as I would suspect.
I could go into more details, but I leave it as is for now. If anybody
has any information about using interrupts with the parallel printer
adapter, please drop me a line. I'll summarize for the net if I get
enough responses.
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-2201x587markg@amdcad.AMD.COM (Mark Gorlinsky) (06/15/87)
In article <371@aucs.UUCP> paul@aucs.UUCP (Paul Steele) writes: >I am having difficulty in getting an interrupt driven parallel printer >driver to work (the way I think it should). I've done all the necessary > >The XT Technical Reference Manual says that an interrupt occurs when >pin 10 (busy) transitions high to low. As far as my understanding >of a parallel printer adapter, this should happen after every character >is output. I have written an interrupt driven routine for a QX-10 and >it worked as I would suspect. > >Paul H. Steele UUCP: {seismo|watmath|utai|garfield}!dalcs!aucs!Paul Your problem lies not with you, but with the basic hardware flaws of the IBM PC. It is impossible to generate a true interrupt driven parallel port. This is because the ACK signal coming back from the printer is tied directly to the interrupt controller. Unfortunately the timing of this signal, as defined for standard centronics interface, is too fast to be acknowledge by the controller! It is uncanny how one simple flip-flop inserted between the signal and the controller could have eliminated the problem. BTW, all clones out there never bothered to correct the problem, they just copied IBM line for line. -- Mark Gorlinsky - AMD Processor Products Division/APPS SQA UUCP: {ucbvax,decwrl,allegra}!amdcad!markg or amdcad!phil@decwrl.dec.com AT&T: (408) 982-7811 DISCLAIMER: What's mine is mine, not my employers.