OSDev.org

Hi.

I faced a problem once in multi processor mode with using bios call INT 0x10 for VESA functionality.
Before entering MP, while the PIC was still enabled, there was no difficulty to use bios call with INT 0x10, but as soon as the PIC was disabled and APIC was enabled, the calls to INT 0x10 fails.

I would like not to go into details now, only would like to ask a couple of questions that might help me solve the issue myself.

1- Does switching off the PIC and enabling APIC (setting LAPIC and I/O APIC with all ISA IRQs and PCI IRQs enabled) affects, in any kind, the SVGA?
2- In general, how would you take care of INT 0x10 when coding the APIC?

Best.
Iman.

BIOS expects things to be a certain way. It probably was trying to send EOI to the PIC, which is disabled. After enabling APIC, you shouldn't call BIOS.

iman wrote:1- Does switching off the PIC and enabling APIC (setting LAPIC and I/O APIC with all ISA IRQs and PCI IRQs enabled) affects, in any kind, the SVGA?

Probably. Many video ROMs contain code for timing. If that timing is implemented via PIT or RTC, then disabling the PIC will make the BIOS int 0x10 freeze or fail. (FYI it will also freeze other BIOS routines, like int 0x16).

iman wrote:2- In general, how would you take care of INT 0x10 when coding the APIC?

I guess your kernel is not running in real-mode. But int 0x10 does, so when you switch modes, disable APIC (maybe not necessary, it might have a PIC-compatibility mode) and enable PIC (that's required for sure). Then when you're done with the BIOS int, disable PIC and (and if turned off) re-enable APIC.

Cheers,
bzt

nexos wrote:BIOS expects things to be a certain way. It probably was trying to send EOI to the PIC, which is disabled. After enabling APIC, you shouldn't call BIOS.

That would be sad, if I would not be able to call bios INT 0x10 once in APIC.

bzt wrote:

iman wrote:enable PIC. Then when you're done with the BIOS int, disable PIC re-enable APIC.

I would go with this strategy. But things getting much slower like this (I had vsync implemented by bios call, but never mind, I'll get around it later).

Now out of curiosity:
Do all modern OSs, in case they have to switch back to SVGA functionalities, do this by disabling APIC and enabling PIC, and do stuff and then get everything back to APIC enabled and PIC disabled?

Modern OSs don't use BIOS calls. Even quite ancient OSs don't.

iansjack wrote:Modern OSs don't use BIOS calls. Even quite ancient OSs don't.

But I've seen quite some drivers written for Windows having bios calls. There are certainly the functionality available as an API layer for windows. For Linux, I don't know.
Of course I could have written code for my actual video card if I had access to its internal registers and so, but thanks to the closed-community of video adapter manufacturers, I have to use SVGA and bios functionality.

iman wrote:But I've seen quite some drivers written for Windows having bios calls. There are certainly the functionality available as an API layer for windows.

I'd be really interested to see such a driver. Where can I see such source code?

iansjack wrote:

iman wrote:But I've seen quite some drivers written for Windows having bios calls. There are certainly the functionality available as an API layer for windows.

I'd be really interested to see such a driver. Where can I see such source code?

Yeah, I'd like to see that, too. It would be quite cool.

If you can't find such drivers, maybe look at this:
https://wiki.osdev.org/Drawing_In_Protected_Mode

Greetings
Peter

iansjack wrote:

iman wrote:But I've seen quite some drivers written for Windows having bios calls. There are certainly the functionality available as an API layer for windows.

I'd be really interested to see such a driver. Where can I see such source code?

Long time ago before I start to write my own OS, I found some of them randomly over websites. Excuse me if I cannot find any better, but these two are quite similar to what I had in mind:
https://www.codeproject.com/Articles/12 ... ck-Part-II
and https://doxygen.reactos.org/d9/df4/x86b ... tml#l00367

This is API prototype from MSDN:
https://docs.microsoft.com/fr-fr/window ... oportint10

I would say that the fact that there is a Windows API that emulates the BIOS call is proof that you can't call the interrupt directly. You could always write your own version of this API (I suspect its intent is to provide compatibility with 16-bit programs) if you need that comparability.

(Note - you should be careful to distinguish between the computer's BIOS, which is invoked by int 10, and the video card's BIOS, which the int 10 call then invokes. It is this latter BIOS that the API function calls. Calling int 10 in protected mode, without setting up an IDT entry pointing to an appropriate routine, would crash the computer.)

iman wrote:https://www.codeproject.com/Articles/12 ... ck-Part-II
and https://doxygen.reactos.org/d9/df4/x86b ... tml#l00367

They are both HAL calls. This means Windows and ReactOS have a kind of VM (HAL.DLL) that is used for this.
You have to write a VM for your OS yourself or port ReactOS' HAL. Is it worth it?

Greetings
Peter

iansjack wrote:Modern OSs don't use BIOS calls. Even quite ancient OSs don't.

That just isn't true. As iman is saying, Windows uses BIOS calls. 64 bit obviously has to emulate them, 32 bit Windows uses V8086 mode probably. Modern 64 bit OSs might not. But circa-2008, as 64 bit was getting widespread, V8086 I am quite sure was in use by Windows .

Yes. The x86BiosCall function used by those drivers does not call the BIOS interrupts, it emulates them. Again, you could write this yourself. But what's the point? If you know how to do that you could just write a protected mode driver without bothering with emulation.

iansjack wrote:The x86BiosCall function used by those drivers does not call the BIOS interrupts, it emulates them.

Then what's the point? I find that hard to believe, as the SVGA BIOS is un-standardized, so emulating it is impossible.