VOGONS


First post, by videogamer555

User metadata
Rank Member
Rank
Member

After testing out some of the different video modes listed here https://en.wikipedia.org/wiki/VESA_BIOS_Extensions in the debugger version of DS Box, I found many of these graphics modes were failing. In some cases, DOS Box itself was calling it an illegal mode (though the return value from the VESA mode interrupt indicated success). In other cases the interrupt function was returning the value 0x014F in the AX register (though DOS Box itself wasn't saying there was an error). That's an error code, because correctly switching to a VESA graphics mode should result in the value 0x004F being returned in the AX register.

Any VESA compliant BIOS should support at least the following video modes (not all of which are currently supported in DOS Box).
Text Modes:
0x0108
0x0109
0x010A
0x010B
0x010C

Graphics Modes:
0x010D
0x010E
0x010F
0x0100
0x0101
0x0110
0x0111
0x0112
0x0102
0x006A (according to the Wikipedia article, this mode is the same as 0x0102)
0x0103
0x0113
0x0114
0x0115
0x0104
0x0105
0x0116
0x0117
0x0118
0x0106
0x0107
0x0119
0x011A
0x011B

Special Mode:
0x81FF (according to the Wikipedia page "Mode 81FFh is a special video mode designed to preserve current memory contents and give access to the entire video memory.")

Some of these modes do seem to work both in terms of not getting an error code in the AX register, and also not getting DOS Box to say it's an illegal mode, but DOS Box gives another warning instead. This other warning is "MOUSE:Unhandled videomode 77 on reset". I don't even know what that means. I haven't even tried to use the mouse in my program. I literally just had it switch to a VESA graphics mode (0x010F in this case, which should be 24bit color with a resolution of 320x200).

Reply 2 of 19, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

From the very same wikipedia page:

Beginning with the VBE 2.0 standard, no new modes will be defined by VESA, and old modes are no longer mandatory. The use of defined modes should be considered deprecated: modern video cards may or may not use these mode numbers (even though most do for backward compatibility), and modern software should not use them. The correct way for software to discover available display modes is to obtain a list of modes (using "Function 00h - Return VBE Controller Information") and then to check each mode (using "Function 01h: Return VBE Mode Information") until it finds the mode/s it requires.

tl,dr: you're just picking video mode numbers out of the air instead of querying for supported modes and using what is reported as available, like sensible software does (because mode numbers vary between cards).

Reply 3 of 19, by Falcosoft

User metadata
Rank Oldbie
Rank
Oldbie
videogamer555 wrote on 2023-02-20, 06:27:

...
Any VESA compliant BIOS should support at least the following video modes (not all of which are currently supported in DOS Box).

This is definitely not true. From VBE 2.0 (that DosBox emulates) there is no such thing as mandatory video mode number support. And even VBE 1.x had not specified that all defined modes had to be supported. It only specified that VESA 1.x defined standard modes had to be available by the specified mode numbers.
E.g. VESA defined VBE text mode support was rather the exception and not the rule (AFAIK e.g. NVIDIA never supported these VESA text modes) .
From VBE documentation:

Note: Starting with VBE version 2.0, VESA will no longer define new VESA mode numbers and it will no longer be mandatory to supp […]
Show full quote

Note: Starting with VBE version 2.0, VESA will no longer define new VESA mode numbers
and it will no longer be mandatory to support these old mode numbers. OEM’s who wish
to add new VBE mode numbers to their implementations, must make sure that all new
modes are defined with mode numbers above 0x100, However, it is highly recommended
that BIOS implementations continue to support these mode numbers for compatibility
with older software and add new mode numbers after the last VESA defined mode
number). VBE 2.0-aware applications should follow the guidelines in Appendix 5 -
Application Programming Considerations - for setting a desired mode.

Website, Facebook, Youtube
Falcosoft Soundfont Midi Player + Munt VSTi + BassMidi VSTi

Reply 4 of 19, by videogamer555

User metadata
Rank Member
Rank
Member
Falcosoft wrote on 2023-02-20, 08:03:
This is definitely not true. From VBE 2.0 (that DosBox emulates) there is no such thing as mandatory video mode number support. […]
Show full quote
videogamer555 wrote on 2023-02-20, 06:27:

...
Any VESA compliant BIOS should support at least the following video modes (not all of which are currently supported in DOS Box).

This is definitely not true. From VBE 2.0 (that DosBox emulates) there is no such thing as mandatory video mode number support. And even VBE 1.x had not specified that all defined modes had to be supported. It only specified that VESA 1.x defined standard modes had to be available by the specified mode numbers.
E.g. VESA defined VBE text mode support was rather the exception and not the rule (AFAIK e.g. NVIDIA never supported these VESA text modes) .
From VBE documentation:

Note: Starting with VBE version 2.0, VESA will no longer define new VESA mode numbers and it will no longer be mandatory to supp […]
Show full quote

Note: Starting with VBE version 2.0, VESA will no longer define new VESA mode numbers
and it will no longer be mandatory to support these old mode numbers. OEM’s who wish
to add new VBE mode numbers to their implementations, must make sure that all new
modes are defined with mode numbers above 0x100, However, it is highly recommended
that BIOS implementations continue to support these mode numbers for compatibility
with older software and add new mode numbers after the last VESA defined mode
number). VBE 2.0-aware applications should follow the guidelines in Appendix 5 -
Application Programming Considerations - for setting a desired mode.

Ok. But shouldn't DosBox support all the documented modes, just in case there's some game out there that uses them?
I thought VESA was supposed to have a mandatory minimum set of modes that needed to be included in a graphics card to be considered VESA compliant. And it would make sense if it was mandatory. Things like 640x480 at 256 colors, as well as 640x480 at 32k colors, 64k colors, and 16M colors, are kinda like standards that cards usually support because of their historical usage in computers. For a long time, even in the time of Windows95, 640x480 was kinda like the standard resolution for monitors (and later bigger monitors came out like 800x600 and then 1024x768, and of course modern monitors that are approximately 4000x3000). So given the historical nature of some of these modes that are higher res than oldschool VGA modes, yet lower capabilities than modern monitors, I would think that VESA would want to require some of these modes as fallback modes for people who don't have the very latest monitors.

Reply 6 of 19, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie
videogamer555 wrote on 2023-02-20, 11:55:

Ok. But shouldn't DosBox support all the documented modes, just in case there's some game out there that uses them?
I thought VESA was supposed to have a mandatory minimum set of modes that needed to be included in a graphics card to be considered VESA compliant. And it would make sense if it was mandatory. Things like 640x480 at 256 colors, as well as 640x480 at 32k colors, 64k colors, and 16M colors, are kinda like standards that cards usually support because of their historical usage in computers. For a long time, even in the time of Windows95, 640x480 was kinda like the standard resolution for monitors (and later bigger monitors came out like 800x600 and then 1024x768, and of course modern monitors that are approximately 4000x3000). So given the historical nature of some of these modes that are higher res than oldschool VGA modes, yet lower capabilities than modern monitors, I would think that VESA would want to require some of these modes as fallback modes for people who don't have the very latest monitors.

DOSBox supports at least these modes (as reported/detected by PCPBench using the proper procedure of querying the BIOS):
file.php?mode=view&id=158016

If your code is failing, it's something on your end.

Attachments

  • dosbox_modes.png
    Filename
    dosbox_modes.png
    File size
    33.99 KiB
    Views
    2677 views
    File license
    Public domain

Reply 7 of 19, by videogamer555

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2023-02-20, 13:32:
DOSBox supports at least these modes (as reported/detected by PCPBench using the proper procedure of querying the BIOS): https:/ […]
Show full quote
videogamer555 wrote on 2023-02-20, 11:55:

Ok. But shouldn't DosBox support all the documented modes, just in case there's some game out there that uses them?
I thought VESA was supposed to have a mandatory minimum set of modes that needed to be included in a graphics card to be considered VESA compliant. And it would make sense if it was mandatory. Things like 640x480 at 256 colors, as well as 640x480 at 32k colors, 64k colors, and 16M colors, are kinda like standards that cards usually support because of their historical usage in computers. For a long time, even in the time of Windows95, 640x480 was kinda like the standard resolution for monitors (and later bigger monitors came out like 800x600 and then 1024x768, and of course modern monitors that are approximately 4000x3000). So given the historical nature of some of these modes that are higher res than oldschool VGA modes, yet lower capabilities than modern monitors, I would think that VESA would want to require some of these modes as fallback modes for people who don't have the very latest monitors.

DOSBox supports at least these modes (as reported/detected by PCPBench using the proper procedure of querying the BIOS):
file.php?mode=view&id=158016

If your code is failing, it's something on your end.

I would like to point out that your mode numbers are not being used correctly. For example mode 0x010F is supposed to be a 24bpp 320x200 mode. However in DosBox it incorrectly is a 32bpp 320x200 mode. While the official VESA specs may no longer require supporting every standard mode, I think they require that the use of any of the standard mode numbers must conform to the official specification for those modes. While VESA does allow for 32bpp modes, it doesn't have any in their list of standard modes. Therefore, if you want a 320x200 32bpp mode, that mode must be given a number other than one of the numbers from the official VESA specifications. 24bpp modes must have exactly 3 bytes per pixel, while 32bit modes must have exactly 4 bytes per pixel. And this is a big difference. 4 bytes per pixel requires copying a single dword for each pixel. However, 3 bytes per pixel requires copying a word and then a byte, for each pixel.

Reply 8 of 19, by jmarsh

User metadata
Rank Oldbie
Rank
Oldbie

It's already been explained to you that VBE2.0 made defined modes deprecated and they should not be relied upon. Deal with it or any app you write may break on any real card that defines modes differently from what you expect.

Reply 9 of 19, by Gmlb256

User metadata
Rank l33t
Rank
l33t

Using hard-coded VESA video modes is ill-advised and this becomes apparent with real hardware where mode numbers (resolutions lower than 640x480 are the most notable ones) aren't consistent between vendors. Not to mention that VBE TSRs are capable of altering these mode numbers.

VIA C3 Nehemiah 1.2A @ 1.46 GHz | ASUS P2-99 | 256 MB PC133 SDRAM | GeForce3 Ti 200 64 MB | Voodoo2 12 MB | SBLive! | AWE64 | SBPro2 | GUS

Reply 10 of 19, by videogamer555

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2023-02-20, 21:54:

It's already been explained to you that VBE2.0 made defined modes deprecated and they should not be relied upon. Deal with it or any app you write may break on any real card that defines modes differently from what you expect.

My understanding is that all this means is that they should not be assumed to exist. However if they exist, I think they are supposed to be defined in the standard way. Only modes that were never officially defined are allowed to have any arbitrary specifications.

Reply 11 of 19, by videogamer555

User metadata
Rank Member
Rank
Member
jmarsh wrote on 2023-02-20, 13:32:
https://www.vogons.org/download/file.php?mode=view&id=158016 […]
Show full quote

file.php?mode=view&id=158016

Where can I download a copy of PCPBench? I Googled it, and all I get are blog and forum posts where people mention using it. No download links.

Reply 13 of 19, by Jo22

User metadata
Rank l33t++
Rank
l33t++
videogamer555 wrote on 2023-02-20, 06:27:

0x006A (according to the Wikipedia article, this mode is the same as 0x0102)

Seriously ? This is/was the most significant SVGA mode of all (800x600 16c).
I'm really suprised it's not being in the list. On the other hand, SVGA and VBE are two separate things, strictly speaking.
The 800x600 16c mode was in use before VBE was in common use, albeit available under different SVGA mode numbers.

Edit: Or does PCPBench simply not check for 4Bpp modes, maybe ?
Generally speaking, games using 16c modes are simulations (SimCity, MS Flight sims) and graphics adventures (by Legend Entertainment games, Magnetic Scrolls etc).
But the early types are using mode numbers specific to a certain SVGA chip/manufacturer, also.

Edit: Either way, some games/applications had code for both specific SVGA card models of their time and a secondary fallback code for then-new VBE.
If 6Ah and 102h are really missing from the list, then I'd like to hear an explanation, please.
Because, the S3 isn't exactly a classic SVGA chip. Not by late 80s/early 90s standards.
Having VBE working as a fallback here would perhaps get software from the transitional time
running without the need for editing dosbox.conf and using a different VGA.

"Time, it seems, doesn't flow. For some it's fast, for some it's slow.
In what to one race is no time at all, another race can rise and fall..." - The Minstrel

//My video channel//

Reply 14 of 19, by ripsaw8080

User metadata
Rank DOSBox Author
Rank
DOSBox Author

Hmm, I'm not sure it was suggested that mode 6Ah or 102h were not implemented or not working.

VESA mode 102h is supported, of course, and must be set with INT 10h function 4F02h.

Modes 69h (alias of mode 101h) and 6Ah (alias of mode 102h) are supported but must be set with INT 10h function 00h, not with function 4F02h.

Reply 15 of 19, by mkarcher

User metadata
Rank l33t
Rank
l33t
videogamer555 wrote on 2023-02-20, 21:43:

I would like to point out that your mode numbers are not being used correctly. For example mode 0x010F is supposed to be a 24bpp 320x200 mode. However in DosBox it incorrectly is a 32bpp 320x200 mode. While the official VESA specs may no longer require supporting every standard mode, I think they require that the use of any of the standard mode numbers must conform to the official specification for those modes. While VESA does allow for 32bpp modes, it doesn't have any in their list of standard modes.

This is not how VESA BIOSes behaved back in the 90s. S3 graphics chips used a 4 bytes per pixel in 16M color modes, mostly because that's required for VRAM based cards with direct DAC data path. Cirrus Logic used 3 bytes per pixel in 16M color modes. The VESA mode number 0x010F was supported by both kind of cards, and the application had to check for the number of bytes per pixel. I can't find the VESA 1.2 specification only (that one added standard mode numbers for high-color and true-color modes), so I can't quote an explicit permission to use both 3-bytes-per-pixel and 4-bytes-per-pixel variations of the 16M color modes in the specification, but for sure both variations were used in practice. All modes (except mode 6A/102) are not meant to be used "blindly" by just setting the mode, but you were required to parse some information from the VESA mode info already in VESA 1.0. For example, the banking granularity was 4KB on Cirrus cards, and 64KB on most other cards. Also, padding at the end of a line was permitted. A 800x600 256-color mode was allowed to be implented with 1024 bytes per line, if the card had enough video memory (i.e. 1MB) for that configuration. Furthermore, some cards allowed to select different banks numbers for reading and writing, whereas other cards allowed different bank numbers for the bottom half of the A000 segment (A000-A7FF) and the top half (A800-AFFF). That's why you have "window A" and "window B" in the VESA mode info, which might be read-only, write-only or read-write.

Graphics chips were not built to implement "the one VESA standard", but VESA was built to provide an abstraction layer over different kind of Super-VGA cards. Applications that previously needed to have hard-coded knowledge about different Super-VGA implementations could now ask the Super-VGA card for their implementation details - but the applications still had to support the different approaches implemented in different cards. So while the hard-coded mode numbers fix some parameters of the video mode, like the number of displayable colors, the memory model (16-color mode use VGA-like planar design, higher color modes use unbanked linear memory) and the resolution, other parameters of the video mode are not fixed. The presence/absence of a reserved fourth bytes in 16M color modes is one of these non-fixed parameters. As DOSBox obviously intends to mimic a S3 video card, implementing 16M color modes at 4 bytes per pixel is exactly the right thing to do. If you use a physical S3 Vision964 card in a 486 or Pentium computer, you will also get 4 bytes per pixel in mode 010F.

videogamer555 wrote on 2023-02-20, 21:43:

Therefore, if you want a 320x200 32bpp mode, that mode must be given a number other than one of the numbers from the official VESA specifications. 24bpp modes must have exactly 3 bytes per pixel, while 32bit modes must have exactly 4 bytes per pixel.

As Wikipedia would phrase it: "Citation required". To the best of my knowledge, the quoted statement is not true, and hardware definitely didn't behave that way in the 90s.

Reply 16 of 19, by videogamer555

User metadata
Rank Member
Rank
Member
mkarcher wrote on 2023-02-21, 18:38:

This is not how VESA BIOSes behaved back in the 90s. S3 graphics chips used a 4 bytes per pixel in 16M color modes, mostly because that's required for VRAM based cards with direct DAC data path.

If you look at this table in Wikipedia from the VESA article, you will see that 24bit modes and 32bit modes are separate types of modes, and that none of the 32bit modes are standard (they are all shown in red meaning they can be used, but aren't required).

Screenshot_2023-02-21 VESA BIOS Extensions - Wikipedia.png
Filename
Screenshot_2023-02-21 VESA BIOS Extensions - Wikipedia.png
File size
43.99 KiB
Views
2377 views
File license
Public domain

As you can see, all of the VESA standard 16M color modes are 24bit modes. The only 32bit modes are nonstandard. In fact, mode 0x010F (320x200 16M colors, 24bits) doesn't even have a nonstandard equivalent mode with 32bits per pixel. The lowest resolution image with 32bits per pixel is 0x0124 (640x400 16M colors, 32bpp).

Yet for some reason, DosBox is using VESA standard mode 0x010F with 32bits per pixel.

Reply 17 of 19, by DosFreak

User metadata
Rank l33t++
Rank
l33t++

"For some reason"
Haven't the reasons already been stated?
Have you checked against a real S3 video card that DOSBox emulates?

How To Ask Questions The Smart Way
Make your games work offline

Reply 18 of 19, by videogamer555

User metadata
Rank Member
Rank
Member
DosFreak wrote on 2023-02-22, 02:13:

"For some reason"
Haven't the reasons already been stated?
Have you checked against a real S3 video card that DOSBox emulates?

I didn't know that was a real type of video card. I thought that was just a term used by the DosBox devs for the generic a SVGA card they were coding for DosBox. I figured that the they couldn't use a real graphics card's name, as that would be a trademark violation.

Reply 19 of 19, by mkarcher

User metadata
Rank l33t
Rank
l33t
videogamer555 wrote on 2023-02-22, 04:19:

I didn't know that was a real type of video card.

See https://en.wikipedia.org/wiki/S3_Trio . The Trio64 and Trio64V+ were very common graphics chips around 1995-1997. They were good 2D performers at a quite affordable price with good image quality (unless the card manufacturer did an awful job), and standard equipment in office computers.