OSDev.org

Oh, even after resetting and restoring PICs, functions needs IRQs doesn't work.

Simple read test with int 0x13 resulted:

Looks like it reads a byte, skipping one, reads the next, skipping one, and going on. So it has 256 bytes instead of 512.

I set the master and slave PICs with their default values, 0x08 and 0x70, as I taken these values from http://wiki.osdev.org/8259_PIC#Real_Mode

Thanks in advance

That does not look like a lost IRQ issue. Do your port I/O routines (in particular the inw case) work correctly?

Aside from that its unwise to reset the PIC as that will interfere with interrupts that are accepted by your protected mode drivers. It would be much better to keep the PIC state, emulate the PIC and inject all occurring interrupts into the emulation.

Korona wrote:That does not look like a lost IRQ issue. Do your port I/O routines (in particular the inw case) work correctly?

Aside from that its unwise to reset the PIC as that will interfere with interrupts that are accepted by your protected mode drivers. It would be much better to keep the PIC state, emulate the PIC and inject all occurring interrupts into the emulation.

Yep, they are working.

Actually another BIOS functions that doesn't use IRQs like 10h and 12h functions are working.
I'm having that problem in only int 13h, that made me suspect IRQs.

In Bochs, it only reads 1/4 of sectors instead of 1/2. Strange
Bochs debugger doesn't work well as code is running in x86emu.

I will enable logging in x86emu and look at its logs, however.

It looks best solution is emulating PICs, as I don't want to lost protected mode IRQs while the BIOS interrupt.

Thanks

Hi,

Agola wrote:Yes, I was marked thread as 'Solved', but I had a new question and I didn't want to open a new thread for it.

Does libx86emu has PIC emulation? If not, as I remapped PICs, interrupts uses PICs will be confused.
I couldn't find anything about PIC in source.

Can I reset the PIC before the interrupt, and restore its state after interrupt? But then it's going to be a hacky code, and it is going to look like "Napalm's Protected Mode BIOS Functionality" which I didn't want to use before because that also resets PICs.

Assume you have an Ethernet card hammering away with a few thousand IRQs per second; but this NIC shares the same PCI IRQ as the hard disk controller. Tell me how you plan to keep the Ethernet card driver working correctly while you're reprogramming the PIC and while you're sending that shared IRQ to the BIOS inside the emulated machine.

It's impossible for it to work properly.

What you need to do is have protected/long mode IRQ handling that is capable of triggering a "fake BIOS IRQ" within the emulated machine if and only if necessary (e.g. if no native driver is using that IRQ, or if all native drivers that are sharing the IRQ say "my device didn't cause the IRQ").

Note that for UEFI none of this can work anyway; every single BIOS function that exists is a crippled/worthless joke; and all the time you spend trying to get it to work reliably for "BIOS only" (including avoiding all potential problems) is time that wasn't spent avoiding the need to use BIOS.


Cheers,

Brendan

Agola wrote:It looks best solution is emulating PICs, as I don't want to lost protected mode IRQs while the BIOS interrupt.

The best solution is writing native storage drivers. Unlike video cards, storage devices are very well documented, so you won't have any trouble finding the information you need to write a real driver.

Octocontrabass wrote:

Agola wrote:It looks best solution is emulating PICs, as I don't want to lost protected mode IRQs while the BIOS interrupt.

The best solution is writing native storage drivers. Unlike video cards, storage devices are very well documented, so you won't have any trouble finding the information you need to write a real driver.

Actually I have storage drivers already. It supports ATA and ATAPI devices, DMA and PIO read / writes. I'm going to use it for only int 0x10.
The reason I tested it with int 0x13 is its easy to understand whats going on.

Then if some BIOSes have IRQ codes in their int 0x10 handler, my code will fail, thats the reason I asked for PICs, actually.

Thanks.

VGA didn't (and often couldn't) use IRQs, so you probably won't find any video cards that need IRQs for their option ROM code.

You might want to block it from accessing non-video-card ports anyway. Most video card ROMs are well-behaved, but not all of them.

Octocontrabass wrote:VGA didn't (and often couldn't) use IRQs, so you probably won't find any video cards that need IRQs for their option ROM code.

You might want to block it from accessing non-video-card ports anyway. Most video card ROMs are well-behaved, but not all of them.

Intel's modern graphics cards (and other manufacturers might be similar) need a vsync to switch high-resolution (e.g. VBE) modes. I don't know if their BIOSes wait for vsync via interrupts or via polling though (but polling seems more likely). I would not neglect the possibility of graphics hardware generating interrupts during mode switch tough.

Korona wrote:I would not neglect the possibility of graphics hardware generating interrupts during mode switch tough.

Personally, I don't think that's likely. This approach (emulation) to running the video BIOS code isn't new; it's been used by plenty of OSs (including Linux and Windows), especially on non-x86 platforms. The emulator we're using was originally written by SciTech (of UniVBE fame) and was used in their SNAP Graphics products, so was absolutely designed for running video BIOS code.

As far as I can tell, none of the open-source users of this library have any handling of hardware interrupts. The original SciTech code didn't even have the x86emu_intr_raise function that could be used for this purpose (the equivalent "X86EMU_prepareForInt" can only be used for software interrupts).

I've also looked at VBE code that used V86 mode, including VBEMP (or at least ReactOS's version of it) and it also has no IRQ handling. I've looked at code that's intended for non-x86 platforms (where PCI video cards designed for PCs may be used) and found no PIC emulation, which would be required to support IRQs on such platforms without a real PIC.

That strongly indicates to me that video hardware that generates and requires handling of IRQs in response to VBE requests is extremely rare, if not non-existent.