Hello list,
The recent thread on freedos-user reminded me that my debugger [1] (and
also the serial comms test application I wrote prior [2]) has an IRQ
handler for serial port communications [3] that doesn't allow sharing
the IRQ with other handlers -- at least, not any installed before it.
(In lDebugX this handler is still purely a Real/Virtual 86 Mode handler,
which I have found can interact with DPMI running in Protected Mode in
tricky ways. That is beyond the scope of my question however.)
The question is, how should I modify the handler to support sharing the
IRQ? Is it enough to simply always chain to the "downlink" [4] after
processing of my interrupt source is done? For reference, this is what
happens (at least once each call) to determine whether to process an
interrupt in my handler:
in al, dx ; (read IIR) get interrupt cause
test al, 1 ; did the UART generate the int?
jnz ih_sep ; no, then it's somebody else's problem
The ih_sep label a few lines down from that restores registers from the
stack and then, as yet, does an iret.
The PS/2 and PC BIOS Interface Technical Reference [5], which is the
original source for the IISP [6] as referenced by INTSHARE.DOC [4], has
this to say about IRQ sharing (on page "4-5", page 166 of the PDF file):
> When the system acknowledges an interrupt request, each interrupt
handler must determine whether it is the appropriate interrupt handler
for the adapter presenting the interrupt request. This is accomplished
by the handler reading the contents of the interrupt status register of
the adapter.
>
> If the handler's device caused the interrupt, the handler must
service the interrupt, reset the interrupt status bit, clear the
interrupts, issue a non-specific EOI to the interrupt controller, then
execute an IRET.
>
> If the handler's device did not cause the interrupt, the handler
passes control to the next interrupt handler in the chain using the
previously stored forward pointer.
This suggests I should chain to the downlink *iff* I detect that no
interrupt was caused by my interrupt source, ie, that the "jnz ih_sep"
branch is taken immediately on the very first check of the UART's IIR.
If however the IIR indicates at least one interrupt was caused by the
UART then after processing all the UART interrupts I should *not* chain
to the downlink and return with an iret instead.
Is this what current practice suggests, too, or is it possibly just an
artefact of this Technical Reference that is not followed commonly?
A related question is how to handle EOI. Currently I issue an EOI to
either the primary PIC or both the secondary then primary PIC at the
beginning of my interrupt handler, depending on which IRQ the handler is
installed for. Should this stay as it is?
The Technical Reference (on page "4-9", PDF page 170) indicates that,
when not "servicing" the interrupt for my interrupt source, I should
check the EOI flag of the IISP header *in* the interrupt handler itself
to determine whether to issue the EOI and iret, or else chain to the
downlink. Does anyone actually do it this way?
Regards,
ecm
[1]: https://pushbx.org/ecm/web/#projects-ldebug
[2]: https://hg.pushbx.org/ecm/serialp/
[3]:
https://hg.pushbx.org/ecm/ldebug/file/c2d96de77120/source/serialp.asm#l22
[4]: https://pushbx.org/ecm/test/20211110/intshare/INTSHARE.DOC
[5]:
https://pushbx.org/ecm/test/20211110/bitsavers.trailing-edge.com%252Fpdf%252Fibm%252Fpc%252Fps2%252FPS2_and_PC_BIOS_Interface_Technical_Reference_Apr87.pdf
[6]: https://pushbx.org/ecm/doc/tsr/keephook.htm#long-workaround
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
