After two months of silence... we are back with a new release 😉

Changes since 0.5.1:

• some user interface fixes (help wasn't worked as intended and some strings were screwed up)
• VESA function 0x1 fake memory size patcher fixes:
  • new video page number is limited to 127 (some LAME applications treat this field as signed byte, which if incorrect and sometimes can cause problems and crashes)
  • new video page number calc procedure now uses only 16 bit registers, therefore S3VBEFIX probably can run on 286 now (is someone uses S3 cards in 286 machines? 😀
• VESA function 0x6 new scanlines number patcher (fixes this and possibly other issues while using /M[x] key)

^ great, time to update 😀
thanks for the release wbc!

I tried v0.52 and naturally it added the 320x400 resolution I wanted for DN3D 😀 but I noticed it detected my 8MB Speedstar A55 as a 4MB card

is this normal ?

funny thing is that I had tested previous version and completely forgot about it, I even found some DN3D framerate notes I made ... I need a brain defrag 🤣

i don't think it matters really, 4mb is enough for that game and mode anyway; also i think it's just bad detection, it was common back in the day and did not influence performance in any way;

keropi wrote:

is this normal ?

probably not 😀
Which amount of memory is reported by other VESA applications/Windows drivers? and AFAIK you are using that patched BIOS version or something else? 😀

Apparently this fix does not fully work on some cards. I have two practically identical ASUS cards, one is Trio64V2/DX and the other is Virge DX. Patch works fine with Trio64, but Virge DX does not show any additional VESA modes, performance is increased though.

Switched to BIOS chip from a common Virge DX card and the problem disappeared. It seems some vendor altered BIOS might cause problems.

Major note: vertical retrace command does not affect VESA modes in the Build engine games. For example, Diamond SpeedStar A55 has forced VSync in BIOS and S3VBEFIX (at its current state) can't fix that, which results in horrible performance.

I've found a bug when trying to use a VESA video mode on Chasm: The Rift while running S3VBEFIX it causes the computer not to display anything and freeze. It is when attempting to use Int 10h AX=4F05H (Display Window Control) after changing the resolution.

The culprit is in the bankproc routine after calling lock_extensions and then jumping where the location of @bankproc_ok is without setting the selected window position on the DX register.

1            ; VESA function 0x5 new routine
2bankproc:
3            push    cx
4
5            test    bl, bl              ; check for selected window
6            jnz     @bankproc_fail      ; window B is not supported
7
8            mov     cx, dx
9            mov     dx, 0x3D4
10            call    unlock_extensions
11
12            ; check for banking enabled
13            mov     al, 0x31
14            out     dx, al
15            inc     dx
16            in      al, dx
17            dec     dx
18            test    al, 1
19            jz      @bankproc_lfb       ; not supported in VGA or LFB modes
20
21            mov     al, 0x6A
22            ; check for get/set bank
23            test    bh, bh
24            jnz     @bankproc_get
25
26            ; set new window pos
27            mov     ah, cl
28            out     dx, ax
29            call    lock_extensions
30            ; bugfix starts - set selected window on the DX register
31            xor     dx, ax
32            mov     dl, cl
33            ; bugfix ends
34            jmp     @bankproc_ok
35
36@bankproc_get:
37            out     dx, al
38            inc     dx
39            in      al, dx
40            dec     dx
41            call    lock_extensions
42            xor     dx, dx
43            mov     dl, al
44
45@bankproc_ok:
46            mov     ax, 0x004F
47            jmp     @bankproc_done
48@bankproc_fail:
49            mov     ax, 0x014F
50            jmp     @bankproc_done
51@bankproc_lfb:
52            mov     dx, cx
53            mov     ax, 0x034F
54@bankproc_done:
55            pop     cx
56            retf

I attached a fixed version which I assembled it in case anyone needs it.

thanks for the bugfix :) confirmed on ViRGE/DX with 2.01.07 BIOS and Chasm v 1.6 (crashes with Runtime Error 216 without fix). yeah the bank procedure is somewhat buggy, @bankproc_get, for example, always returns 0x59 due to value read from CRTC register not preserved during lock_extensions call, that was the 6 years old codebase :D

I've finally got a Savage4 (particulary, the Creative 3D Blaster 32MB AGP), and noticed a few more points:

• banked modes booster does not work anymore. in fact, Savage4 datasheet lists only 32MB option (CR58 bits 1-0 == 11), others are "Reserved":
  In practice, that means banking is not working and display stays blank (but seemingly applications don't crash).
• while setting new VESA mode, there is significant (~2sec) blank screen delay, then actual mode set happens. This is observed with stock Creative BIOS, regardless of S3VBEFIX loaded or not, I'll try with latest generic S3 BIOS later.
• the RAMDAC is inherited from Trio3D line, with 8-bit palette and gamma correction support. VBE Mode info block have a DirectColorModeInfo field which describes RAMDAC capabilities in Hi/TrueColor modes:
  Copy code to clipboard

  1     The DirectColorModeInfo field describes important characteristics of
  2     direct color modes.  Bit D0 specifies whether the color ramp of the
  3     DAC is fixed or programmable. If the color ramp is fixed, then it can
  4     not be changed. If the color ramp is programmable, it is assumed that
  5     the red, green, and blue lookup tables can be loaded by using VBE
  6     Function 09h.  Bit D1 specifies whether the bits in the Rsvd field of
  7     the direct color pixel can be used by the application or are reserved,
  8     and thus unusable.
  9
  10     D0   =    Color ramp is fixed/programmable
  11          0 =  Color ramp is fixed
  12          1 =  Color ramp is programmable
  13     D1   =    Bits in Rsvd field are usable/reserved
  14          0 =  Bits in Rsvd field are reserved
  15          1 =  Bits in Rsvd field are usable by the application
  

  Thus, it is theoretically possible to perform hardware gamma-correction in Hi/TrueColor VESA modes on Trio3D/Savage cards (as in Windows), albeit I don't know of any application taking any advantage of this feature, as it is not widely supported (older S3 Trio64/ViRGE line have 6-bit RAMDAC CLUT without any gamma correctin capability, same for most of other graphics chips). Anyway, I tested it and integrated in S3VBEFIX as option (exposing gamma capability in VBE mode info, enabling gamma for Hi/TrueColor modes and uploading identity gamma ramp), and seemingly it works fine :)

i will probably post the updated version soon, if anyone could help with testing on more hardware, as my Trio3D/2X does not work anymore for absolutely no reason :(

You're welcome!

I could test the hardware gamma correction support in DOS with my S3 Trio3D/2X card. 😀

BTW, could support be extended to the VBE Protected Mode Interface? Said interface has a protected mode version of the "set display start" function. Programs that are using it makes "wait for vertical retrace" parameter of S3VBEFIX do nothing (especially with Build-based games as mentioned by The Serpent Rider times ago).

meanwhile.... S3VBEFIX v0.6.0!

List of new features:

• VESA BIOS Extensions reported version override
• Linear Frame Buffer control (default, off or force on)
• Maximum video page count limit setting - useful for apps/games with broken double/triple-buffer support (i.e. fix Build Engine games HUD/weapon flicker or 30fps lock at expense of possible tearing)
• VESA Get/Set Palette (0x4F09) custom procedure - for "fake VBE 2.0" feature, see below
• VESA 320x400/320x480 modes are now added only if requested by /X switch
• VESA Get Current Mode (0x4F03) now returns correct mode number for 320x400/320x480 modes created by /X switch
• Hi/TrueColor gamma correction option for S3 Trio3D/Savage. NOTE it does not allow gamma control itself, only allows to load gamma ramp inside application. If anyone is willing to waste 768 bytes of memory, I might add this in the future :)
• "fake VBE 2.0" feature - enables LFB and palette functions for VBE 1.2 video BIOSes (Trio64/V+/original ViRGE) - experimental, see below
• optional INT 6D hooking (debug only, disables release feature!)

Changes since 0.5.2 (db20533):

• fix broken VESA Display Window Control (0x4F05) procedure - return current bank in DX (fix Chasm: The Rift Runtime Error 216)

Download link in the first post or here :)

now a bit more words abount "fake VBE 2.0" feature:
NOTE: this is a dirty hack allowing to enable partial VBE 2.0 support on VBE 1.2 capable S3 video BIOSes (primarily, Trio64/V+/original ViRGE). It seems to work with most applications (Quake, Duke3D, some apps/demos) but it might fail in more advanced cases. USE AT OWN RISK!

Since S3VBEFIX now supports VBE version override and LFB control, it is possible to force LFB version to 2.0 or later, and enable LFB capability. This alone is usually enough to run most LFB applications, but some 256 color games (like Quake) use VBE Get/Set Palette (0x4F09) function, which is not present in VBE 1.2. You can install custom 0x4F09 procedure with /Q switch, but it has to be done during installation.

To activate fake VBE 2.0 mode, run

1S3VBEFIX /V200 /L2 /Q

NOTE: S3VBEFIX does NOT initialize VBE 2.0-specific controller info fields like adapter name/revision/vendor string pointers, leaving them at whatever BIOS has returned (usually zeroes, so these pointers are NULL). Some applications may not like this. Moreover, SciTech Display Doctor's VBETEST may hang or crash during mode test. Besides that, no additional VESA modes are added (except for /X switch but those 320x400 / 320x480 modes are hacked from existing 320x200 / 320x240 modes, and if BIOS does not provide them, then /X switch is useless). VBE 2.0 protected mode services (0x4F0A) are also not inplemented, or, rather passed through the BIOS :)

I don't have access to my original ViRGE now, so if anyone wants to try this on their cards, please leave the feedback and bug reports either here or on GitHub Issues. If anyone have a VLB card, that would be amazing to test on those, especially LFB support :D

Gmlb256 wrote on 2022-10-02, 16:34:

BTW, could support be extended to the VBE Protected Mode Interface? Said interface has a protected mode version of the "set display start" function. Programs that are using it makes "wait for vertical retrace" parameter of S3VBEFIX do nothing (especially with Build-based games as mentioned by The Serpent Rider times ago).

that would require complete rewriting of PM interface, so it's easier to disable it by making the 0x4F0A function return error and forcing applications to revert to real-mode INT10 code.

regarding Build Engine issues, the workaround now is to completely disable double buffer by /P1 key :) I might reimplement Set Display Start function later.

Following up on this. It does not fix the overbright problem with the S3 ViRGE intergrated into my Intel 430HX motherboard. It also seems to be immune to other methods of fixing it, which work on other cards that are not integrated. I managed to find a compatible BIOS that could be flashed to shadow ROM, which may help to provide some insight on why previously known working methods don't seem to have an effect.

Re: Intel TC430HX Socket 7 motherboard repair

Hi
Would this work on VIA video cards derived from S3 Savage? CLE266, UniChrome, Chrome9HC etc
I know the thread is old yes

This is an old thread and probably not the right place to ask this, but thus far, this is the only custom S3 TSR I've found on the internet, so here goes...can this custom TSR be used, or modified in some way, to fix DOS screen scaling for 320x200 games so that they run in a stretched 4:3 aspect ratio? My biggest problem with my Toshiba ViRGE MX laptop is that DOS games running in 320x200 simply zoom-scales the display, using 640x480 and filling in the rest of the display with black bars. Other variants of this same Toshiba Tecra line that had a C&T 65550 or 65554 instead of the ViRGE MX had a custom TSR that did exactly this, allowing for filled full-screen 4:3 aspect ratio DOS games running in stretched 320x200, how most DOS games were intended to be run.

It may very well be out of the scope of the intention of this TSR, but it's a shot in the dark considering this is the only person brave enough to have tackled a custom S3 TSR that I can find.

Bruno128 wrote on 2024-07-26, 20:52:

Hi
Would this work on VIA video cards derived from S3 Savage? CLE266, UniChrome, Chrome9HC etc
I know the thread is old yes

I have a UniChrome-based laptop but didn't even tested it nor intended to work on later VIA integrated graphics, so it may or may not work in this case.

EriolGaurhoth wrote on 2024-08-16, 21:18:

This is an old thread and probably not the right place to ask this, but thus far, this is the only custom S3 TSR I've found on the internet, so here goes...can this custom TSR be used, or modified in some way, to fix DOS screen scaling for 320x200 games so that they run in a stretched 4:3 aspect ratio? My biggest problem with my Toshiba ViRGE MX laptop is that DOS games running in 320x200 simply zoom-scales the display, using 640x480 and filling in the rest of the display with black bars. Other variants of this same Toshiba Tecra line that had a C&T 65550 or 65554 instead of the ViRGE MX had a custom TSR that did exactly this, allowing for filled full-screen 4:3 aspect ratio DOS games running in stretched 320x200, how most DOS games were intended to be run.

It may very well be out of the scope of the intention of this TSR, but it's a shot in the dark considering this is the only person brave enough to have tackled a custom S3 TSR that I can find.

I am pretty sure this is possible, but I can't gurantee that i'll make such fix in the near future, as I'm pretty busy with other projects + don't have any hardware to experiment on, and seems that ViRGE/MX datasheet is not available online - on the other hand, XFree86 seems to support ViRGE/MX so this could be used as a reference.

I am in the same boat with Tecra 780 and screen stretch/scale issue. Would be so good if you could look into this - I would definitely owe you one!

wbc wrote on 2024-09-03, 13:10:

EriolGaurhoth wrote on 2024-08-16, 21:18:

This is an old thread and probably not the right place to ask this, but thus far, this is the only custom S3 TSR I've found on the internet, so here goes...can this custom TSR be used, or modified in some way, to fix DOS screen scaling for 320x200 games so that they run in a stretched 4:3 aspect ratio? My biggest problem with my Toshiba ViRGE MX laptop is that DOS games running in 320x200 simply zoom-scales the display, using 640x480 and filling in the rest of the display with black bars. Other variants of this same Toshiba Tecra line that had a C&T 65550 or 65554 instead of the ViRGE MX had a custom TSR that did exactly this, allowing for filled full-screen 4:3 aspect ratio DOS games running in stretched 320x200, how most DOS games were intended to be run.

It may very well be out of the scope of the intention of this TSR, but it's a shot in the dark considering this is the only person brave enough to have tackled a custom S3 TSR that I can find.

I am pretty sure this is possible, but I can't gurantee that i'll make such fix in the near future, as I'm pretty busy with other projects + don't have any hardware to experiment on, and seems that ViRGE/MX datasheet is not available online - on the other hand, XFree86 seems to support ViRGE/MX so this could be used as a reference.

I too am interested in seeing if functionality could be built to enable this for the Virge/MX.

The Virge datasheet seems to make mention of two "stream processors" which can scale two different pixel pipelines.

The reference manual indicates that whilst the vertical scaling uses line doubling, the horizontal can either use linear methods, or optionally a bilinear filter and non-power-of-two scaling. That would seem to give a possible route to go full screen for 320x200/240 on both 800x600 and 1024x768 panels.