OSDev.org

Ok so I have read a few times about a myth that I never could quite understand. So I came here to ask you guys. Alright. So I would like to have high res graphics, I don't really want to write graphic specific drivers because it's a massive pain and a massive time consumer. So I read about the possibility of emulating, or writing a 16bit virtual machine to run in my Protected Mode operating system, and then run the VBE Bios in that. Though, what I don't understand is, where can I find the VBE Bios that will be ran, and how does that work? I mean I am in Protected Mode so how does running the VBE Bios in a 16bit emulator allow me to call VBE Bios calls?


Thanks,


Matt

Well your emulator knows what the BIOS is doing and can forward the commands to the real hardware. Your emulator can figure out what to execute by looking at the IVT.

I don't really understand your issue.

Nessphoro wrote:I don't really understand your issue.

Basically I want to write a 8086 Emulator to access real mode BIOS interrupts. What I am wondering and trying to understand is how a Real Mode Emulator running in Protected Mode allows BIOS interrupts. Is this because the BIOS code running in the Emulator for example when you call Int10h is called, the code behind that interrupt is ran in the Emulator right?

Thanks, Matt


I'm trying to access the VBE in Protected mode by writing an Emulator.

Hi,

PearOs wrote:Basically I want to write a 8086 Emulator to access real mode BIOS interrupts. What I am wondering and trying to understand is how a Real Mode Emulator running in Protected Mode allows BIOS interrupts. Is this because the BIOS code running in the Emulator for example when you call Int10h is called, the code behind that interrupt is ran in the Emulator right?

If the emulator emulates the BIOS/VBE code's instructions but reads/writes to real physical addresses and IO ports, then any devices (that respond to reads/writes to those real physical addresses and IO ports) won't know the difference. In that way you can (in theory) run BIOS/VBE code, including software interrupts and IRQ handlers.

However; the BIOS/VBE code makes assumptions about the state of hardware, and the hardware's state must match
the assumptions that BIOS/VBE code makes for those reads/writes to real physical addresses and IO ports to work correctly. For a simple example; if you reconfigure the PIC chips like you should, then any BIOS code that accesses the PIC chip/s will get all confused and broken. To fix that you could also emulate the PIC chips, so that you can reconfigure the real PIC chips and emulate fake PIC chips to satisfy the BIOS. The same applies to any hardware that you touch (e.g. emulate any/all hardware that you've reconfigured, to keep the BIOS/VBE happy).

Of course a decent OS will take full control of all hardware (including reconfiguring PIC chips, reserving the right to change PCI configuration space for any/all devices, using all RAM for whatever it likes, etc); and an OS that isn't crap will also be designed to support UEFI one day (where there's no guarantee that any hardware was ever in the state that VBE code expects and no guarantee that the video card itself actually has a ROM containing VBE). For these reasons it's far better to set a high resolution video mode during boot using whatever services the firmware provides (VBE for BIOS, and UGA or GOP for UEFI), before the OS starts doing its job (e.g. before the OS takes control of the computer and starts reconfiguring everything to suit itself). In this case you have no need for a large, complex/unstable, slow and ugly emulator to execute code that may or may not exist.


Cheers,

Brendan

I think that using BIOS services after entering Protected Mode/Long Mode is a bad idea. It should be a one-way street. Use all necessary services while you are still in Real Mode when the boot loader runs. Like setting the VBE video mode. Going back to Real Mode should be avoided at any cost.

All the Virtual 8086 Mode / Emulator hacks should be avoided as well. Newer versions of VBE support an interface that can be used in Protected Mode and using that would be lightly less wrong. However, it is not elegant to use BIOS services while the OS runs.

This is just my point of view. Of course, people are allowed to create a modern Real Mode OS: an OS that runs in Protected Mode but is like a Real Mode OS.

EDIT: I wrote this before Brendan's post but I was too slow. Due to this, better reasoning was already available above.

Of course the most elegant solution would be to have drivers for everything. Sadly, that's not an option for everyone except m$ either

Therefore, concessions.

Combuster wrote:Of course the most elegant solution would be to have drivers for everything

You would still be able to use the video mode you set earlier. I think it is a good compromise for hobby OSs.

Wow thanks for all the replies guys. So I guess I have two options then.

1. In Real Mode set the Graphics Mode and then manipulate the screen in Protected Mode.
2. Make a 8086 Emulator and hopefully emulate the VBE Bios.

I love to program for operating systems. So I guess trying both would be a good learning experiment. So where can I find the VBE Bios that the Emulator would run?

Now off to the second part. I guess I can try the first option. Though my bootloader sticks me in Protected Mode automatically. I am using isolinux. So I guess go back to real mode and then protected mode? Even then how do I set a mode, and then manipulate pixels in Protected Mode? Are there any good code examples of this?

Another question, has there ever been an Open Source OS that has successfully used the VBE Bios in an Emulator in their OS?

Thanks Guys,

Matt

You can find the VBE BIOS by looking up where int 0x10 points to in the interrupt table.

Returning to real mode might work - though if isolinux has changed any hardware configuration, there could well be problems; switching back to real mode isn't generally recommended. Ideally any video mode changes would be done before switching to protected mode. GRUB allows you to specify what resolution you want in the multiboot header, so if you're able to use GRUB instead of isolinux then that's an easy way to do it.

One thing of note is that X.Org contains support for running a VESA BIOS on non-PC platforms.

Most VESA BIOSes don't have any real dependencies on the system BIOS.

madanra wrote:You can find the VBE BIOS by looking up where int 0x10 points to in the interrupt table.

Returning to real mode might work - though if isolinux has changed any hardware configuration, there could well be problems; switching back to real mode isn't generally recommended. Ideally any video mode changes would be done before switching to protected mode. GRUB allows you to specify what resolution you want in the multiboot header, so if you're able to use GRUB instead of isolinux then that's an easy way to do it.

I agree. Ok so that's a good start. Now since I am in protected mode, sorry if this sounds noobish. I have never really done this before, isn't INT 10h remapped because I setup my own table so that I could get interrupts working. Or is it still intact somehow? Thanks, Matt

Owen wrote:One thing of note is that X.Org contains support for running a VESA BIOS on non-PC platforms.

Most VESA BIOSes don't have any real dependencies on the system BIOS.

Interesting, if you could point me to where that's located that would be really useful. I am curious as to how they are doing that, most likely emulating. Thanks, Matt

It's called libx86emu

PearOs wrote:I have never really done this before, isn't INT 10h remapped because I setup my own table so that I could get interrupts working. Or is it still intact somehow?

The real mode Interrupt Vector Table (IVT) is stored in the first 1KB of RAM, so you can look it up there, as long as neither isolinux nor your OS has overwritten that part of RAM.