On 22/11/2024 05:52, David Schwab via Freedos-devel wrote:
I'm working my way through Norton's Advanced Assembly Language, and in one section he shows how to the find interrupt vector for the BIOS keyboard service (int 9). I've found the vector and unassembled it (being sure to use little endian), but that doesn't look like an interrupt to me: for one thing, it doesn't begin with STI.
I thought interrupt handlers generally didn't have STI opcodes in them at all. But it does seem that the original IBM PC does this. Either way, most BIOSes don't do this. The PC/AT *kinda* does this but it seems that 1. MS-DOS installs some kind of hook to wrap around it, and 2. the BIOS itself does a JMP which *then* leads to an STI opcode. (I'm using 86Box for testing here, it takes up a lot less physical space than actual hardware.)

The reason for doing this is to allow a higher-priority interrupt to, well, interrupt a lower-priority interrupt. A bizarre thing about this practice is it's even done for IRQ0 despite the only higher-priority interrupt being the non-maskable interrupt which is, well, not maskable.

By the way, are you obtaining the interrupt vector via the IVT at segment 0000, or via INT 21h AH=35h? You should be doing the latter - probing the IVT directly will not work if you have something which remaps the PIC interrupts for the benefit of protected mode stuff. (21h/35h = get vector, 21h/25h = set vector) Furthermore, the vector number you use should be as if the PIC interrupts are not remapped from what the BIOS provides, so you still provide interrupt numbers 08h through 0Fh and 70h through 77h.


Am I looking in the right place?

Sent with Proton Mail <https://proton.me/mail/home> secure email.


_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel
_______________________________________________
Freedos-devel mailing list
Freedos-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/freedos-devel

Reply via email to