OSDev.org

Guys, just a question.

I would like to know, I case of anyone knows that....

How do an operating system like " windows, linux " call a real mode int ? like 0x10 for example.

I create a new process with a flags 0x20202L that use a vm flag bit 17 ... <- that stuff works some time... but for now I'm having some problem " crazy one " traying to use 2x times of int 0x10..

first I get if a given screen mode is suported like 1024x768x32 x linear frame buffer... and at second on I change video mode to selected mode if is supported...

but know is the problem.... after executing first int 0x10, my operating disable my keyboard... like freeze keyboard.

and know I would like to know if I'm doing something wrong ....

Using interrupts under protected mode calls the BIOS, which is not possible in protected mode. You can use VM86 extensions to regain access to the BIOS later, but for even more video flexibility, it is also possible to write a proper VGA driver and avoid the BIOS altogether.

Using your only driver is better than BIOS calls.
I think you should better make driver if it's possible.

Hi,

digo_rp wrote:Guys, just a question.

I would like to know, I case of anyone knows that....

How do an operating system like " windows, linux " call a real mode int ? like 0x10 for example.

I create a new process with a flags 0x20202L that use a vm flag bit 17 ... <- that stuff works some time... but for now I'm having some problem " crazy one " traying to use 2x times of int 0x10..

first I get if a given screen mode is suported like 1024x768x32 x linear frame buffer... and at second on I change video mode to selected mode if is supported...

but know is the problem.... after executing first int 0x10, my operating disable my keyboard... like freeze keyboard.

and know I would like to know if I'm doing something wrong ....

It certainly sounds like you're doing things correctly - you've set up a VM86 task which is one way to access real mode interrupts in protected mode. From your problem description it certainly sounds like you're disabling interrupts and forgetting to reenable them. Is this the case?

Using your only driver is better than BIOS calls.
I think you should better make driver if it's possible.

Grand. Let's all just make drivers for closed-source cards. That's a sensible solution. If you have nothing but tripe to say, please refrain from saying it at all.

Cheers,

James

JamesM wrote:

Using your only driver is better than BIOS calls.
I think you should better make driver if it's possible.

Grand. Let's all just make drivers for closed-source cards. That's a sensible solution. If you have nothing but tripe to say, please refrain from saying it at all.

I assume he meant a VGA driver, not a 2D/3D accelerated driver - that standard is well documented and generally reasonably conformed to. No BIOS call would give you acceleration either. Although since the OP has VM86 running (presumably correctly), it would mean much more work in a different direction. I'm not saying it's the best answer, but it's not what I would consider "tripe".

NickJohnson wrote:

JamesM wrote:

Using your only driver is better than BIOS calls.
I think you should better make driver if it's possible.

Grand. Let's all just make drivers for closed-source cards. That's a sensible solution. If you have nothing but tripe to say, please refrain from saying it at all.

I assume he meant a VGA driver, not a 2D/3D accelerated driver - that standard is well documented and generally reasonably conformed to. No BIOS call would give you acceleration either. Although since the OP has VM86 running (presumably correctly), it would mean much more work in a different direction. I'm not saying it's the best answer, but it's not what I would consider "tripe".

There's a reason you use VBE functions instead of writing a simple VGA driver - VGA can only go up to a certain resolution - IIRC 640x480. VBE functions use the video rom, and can access a larger list of graphics modes.

There are documents for Intel and ATI hardwares.

When it comes to setting modes, I use the real mode manager I wrote which drops to real mode and comes back very smoothly. It doesn't have any problem and I have been using it. It obviously has its own disadvantages, but it is not buggy and I think for such operations, which only need to be done once in a while, you can use such a method.

salil_bhagurkar wrote:When it comes to setting modes, I use the real mode manager I wrote which drops to real mode and comes back very smoothly. It doesn't have any problem and I have been using it. It obviously has its own disadvantages, but it is not buggy and I think for such operations, which only need to be done once in a while, you can use such a method.

Yes, but you're missing the point. The author did not ask what methods he could use to execute realmode interrupts - he asked if he was doing anything wrong, i.e. wanted his own solution debugging. There seems to be an awful lot of "I won't answer your question but I will tell you what I do instead, even though it achieves nothing but brings the discussion off-topic".

Please, can we wait for him to respond and help him through his problem? Please?

JamesM wrote: Yes, but you're missing the point. The author did not ask what methods he could use to execute realmode interrupts - he asked if he was doing anything wrong, i.e. wanted his own solution debugging. There seems to be an awful lot of "I won't answer your question but I will tell you what I do instead, even though it achieves nothing but brings the discussion off-topic".

Please, can we wait for him to respond and help him through his problem? Please?

Sorry , but I thought by asking "How oses do that" he meant what could be the method.

I think I got what could be the problem. I have encountered this before. If you switch to the mode immediately after the user selects an option out of the available video modes, then you are doing it on a key press and by the time the keyboard sends a key release code, you are already operating on the mode switching. During this time, you miss out on the IRQ and the keyboard won't send you any more IRQs unless you accept the pending characters. So you might want to do a few 'inb(0x60)' after coming back from the vm86 task.

JamesM wrote:Hi,

Grand. Let's all just make drivers for closed-source cards. That's a sensible solution. If you have nothing but tripe to say, please refrain from saying it at all.

Cheers,

James

James, didnt you do precisley this? It may not be a sensible solution, but hey, whose really here for that?
http://forum.osdev.org/viewtopic.php?f=2&t=19033

yemista wrote:

JamesM wrote:Hi,

Grand. Let's all just make drivers for closed-source cards. That's a sensible solution. If you have nothing but tripe to say, please refrain from saying it at all.

Cheers,

James

James, didnt you do precisley this? It may not be a sensible solution, but hey, whose really here for that?
http://forum.osdev.org/viewtopic.php?f=2&t=19033

Yes, I did, but for 2D acceleration, not changing graphics mode!