I heard of a guy managing to get widescreen resolutions out of 3.1x by hacking the video drivers for his video card. I wish I could find the link for where I saw that but it might be gone as I read that over 10 years ago.

On real hardware that is probably difficult, as every clock(and it's resulting horizontal pixels) is generated using dividers. And for pretty much all MDA and newer cards, those timings have a base divider of either 9(MDA-compatible) or 8(CGA-compatible, as well as EGA and (S)VGA) pixel clocks, meaning that everything (horizontally at least) must be a multiple of either 8 or 9 pixels. Then there's (at least for analog(VGA and up), perhaps digital as well) constraints on the receiving hardware, causing loss of sync(when the connected device can't keep up with horizontal or vertical rates) or permanent damage(for example feeding a too high vertical rate).
You could theoretically output a ~3125000Hz vertical sync onto a VGA using a 25MHz clock(8 pixels x 1 scanline), but that would burn out the display if you try to use it, if it can even keep up(and not lose sync immediately, which it probably will immediately when activated). Most displays are made with VGA compatibility in mind, so everything with the horizontal and vertical sync rate of 640x480x16 should work. The same for 800x600 for base SVGA monitors. Higher resolutions depend on the display itself for support.

superfury wrote on 2021-12-16, 22:12:

On real hardware that is probably difficult, as every clock(and it's resulting horizontal pixels) is generated using dividers. And for pretty much all MDA and newer cards, those timings have a base divider of either 9(MDA-compatible) or 8(CGA-compatible, as well as EGA and (S)VGA) pixel clocks, meaning that everything (horizontally at least) must be a multiple of either 8 or 9 pixels. Then there's (at least for analog(VGA and up), perhaps digital as well) constraints on the receiving hardware, causing loss of sync(when the connected device can't keep up with horizontal or vertical rates) or permanent damage(for example feeding a too high vertical rate).
You could theoretically output a ~3125000Hz vertical sync onto a VGA using a 25MHz clock(8 pixels x 1 scanline), but that would burn out the display if you try to use it, if it can even keep up(and not lose sync immediately, which it probably will immediately when activated). Most displays are made with VGA compatibility in mind, so everything with the horizontal and vertical sync rate of 640x480x16 should work. The same for 800x600 for base SVGA monitors. Higher resolutions depend on the display itself for support.

Oh wow, really interesting, thanks for the write up. I figured this would be tricky for various reasons considering no one has done it.

And yeah, I'm mainly thinking about using it for emulation/virtualization here, rather than trying to natively output arbitrary resolutions to an actual device (except maybe for more common resolutions that you could theoretically do in a sensible way). Like it would be a very nice addition to any kind of virtualization setup.

I wonder how VMware Fusion does this for Windows 98. I'm not sure if there's a way to tell exactly what kind of sync it's using for a given resolution. Maybe I can install an old version of Powerstrip and find out that way. Either way I suppose actually writing a driver that's able to pull something like this off would require some very specialist knowledge.

I'm speaking under correction, but maybe VBE can partially solve the issue.
Well, at least in emulation. With a bit of hacking, too.

There are at least two modified Windows 3.1 SVGA drivers available that use VBE instead of chip-specific video modes.
Alas, there's a catch - the SVGA driver uses one, hardcode configuration permanently (1024x768 pels ?, 256c palettized).

By using video modes, it's essentially up to the VGA/VBE BIOS to take care of timings and colour depts.
And from what I see, there are unofficial and weird video mode numbers out there.

https://en.wikipedia.org/wiki/VESA_BIOS_Extensions

Switching resolutions "on the fly" was a feature that officiall came with Windows 98, maybe Windows 95 also.
However, I *believe*, some drivers by ATI or ELSA provided that ability on Windows 3.1x, too.

Edit: Another idea would be to use emulation of an early video accelerator. Like TIGA, for example.
TIGA was very intelligent and high-level. The driver shipped with Windows 3.1 was merely an interface/helper driver.
The actual work was done by the TIGA drivers supplied by the TIGA cards.

I've just thought about it again. Then I remembered something about (S)VGA latches!
The 9 pixel divider can only be effectively used for text modes (the MDA/VGA text modes to be exact, where each 8th pixel is doubled for line drawing characters and given color number 0 for all others). It cannot work properly in graphics modes, since only the equivalent of 32-bits are latched and shifted out, but a 9th pixel would require another 4 bits, which aren't latched, resulting in 4 0-bits after every 32-bits being mixed in due to shifting the 32-bit register 36 times(shifting in zeroes). Thus in 16 color modes a black vertical line after each 8 pixels and the same effect on the horizontal data in 8/16/24/32-bit modes, messing up the colors entirely.

That's why multiples of 8 pixels are the only option.

Superfurry, what you wrote makes sense to me.
Thanks a lot for the explanation, too.
It reminds me of my father's tech voodoo, who wrote a whole CP/M FDD driver for his Z80 PC when he was young..

Another approach - How about not using VGA specific technology, at all?
Virtualbox deprecated its synthetic "VGA" device (VBoxVGA) a longer time ago, anyway.
That's why 3D acceleration broke for Win XP guests from v6.1 onwards, also.
The old VGA device became unsafe, so its pass-through feature was scrapped/disabled.
The newer releases feature a different device, or two (VBoxSVGA, VMSVGA), strictly speaking.
https://forums.virtualbox.org/viewtopic.php?t=94795
https://forums.virtualbox.org/viewtopic.php?t=96010
https://superuser.com/questions/1403123/what- … a-in-virtualbox

Windows 3.1 itself isn't dependent on VGA, if non-Windows applications aren't used.
Also, Windows 3.0 started to have more flexible drivers and Windows 3.1 improved upon this (GDI acceleration, first GUI accelerators).
Windows 2.x driver, by comparison, were static still and could be selected during Windows installation only.

With a *little bit* of thinkering and the help of the Win 3 SDK/DDK, a matching Windows 3.1 driver could be compiled in the future.
Maybe one that's using the communications channels of the VM, even.
So it could draw an overlay output directly using the host's OpenGL, not sure.
If not, it could at least use the VMs frame buffer device directly, without any BIOS/VGA specific mechanisms.

I'm speaking under correction, of course. I'm merely a layman, after all.

Edit: From what I remember, Wabi was essentially loading the Windows 3.x Enhanced-Mode kernal atop of Solaris/Linux kernal.
It successfully ran it without any VGA or DOS support.

https://en.wikipedia.org/wiki/Wabi_(software)
https://www.youtube.com/results?search_query=WABI+Caldera
Linux desktops with Wabi

There were custom builds for the Matrox Mystique so you could support fixed frequency screens , I owned one and it worked fine, could center and resize all in software too.

I remember some packages let you set everything custom within the limitations of the card, even had a utility to move the phase around in the case the lh & rh edges of the image were in the middle.
I was able to display 800x560 on a Tandy vga monitor but at a low refresh rate playing around with such a card.

I only really saw this capability under Windows 3.1 on older Matrox cards with custom drivers / control panel, without a custom bios driving a fixed frequency screen in plain dos could be dangerous

you can just run the 3.1 apps in winxp in vmware