VOGONS


Reply 140 of 155, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Has anyone else managed to test their STB PowerGraph 64V+ replica card? I recently finished assembly of my card and noticed something perculiar. Occasionally, during quick changes of text on the screen in DOS, e.g. after selecting Windows 95 from the boot loader, I will see a horizontal line that appears and disappears as shown. There's no corruption in DOOM, Quake, 3Dbench, etc. It only occurs during rapid text changes in DOS. This horizontal line appears, for perhaps 1/30 or 1/60 of a second. I am using the original STB PowerGraph 64V+ BIOS, not the 0WS BIOS.

Trio64Vplus_replica_testing_1.png
Filename
Trio64Vplus_replica_testing_1.png
File size
464.92 KiB
Views
768 views
File license
CC-BY-4.0

Another issue I've encountered is sometimes the display won't show at power-on. This has occurred on two different motherboards now. The solution on motherboard A was to hold the reset button down for a full 3 seconds. On motherboard B, this method didn't work, but a simple power cycle did work.

What did work was the hacked 0 ws BIOS on my ALi PANDA based motherboard when the FSB was 25 MHz.

Ultimate 486 Benchmark | Ultimate 686 Benchmark | Cyrix 5x86 Enhancements | 486 Overkill Graphics | Worlds Fastest 486

Reply 141 of 155, by TheMobRules

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote on 2022-03-07, 14:02:
Has anyone else managed to test their STB PowerGraph 64V+ replica card? I recently finished assembly of my card and noticed som […]
Show full quote

Has anyone else managed to test their STB PowerGraph 64V+ replica card? I recently finished assembly of my card and noticed something perculiar. Occasionally, during quick changes of text on the screen in DOS, e.g. after selecting Windows 95 from the boot loader, I will see a horizontal line that appears and disappears as shown. There's no corruption in DOOM, Quake, 3Dbench, etc. It only occurs during rapid text changes in DOS. This horizontal line appears, for perhaps 1/30 or 1/60 of a second. I am using the original STB PowerGraph 64V+ BIOS, not the 0WS BIOS.

Trio64Vplus_replica_testing_1.png

Another issue I've encountered is sometimes the display won't show at power-on. This has occurred on two different motherboards now. The solution on motherboard A was to hold the reset button down for a full 3 seconds. On motherboard B, this method didn't work, but a simple power cycle did work.

What did work was the hacked 0 ws BIOS on my ALi PANDA based motherboard when the FSB was 25 MHz.

A couple of days ago I completed assembly of my card, but I haven't had much time to test it, most likely during the weekend I will be able dedicate a few more hours. This is what I have so far:

I tried both the stock STB PG64V+ BIOS (1WS) and the version modded by Madao for 0WS. Both appear to be working perfectly... which is strange, as Madao mentioned that Windows 3.1 fails when using 0WS, but I'm able to load it just fine with the 0WS PG64V+ modded BIOS, at least using the generic VGA driver. There's another BIOS that Madao sent me I haven't tested yet called "highspeed ROM", is that the one that causes problems with Win3.1? What's the difference between that one and the 0WS modded Powergraph BIOS?

I don't seem to be experiencing the issues that Feipoa mentions... after testing with 3 different boards (two SiS471 and one UM8494/8496, all of them using 33MHz bus speed and 0WS on the VESA local bus) I always get the display after power-on. Regarding the horizontal line, I haven't noticed that, but I don't have Win95 in my test drive, just DOS and Win3.1. @feipoa is there any consistent way to reproduce that other than loading Win95?

The only issue I have is that UniVBE does not enable the LFB on the card so I cannot get the speed boost for VESA modes, and loading S3VBE20 results in a black screen when changing to a VESA mode. But apparently this is expected behavior even on the original STB cards. In the My Very Long Bus Adventure thread Madao mentions the need for a patched S3VBE20 but I don't know if this exists or what kind of patch it would take to get the LFB working.

Reply 142 of 155, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie
TheMobRules wrote on 2022-04-20, 20:40:

In the My Very Long Bus Adventure thread Madao mentions the need for a patched S3VBE20 but I don't know if this exists or what kind of patch it would take to get the LFB working.

I wrote that patch for S3VBE20 that enables LFB support for VL cards. The issue is that S3VBE20 tries to program the S3 chip to some specific LFB address (like 64MB), but the S3 Trio64/V+ in LPB mode (that's what the 765VL-000 implements) doesn't support programmable LFB addresses, but requires the logic around the Trio64/V+ to detect the LFB address and tell the chip "this is an LFB cycle for you".

The LFB base configuration register still exists in the Trio64/V+, but it is (mostly) ignored in VL mode. The BIOSes distributed by Madao initalize the register to a value that actually matches the external hard-wired decoder, so if software would just trust the base address register instead of trying to reprogram it, it would work out-of-the-box with the 765VL-000. "Just trusting the base register" is exactly what you also need to do if the S3 chip is a PCI chip, as for PCI cards, the BIOS assigns the address during PCI initialization, and you better don't change anything afterwards. IIRC the classic base address register is read-only in PCI mode.

So you "just" need to decompress the packed S3VBE20 executable, and patch it to treat the LFB address determination for VL cards just as it is for PCI cards.

As S3VBE20 is not "free/open source software", I don't have a license to modify it, to run modified versions, and certainly not to distribute modified versions, though. If you want to take the legal risk yourself, get S3VBE/Core 2.0 version 3.18, understand that the terms of use explicitly state that the license for using, copying and distributing only applies "if you don't modify the files in this package in any way", so you certainly wouldn't undo the LZEXE compression, and patch the byte at offset 0x2d2f from 0x75 to 0xEB.

Reply 143 of 155, by TheMobRules

User metadata
Rank Oldbie
Rank
Oldbie
mkarcher wrote on 2022-04-20, 21:15:
I wrote that patch for S3VBE20 that enables LFB support for VL cards. The issue is that S3VBE20 tries to program the S3 chip to […]
Show full quote

I wrote that patch for S3VBE20 that enables LFB support for VL cards. The issue is that S3VBE20 tries to program the S3 chip to some specific LFB address (like 64MB), but the S3 Trio64/V+ in LPB mode (that's what the 765VL-000 implements) doesn't support programmable LFB addresses, but requires the logic around the Trio64/V+ to detect the LFB address and tell the chip "this is an LFB cycle for you".

The LFB base configuration register still exists in the Trio64/V+, but it is (mostly) ignored in VL mode. The BIOSes distributed by Madao initalize the register to a value that actually matches the external hard-wired decoder, so if software would just trust the base address register instead of trying to reprogram it, it would work out-of-the-box with the 765VL-000. "Just trusting the base register" is exactly what you also need to do if the S3 chip is a PCI chip, as for PCI cards, the BIOS assigns the address during PCI initialization, and you better don't change anything afterwards. IIRC the classic base address register is read-only in PCI mode.

So you "just" need to decompress the packed S3VBE20 executable, and patch it to treat the LFB address determination for VL cards just as it is for PCI cards.

As S3VBE20 is not "free/open source software", I don't have a license to modify it, to run modified versions, and certainly not to distribute modified versions, though. If you want to take the legal risk yourself, get S3VBE/Core 2.0 version 3.18, understand that the terms of use explicitly state that the license for using, copying and distributing only applies "if you don't modify the files in this package in any way", so you certainly wouldn't undo the LZEXE compression, and patch the byte at offset 0x2d2f from 0x75 to 0xEB.

Thank you very much for the detailed explanation!

It's a shame I cannot legally patch the file! 😉

Reply 144 of 155, by feipoa

User metadata
Rank l33t++
Rank
l33t++
TheMobRules wrote on 2022-04-20, 20:40:

@feipoa is there any consistent way to reproduce that other than loading Win95?

Just keep playing with it and don't blink during rapid text changes. It will sometimes exhibit the issue in DOS text mode, like using "dir", but it is much less repeatable than the boot time. I don't think it is related to Windows 95 in any way. If I recall, I was using the NT boot loader. I do plan on experimenting with this some more, but have had to put everything away for the time being. I will also experiment with the Virge chip on the same PCB.

I am surprised you don't have the issue with blank screen at boot. This also doesn't always occur, but with enough experimenting, it shows up for me.

What type of gains are you hoping for with LFB? I haven't yet tried S3VBE20, nor univbe.

I could only use 0WS with 25 MHz FSB on the particular board I was testing on. Benchmark improvements were minimal.

Ultimate 486 Benchmark | Ultimate 686 Benchmark | Cyrix 5x86 Enhancements | 486 Overkill Graphics | Worlds Fastest 486

Reply 145 of 155, by matze79

User metadata
Rank l33t
Rank
l33t

I use STB Powergraph BIOs with no flaws, for LFB a modded S3VBE20 Tool is needed

https://dosreloaded.de - The German Retro DOS PC Community
https://www.retroianer.de - under constructing since ever

Co2 - for a endless Summer

Reply 146 of 155, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I have my IBM Blue Lightning BL3 system setup with the Diamond S3 Trio64, with operating systems MS-DOS, w3.11, NT 3.51, NT4.0, and w95. I decided to swap out the Diamond for the replica Trio64V+ card and boot NT 3.51. Upon boot-up with 1280x1024x8, I notice several icons without colour and my mouse pointer is a black square. Similar behaviour is noticed at 800x800x16, except the icons are missing. Has anyone else noticed this issue in NT 3.51 or NT 4.0 using the Microsoft provided S3 driver? I am using the standard STB PowerGraph 64V+ BIOS, not the 0 ws modified BIOS.

Trio64Vplus_NT351_S3_driver.JPG
Filename
Trio64Vplus_NT351_S3_driver.JPG
File size
185.75 KiB
Views
485 views
File license
CC-BY-4.0

Ultimate 486 Benchmark | Ultimate 686 Benchmark | Cyrix 5x86 Enhancements | 486 Overkill Graphics | Worlds Fastest 486

Reply 147 of 155, by feipoa

User metadata
Rank l33t++
Rank
l33t++

I was able to source functional drivers for the replica STB Powergraph 64V for use within WINNT4 and WINNT 3.51. For whatever reason, the Microsoft supplied and STB supplied drivers would not work correctly. The STB drivers found on Wayback for WIN 3.1 and WIN 95 do work, however. To save others the trouble of hunting down drivers, I'm attaching the drivers I found to work properly here.

For this round of testing, I used a PC Chips M919 v3.4. On this particular motherboard/CPU combination, I did not have the issue with the screen staying blank at hard reset or power-on. I do still see the brief single-frame artefact after the NT boot loader selects the operating system, however it is not visible in games or Windows. Overall, I am very pleased with this replica card and express thanks to Madao for his efforts.

Unfortunately, I could not get the 0 WS BIOS to function on the M919 using a 33 MHz FSB and a Cyrix 5x86-100. If I recall, the screen stayed blank at power-on. I was only able to use 0 WS at 25 MHz, which was tested on another motherboard previously.

I will now move on to soldering a ViRGE (325) chip onto my second PCB. If there is anything in particular you want tested, let me know. I plan to test Windows drivers in the 4 operating systems and compare the VGA mode speed in DOS against the Trio64V+ (765) chip.

EDIT: I was doing some testing with the Trio64V+ replica card on my PC Chips M919 v3.4 and noticed an issue. I would run Win Quake, but on exit, my mouse pointer was missing. I resolved this issue by installing DirectX 6.1 again and letting the directX installation "update" my STB drivers with the DirectX drivers for this card.

Filename
STB_Powergraph64V_drivers_WIN31_from_STB_p64v212h.zip
File size
898.92 KiB
Downloads
2 downloads
File license
Public domain
Filename
STB_Powergraph64V_drivers_WIN95_from_STB_p64V124h.zip
File size
307.05 KiB
Downloads
2 downloads
File license
Public domain
Filename
STB_Powergraph64V_drivers_WINNT351_from_S3.zip
File size
81.15 KiB
Downloads
1 download
File license
Public domain
Filename
STB_Powergraph64V_drivers_WINNT4_from_S3.zip
File size
102.78 KiB
Downloads
2 downloads
File license
Public domain
Last edited by feipoa on 2022-05-18, 07:15. Edited 2 times in total.

Ultimate 486 Benchmark | Ultimate 686 Benchmark | Cyrix 5x86 Enhancements | 486 Overkill Graphics | Worlds Fastest 486

Reply 148 of 155, by Disruptor

User metadata
Rank Oldbie
Rank
Oldbie
feipoa wrote on 2022-05-05, 09:56:

I will now move on to soldering a ViRGE (365) chip onto my second PCB.

A 365 is a Trio3D for AGP. You surely mean a 325.
Common drivers will not work on VL cards.

Reply 149 of 155, by feipoa

User metadata
Rank l33t++
Rank
l33t++

Yes, 325. Fixed the typo.

I thought only the S3d functionality wouldn't work for ViRGE on VL? If Windows drivers also won't work, then I won't bother.

Ultimate 486 Benchmark | Ultimate 686 Benchmark | Cyrix 5x86 Enhancements | 486 Overkill Graphics | Worlds Fastest 486

Reply 150 of 155, by Disruptor

User metadata
Rank Oldbie
Rank
Oldbie

The Virge architecture has dropped 2D acceleration support. Instead it uses its 3D functions to speed up 2D. Therefore S3 drivers for older graphics card won't work.

mkarcher has adapted some Windows PCI Virge drivers to work with VL Virge. However, he's still facing problems when a task switch includes a mode switch (DOS in fullscreen).

Reply 151 of 155, by feipoa

User metadata
Rank l33t++
Rank
l33t++

That's not a big problem for me. I'm hoping he will release some alpha NT 3.51/4.0 drivers.

Ultimate 486 Benchmark | Ultimate 686 Benchmark | Cyrix 5x86 Enhancements | 486 Overkill Graphics | Worlds Fastest 486

Reply 152 of 155, by furan

User metadata
Rank Member
Rank
Member
Disruptor wrote on 2022-05-06, 06:13:

The Virge architecture has dropped 2D acceleration support. Instead it uses its 3D functions to speed up 2D. Therefore S3 drivers for older graphics card won't work.

This is not why S3 drivers for older graphics cards won't work. If you look at the Virge datasheet, the 2D hardware is similar to the Trio64.
You can read the datasheet here: http://www.bitsavers.org/components/s3/DB019- … tor_Aug1996.pdf

Reply 153 of 155, by Disruptor

User metadata
Rank Oldbie
Rank
Oldbie
furan wrote on 2022-05-30, 19:26:
Disruptor wrote on 2022-05-06, 06:13:

The Virge architecture has dropped 2D acceleration support. Instead it uses its 3D functions to speed up 2D. Therefore S3 drivers for older graphics card won't work.

This is not why S3 drivers for older graphics cards won't work. If you look at the Virge datasheet, the 2D hardware is similar to the Trio64.
You can read the datasheet here: http://www.bitsavers.org/components/s3/DB019- … tor_Aug1996.pdf

I'm sorry, you are absolutely wrong.

Please refer to the linked manual, section 15.4.4
The Virge uses its "S3d Graphics Engine Features" to achieve "High performance 2D Windows acceleration".

The Trio64V+ instead uses rather a kind of 8514/A style 2D acceleration.
Just the framebuffer part is compatible to the Trio64V+. However framebuffer access is unaccelerated.

Reply 154 of 155, by matze79

User metadata
Rank l33t
Rank
l33t
feipoa wrote on 2022-05-05, 09:56:

I will now move on to soldering a ViRGE (325) chip onto my second PCB. If there is anything in particular you want tested, let me know. I plan to test Windows drivers in the 4 operating systems and compare the VGA mode speed in DOS against the Trio64V+ (765) chip

Yeah you can do this, but there are Hardware Mods needed, at least ?SAUP2? needs to be delayed if i remember right.
So a 74LS74 needs to be added.
Also some other issues will pop up, there few bugs in vlb interface of virge.
This was maybe the reason why it never came out officially.
However there are ways to work around it with additional hardware, at least it seems.

https://dosreloaded.de - The German Retro DOS PC Community
https://www.retroianer.de - under constructing since ever

Co2 - for a endless Summer

Reply 155 of 155, by mkarcher

User metadata
Rank Oldbie
Rank
Oldbie
matze79 wrote on 2022-05-31, 21:56:
feipoa wrote on 2022-05-05, 09:56:

I will now move on to soldering a ViRGE (325) chip onto my second PCB. If there is anything in particular you want tested, let me know. I plan to test Windows drivers in the 4 operating systems and compare the VGA mode speed in DOS against the Trio64V+ (765) chip

Yeah you can do this, but there are Hardware Mods needed, at least ?SAUP2? needs to be delayed if i remember right.
So a 74LS74 needs to be added.

OK, if you go public with that info (no problems with that), let me elaborate a bit: Certain (perfectly valid) VLB access patterns result in corruption of vital system control registers of the ViRGE chip (which might lock up the VL bus), or accidental activation of the busmaster DMA engine (which is a bad idea in VL mode - the ViRGE chip does not support VL bus master DMA, this will cause bus lockups again). You can work around the problem in some applications by making sure the card runs in "1 WS, late decode" mode, and delay SAUP2 by one VL clock. 74LS74 doesn't sound fast enough (unless you run FSB8 like some boards in deturbo mode do), better use a 74ACT74 or 74F74.

To delay SAUP2 (which is already connected via a 0-Ohm resistor), so easily splittable, connect VL-Clock (pick it up at the ViRGE side of the series termination resistor) to CLK of the 74F74, connect the VL side of SAUP2 (i.e. A30) to D, connect Q to SAUP2 (ViRGE side), connect SET and RESET to VCC. The 74F74 has two flip-flops. Connect all input pins of the second half (i.e. everything except Q and /Q) to Vcc. I tested that mod with an 74F74 in SO form factor put on top of the I/O decoder logic chip, bending the VCC and GND legs down and soldering them directly to the VCC and GND legs of the I/O decoder chip, and bending all other legs up and hook them up using bodge wires (enamelled copper makes good bodge wires for SMD stuff).