VOGONS


Reply 20 of 32, by wbc

User metadata
Rank Member
Rank
Member

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)

--wbcbz7

Reply 21 of 32, by keropi

User metadata
Rank l33t++
Rank
l33t++

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

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 22 of 32, by keropi

User metadata
Rank l33t++
Rank
l33t++

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

eBh2YJP.jpg

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 🤣

🎵 🎧 PCMIDI MPU , OrpheusII , Action Rewind , Megacard and 🎶GoldLib soundcard website

Reply 23 of 32, by mrau

User metadata
Rank Oldbie
Rank
Oldbie

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;

Reply 24 of 32, by wbc

User metadata
Rank Member
Rank
Member
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? 😀

--wbcbz7

Reply 25 of 32, by The Serpent Rider

User metadata
Rank l33t++
Rank
l33t++

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.

ASUS S3 Trio64V2 DX and Virge DX.jpg
Filename
ASUS S3 Trio64V2 DX and Virge DX.jpg
File size
1.15 MiB
Views
2145 views
File license
Fair use/fair dealing exception

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

I must be some kind of standard: the anonymous gangbanger of the 21st century.

Reply 26 of 32, by The Serpent Rider

User metadata
Rank l33t++
Rank
l33t++

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 must be some kind of standard: the anonymous gangbanger of the 21st century.

Reply 27 of 32, by Gmlb256

User metadata
Rank l33t
Rank
l33t

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.

            ; VESA function 0x5 new routine
bankproc:
push cx

test bl, bl ; check for selected window
jnz @bankproc_fail ; window B is not supported

mov cx, dx
mov dx, 0x3D4
call unlock_extensions

; check for banking enabled
mov al, 0x31
out dx, al
inc dx
in al, dx
dec dx
test al, 1
jz @bankproc_lfb ; not supported in VGA or LFB modes

mov al, 0x6A
; check for get/set bank
test bh, bh
jnz @bankproc_get

; set new window pos
mov ah, cl
out dx, ax
call lock_extensions
; bugfix starts - set selected window on the DX register
xor dx, ax
mov dl, cl
; bugfix ends
jmp @bankproc_ok

@bankproc_get:
out dx, al
inc dx
in al, dx
dec dx
call lock_extensions
xor dx, dx
mov dl, al

@bankproc_ok:
mov ax, 0x004F
jmp @bankproc_done
@bankproc_fail:
mov ax, 0x014F
jmp @bankproc_done
@bankproc_lfb:
mov dx, cx
mov ax, 0x034F
@bankproc_done:
pop cx
retf

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

Attachments

  • Filename
    S3VBEFIX.ZIP
    File size
    21.76 KiB
    Downloads
    128 downloads
    File comment
    S3VBEFIX with the bugfix
    File license
    Public domain

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 28 of 32, by wbc

User metadata
Rank Member
Rank
Member

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": B58HDSTh.png
    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:
         The DirectColorModeInfo field describes important characteristics of
    direct color modes. Bit D0 specifies whether the color ramp of the
    DAC is fixed or programmable. If the color ramp is fixed, then it can
    not be changed. If the color ramp is programmable, it is assumed that
    the red, green, and blue lookup tables can be loaded by using VBE
    Function 09h. Bit D1 specifies whether the bits in the Rsvd field of
    the direct color pixel can be used by the application or are reserved,
    and thus unusable.

    D0 = Color ramp is fixed/programmable
    0 = Color ramp is fixed
    1 = Color ramp is programmable
    D1 = Bits in Rsvd field are usable/reserved
    0 = Bits in Rsvd field are reserved
    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 :(

--wbcbz7

Reply 29 of 32, by Gmlb256

User metadata
Rank l33t
Rank
l33t

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).

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 30 of 32, by wbc

User metadata
Rank Member
Rank
Member

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

S3VBEFIX /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

--wbcbz7

Reply 31 of 32, by wbc

User metadata
Rank Member
Rank
Member
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.

--wbcbz7

Reply 32 of 32, by Kahenraz

User metadata
Rank l33t
Rank
l33t

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 need to have an effect.

Re: Intel TC430HX Socket 7 motherboard repair

20221027_234856_resize_34.jpg
Filename
20221027_234856_resize_34.jpg
File size
161.34 KiB
Views
1187 views
File license
CC-BY-4.0