Is entering VBE modes is real without interrupts or VM86?

[abcdef4bfd]

Doesn't this emulator need vitrual 8086 mode? So it's basically the same, only a bit harder.

No, there is no need for any particular CPU features (and it could even run on a non-x86 platform, though that probably wouldn't work). 64-bit Windows uses an emulator to set the video mode when there's no graphics driver available.

If that, give me a link or a code, please.

[BrightLight]

64-bit Windows uses an emulator to set the video mode when there's no graphics driver available.

That's cool. I'd probably try to do that in the x86_64 port of my OS. For now, it doesn't have much to see.

[BrightLight]

No, there is no need for any particular CPU features (and it could even run on a non-x86 platform, though that probably wouldn't work). 64-bit Windows uses an emulator to set the video mode when there's no graphics driver available.

If that, give me a link or a code, please.

Writing an emulator would be pretty much like writing an x86 CPU implementation in software. I guess, you would have to learn about "pure" machine language and opcodes (eg CLI is 0xFA, HLT is 0xF4, etc...). I guess, v8086 would be more suitable to your needs, unless you're working on a 64-bit OS?
Emulator development may well be harder than OS development, because you need extensive CPU knowledge.

[Roman]

There is a ready (?) x86 emulator already - http://www.d-rift.nl/combuster/mos3/?p= ... /libx86emu

[araxestroy]

A potentially more up-to-date source for libx86emu: https://github.com/wfeldt/libx86emu

I do something a little different on x86. When the kernel first gains control of the system, it copies a small sub-kernel to a point in low memory which it can then invoke to make BIOS calls. A wrapper exists in the kernel to halt all running processes, freeze the scheduler, effectively save the kernel state, and return to flat real mode at the sub-kernel's entry point. The call is handled, the wrapper's tasks are reversed, and the system continues on its way.

The problem this method has is that it effectively halts whatever you're doing for upwards of a second. Thus, it's only used for video mode changes and system shutdown on non-ACPI platforms that support APM.

[Combuster]

There is a ready (?) x86 emulator already - http://www.d-rift.nl/combuster/mos3/?p= ... /libx86emu

For your own sanity, grab the original, not my instrumented version.

[embryo2]

Doesn't this emulator need vitrual 8086 mode? So it's basically the same, only a bit harder.

No, there is no need for any particular CPU features (and it could even run on a non-x86 platform, though that probably wouldn't work). 64-bit Windows uses an emulator to set the video mode when there's no graphics driver available.

The mechanics of the emulator usage are unclear. Are you suggesting to create an emulator just to do the same things in it that you have to do without it? Or do you suggest to use some third party emulator that can handle the real mode/vm86 switch for you (and instead of you, freeing you from writing such switch)? But it should be noted, that in any case there is a need for real mode or the virtual 8086 mode. So, there's no actual "third way", but only some ways to hide mode switch.

[Combuster]

Ok, I've read enough nonsense.

Originally, everyone ran in Real Mode and called bios interrupts. People were happy. Then came protected mode, and you couldn't call BIOS interrupts anymore. Instead for the glory of backwards compatibility they added an operating mode called V8086 mode, so that you didn't have to leave the protection of protected mode behind to actually run the original 16-bit code.

Then came long mode, and with it, they dropped V8086 mode. People were unhappy because they couldn't run real-mode code anymore, so they had to write new software to emulate an older x86 processor and in this way they pretended that the BIOS code was running on a real processor.

In addition, if you would drop a graphics card into a non-x86 machine in the past, you couldn't do anything with it because the BIOS code needed to have it display something was still designed for 16-bit x86 processors. Long before 64-bit came to x86, the X server already had an emulator that could read the ROM image from a PCI card and run it on a different architecture by routing all the video accesses to the real hardware and any memory accesses to some generic userspace piece of RAM.

That library was libx86emu. Of course, you can grab the software CPU cores from other projects depending on your taste (for instance, Bochs), but for 64-bit OSes using an emulator is the only universally good design to get a VESA driver up and running.

[embryo2]

Long before 64-bit came to x86, the X server already had an emulator that could read the ROM image from a PCI card and run it on a different architecture by routing all the video accesses to the real hardware and any memory accesses to some generic userspace piece of RAM.

That library was libx86emu. Of course, you can grab the software CPU cores from other projects depending on your taste (for instance, Bochs), but for 64-bit OSes using an emulator is the only universally good design to get a VESA driver up and running.

It's new to me. Interesting.

Does emulator have a BIOS code as a part of itself? How a new hardware is managed then? Or emulator reads the BIOS's code from ROM? And there were mentioned non-x86 machines, so, does the emulator have the knowledge of many different architecture memory layouts (where to read the BIOS) and other differences (like how to handle interrupts)? Or there is kind of plugins for such purpose (like emulated CPU cores)?

[Octocontrabass]

Does emulator have a BIOS code as a part of itself? How a new hardware is managed then? Or emulator reads the BIOS's code from ROM?

The emulator receives a copy of the video BIOS from the video card's ROM, which means it doesn't have to do anything special to handle a new video card.

And there were mentioned non-x86 machines, so, does the emulator have the knowledge of many different architecture memory layouts (where to read the BIOS) and other differences (like how to handle interrupts)? Or there is kind of plugins for such purpose (like emulated CPU cores)?

The emulator doesn't need to know anything about the host hardware. Hardware differences should be handled by the kernel and drivers. For example, locating the video BIOS will most likely be a responsibility of the PCI driver, assuming a PCI video card.

[Ready4Dis]

Actually, for an x86 system, the video bios is at a 'known' location at boot. It is always located at 0x000C0000. In my OS, I basically just make a copy of the lower 1mb of memory after boot and don't touch it. I can then make a copy of it anytime I want to spawn an emulated task and give it a copy so it contains the video bios, interrupt vector table, and anything else. I may change it to later only store specific parts required and then map in blank pages, but honestly, 1mb isn't to much memory to me nowadays. I'm sure I could just store the information I need (IVT, bios data area, extended bios data area, etc) and probably save a bit of space though.

[Ready4Dis]

The mechanics of the emulator usage are unclear. Are you suggesting to create an emulator just to do the same things in it that you have to do without it? Or do you suggest to use some third party emulator that can handle the real mode/vm86 switch for you (and instead of you, freeing you from writing such switch)? But it should be noted, that in any case there is a need for real mode or the virtual 8086 mode. So, there's no actual "third way", but only some ways to hide mode switch.

No, it bypasses the switch completely by setting up a full x86 environment (using the existing bios/video rom) and runs the emulator on the actual code used by the motherboard and video card. This means that it can be preempted, it can be mapped to anywhere since it's just being accessed via an emulator it doesn't actually have to reside <1mb, it can be anywhere in memory (it just thinks it's running <1mb due to the emulator). So yes, it is a third way, and it alleviates the problems associated with vm86 and/or dropping back into real mode. You can keep interrupts enabled, you can use 64-bit (long) mode, etc. I used to drop back into real mode and it worked, but not so much once long mode came along. The other option is just set it at bootup and never look back until you reboot or get a real video card driver working, which is the simplest option.

[Octocontrabass]

Actually, for an x86 system, the video bios is at a 'known' location at boot. It is always located at 0x000C0000.

Not all x86 systems are PC-compatible.

It doesn't really matter where you get the video BIOS, as long as you're getting the right thing. (I wonder what would happen if you tried to use VBE for multiple video cards...)

[Combuster]

I wonder what would happen if you tried to use VBE for multiple video cards...

You'll probably hit each card's VGA Enable switch, after which you have two devices listening to the same memory accesses (and most likely treating them differently enough).

[alexfru]

I wonder what would happen if you tried to use VBE for multiple video cards...

You'll probably hit each card's VGA Enable switch, after which you have two devices listening to the same memory accesses (and most likely treating them differently enough).

VBE 3.0 spec says among the other things:

It is not possible to support multiple independent controllers via the VBE/Core interface.
However multiple independent controllers can be fully supported using the VBE/AF Accelerator
Functions specification (contact VESA for more information), and also allow the graphics
accelerator functions for all installed controllers to be programmed concurrently.