mwdmeyer wrote on 2026-08-15, 03:37:

if you can run the dos exe I can collect info about your card and try and build a supported driver

Nice to see your great work. I'm impressed with what you'd like to achieve and crossing my fingers for success.
I believe so far nobody attached some results from survey tool so please find atached the results from my computer. It's the VLB card with S3 Trio64V+ chip (86C765) designed by Madao.
The mainboard in my computer is a bit uncommon as it uses EDRAM. There could be something suspicious in results as I'm experiencing issues with this card in Windows 3.11. None of the drivers dedicated for this S3 chip works there. Just plain VGA 3.0 driver works. In contrast in DOS everything works without any issue. (some details can be found here: Re: S3 ViRGE VLB project (or " Making a Concurrent for Creative 3D Blaster VLB" ))

I do have a VIRGE VLB card (prometheus) but without any hardware changes, running on TRIO64V+ VBIOS, so it's likely useless. But if I get the time I can do some tests for you

Thanks I have DOS survey tool:
https://github.com/michaeldale/velocity9x/rel … s/tag/survey-v2

Then I can build you a test driver.

mwdmeyer wrote on 2026-08-22, 11:41:

Do you know for the MMIO issue if you wrote a driver (and if so MMIO at A0000 is itself broken over VLB) or attempted to work a […]
Show full quote

Do you know for the MMIO issue if you wrote a driver (and if so MMIO at A0000 is itself broken over VLB) or attempted to work around with the existing Virge PCI MMIO driver?

Trio style MMIO puts its acceleration registers into one of two memory ranges CR53 bit 5:

A: the registers appear at 0xA0000–0xAFFFF (the 64 KiB segment normally used for VGA graphics memory).
B: the registers appear at 0xB8000–0xBFFFF (the text-mode segment, 32 KiB).

It does not matter what mode you use. I can't disclose any details, but the issue occurs when you mix access to framebuffer memory and certain regions of the MMIO space. One possible consequence ist corruption of the hardware configuration. The worst case is accidentally enabling bus interface features like PCI retries while the chip is in VL mode, which will lock up the VL bus at some time later. The PCI interface of the ViRGE does not have the same issue: The troublesome access patterns are handled perfectly by a PCI-connected ViRGE. As the issue only appears when you mix framebuffer and MMIO access, you won't observe it if you use variant A without having the LFB enabled, because there would be no way to access the framebuffer at all. On the other hand, variant B (the "Trio 64 new MMIO") allows a 64KB windows of the frambuffer at A000 while MMIO is at B800, which is susceptible to this problem even without using the LFB at some high memory address.

As the ViRGE/DX is quite closely related to the classic ViRGE, I wouldn't be surprised if the core still contains the same buggy VL interface, but it has just been shut down by S3 to prevent it from being used. I actually modded a PCI ViRGE/DX card to strap the chip like you would strap a classic ViRGE for VL, and the ViRGE/DX stayed in PCI mode, and reading the configuration strap register clearly showed that one of the two strap resistors for the bus interface configuration is not picked up by the ViRGE/DX.