lairdb@crash.cts.com (Laird Broadfield) (01/04/91)
madams@somewhere-or-other writes: ><uV5wu2w163w@ozonebbs.UUCP> steven@ozonebbs.UUCP (Steven Rubin) writes: >>$I don't know if this is the "correct" way to do a spooler, but The way I do >>$it would be something like this >>$1) Capture int 1Ch. >>$2) Every clock tick, print x amount of characters from the file >>$3) return control to the other program. > ><1990Dec30.160422.27898@xrtll.uucp> silver@xrtll.UUCP (Hi Ho Silver) writes: >> Well, there isn't a "right" way and a "wrong" way; there are ways which >>don't work, and there are ways which do work with varying degrees of >>efficiency. >> >> A more efficient, though slightly more difficult, way might be to set >>up the printer port to interrupt the CPU whenever it's ready for another >>character. ... see int 0Fh. > >Silver: > Good posting! I liked what you had to say, but my DOS reference >guide seems to think that int 0Fh should be AVOIDED! > >"On the PC, int 0Fh was assigned to the printer controller to >detect printer errors and print completion. Programmers typically >do not use it because many controllers DO NOT generate it RELIABLY. >Generaly, you can ignore this interrupt. The IRQ7 request can also >be generated as a default by the 8259 Priority Interupt Controller, >if the controller is unable to determin which device requested service. >Thus, it is NEVER SAFE to assume that an interrupt reaching this >handler was originated by the Printer; it could originate anywhere." "Silver" writes: >It is true that the 8259A interrupt controller will generate IRQ7 as its >"default interrupt", but this is a symptom of a failing interrupt system >(e.g., two devices fighting over the same IRQ line). In normal system >operation, default interrupts should not occur. > >It is also true that some clones (e.g., early Olivetti models) do not >correctly implement IRQ7 on their parallel ports. Oh well. IBM machines, >of course, do it right. > >My suggestion is to implement IRQ 7 processing, but also hook the timer >interrupt and, if a long timeout with no "ack" occurs, use the timer >interrupt to restart output. Mainframes do this -- it's referred to as >"missing interrupt processing." also: > Hmm, that sheds new light on the situation :-) Well then, I suppose one >could still use an int 0Fh routine; you'd just have to make sure you checked >the printer port's status every time before trying to send a character (which >would be a Good Thing to do anyway). And perhaps a clock tick hook would >also be useful in case an int 0Fh failed to get through. ----------------------- [sorry if some of the above are out of order, I think most of the sense is there.] As "Silver" remarked, the 8259A will generate a level 7 under some strange conditions. According to the 8259A document (INTEL 231468-002) this only happens when the CPU queries the 8259A (with the /INTA line) when _no_ interrupt line has been triggered. Since the /INTA line is operated by the 80x86 microcode, presumably only in response to the 8259A raising the INTR line, this should only occur if your processor is internally bananas. (See also INTEL 210911-003 "iAPX 86 Programmer's Reference", pp 4-7,8.) Obviously, it's a good idea to check the ready and busy lines anyway (it doesn't cost much.) It _is_ the case that some odder clones don't properly operate IRQ7, as well as some odder add-in cards. Obviously, this is a failure to follow spec, and I've found that 99+% can be depended on to support it. Note though, that printing is a noisy, flaky, thing to do. Hooking the timer interrupt is a _very_ good idea. What I did as a compromise between efficiency and reliability is to hook onto the tick, but only check roughly once a second (keep a counter and mod it by 16, this can be optimized into a mask-and-JNZ.) If the check consists of just checking if your head-pointer has moved since the last time you looked, this also can be accomplished very quickly. -- -- Laird P. Broadfield | Year after year, site after UUCP: {akgua, sdcsvax, nosc}!crash!lairdb | site, and I still can't think INET: lairdb@crash.cts.com | of a funny enough .sig.