OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Aug 22, 2018 2:12 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 9 posts ] 
Author Message
 Post subject: Other VESA graphic modes.
PostPosted: Mon Jun 04, 2018 4:50 am 
Offline

Joined: Sun Apr 30, 2017 7:19 am
Posts: 2
Hello,
I achieved VBE VESA in my operating system. I init VBE from syslinux and then enable it but I have a problem, only some modes seems supported. For exemple I can't get 1366*768 working, on the net there is like nothing about this VESA mode..
If you have ideas thanks for your help!


Top
 Profile  
 
 Post subject: Re: Other VESA graphic modes.
PostPosted: Mon Jun 04, 2018 2:46 pm 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8453
Location: At his keyboard!
Hi,

valentinbreiz wrote:
I achieved VBE VESA in my operating system. I init VBE from syslinux and then enable it but I have a problem, only some modes seems supported. For exemple I can't get 1366*768 working, on the net there is like nothing about this VESA mode..
If you have ideas thanks for your help!


The list of supported VBE modes comes from a table the manufacturer compiled into the ROM, where the manufacturer has no idea what kind of monitor will be attached and doesn't have an infinite amount of space for a huge number of video modes. The end result is that usually the list only contains the most common modes (and may not contain less common modes like 1366*768).

Also note that once upon a time (for VBE 1.0 and VBE 1.2) there were "VESA defined mode numbers" where VESA would say (e.g.) "mode 0x113 is 800*600 with 32768 colours". This was deprecated in 1994 (when VBE 2.0 was released), no new "VESA defined mode numbers" have been defined since 1994, and software should have stopped using "VESA defined mode numbers" in 1994.

Sadly some shrink wrapped third party boot loaders still to use these "deprecated 24 years ago" VESA defined mode numbers, rather than (e.g.) using something like "vga = 1366x768, bits=24, rate=60Hz" and searching for whichever mode is the closest match. In this case, even if you're lucky and the video card's VBE does include a less common video mode, you still won't be able to ask the boot loader to set that mode.

Finally; for cases where its impossible to know anything about all the different computers that the OS could be booted on (generic OS installer, "Live CD", ...) the idea of requesting a specific mode is broken (unless it requests the old "VGA 640*480 @ 60 Hz", which was defined as a "VESA safe mode timing" and should be supported on all PCs and monitors). Ideally; for these cases you'd have code that auto-selects the best video mode (to suit the OS, the video card and the monitor); and if you have code that does "hassle-free video mode auto-selection" well, then you can use it for all cases (including when the OS is installed on a specific computer and the user guarantees they will never upgrade their video card or monitor).


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Other VESA graphic modes.
PostPosted: Thu Aug 09, 2018 4:15 am 
Offline

Joined: Sun Apr 30, 2017 7:19 am
Posts: 2
hello !
Thanks for you response. Do you think that Syslinux is one of the "wrapped third party boot loaders" that uses this old method ?
I understand why it doesn't work but do you have a solution for this ? I really need VBE on 1366*768! :D


Top
 Profile  
 
 Post subject: Re: Other VESA graphic modes.
PostPosted: Thu Aug 09, 2018 5:15 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8453
Location: At his keyboard!
Hi,

valentinbreiz wrote:
Thanks for you response. Do you think that Syslinux is one of the "wrapped third party boot loaders" that uses this old method ?


There's only 2 cases: either you're using a boot loader that was custom designed specifically to suit the OS; or you're using a generic "shrink wrapped" third party boot loader.

valentinbreiz wrote:
I understand why it doesn't work but do you have a solution for this ? I really need VBE on 1366*768! :D


The first step would be to see if VBE supports 1366*768 at all. If it's not supported by VBE then there's only 4 possibilities:
  • Cross your fingers and hope that there's a firmware update or video card ROM update that you can install
  • Keep replacing the video card until you find one that supports 1366*768
  • Write a native video driver
  • Choose a different resolution that VBE does support

Unfortunately, only one of these possibilities is likely to be practical (hint: it's the last one).

If VBE actually does support 1366*768 and the problem is the boot loader, then it's not that hard to write a boot loader (especially if you only want it to be as good as syslinux).


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Other VESA graphic modes.
PostPosted: Mon Aug 13, 2018 6:19 am 
Offline
Member
Member

Joined: Wed Jul 18, 2007 5:51 am
Posts: 168
VESA is another example of short term thinking, badly planned PC infrastructure.

VBE 2.0 should have been 16bit dual mode code.
That is code that works in both x86 16bit protected mode and 16bit real mode.
VBE 2.0 should have completely removed all references to INT 10h. It should have been implemented only as FAR CALLs.
VBE 2.0 should have been a brand new standard, zero backwards compatibility with VBE 1.2.
For video games etc, this would have required total rewrite of VESA 1.2 code, but that is progress.

From memory, I think VESA 3.0 did have 16bit dual mode, but it was too late as video card manufacturers were focussed on Windows drivers and large number of video cards only bothered to implement VBE2.0.


Top
 Profile  
 
 Post subject: Re: Other VESA graphic modes.
PostPosted: Mon Aug 13, 2018 9:37 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1272
Location: Athens, GA, USA
tom9876543 wrote:
VESA is another example of short term thinking, badly planned PC infrastructure.


I quite agree, which is why I stand by Brendan in recommending that OS devs avoid it wherever feasible (boot loaders are an edge case for this, as it's hard to select a driver to use if you don't yet know what hardware you need to support). VESA came out at a time when things were developing too fast for a meaningful standard to be possible at all. Each of the three iterations of it ended up more than a year out of date by the time they were proposed, and even more once they were published. By the time VESA 3.0 was out, the entire concept of user software interfacing directly with the BIOS was irrelevant, and there was simply no way to devise a common set of BIOSes that would be useful for a 32-bit protected mode OS.

For most OS devs, trying to support VESA in their OS (as opposed to the boot loader, as the OP seems to be doing) is likely to be a pointless diversion from developing more robust video drivers, at least for those GPUs whose interface details are published. And honestly, I am pretty sure that you'll find that implementing drivers that support the basic functions on the Intel and AMD GPUs is actually no harder than implemented VESA support would be (more advanced features are another matter, but you'd at least be in a position to approach them).

Especially since most GPU vendors have been quietly dropping support for VBE over time, with only the bare minimum set of routines needed to support some older software still being provided. Most of VESA 3.0 was never widely implemented in the first place.

tom9876543 wrote:
VBE 2.0 should have been 16bit dual mode code.
That is code that works in both x86 16bit protected mode and 16bit real mode.


Probably not, as 16 bit p-mode was pretty much a dead topic already by 1994. Most people then agreed with Bill Gates' notorious initial assessment that the 80286 was a 'loser' of a chip design and jumped on the 80386 with both feet as soon as possible.

Getting the software moved to 32-bit p-mode was another story, but no one wanted to write code for 16-bit p-mode if they could avoid it, modulo a certain OS dev who still posts here about it from time to time (and even he has been using 32-bit p-mode since around 1992, albeit with more use of segments than most others care to).

While Windows 3.1 (1992) still focused on 16-bit p-mode (have only just ditched real mode), it introduced 386 Enhanced Mode as well (with Win32s on the way but not quite ready then, meaning that actual 32-bit user applications for mainstream Windows was a bit delayed by several months), and Microsoft had already announced that the next major version would only support 32-bit p-mode. Also, there were relatively few AT (286) class systems in use compared to either XT (8088) or AT/386 systems, and while new XTs were still being sold in fair numbers as late as 1991, 80286 systems had fallen off the map by then; by 1992 most newer systems were 386s or 486s, and by 1994, Pentium systems were picking up momentum.

To repeat a point I have made many times: through most of the history of small computers, sales figures by microarchitecture roughly paralleled Moore's Law (XTs were something of an anomaly, as were the Apple II and Commodore 64 lines, but not as much as you'd think). By 1994, the 80286-based AT style of systems was four system generations old. There were far more systems capable of running both 16-bit and 32-bit p-mode in use in 1994 than ones which could run 16-bit p-mode but not 32-bit.

Since Windows had its own drivers and didn't use VESA (never really did; by the time Windows was using screen modes above 640x480;4b regularly, starting with Win95, card makers were well past the capabilities of even VESA 3.0, which was still being developed at the time), and the rising popularity of 32-bit DOS extenders meant no DOS games were being written for the now-defunct 286 market (there were still many real mode games being made, right up until the end of MS-DOS as a whole, but anything that needed more leapfrogged directly to 32-bit), having a 16-bit p-mode VESA extension would have been pointless.

In any case, by late 1995 2D and 3D accelerated cards were starting to appear, and card designers were already looking towards what would eventually become GPUs (though it would be about five years before they hit the market). While VESA 3.0 did include some basic standards for 2D acceleration, few card manufacturers implemented them, as a) there was no real common subset of features supported by all cards, b) all the card already out had shipped with drivers for 32-bit DPMI and Windows 95 (but not Windows 3.1 for the most part), and most of all, c) programs would need to have card-specific drivers for the 3D acceleration features anyway, and since Windows WinG (the original accelerated graphics API for Windows 3.1 and still retained initially by Windows 95) had been a flop and it looked as if its replacement, DirectX, would be too at that point (I guess they'd heard that Alex St. Jackass was running the project...), no one was thinking in terms of Windows 3D programming yet.

Note that as far as I know, no 3D acceleration cards had 16-bit BIOS hooks, real or p-mode. For 3D, it was "32-bit or GTFO".

So basically, even when VESA 2.0 came out, VESA was irrelevant, and a 16-bit p-mode for it would have been doubly so. The former wasn't clear until much later, but the latter was abundantly so by then, and no one was putting any more money into 16-bit p-mode software even in 1992 when VESA 2.0 was first being debated.

Of course, no one, then or now, was thinking of what would be needed for supporting independent OS development.

It is hard to explain to those who didn't see it how much Linux blindsided people, even with things like Jolix and Minix already around. Even though it never really had much real impact outside of server farms, the fact that someone did it at all was like lighting a fire under the community, for those interested in OS development.

But no one making hardware had any reason to be interested in accommodating small OS projects, as it would be just an expensive waste for the overwhelming majority of users, so they didn't. That is just as true today, perhaps moreso if anything; it is easier just to special-case a set of blob drivers for Linux, or publish the documentation needed for the community to write a driver (or both, which often means giving just enough information to support most functions while withholding some of the more proprietary aspects), and many companies can't be bothered to do that even much. Linux is a diversion, not a market, and that's even truer for what we are doing.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
 Post subject: Re: Other VESA graphic modes.
PostPosted: Tue Aug 14, 2018 3:13 am 
Offline
Member
Member

Joined: Wed Jul 18, 2007 5:51 am
Posts: 168
Schol-R-LEA, thank you for making many good points.

Regarding dual mode code (16bit pmode and 16bit real mode compatible), this was absolutely required. 32bit code wouldn't have worked.
The video card BIOS has to maintain support for the legacy VGA INT 10h interface. If the VBE standard was properly designed, the VGA BIOS that runs in real mode could implement INT10h routines as simple wrappers around the VBE dual mode code.

Doom was released in 1993. It used DOS 32bit DPMI.
32bit protected mode can interface directly with 16bit protected mode code. That is much more efficient than switching back to real mode, and then switching back to 32bit pm. I can't remember exactly how much VBE functionality DOOM used.


Top
 Profile  
 
 Post subject: Re: Other VESA graphic modes.
PostPosted: Tue Aug 14, 2018 5:54 am 
Offline
Member
Member
User avatar

Joined: Sat Jan 15, 2005 12:00 am
Posts: 8453
Location: At his keyboard!
Hi,

Schol-R-LEA wrote:
tom9876543 wrote:
VBE 2.0 should have been 16bit dual mode code.
That is code that works in both x86 16bit protected mode and 16bit real mode.


Probably not, as 16 bit p-mode was pretty much a dead topic already by 1994. Most people then agreed with Bill Gates' notorious initial assessment that the 80286 was a 'loser' of a chip design and jumped on the 80386 with both feet as soon as possible.


I think you're confusing "80286 protected mode" with "80386+ protected mode". The 16-bit dual mode code tom9876543 is talking about could run as 16-bit code in a 64-bit OS that uses long mode; and was implemented (as an optional feature) in VBE 3.0.

The real problem was that in 1994 when VBE 2.0 was released almost everything that was using VBE had to use real mode for BIOS and DOS functions anyway; and a protected mode interface only mattered for the performance critical VBE functions that might be called every frame (bank switch, display start, palette load), and these functions were tiny so there wasn't much reason to use dual mode code to save video card ROM space.

Schol-R-LEA wrote:
In any case, by late 1995 2D and 3D accelerated cards were starting to appear, and card designers were already looking towards what would eventually become GPUs (though it would be about five years before they hit the market). While VESA 3.0 did include some basic standards for 2D acceleration, few card manufacturers implemented them, as a) there was no real common subset of features supported by all cards, b) all the card already out had shipped with drivers for 32-bit DPMI and Windows 95 (but not Windows 3.1 for the most part), and most of all, c) programs would need to have card-specific drivers for the 3D acceleration features anyway, and since Windows WinG (the original accelerated graphics API for Windows 3.1 and still retained initially by Windows 95) had been a flop and it looked as if its replacement, DirectX, would be too at that point (I guess they'd heard that Alex St. Jackass was running the project...), no one was thinking in terms of Windows 3D programming yet.


Here you're confusing VBE 3.0 (which didn't include any 2D or 3D acceleration) with a completely different standard called VBE/AF (which only included 2D acceleration). Note that there was also a standard for audio called VBE/AI (covering digitised sound and MIDI) that also had nothing to do with VBE 2.0 (even though it was released at about the same time).

Schol-R-LEA wrote:
So basically, even when VESA 2.0 came out, VESA was irrelevant, and a 16-bit p-mode for it would have been doubly so. The former wasn't clear until much later, but the latter was abundantly so by then, and no one was putting any more money into 16-bit p-mode software even in 1992 when VESA 2.0 was first being debated.


No, when VBE 2.0 came out (1994) VBE was at its peak - used by almost every game. Windows 95 hadn't been released yet and almost nobody used Win3.x for games.

For VBE 3.0; the protected mode interface was intended for operating systems. There's even a note in the spec ("VBE Features" on page 5) saying "Optional protected mode interface for OS’s such as Windows NT, OS/2 and UNIX.". The fact that operating systems have their own native drivers doesn't really change this - an OS will always need something during boot, and an OS will always need something for "no driver limp mode". Of course for both of these cases a linear frame buffer is easier and more portable (e.g. can work the same with older video cards and UEFI), so I wouldn't/don't recommend using the VBE 3.0 protected mode interface (even if it is supported).


Cheers,

Brendan

_________________
For all things; perfection is, and will always remain, impossible to achieve in practice. However; by striving for perfection we create things that are as perfect as practically possible. Let the pursuit of perfection be our guide.


Top
 Profile  
 
 Post subject: Re: Other VESA graphic modes.
PostPosted: Tue Aug 14, 2018 11:21 am 
Offline
Member
Member
User avatar

Joined: Fri Oct 27, 2006 9:42 am
Posts: 1272
Location: Athens, GA, USA
Brendan wrote:
Hi,

Schol-R-LEA wrote:
tom9876543 wrote:
VBE 2.0 should have been 16bit dual mode code.
That is code that works in both x86 16bit protected mode and 16bit real mode.


Probably not, as 16 bit p-mode was pretty much a dead topic already by 1994. Most people then agreed with Bill Gates' notorious initial assessment that the 80286 was a 'loser' of a chip design and jumped on the 80386 with both feet as soon as possible.


I think you're confusing "80286 protected mode" with "80386+ protected mode". The 16-bit dual mode code tom9876543 is talking about could run as 16-bit code in a 64-bit OS that uses long mode; and was implemented (as an optional feature) in VBE 3.0.


Hmmn, OK, I am unfamiliar with the dual-mode referred to, then. Thank you for pointing that out. And yes, I did get confused about VBE/AF, I had the impression it was part of VESA 3.0. Again, I don't know it terribly well.

My recollection of games run in DPMI, however, was that most video cards of that era shipped with a DPMI driver. The games themselves usually also shipped with DPMI drivers for several cards, and you sometimes had to select yours from a list of options, because auto-detection was in its infancy (the same was true for sound cards, especially early on before Adlib/SoundBlaster emulation was common).

Often, cards were bundled with card-specific DPMI versions of popular games which were enhanced to show off the card's capabilities. Though that was most common a bit later (1996-97), when accelerated cards were coming into regular use.

I certainly wasn't thinking of Windows games, as what today would be called 'AAA' games didn't really start being written for Windows in any real numbers until around the end of 1997, and many from early 1999 onward required Windows 98 and Direct X 6, IIRC, meaning that anyone who hadn't upgraded was stuck with DPMI. DirectX didn't really push DPMI out of the market entirely until late 1999 or early 2000, though by then the hassle of running games in DOS mode was making Windows-based games very appealing to most players. A number of games were sold bundling both a DOS DPMI version and a Windows version on separate CDs as late as 2002, but that had mostly only been common in 1998-99.

_________________
Rev. First Speaker Schol-R-LEA;2 LCF ELF JAM POEE KoR KCO PPWMTF
μή εἶναι βασιλικήν ἀτραπόν ἐπί γεωμετρίαν
Lisp programmers tend to seem very odd to outsiders, just like anyone else who has had a religious experience they can't quite explain to others.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 9 posts ] 

All times are UTC - 6 hours


Who is online

Users browsing this forum: Google [Bot] and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group