vm86 interrupt handling

[Ozguxxx]

hi, Ive checked some previous threads but I could not find much information about this. What is your approach while handling vm86 software interrupts? IA32 vol.3 chapter 16 tells a lot but I think it is much detailed, vme bit, cr4 register, etc., what is the real usage of this 8086 interrupt emulation other than running some of old 8086 programs and having access to bios interrupts?

[Curufir]

...what is the real usage of this 8086 interrupt emulation other than running some of old 8086 programs and having access to bios interrupts?

Nothing. It was designed specifically for backwards compatibility, a goal which it accomplishes. What else are you expecting it to do?

[Ozguxxx]

I cannot expect anything that Im not aware of, can I? Im trying to learn if it has any usage, if I had known its usage I wouldnt be asking here, rather Id be writing some code to finish this world.

Im serious, some gurus might have implemented vm86 tasks for accomplishing things -like video stuff- that I am currently not aware of and that could make other things easier, I wanted to know if there is anybody who did it. Thanx.

Note: Im watching x-files while writing this, no offense.

[aladdin]

vm86 allow you to use bios ints, so you can use video interrupts without having to write a sp?cific driver for your video card. all what you have to do is to switch to vm86 switch video mode, then return back to pmode...

[Ozguxxx]

I know bios ints are available in vm86 mode my problem is intel manuals, you cannot simply call int 13h (Im not sure about int number) becuase the interrupts are intercepted by monitor. Intel manual gives 6 ways to handle software ints in vm86 mode depending on cr4 register and etc., Im curious if anything of this kind is really needed. But thanks for your advice Ill really try it for changing my video mode.

[Pype.Clicker]

the 'traditionnal' (i386-compatible) way of doing this is to catch the GPF, identify the 'INT nn' opcode, lookup the value of 'nn' in the instruction stream and fake the behaviour of INT nn by redirecting CS:IP to the IVT-stored address after placing the current CS:IP on the V86 SS:SP ...

Now, if you enable the correct bits in CR4 after checking they were active in CPUID, etc. you can have the CPU knowing that INT 10h *can* be called in V86 by just setting the proper bit in the interrupt map

[Ozguxxx]

So to resolve the interrupt, I have to trace the vm86 code in gpf handler. btw, thanx for explanation.

[Pype.Clicker]

np. If you get a look at the VM86 page in the FAQ (http://www.osdev.org/osfaq2/), you'll find a pointer towards Tim's tutorial which explain such issues in details with a reference GPF handler, iirc.