Guys, could someone do an independent comparison of the speed of all the firmware versions on their systems, to see if there's actually a performance gain? I collected my own data using Dr.Hard.

At 1st we would need to download all 5 rom images somewhhere, I still have only 3. Btw your mod of 1ws stb rom was done on wrong offset so it cannot have any effect.

Yes, I saw your message. Unfortunately, I don’t have information about the correct offsets for those variables in the STB BIOS.
At the very least, please compare the performance of the original highspeed.rom file from GitHub with my version to confirm that the speed improvement is real and not just a result of some quirks in my hardware setup.

Yes, I need some time to find some free eprom/eeprom, erase it, pogramm... But I have some doubts as even in hispeed rom when disassembled there are no references to offsets you changed anywhere in code. So I would rather aim to reprogramm the mclk pll...

Well, I have found in S3 datasheet that RDY ctl min wait states is set by bit 4 in CR40 register. I wrote a small utility that displays a few S3 options from varoius CRs. With 0WS rom the bit was 0 and with 1WS rom the bit was 1 as expected. CRs seems to be unlocked by bios. So I cleared bit4 to 0 at runtime on 1WS rom and read it back to confirm the value has changed but it has not any effect on performance, strange... I coul search in dasmed 1WS rom if I find any CR40 manipulation and try to change it there.

Other though. Both roms reported me that memory config is 2-cycle EDO. Could modifying to 1-cycle EDO make it faster?

I also plan to add code for reading MCLK PLL regs to check how fast is running.

RayeR wrote on 2025-06-04, 13:44:

Well, I have found in S3 datasheet that RDY ctl min wait states is set by bit 4 in CR40 register. I wrote a small utility that displays a few S3 options from varoius CRs. With 0WS rom the bit was 0 and with 1WS rom the bit was 1 as expected. CRs seems to be unlocked by bios. So I cleared bit4 to 0 at runtime on 1WS rom and read it back to confirm the value has changed but it has not any effect on performance, strange... I coul search in dasmed 1WS rom if I find any CR40 manipulation and try to change it there.

Other though. Both roms reported me that memory config is 2-cycle EDO. Could modifying to 1-cycle EDO make it faster?

I also plan to add code for reading MCLK PLL regs to check how fast is running.

MCLK: There already is a tool for that, see Re: Tool to adjust the memory clock on Cirrus Logic CL-GD542x graphics cards . 2-cycle EDO vs. 1-cycle EDO is a strapping option. I used to think that the 765VL is strapped to 1-cycle EDO. VL with 1WS is already quite fast (up to 44MB/s at 33MHz if the mainboard doesn't add an extra clock for RDY synchronization), so you need a quite fast processor and a mainboard that doesn't add extra wait states to actually notice 0WS (up to 66MB/s at 33MHz). The 0WS/1WS difference is more noticeable on mainboards that do add an extra wait state to synchronize the RDY signal: In that case, zero WS at the cards allows up to 44MB/s and one WS at the card drops to 33MB/s.

Cool, I didn't know about this tool, I'll have to try it.
And what difference would you guess between 1/2-cycle EDO? It seems there are some other video memory timings CRs...

UPDATE:
good tool, changing EDO from 2 cycle to 1 cycle makes a huge difference in VESATEST, 15 -> 22 MB/s (RAM->FB)!

default MCLK=59,96MHz m=65, n=2, r=2 (well BIOS set it but I cannot see it in DASM)
In 2-cycle mode transfer speed scaled with increasing MCLK up to cca 73MHz where it capped to 22MB/s and even change to 1-cycle EDO didn't push more. I could push MCLK insanely high at 100MHz, over 104MHz I saw some snowing artifact and at ~110MHz it messed up textmode and hanged.

In Doom the MCLK effect is zero.
In Quake 320x200 and 640x480 also the same...

Another idea, as I read in other thread about ARK1000, it may help to improve performace lowering the refresh rate. Original 1WS STB BIOS outputs VESA mode at 75Hz which is nice on CRT but for LCD 60Hz is enough and more memory BW could left for GPU/CPU writes. This could be patched in video BIOS...

I've tried some generic PCI 86C765 BIOSes with my Trio VLB and most of them work without any issues. The fastest one for me is this one from Hercules Terminator 64/Video:
https://theretroweb.com/expansioncards/s/herc … r-64-video#bios
On DTK PKM-0038S E2-A M/B with newest ASUS VL/I-486SV2GX4 BIOS and PODP83 i have 20.3FPS in dosbench Quake and 23.4FPS on optimized Pentium version.

I don't know if anyone has mentioned this here before but the Windows 98 DDK seems to contain a full S3 Virge Modesetting as well as Direct3D driver (in folders \98DDK\src\display\mini\s3v and \98DDK\src\display\vdd\s3v, documented in 98DDK\help\dxddk.chm). I saw the creator of SoftGPU mentioned it as the base for the display mode setting in that project. It's probably not exactly easy to modify this to connect to VLB instead of PCI (and doesn't do anything for DOS or S3D) but surely it's easier than writing a whole new driver?

Also the Windows 2000 DDK has a Virge driver in NTDDK\src\video\displays\s3virge which is at least mostly in C instead of ASM but this one is a completely different driver model.

Unless you know someone who is volunteering their effort, I don't think anyone is still working on S3 Virge VLB Win9x/ntx drivers, nor DOS S3D functionality. Seems that a hardware fix is also needed, which from the sounds of it, isn't guaranteed.

I also assembled this execellent card for my 486. In DOS all works great, it's faster than my previous S3 805. In PC Bench I'm able to run tests with both Vesa 1.2 and Vesa 2.0 modes (after using the patched TSR).
However in Win 3.11 I'm unable to use any Vesa mode. Just starnadard VGA mode works, nothing else. Windows freeze during boot.
I confirmed that the problem is related just to my target 486 mainboard. With other VLB Socket 3 mainboard from Shuttle the S3 Trio card works without any problem with the same very same sound/LAN/Multi IO. I can get 1024x768 256 colors without any issue.
So the problem lies somewhere in my desired Socket 3 board.
Some details about my config:
1) Mainboard: DIGIS 486EL - linkhttps://theretroweb.com/motherboards/s/digicom-digis-486el
2) 8 MB EDRAM
3) Am5x86 133MHz in WT mode
3) SB 16 CT2290
4) LAN 3COM 3C509B + BootRom XT-IDE set at D000h - D3FFFh
5) Multi IO UMC on 16bit ISA with COM1 mouse + Primary HDD 6GB + Secondary CD-ROM LG + FDD 1.44
6) S3 Trio with STB Powergraph BIOS

With the very same mainboard S3 805 works without any problem in Windows 3.11.
I've tried to check many things so far:
- removed EMM386
- different settings for Vesa 2.0 TSR including no TSR at all
- lower ISA clock
- slow A20 gating
- different BIOS for Trio and different Windows drivers

All the time the problem is the same, Windows freezes during boot, sometimes it freezes with garbage on screen, sometimes with black screen only.
I thought that some RAM address are in colision with S3, but when I'm checking memory map with CheckIt I'm getting strange differences for 3 boots of the same computer in a row (with power off between these boot). Intrrupt vectors F1h - F6h are changing between boots. However for S3 805 I observe the same behavior. I'm attaching logs from CheckIt for reference.

Any advice what to do more? This card is great in DOS, but I'd like to get it work in Windows 3.11 too.

Have you eliminated the LFB at 16MB hole problem?

BitWrangler wrote on 2026-06-07, 16:47:

Have you eliminated the LFB at 16MB hole problem?

I'm not sure if I understand correctly, but 16MB hole I recall as the issue for ISA cards where due to addressing limittations they had used some address space between 15th and 16th MB for their purposes. I recall there was some BIOS option for this making memory hole remaping, but my BIOS does not have one. Acctualy my BIOS is very, very limited in available options. I'm attaching some screenshots. Additionally I made some check with AmiSetup and also in hidden options I don't find setting for memory hole.
Additionally I thought that with my 8MB RAM I'm safe, unless you meant that S3 Trio could put something in that address area? How can I check that?

Sorry, yes, looks eliminated if trouble is happening with only 8MB. VLBs can behave like ISA in some rare cases.

However, I guess you can look for MR Bios for that board.

VLB graphic cards usually map linear buffer at 32 or was it 64MB? so shouldnt be a problem with 8MB of ram.

rasz_pl wrote on 2026-06-08, 02:18:

VLB graphic cards usually map linear buffer at 32 or was it 64MB? so shouldnt be a problem with 8MB of ram.

The MK-765VL has the LFB area above 1024MiB (that's 1GiB), so no need to worry about addressing conflicts.

mkarcher wrote on 2026-06-08, 16:58:

rasz_pl wrote on 2026-06-08, 02:18:

VLB graphic cards usually map linear buffer at 32 or was it 64MB? so shouldnt be a problem with 8MB of ram.

The MK-765VL has the LFB area above 1024MiB (that's 1GiB), so no need to worry about addressing conflicts.

but maybe too high for the win3 VESA driver?

rasz_pl wrote on 2026-06-09, 04:42:

mkarcher wrote on 2026-06-08, 16:58:

The MK-765VL has the LFB area above 1024MiB (that's 1GiB), so no need to worry about addressing conflicts.

but maybe too high for the win3 VESA driver?

I believe the problem is not related to this, because on other VLB board the same S3 Trio works without any problem in Win 3.11 with the very same STB Windows driver.

zami555 wrote on 2026-06-09, 17:55:

I believe the problem is not related to this, because on other VLB board the same S3 Trio works without any problem in Win 3.11 with the very same STB Windows driver.

does the other one also map to 1GB?