Any idea on how Windows changes the Video Mode?

[Nessphoro]

Hey guys I was wondering if any of you know how Windows (x64 in particular) changes the video mode,
Since as I realized, just setting up v86 for that is useless and v86 is pretty shitty to manage/get working.

Thanks in advance.

[piranha]

Probably using vesa, vga, drivers for graphics cards, etc.

-JL

[Brendan]

Hi,

Hey guys I was wondering if any of you know how Windows (x64 in particular) changes the video mode,
Since as I realized, just setting up v86 for that is useless and v86 is pretty shitty to manage/get working.

Windows uses native video drivers (where each different video driver for each different video card uses direct access to the video card's IO ports and memory mapped IO areas for that card to do thing like change video modes, etc).

If I remember right, when there is no native video driver, for Windows 95 you had to reboot to change video modes (and it used VESA/VBE during boot to set the video mode); and Windows 98 added support for changing video modes without rebooting (using virtual8086 mode and VESA/VBE). I'm not sure what modern versions of Windows do when there's no native video driver (the GUI requires 2D/3D acceleration now, and VESA/VBE isn't adequate).


Cheers,

Brendan

[Owen]

I'm not sure what modern versions of Windows do when there's no native video driver (the GUI requires 2D/3D acceleration now, and VESA/VBE isn't adequate).

The GUI still runs fine when you have no GPU; just the UI gets downgraded to the Aero Basic theme and all the flashy effects turn off. They need the non-accelerated fallback for Safe Mode.

I presume similar things happen on EFI systems except you won't be able to change the resolution post-boot (so it will probably pick a reasonable one and you're stuck with that)

[Gigasoft]

When no driver exists for your card, Windows just uses the default VGA driver instead.

[DavidCooper]

I've been thinking about a possible solution to part of this problem. If you're a big company like Microsoft or one that produces BIOS code, you'll get the graphics card companies sending you all their technical spec so that you can support their products - not to do so would severely limit their sales potential. I don't know if the same information is made available to rest of us, but the most up-to-date stuff I've been able to find so far is this ancient document with links to info on a number of SVGA cards: http://bespin.org/~qz/pc-gpe/.

But hold on a minute: a lot of the information we need is already sitting there in the BIOS, so what I'm thinking of doing is writing code to translate parts of the BIOS's video code from real mode into 32-bit mode so that it can be run directly even within long mode, and it would do a fresh translation everytime you change screen mode (to a mode you haven't already used since booting). The translations would never be saved to disk and would never be part of the distribution version of an operating system, so I don't think it wouldn't be breaking anyone's copyright. I don't know if there are any barriers in the way of doing this, but if all the necessary BIOS code is openly readable without having to switch banks of it in and out of memory (I don't know if that ever happens), then it should be possible. Assuming that that's the case then, here's the plan:-

An area of memory will be set aside for the translation to be held, and only the active line would be translated as required. What that means is, if for example you want to move the window into video memory in order to write to a different part of the screen, you set ax to f405h, bx to 0 and dx to the window position (in granularity units), then you call the non-existent 32-bit translated version of the BIOS code. It actually finds an int3 instruction there which signifies that the translated code doesn't exist yet, so the translation module then kicks in to generate it, generating only the path which is needed for the required function, with any unfollowed branches leading to futher int3 instructions just in case they are taken the next time the code is run. Once the required path is complete, the code gets run. The next time it is run it may run all the way through without hitting an int3 instruction, but if it does hit one it will simply trigger the translation of the missing path. After a few calls have been made to this routine, all the necessary code will have been translated, and no BIOS code that isn't needed will have been touched.

So, the translation is done every time you change to a new screen mode, just a few test runs being enough to generate most or all of the translation of the required BIOS code, and from then on it will simply run as 32-bit code without any further delays. It may also be possible to do some analysis of the code to identify parts which can be skipped, possibly leading to the generation of a list of values and the ports to send them to so that the whole algorithm can be reduced to the absolute essentials, but that would be a longer-term objective.

How would the translation be done? I'm thinking about doing it using indexed machine code so that it can be edited easily as new paths are fitted into existing ones. Each byte of translated code would have four bytes of address associated with it to tie it to the original real mode version so that paths can be linked up properly without accidental duplication.

Before I start work on this, I'd like to know what any experts on BIOS video-related ROM here think of this as they may be aware of some project-wrecking barriers which I know nothing about. I'm not worried about the actual translation part of the process - I've done something similar before.

[Owen]

Everyone just does something far easier: They use x86emu. x86emu is a real mode emulator; its a few thousand lines of C. Theres not that much you have to emulate for a VGA BIOS to work

[egos]

Before I start work on this, I'd like to know what any experts on BIOS video-related ROM here think of this as they may be aware of some project-wrecking barriers which I know nothing about. I'm not worried about the actual translation part of the process - I've done something similar before.

I had discussion about this solution 5 years ago. Here is one barrier that we had

DECOMPILATION OR DISASSEMBLY PROHIBITED

[Brendan]

Hi,

I've been thinking about a possible solution to part of this problem. If you're a big company like Microsoft or one that produces BIOS code, you'll get the graphics card companies sending you all their technical spec so that you can support their products - not to do so would severely limit their sales potential. I don't know if the same information is made available to rest of us, but the most up-to-date stuff I've been able to find so far is this ancient document with links to info on a number of SVGA cards: http://bespin.org/~qz/pc-gpe/.

In a lot of cases, companies don't send specs to Microsoft, they send working drivers.

But hold on a minute: a lot of the information we need is already sitting there in the BIOS

No it's not. It contains code to set an obsolete subset of video modes (the ones intended for 4:3 monitors that aren't very suitable for modern wide screen monitors that typically have a preferred/native resolution that you can't achieve with VESA/VBE) and a few miscellaneous functions (mostly for text mode). There's no hardware cursor (mouse pointer) support, no 2D acceleration (including basic bit blitting - you can't even get a simple "vertical retrace" IRQ out of it), no 3D acceleration (including stuff like fog and shaders), no power management (can't even put the monitor into "standby" state), etc. On top of that, it doesn't work at all for systems with multiple monitors (whether it's multiple monitors connected to the same video card or multiple monitors connected to different video cards).

It's the absolute minimum, which fails to meet end-user expectations by a massive margin.

How would the translation be done? I'm thinking about doing it using indexed machine code so that it can be edited easily as new paths are fitted into existing ones. Each byte of translated code would have four bytes of address associated with it to tie it to the original real mode version so that paths can be linked up properly without accidental duplication.

A better approach would be "JIT emulation", similar to what a lot of emulators (e.g. Qemu) use.

Before I start work on this, I'd like to know what any experts on BIOS video-related ROM here think of this as they may be aware of some project-wrecking barriers which I know nothing about. I'm not worried about the actual translation part of the process - I've done something similar before.

It's entirely possible. The main problem is that you can't just translate the video card ROM's code, and have to also emulate (parts of) the environment that the video card ROM's code expects to be executed in.

The other problem is that (if it's done right) it'll probably take a few years to implement, and after you've implemented it'll still fail to meet end-user expectations by a massive margin (just like VESA/VBE).


Cheers,

Brendan

[DavidCooper]

Everyone just does something far easier: They use x86emu. x86emu is a real mode emulator; its a few thousand lines of C. Theres not that much you have to emulate for a VGA BIOS to work

I've already written what is effectively a 32-bit mode emulator for 32-bit code which I use as a monitor program, so it won't take a lot of work to create a real mode emulator based on it. My original idea was to copy the same design and put each instruction into an "action array" where it can be run in its 32-bit form, but it would be perfectly possible to stick a whole lot of consecutive instructions into this array and to run them as a block of continuous code, and there could be a number of such blocks within the array which can be run at different stages of the emulation, ultimately reaching the point where they can be run directly every time they're needed without any delay.

I had discussion about this solution 5 years ago. Here is one barrier that we had

DECOMPILATION OR DISASSEMBLY PROHIBITED

It would be hard for them to argue that it's being decompiled or disassembled - it is simply being emulated in a very efficient manner, and no one would be getting their hands on any of the secrets hidden within their code.

In a lot of cases, companies don't send specs to Microsoft, they send working drivers.

So what's stopping them sending working drivers to each of us, I wonder? This is a clear case of anti-competitive practices.

But hold on a minute: a lot of the information we need is already sitting there in the BIOS

No it's not. It contains code to set an obsolete subset of video modes (the ones intended for 4:3 monitors that aren't very suitable for modern wide screen monitors that typically have a preferred/native resolution that you can't achieve with VESA/VBE) and a few miscellaneous functions (mostly for text mode). There's no hardware cursor (mouse pointer) support, no 2D acceleration (including basic bit blitting - you can't even get a simple "vertical retrace" IRQ out of it), no 3D acceleration (including stuff like fog and shaders), no power management (can't even put the monitor into "standby" state), etc. On top of that, it doesn't work at all for systems with multiple monitors (whether it's multiple monitors connected to the same video card or multiple monitors connected to different video cards).

It's the absolute minimum, which fails to meet end-user expectations by a massive margin.

Right, I see. The situation's pretty dire then. I hadn't realised (or had forgotten - it rings a slight bell now) that VESA haven't even managed to keep up with widescreen developments. So far I've only explored a few modes like 100h, 101h and 103h - I was planning to look for 1024x600 modes on my netbook next, but presumably I'll find that they simply aren't available through VESA. That's a pity. This needs a big player to push for change, but the established ones are all quite happy that this situation blocks our progress. Still, you still have to wonder if it might be possible to force graphics card companies to release their spec.s - what they're doing by shutting us out cannot be legal.

[Combuster]

In a lot of cases, companies don't send specs to Microsoft, they send working drivers.

So what's stopping them sending working drivers to each of us, I wonder? This is a clear case of anti-competitive practices.

Actually, they are not preventing anything at all. Everything you asked for freely off the web

[Neolander]

I thought VBE2/3 stopped enforcing an arbitrary and outdated set of video modes and allowed manufacturers to put whatever video mode they want in. Have manufacturers chosen not to move their lazy Assembly and do it ?

[Brynet-Inc]

Basic modesetting is documented in the publicly available specifications made available by Intel and ATI, the information could also be gleamed from the permissively licensed Xorg drivers.

However, as someone else has suggested, if you must.. just go down the x86emu route.

[DavidCooper]

Actually, they are not preventing anything at all. Everything you asked for freely off the web

Everything? If that's really the case, I take it all back. I'm guessing the thing to do then is try to adapt your OS to use Linux, Solaris or FreeBSD drivers. I don't think I'll rush into exploring that idea for a while yet, but it's good to know the door isn't as closed as I'd imagined.

By the way, I've just tried VESA on my Netbook and I was offered nine modes, of which three weren't valid, due no doubt to the limited vertical resolution of the monitor. So it's got to be either 640x480 or 800x600, and in one of three flavours (1/2/3 bytes per pixel). Looks like I'll be stuck with having to draw elipses to make circles for a long time.

However, as someone else has suggested, if you must.. just go down the x86emu route.

I'll certainly write my own emulator for it. I might not bother to make it as advanced as I suggested earlier - I've just done some speed experiments with changing back to real mode repeatedly to change the window position and to do hardware scrolling, and it's so fast that I'm no longer so concerned about trying to speed it up. It should be dead easy to get pixel-level scrolling in any direction at high speeds even on a slow machine, judging by the enormous delay loops I had to put in to slow it down to usable speeds.

[Brendan]

Hi,

Actually, they are not preventing anything at all. Everything you asked for freely off the web

Everything? If that's really the case, I take it all back. I'm guessing the thing to do then is try to adapt your OS to use Linux, Solaris or FreeBSD drivers. I don't think I'll rush into exploring that idea for a while yet, but it's good to know the door isn't as closed as I'd imagined.

Combuster's comments highlight the long-term goal: make your OS popular enough, and hardware manufacturers will write the drivers for you. Finding a way to make your OS popular enough is the hard part.

By the way, I've just tried VESA on my Netbook and I was offered nine modes, of which three weren't valid, due no doubt to the limited vertical resolution of the monitor. So it's got to be either 640x480 or 800x600, and in one of three flavours (1/2/3 bytes per pixel). Looks like I'll be stuck with having to draw elipses to make circles for a long time.

In general, I'd design the video driver interface so that the driver receives a list of commands describing what to draw, where the video driver is responsible for doing all of the drawing (either in software or with assistance from the 2D/3D acceleration hardware). The applications (and GUIs, etc) themselves don't need to care what resolution (or colour depth) is being used - they'd use a virtual coordinate system (and standardised representation of colour).


Cheers,

Brendan