PluMGMK/vbesvga.drv: Modern Generic SVGA driver for Windows 3.1

Modern Generic SVGA driver for Windows 3.1

This is a rewrite of the Windows 3.1 SVGA driver, designed to support all 8-bit, 16-bit, 24-bit or 32-bit graphics modes are available on any system that provides the VESA BIOS Extensions (so the VBE by name). It is based on the Video 7 SVGA driver included in the Win16 Driver Development Kitwith most of the hardware-specific code eliminated, and with support added for multi-byte pixels.

• To demonstrate that it is possible to run Windows 3.1 in True-Colour Full HD
• Because my AMD Radeon RX 5500 XT does not support 256-color modes, which renders the old VESA Patch nothing to me
• To help out any fellow enthusiasts who want to run old software on new hardware!

This True-Colour Full HD screenshot gives you an idea of ​​what’s been working so far. The color settings dialog shows that almost the entire Windows GUI renders correctly, and the Program Manager shows icons that work as well. The two windowed DOS prompts show that I’m running it in MS-DOS 6.20, and that I’m using a real AMD graphics card with seller poison equal to (C) 1988-2018, Advanced Micro Devices, Inc. and product name equal to NAVI14. Minesweeper looks OK, while Solitaire mostly works, but some glitches appear…

See the Issues page for more details on what these are not working now…

This screenshot shows the True Color rendering capability, in the Windows-XP derived icons used in the Calmira XP shell. the Advanced Task Manager for example reaffirming that we are on DOS 6.20 and Windows 3.10. It also says we’re on a 486, which of course isn’t true, but that’s just the latest CPU Windows 3.1 knows! Again, the debugx session at the DOS prompt confirms that I am using a real AMD graphics card with seller poison equal to (C) 1988-2018, Advanced Micro Devices, Inc. and product name equal to NAVI14 (reportedly a bit more readable this time!).

• Install both Win16 DDK and a contemporary version of Visual C++
• Put the VBESVGA folder from this repository in the DDK hierarchy, at 286/DISPLAY/8PLANE/VBESVGA
• ensuring 286\TOOLS from DDK and MSVC\BIN from Visual C++ is in your PATH
• Go to VBESVGA\mak folder and run make vbesvga.mak; it should create the file VBESVGA.DRV which can be loaded into Windows

• Put the VDDVBE folder from this repository in the DDK hierarchy, at 386/VDDVBE
• ensuring 386\TOOLS from DDK and MSVC\BIN from Visual C++ is in your PATH
• Go to VDDVBE folder and run nmake; it should create the file VDDVBE.386 which can be loaded into Windows

To enable the debugger WDEB386 work, you need to change some bytes:

• In position 63D8you have to change 0F 24 F0 on 66 33 C0
• In position 63DFyou have to change 0F 24 F8 on 66 33 C0

This removes references to TR6 and TR7 registerswhich crashes the system because they only exist on the 386, 486 and a few other less well-known chips!

The following changes are required in your C:\WINDOWS\SYSTEM.INI files:

• In the (boot) section, change the display.drv= line to be pointed vbesvga.drv. You must specify the full path, or else copy the file to C:\WINDOWS\SYSTEM. (Note that if the path is too long, the CodeView debugger may crash on startup!)
• In the (386Enh) section, change the display= line to be pointed vddvbe.386. Again, you must specify the full path, or else copy the file to C:\WINDOWS\SYSTEM.
• Make a (VBESVGA.DRV) section to configure the driver, as detailed UNDER.

This table lists the parameters you can set to (VBESVGA.DRV) section of SYSTEM.INI.

The VESA BIOS Extensions spec allows graphics firmware to provide an interface for Protected-Mode drivers. This driver tries to use this interface if possible, to avoid the need to allocate DOS blocks of memory to communicate with the BIOS. In theory, according to Page 21 of the specthe driver must find the part C000h for a structure that starts with the signature PMID and ending with a valid checksum to determine if this interface is supported or not. However, some firmwares don’t set the checksum correctly, and some firmwares “provide” the interface but don’t do QA to make sure it works. To account for this, four options are provided:

(VBESVGA.DRV)
PMIDcheck=sanity
Width=1920
Height=1080
Depth=16
DoubleBufRefreshRate=75

In general, the VBE modes used by this driver include a framebuffer that is larger than a single segment can handle (65536 bytes). VBE provides two strategies for dealing with this: bank switching and using linear framebuffers. A bank transfer involves mapping only one part at a time to physical memory, usually an address A0000hwhereas a linear framebuffer will be completely mapped to an area of ​​high memory (ie beyond the 1-MiB boundary). This driver prefers to use linear modes when available, but unfortunately, due to a bug in the DOSX.EXEit cannot be done when running Windows in Standard Mode while using EMM386. To ensure that the driver can use linear framebuffers, you must run Windows in 386 Enhanced Mode, or else. EMM386.

If using a linear framebuffer, the driver will also try to use one Double Bufferingwhich improves performance by ensuring that GDI operations do not need to touch video RAM directly. However, this involves allocating two copies of the framebuffer to the system RAM, which is quite expensive (especially since Windows 3.1 usually doesn’t take advantage of more than a quarter of a GiB). If it cannot allocate this much RAM, it reverts to direct VRAM access.

Usually, if you are using 386 Enhanced Mode (or Standard Mode without EMM386), with a modern graphics card and a decent amount of system RAM, then the driver may be able to do Double Buffering. In that case, you can adjust the refresh rate using the DoubleBufRefreshRate= putting on SYSTEM.INI!

When Windows boots, the driver queries the BIOS for available modes, and automatically selects the first one that meets the following criteria:

• Supported by current hardware according to BIOS
• Graphics mode (not text)
• Color mode (not black and white)
• The resolution matches what is specified in the SYSTEM.INI
• Total bit depth (ie red+green+blue+padding) is 1, 2, 3 or 4 bytes.
• Either packed-pixel or direct color framebuffer
• Significantly less depth (ie red+green+blue but no padding) matches what is specified in SYSTEM.INI

The driver first looks for linear modes, and if it doesn’t find it (or the system doesn’t support it), it goes back and looks for bank transfer modes. If it doesn’t find any mode that matches the above criteria, it switches the display back to text mode, prints an error message and returns to DOS.

Note that this automatic search is currently the only way the driver selects modes: you cannot give it a specific VESA mode number to use.