Photo of my system.

Yftul,

I am having trouble following your English, but will relay some of my problems and the solutions.

1) In some VGA modes, I had garbled characters. The solution was to resolder one of the memory pads. This pad was hard to find because when I pressed the multi-meter onto the memory lead, it would force contact with the pad.

2) On some instances, I had garbled characters on the screen after I had let the graphics card sit in a drawer for 2 years. I added generous flux to the Trio64V+ chip and manually reflowed each pin. The garbled characters disappeared.

3) On another card, everything appeared to work fine except at 1280x1024 in Windows 95. I think the image was noisy. The RAM was soldered fine, but replacing the Trio64V+ chip with another unit resolved the issue. While the issue was also most likely related to soldering, I spent several hours trying to get the original Trio64V+ chip working fine, but with no success. Flux and reflow didn't help this time. Immediately after replacing the Trio64V+ chip, it worked fine.

4) Some motherboards do not work well with this graphics card. If my memory is correct, the board wouldn't run in one of my VIP boards (PCI+ISA+VLB). It didn't run well in a few other odd motherboards as well. I'd suggest starting out testing on a VLB/ISA-only motherboard rather than a VLB board. I don't think VIA based 386/486 boards were the most common testing platform. Do you have a motherboard based on UMC or SiS for testing, but not the M919?

Alright, I’ll give AI a shot, since Google Translate still struggles with proper technical translation.

The issue of incomplete soldering is very real—each of these cards required touch-ups in multiple places. It’s been an ongoing challenge.

There’s also a compatibility issue. None of these cards will POST on the FIC 486-VIP-IO motherboard. Since I’m currently away from home, I don’t have access to my broader collection of boards, so I’m unable to test them on alternative systems at the moment.

As for quirks specific to these video cards, I’ve observed graphical artifacts when launching Age of Empires and Might and Magic VII. I’m not entirely certain the cards are to blame—it could very well be a driver-related issue.

Regarding image noise, out of the two cards I own, one produces minor noise artifacts, but only when running at 40 MHz. At 33 MHz, the output is clean. This suggests the issue likely stems from the video chip itself rather than the surrounding circuitry.

Now, regarding the performance-boosting modification: while comparing multiple video cards that came into my possession, I noticed one significantly outperformed the others. I proceeded to compare their BIOS dumps and found differences in certain constants. After replicating these changes on a VLB card, it too exhibited noticeably better performance, with no adverse impact on stability or functionality.

Yftul wrote on 2025-05-17, 05:44:

Now, regarding the performance-boosting modification: while comparing multiple video cards that came into my possession, I noticed one significantly outperformed the others. I proceeded to compare their BIOS dumps and found differences in certain constants. After replicating these changes on a VLB card, it too exhibited noticeably better performance, with no adverse impact on stability or functionality.

About what videocards are you talking? Trio64v+ based? What constants? Maybe you changed some vram timing.

I think that you and feipoa have different issues caused by soldering but in my case i'm pretty sure it's soldered well (inspected with binocular microscope) and I don't have any image quality issues like artifacts or broken fonts. VMT (video memory test) passed multiple times. So my only problem is switching back ftom gfx to txt mode with 0ws ROM.

Yes, all the cards were based on the Trio64V+ chipset. The constants are likely related to memory access settings.

OK, can you share more details about what data/offset you changed, if you disassembled that part of code what it really do - what S3 regs it sets? It makes sense that videobios which set faster video memory timings would have better perf. I have 45ns DRAMs soldered on so maybe it could be pushed a bit more...

I didn’t perform a full disassembly of the code at the time; only two constants were changed, right at the beginning of the binary. If I’m not mistaken, they were 32-bit and 8-bit. You can find the exact addresses by doing a simple comparison using, say, the win utility fc: fc bin1 bin2 /b. If you decide to experiment, don’t forget to also update the file’s checksum (the last byte).

If I compare PG64V12.BIN and HighSpeed_ROM.bin from the Github they start to differ at:
00000015: 3D A4
00000016: 1A 11
00000018: 00 10
00000019: 00 01
0000001A: 9B 6B
0000001B: 0D 4E
0000001C: A2 6F
0000001D: 0D 4E
You mean this? What register is fed by it?

Please use original project's highspeed rom and my modification.

S3_trio64V+_vlb>fc highspeed_ROM.BIN highspeed_ROM_mod.bin /b
Сравнение файлов highspeed_ROM.BIN и HIGHSPEED_ROM_MOD.BIN
0000003C: A9 14 <-- 8 bit const
000000A6: 41 28 <-- 32 bit const
000000A7: 42 22
000000A8: 28 25
000000A9: 41 22
00007FFF: FE EE <-- checksum

And where can I DL your modified ROM?

Ah, here, would be nice if madao can add link to the 1st post... Re: S3 ViRGE VLB project (or " Making a Concurrent for Creative 3D Blaster VLB" )

Please can you also do this mod on original STB powergraph 64 ROM?

I'm not sure if it will work, you can try it on your own system and notify us.

S3_trio64V+_vlb>fc PG64V12.BIN PG64V12_mod.bin /b

0000003C: 3C 14
000000A6: 54 28
000000A7: 65 22
000000A8: 63 25
000000A9: 68 22
00007FFF: 28 43

It seems the difference is within the margin of error, so there's not much point in modifying it—unless we choose more aggressive constants.

Thanks. It would help dasm bios code and try to understand what that values means, into which registers are loaded and find in datasheet how to properly calculate them. Maybe it would be e.g. some PLL constants (multiplier and divider) or so. I could give a try in IDA. Also it would be good experiment if we can modify powergraph rom to 0ws...

There aren’t many options — most likely it’s either the memory settings or the chip's frequency.
Try disassembling it, maybe you can still squeeze something more out of this card.
I'm currently trying to figure out another issue, but so far not very successfully.

Yftul wrote on 2025-05-22, 12:26:

S3_trio64V+_vlb>fc PG64V12.BIN PG64V12_mod.bin /b 0000003C: 3C 14 000000A6: 54 28 000000A7: 65 22 000000A8: 63 25 000000A9: 68 2 […]
Show full quote

S3_trio64V+_vlb>fc PG64V12.BIN PG64V12_mod.bin /b
0000003C: 3C 14
000000A6: 54 28
000000A7: 65 22
000000A8: 63 25
000000A9: 68 22
00007FFF: 28 43

This offsets are not correct for PG64V12.BIN!
There's a BIOS string "Copyright 1987-1992 Phoenix Technologies Ltd." at offset 008Ah so this mean 32bit magic constant couldn't lay inside that string, your modded version changed it to "Copyright 1987-1992 Phoenix ("%"nologies Ltd." this cannot have desired effect.

I tried to disassemble HighSpeed_ROM.bin in IDA but it didn't show any reference to byte and dword at offsets 3Ch and A6h from code.
I looked at Trio64V+ datasheet and I think that most speed difference can be caused by MCLK (memory controller clock). There are also some registers for more video RAM tuning like various precharge and refresh timing values but I guess it would have minor effect. MCLK is generated by 1 of 2 PLLs according to formula:
fMCLK = fref*(M+2)/[(N+2)*2^R]
where M: [1-128], N: [1-31], R: [0-3]
M is set in SR11.6:0 reg.
N is set in SR10.4:0 reg.
R is set in SR10.6:5 reg.
new values are loaded to PLL by setting SR15.0 bit to 1 and back to 0
This registers are not directly mapped in IO space but accessed via 2 IO ports:
3C4h - index (e.g. 10h for SR10)
3C5h - data (value of SRxx)
And before writting to SR9-SR1C it has to be unlocked before by writting x6h to SR8

The default MCLK is 45MHz after power on and can be set up to 60MHz, maybe even higher...

Which BIOS are you disassembling? The 5 of know of are:

1) STB Powergraph 64V v1.2 0 WS from Madao
2) STB Powergraph 64V v1.2 1 WS from Madao
3) STB Powergraph 64V v2.1 1 WS
4) S3 generic 86C765 v1.03-08N
5) S3 generic 86C765 v1.03-08N "high speed modby Yftul"

RayeR wrote on 2025-05-24, 00:59:

The default MCLK is 45MHz after power on and can be set up to 60MHz, maybe even higher...

Do we know which MCLK speeds have been attempted? If it is anything like the ARK1000VL, we were able to increase MCLK from 55 MHz to 80 MHz, but DRAM had to be 50 ns or better. 60 ns could do 70 MHz. Where to obtain 110 MHz RAMDAC for ARK1000VL graphics card?

It's HighSpeed_ROM.bin from GitHub https://github.com/matt1187/765VL/tree/main/rom
Where are the others ROMs you listed? Esp. the 1) STB Powergraph 64V v1.2 0 WS from Madao ? That one on GitHub is 1WS.

I also DASMed PG64V12.BIN 1WS from GitHub and I cannot find code that would set MCLK PLL only the DCLK so it may run at default 45MHz (slow)

All the drivers floating around gets confusing. Here's the breakdown. I checked via GTKhash to confirm.

1) STB Powergraph 64V v1.2 0 WS from Madao ----> It is my understanding that this is the 0 ws version of the STB branded driver. I think Madao or mkarcher released it or provided direction on how to edit it. I don't recall.

2) STB Powergraph 64V v1.2 1 WS from Madao ----> PG64V12.zip from github. Standard STB 1ws driver.

3) STB Powergraph 64V v2.1 1 WS ----> found online somewhere; not modified. Standard STB driver, but later revision.

4) S3 generic 86C765 v1.03-08N ----> highspeed_ROM.zip
I thought this was just a generic S3 765 driver. It is actually a 0 ws S3 driver? Or are there other improvements which make it faster compared to item 2) above ?

5) S3 generic 86C765 v1.03-08N "high speed mod by Yftul" ----> highspeed_ROM_mod.7z. Are you able to list what Yftul changed to make it faster?

I searched through this thread and didn' t find any other ROMs than Ytful's. I also searched for "0WS" string. Ytful's ROM changes just 1 byte and 1 dword but I cannot find any references in dasmed code to this so I'm confused about that, it's not clear what it does and in what registers it's loaded. It seems all regs for PLL and memctrl settings are 8-bit not 32-bit...