Page 1 of 1

int86 implementation

Posted: Wed Mar 03, 2010 5:38 pm
by jasonc122
hi,

I'm unsure of how to go about implementing an int86-like function as found in dos.h. I need to execute video interrupt in real mode and would like guidance on how to implement such a function (code would be nice :shock: )

Thanks

Re: int86 implementation

Posted: Wed Mar 03, 2010 6:00 pm
by Love4Boobies
Code would be nice but you can't have any because you won't learn anything. That function just loads a bunch of registers from parameters and executes an INT. It's basica assembly. If you can't code it yourself you should probably learn a bit more before taking on OSDev'ing.

Re: int86 implementation

Posted: Wed Mar 03, 2010 6:27 pm
by jasonc122
=D> Very helpful

Instead of making me reinvent the wheel please just post the code.

Re: int86 implementation

Posted: Wed Mar 03, 2010 6:28 pm
by pcmattman
An int86 function changes in complexity depending on if you run in protected mode or not. From your post it sounds like real mode, which means the int86 function is quite elementary to write (as Love4Boobies has already stated).

Re: int86 implementation

Posted: Wed Mar 03, 2010 6:37 pm
by jasonc122
I'm running in protected mode and need to run an INT in real mode. What's the easiest way to add a 16 bit code thunk (which will include the 16 bit INT instruction) to 32 bit elf? Failing that just please post the code - I'll learn much faster from that

Re: int86 implementation

Posted: Wed Mar 03, 2010 6:40 pm
by pcmattman
You probably need to actually drop back to real mode and then run the interrupt, and return to protected mode when done.

The alternative is to write a virtual 8086 mode monitor.

Re: int86 implementation

Posted: Thu Mar 04, 2010 2:58 am
by thepowersgang
Please stop asking us to post the code, trust me, just blindly copy-and-pasting code will cause no end to hell for you down the line, and you generally don't learn from it.

As pcmattman said, in protected mode you cannot just directly call a BIOS interrupt, instead you either need to drop back to real mode (normally not a good idea) or implement VM8086.

Just out of curiosity, why do you need to call a BIOS int, because unless it's for setting the video mode, it's usually easier to write your own driver for the device, and use that. Calling the BIOS from PMode is ... difficult.

Re: int86 implementation

Posted: Thu Mar 04, 2010 5:27 am
by ~
jasonc122 wrote:I'm running in protected mode and need to run an INT in real mode. What's the easiest way to add a 16 bit code thunk (which will include the 16 bit INT instruction) to 32 bit elf? Failing that just please post the code - I'll learn much faster from that
You could use x86emu (cached here).

Also, you can easily run INT services if you are in real mode, even from the DOS command line, you can see a sample here, just look for the "CPU/opcodes" and "CPU/regs" folders.

Re: int86 implementation

Posted: Thu Mar 04, 2010 9:21 am
by Creature
Because of the way you keep asking for code, I doubt a lot of people will give you it.

Anyway, what you're looking for is inside the Intel docs (drop PMode -> RMode, the opposite and the stages in between (16-bit PMode?)). As already was said, the alternative is to implement VM8086. The only thing that might be of help when doing the first is that an easy way to execute 16-bit code is (assuming your OS is running in 32-bit protected mode) to write a flat binary program that you can jump to or call that goes back and forth.

Re: int86 implementation

Posted: Fri Mar 05, 2010 12:40 pm
by Love4Boobies
It sounds to me like he's in real mode (dos.h).
thepowersgang wrote:Just out of curiosity, why do you need to call a BIOS int, because unless it's for setting the video mode, it's usually easier to write your own driver for the device, and use that. Calling the BIOS from PMode is ... difficult.
It's not difficult, it's just slow, non-re-entrant (which in the end adds to the slowness) and it doesn't provide as many features as a device driver.

I also think the OP has stopped reading the thread.