Running several other applications like X-VESA after adding modes via the vbeplus utility (among others) would seem to suggest (or confirm) that double scan mode is not supported by the P9000. This would make sense for its intended use, of course. Still...

I don't know if chips can have undocumented/unsupported features. For example if you programmatically did a query to the chip for VBE information and it said double scan isn't supported... but you attempted to switch to a mode with the double scan flag set... what happens?

In any case - if you have a Diamond Viper VLB and want faster performance in DOOM via FastDOOM or Build engine games, you can always use this hacked, non-double scanned mode paired with a scaler. Extra work, but - perhaps a solution if you already have a scaler in your video output chain.

Hi CkRtech,

if I try to summarize your issue, I understand you have:

- standard VGA Mode 13h works correctly (fills the full screen), but has low FPS performance in 320x200 DOOM (presumably due to going through the Oak 2D chip),
- using a VESA TSR extension program to set up a custom 320x200 video mode in VESA improves FPS performance in VESA-enabled games (like Fastdoom and Duke3D), but results in a small window centered in full screen? (e.g. as if you had a 320x200 window centered inside a 640x400 resolution?) So you are looking for a double-scanning mode to be able to get the 320x200 window fill the whole screen?

The unfortunate challenge with VESA is that it only standardizes a software-level programming API and BIOS procedure calls; but it does not standardize any register level features.

For example, double-scanning is not a feature present in VESA. So there is no software API to specify double-scanning.

Standard VGA does have a hardware register to set double-scanning (CRTC register 0x3D4h/0x3D5h index 09h: Maximum Scan Line Register, bit 7, Scan Doubling), but VESA does not guarantee any hardware register compatibility with VGA. This means that there is no guarantee that adjusting that register after having set a VESA mode would result in the scan doubling taking any effect. It all depends on the graphics hardware.

They might have a separate custom register space to control Scan Doubling feature when a VESA mode is set, and this register might not live in the ISA I/O port address space, or there might not exist a register to achieve such a feature in VESA mode. There is unfortunately no telling without getting deep into the internals of the graphics card in question. You might try to see if you can locate a hardware/programmer reference for the Diamond Viper VLB.

If this were VGA and not VESA, then in addition to double-scanning 320x200 to 320x400, you would need to activate the 1:2 halved dot clock rate (VGA Sequencer Register 0x3C4h/0x3C5h index 01h: Clocking Mode Register, bit 3, Dot Clock Rate). This is because the 25.2 MHz pixel clock generates a 640x400 image, but to output 320x400, you'll have to divide the clock by two to get 12.5 MHz effective pixel clock. (otherwise with 25.2 MHz pixel clock, you'd get 640 pixels sequenced for every scanline)

But again there is a challenge with VESA, since there is no guarantee that this register takes any effect in VESA modes. If the engineers were very compatibility friendly towards programs that don't understand anything about VESA, they might implement VESA support "overlaid" on top of the VGA register space, in which case the 1:2 halved dot clock rate register might be honored. Or if they were eyeing to implement modern VESA support only and forget about legacy VGA stuff, they might ignore all VGA register writes whenever in a VESA video mode.

One way to probe here might be to write another TSR that force-sets the 1:2 Dot Clock Rate and Scan Doubling register bits and see if that does anything.

Or maybe locating the programming docs for the card might give some clues of what the extent of possibilities here might be.

Your summary sounds perfect.

I have found the P9100 documentation, but not the P9000. https://bitsavers.computerhistory.org/compone … inary_Nov93.pdf

As for the Diamond Viper VLB, I don't have any sort of technical documentation on it. Considering the P9000 application to win 3.1 and how Diamond went about using it, I wouldn't be surprised if there is some functionality for the P9000 - documented or not - that Diamond wouldn't have bothered to use on the card. It was designed as a Windows 3.1 accelerator, and anything fancy for DOS was an afterthought.

What is interesting is that some older versions of univbe as well as vogon's own Mumak's HWInfo version 6.2.6 will attempt to access VESA modes or attempt to query modes only to leave the card in a broken state. Flashing graphics or garbage graphics appear with a flashing cursor at the same time. You can cls to return the cursor to the top of the screen. You can change directories to move the cursor further to the right, but the text doesn't show up. Sometimes changing to a different VGA mode will fix it, but sometimes the problem remains. It takes a cold boot to fix the issue in that case.

Anyway - that has me curious as to just how the VGA Oak component interfaces with the P9000 chip.