VESA alternatives?

[animefreak1233]

The reason I think it sucks is because I thought I'd get something more exciting... But either way, thank you all for the answers.

[Combuster]

The reason I think it sucks is because I thought I'd get something more exciting... But either way, thank you all for the answers.

If you want to go down the exciting route instead of getting something that works on any short term, you can still attempt the huge challenge to write hardware-specific drivers. But ultimately, that's your choice.

[animefreak1233]

I sure as hell wish I had the time...

[Brendan]

Hi,

I sure as hell wish I had the time...

You don't necessarily need the time now. There's nothing wrong with designing a system for "everything" (e.g. for native video drivers) and then only implementing a small part (e.g. whatever is the least you can do for the "no video driver" fall-back you're going to need anyway); because that avoids the "Oh, I need to redesign/rewrite a lot of things" problem if you ever do get the time later.


Cheers,

Brendan

[embryo2]

If you want to go down the exciting route instead of getting something that works on any short term, you can still attempt the huge challenge to write hardware-specific drivers.

Intel's hardware without the GPU's processing power looks much simpler. The complexity of a hardware specific driver without processing acceleration is at the same level as the combination of VGA+VESA+v8086. It is possible to start with Intel's VGA mode documentation and next to extend a driver towards Intel's specific modes. And sometime in the future a developer with such experience will be ready to start working on the GPU's processing power utilization.

Here is the latest available display part of the Programmer's Reference Manual for Intel Graphics.

And here is the list of all available specifications.

[tom9876543]

VESA VBE 2.0 is unfortunately another example of a pathetic terrible API design.

VBE 2.0 was released in 1994. The world was obviously moving to 32bit protected mode. DOS Games were using DOS extenders to run in 32 bit mode. Windows 3.11 had 32 bit mode and everyone knew the next windows would be 32 bit. OS/2 was 32bit from 1992.
So VBE 2.0 should of been a 32bit protected mode API ONLY. No real mode / 16bit PM crap.
VBE 2.0 should of made it possible for multiple PCI video cards to operate independently, with a standard way to load their 32 bit code into the address space. Real mode limitation of only 1 BIOS obliterated.
VBE 2.0 should of been a completely new hardware focussed API, with no references to VGA or VBE 1.2 graphics modes. There would have to be a VBE 2.0 "shutdown" command to a) revert the video card back to BIOS mode if it was booted that way or b) put PCI video card and monitor in low power mode
VBE 2.0 should of included some fast blitting / 2D accelerated graphics functions. And a very clearly defined API for the video card to report if graphics functions are HW accelerated or using the CPU.
And it should have been well designed so that VBE 2.1.... 2.9 could have further acceleration added, without losing backwards compatibility.

If VBE 2.0 was well designed, we wouldn't need Windows drivers. Or Linux/FreeBSD etc drivers. If VESA were smart, they could of convinced IBM to pay some money, giving IBM a guarantee OS/2 could work with native speed for all video cards.

Unfortunately VBE 2.0 was only a small improvement on 1.2, it could of been so much better.

[rdos]

Unfortunately VBE 2.0 was only a small improvement on 1.2, it could of been so much better.

Not only that but since no major OS uses VBE 2, and the protected mode interface, many implementations actually won't work so you need to stick to the real-mode interface.

[rdos]

If you want to go down the exciting route instead of getting something that works on any short term, you can still attempt the huge challenge to write hardware-specific drivers.

Intel's hardware without the GPU's processing power looks much simpler. The complexity of a hardware specific driver without processing acceleration is at the same level as the combination of VGA+VESA+v8086. It is possible to start with Intel's VGA mode documentation and next to extend a driver towards Intel's specific modes. And sometime in the future a developer with such experience will be ready to start working on the GPU's processing power utilization.

Here is the latest available display part of the Programmer's Reference Manual for Intel Graphics.

And here is the list of all available specifications.

I just feel overloaded with excess information whenever I try to make any sense of this. Isn't there a simple example of how to setup the Intel GPU for LFB, and then one could start with that and go to the more fancier things later? I even ponder on single-stepping the real mode mode change code in order to understand what registers are important, but surely there should be some better source than that to get to this point?

[kzinti]

I just feel overloaded with excess information whenever I try to make any sense of this. Isn't there a simple example of how to setup the Intel GPU for LFB, and then one could start with that and go to the more fancier things later?

Even "just setup a LFB" is complicated and a lot of work. So no, there isn't a simple example and there won't ever be.

[jojo]

I mean, if your system's VESA implementation supports LFB then it's relatively straightforward to set up a simple

Code: Select all

boot->enter VESA LFB mode and store base address->set up 32-bit structures->enter C code and do some drawing

The complex part is, as mentioned, configuring VESA from inside 32-bit code almost not even because of the complexity of the details of v86 but because it depends on either going through all of the details of setting up process management which is a whole subject unto itself or otherwise assuming that the user has set that up already in which case you can't really tell them how to start v86 helpers because you don't know how they decided to set up their process model.

You have way less flexibility, but if you can write a booter that enters protected mode then you can add a pre-protected mode enter LFB section pretty easily. The let-the-user-pick solution to the problem of finding a sane mode can even be done before entering protected mode, so that's not an excuse.

Having a framebuffer all to myself was one of the reasons I wanted to write an OS at all when I first started, and dread over the v86 shenanegans was one of the things that made me quit when I was a kid. I think just being able to have something to play around with would be very rewarding for a beginner and provide a base of knowledge upon which a more flexible v86-based driver can be built later on, so I might start writing a tutorial for exactly the aforementioned case when I get home.

[rdos]

I mean, if your system's VESA implementation supports LFB then it's relatively straightforward to set up a simple

Code: Select all

boot->enter VESA LFB mode and store base address->set up 32-bit structures->enter C code and do some drawing

The complex part is, as mentioned, configuring VESA from inside 32-bit code almost not even because of the complexity of the details of v86 but because it depends on either going through all of the details of setting up process management which is a whole subject unto itself or otherwise assuming that the user has set that up already in which case you can't really tell them how to start v86 helpers because you don't know how they decided to set up their process model.

You have way less flexibility, but if you can write a booter that enters protected mode then you can add a pre-protected mode enter LFB section pretty easily. The let-the-user-pick solution to the problem of finding a sane mode can even be done before entering protected mode, so that's not an excuse.

Having a framebuffer all to myself was one of the reasons I wanted to write an OS at all when I first started, and dread over the v86 shenanegans was one of the things that made me quit when I was a kid. I think just being able to have something to play around with would be very rewarding for a beginner and provide a base of knowledge upon which a more flexible v86-based driver can be built later on, so I might start writing a tutorial for exactly the aforementioned case when I get home.

I have no problem with using the VESA interface from V86 to switch video mode. That has worked for many years now. The problem is that more and more BIOSes (and apparently mostly Intel BIOSes) are broken and don't have all the relevant video-modes. Also, in order to boot with UEFI without sacrificing video mode independence, I will eventually need to do change video mode directly against the Intel GPU rather than with the BIOS.

[jojo]

Code: Select all

in order to boot with UEFI without sacrificing video mode independence

Well that's just a targeting choice/issue, then. It's up to the implementer to decide what video devices they want to write drivers for. It sounds like OP wants a flat VESA FB to play around in as easily as possible, so I'm addressing that.

EDIT:

The problem is that more and more BIOSes (and apparently mostly Intel BIOSes) are broken and don't have all the relevant video-modes.

Also just curious about that, because I haven't experienced this on any of my testing hardware so far. Are you saying that the VESA calls return entries in the supported video modes list that can't actually be entered? Not being contrarian or anything, I'm honestly just curious if that's what the story is.

[rdos]

The problem is that more and more BIOSes (and apparently mostly Intel BIOSes) are broken and don't have all the relevant video-modes.

Also just curious about that, because I haven't experienced this on any of my testing hardware so far. Are you saying that the VESA calls return entries in the supported video modes list that can't actually be entered? Not being contrarian or anything, I'm honestly just curious if that's what the story is.

There is a VESA function to return the supported video modes, but some BIOSes will only report 4x3 resolutions like 640x480 and 800x600, even when used with an LCD-display that has another resolution, often wide-format or similar. This makes the display show non-quadratic pixels, which is a big problem.

[rdos]

I just feel overloaded with excess information whenever I try to make any sense of this. Isn't there a simple example of how to setup the Intel GPU for LFB, and then one could start with that and go to the more fancier things later?

Even "just setup a LFB" is complicated and a lot of work. So no, there isn't a simple example and there won't ever be.

Another thing is that the Linux documentation that Intel provides has 9 different sets of manuals for different processors. Does that mean I'll need to write 9 different drivers for the Intel GPU alone? Probably not, but organizing the documentation in a "common" part and "feature" part would be far better. As it is now, I have no idea if I need to write 9 different drivers to setup LFB or not.

Besides, Intel has the LFB setup code both in the legacy BIOS as well as in UEFI, so why not release either of those as public domain instead of the current very confusing "documentation"?

[Schol-R-LEA]

VESA VBE 2.0 is unfortunately another example of a pathetic terrible API design.

I'm not going to argue with that. However, there was no way that a 32-bit VESA was going to come out at that point.

VBE 2.0 was released in 1994.

Released, yes, but only after three years in committee - they were already discussing it when VESA 1.2 was released. In any case, in 1994 there were still a number of new XTs and 286s shipping (not many, but they were cheap and no one really thought Windows was here to stay), and plenty of used ones around as well. Backwards compatibility was, sad to say, a significant concern, even for a standard applying to new motherboards.

The world was obviously moving to 32bit protected mode.

It's only really obvious in hindsight. More people ran MS-DOS without Windows than with it even at that point (trust me on this - I had to grapple with maintaining some MS-DOS and Windows 3.1 systems through Y2K, and saw some DOS boxes limping along as late as 2005). Windows 3.1 was still a hybrid 16/32 bit system, with the 32 bit subsystem crudely bolted on and highly unstable. No one actually believed Windows 95 would ship in 1995 (it almost didn't), or be truly 32 bit (it wasn't, not yet anyway). OS/2 had an effective market share of zero, and was mainly a 16-bit p-mode OS at the time, anyway. While Lotus 1-2-3 required protected mode, it was still mostly geared towards 16-bit p-mode, too, and the 32-bit system they used didn't play well with Windows. As for DOS extenders, those applied only to games, and no one at the time really took PC gaming seriously - remember, the shareware preview version of DOOM was less than a year old at that point, and even game developers were still leery of anything that didn't run on 8088 systems.

VBE 2.0 should of made it possible for multiple PCI video cards to operate independently, with a standard way to load their 32 bit code into the address space.

IIRC, there were no PCI video cards until the middle of 1994, and they only came out because VLB had problems when used in Pentium systems. While PCI was developed in 1990 (as a response to MCA and the failure of EISA, both of which were almost forgotten about by 1994), it wasn't released until 1993, and it was originally designed (and used) for high-speed multi-Ethernet adapters - it was expected to be used exclusively on servers. The high-speed video standard at the time was VESA Local Bus, which was so dependent on the 80486 architecture that it broke when Pentiums came out, and had no ability to allow multiple video cards at all. When AGP (a modified version of PCI specifically for video cards, because PCI 1.0 was actually slower than VLB) came out a few years later, it didn't really support PCI bus mastering, either. Besides, most PCs still used ISA for video until around 1996 - only gamers would bother with an accelerated card, and gaming just wasn't seen as important by anyone who wasn't a gamer themselves.

The real question is, why was VBE 3.0 just a bug patch, and why was there no later 32-bit replacement? The answer is simple: no one wanted or needed one. By 1998, things were moving away from using the BIOS in general, and probably would have done so even if there were an adequate 32-bit extension to it; the only reason it had been relevant as long as it had was because MS-DOS's driver support was hopelessly inadequate.

More importantly, video card manufacturers like 3Dfx, ATI, and nVidia didn't want their precious hardware shaders, texture renderers, etc. to work with generic drivers. Everyone had more or less lined up behind Windows 95, which let them be as proprietary as they cared to be as long as their drivers talked to GDI, and most of the main players were actively blocking the development of Linux drivers for their hardware - they didn't want to waste their own time on writing the drivers (something they were scrambling all over themselves to do a few years later), but they were damned sure not going to give out any proprietary information to the FOSS community, which they regarded as crazed anarchists. For their own part, most Linux enthusiasts of the time still sneered at the idea of a GUI, and those who didn't were up to their eyeballs just getting plain-vanilla Motif to work even as late as the release of AGPpart that same year. In the end, by 1998 VESA was seen as defining the minimum requirements for a video card, and a very bare minimum at that.

Today, it isn't even a minimum. VBE - and BIOS support, period - is a dead letter for everyone who isn't an OS developer themselves, and even for us it is relevant only because the video card manufacturers are about as tight-lipped over their hardware APIs as KFC is about their eleven herbs and spices.