
Toward using the BIOS from protected mode.

Here's the plan. Grab all ints with a regular 32 bit IDT. Insert a second
table, the I.I.T., Interrupt Indirection Table, between the 32 bit ints
and a single int caller routine. The descriptors of the IDT invoke code in
the I.I.T. on an int occurance. All the I.I.T. entries are just CALLs to
the one int handler, INTCALLER. There's 256 I.I.T. entries. Each I.I.T.
entry has a unique call offset, since they all CALL the same routine from
thier own unique but sequentially tabular location. The return value is
EIP, which is the physical address of the next I.I.T. table entry.
INTCALLER figures out which int called it by popping the return address of
the I.I.T. call. That POP in effect converts the I.I.T. calls to branches.
The I.I.T. calls don't return. SO, from an int, we get to INTCALLER
knowing what int we are, and with a 32 bit IRET stack frame pending, which
will return us to where we originally came from. If we get to INTCALLER
that means we successfully built a matching IDT and I.I.T. that point at
INTCALLER.

All the above works.

Now INTCALLER has to perform the int code. Currently it just increments a
character cell in the VGA text buffer, drops the int error code if there
was one, and IRETs. I was trying to stay IN pmode. Heh. Some other time.
Fortunately, the crux of the biscuit is, we get to INTCALLER from pmode,
with ints disabled, so we can do what we want and protection isn't
broken, as far as I can see.

So what INTCALLER is hoped to do at this writing is switch to real address
mode, far call (indirect) the int with a hand-pushed FLAGS for the BIOS
IRET, switch back, and do the still-pending pmode IRET. In order to handle
ints as per normal we have to be a bit clever about register state. We
want to preserve the state of the basic registers on int entry, and then a
bit later replicate that register state when we LCALL the BIOS.

This stuff is small. Building tables of code isn't much code. This is also
easily overridable on a per-int basis; just clobber the pertinent IDT
entry and that int is your problem. 

aug 2000  Rick Hohensee
