Thank you. In Doom, you've showed that the Trio64V+ is 7% faster than the Trio64 and that the Trio64V+ is 5% faster than the custom 968VL, but how much faster is the 968VL compared to the Trio64? Is it correct to infer that the custom 968VL is 2% faster than the mass produced Trio64?

Is that really a topic for this thread?

Trio64V+ and Virge use same pinout. This is interessing point. Trio64V+ and ViRGE is very fast in DOS-mode. No difference, if ROM is same.

But i am now on one point: STB Powergraph 64VL is not capable to swapping to ViRGE. Dito my first draw with configable address decoder.
S3d-game need linear framebuffer up to 4MB. And it is freezed with first ViRGE_VL draft.
Same result with useage of linear framebuffer on Trio64V+ VLB and S3VBE20. S3VBE20 tell me, linear framebuffer at 64MB. It is not correct. (128, 256, 384MB address, mirrored )
After start of s3d-game is address-range above 64MB and it is freezed. Alright, i am one step forwards. 😀

My solution with address range is same with proposal from MrKracher.
0xA000-0xBFFFF -> SAUP1 (memory , use for old mmio)
free config address -> SAUP1 (memory)
free config address +16M Offset -> SAUP2 (register)
modified Trio64V+ ROM tell: it is 64MB offset . -> config to 64MB Address (or i change value of ROM to 128 or 256MB offset )

Address schema is same with PCI address space. (0-4MB linear framebuffer, 16MB register, above 32MB is for Motola system ( big-endian ) )

Now, i am waiting on this second PCB (only address decoder for plug into seconds VLB slot and it is connecting to frist PCB draw. )
if it is a success -> huge modification from frist draw is neccessary.

Modification:
Trio/ViRGE is not ROM-decoder anymore, it got own address decoder on ISA BUS. (already checked )
4x address-decoder and LVC-gatter instead old solution with 74F260 for Trio64V+ and/or configable single address decoder.

Greetings
Matt

Madao wrote on 2020-12-21, 14:09:

My solution with address range is same with proposal from MrKracher. 0xA000-0xBFFFF -> SAUP1 (memory , use for old mmio) fre […]
Show full quote

My solution with address range is same with proposal from MrKracher.
0xA000-0xBFFFF -> SAUP1 (memory , use for old mmio)
free config address -> SAUP1 (memory)
free config address +16M Offset -> SAUP2 (register)
modified Trio64V+ ROM tell: it is 64MB offset . -> config to 64MB Address (or i change value of ROM to 128 or 256MB offset )

64MB was a very good choice in the good ol' VL days where the maximum RAM supported by consumer 486 chipsets was 4 banks of 4 x 4MB 30-pin SIMMs (the smaller boards got 2 banks), and the whole RAM decoding logic operated with address bits just up to A25. With the advent of PS/2 RAM, many chipsets support more RAM. I suggest to patch the ROM to use 256MB to be outside of the RAM area supported by modern chipsets (hoping that no chipset mirrors RAM there...).

How difficult would it be to have a jumper that choses 32MB/64MB/128MB/256MB/512MB? Or maybe fix the 32MB bit, so we get 32MB/96MB/160MB/544MB. This has the advantage that it is less likely that the only working configuration has the LFB directly adjacent to system RAM, and some software could mistake the LFB for extended memory. I could contribute a BIOS patch that tries to auto-detect the jumper position by probing for the S3 registers at different addresses and setting up the LFB address register in the S3 chip accordingly. As I remember from the Windows drivers, they read back that register to find the linear address base.

Virge PCI driver read over VGA register on Iidex 0x59 & 0x5A ?

Modification of ROM for Trio64V+/ViRGE is only Register changing (disable one /two function, but not change of address offset, it was a Trio64V+ PCI ROM ) I am looking after 64M offset in this ROM. But not now.

Greetings
matt

Madao wrote on 2020-09-26, 11:42:

I have here Virge Driver for Win95, can you look quick ?

https://www.vogonsdrivers.com/files/downloade … .php?fileid=588

Madao wrote on 2020-12-21, 21:07:

Virge PCI driver read over VGA register on Iidex 0x59 & 0x5A ?
matt

The driver you linked reads "LinearAddressBase" from the "display" section of SYSTEM.INI using GetPrivateProfileInt, default is -1. -2 disables linear addressing; all other values force a specific LBA address (units of 64KB). -1 causes the base address to be read from CR59/CR5A during initialization. The base address read back or forced from system.ini is later written into CR59/CR5A.

I have check with S3VBE20 on native MS-DOS, not Windows. -> 64MB location is hidden in ROM. Your notice with driver for Windows, it looks good.

PCB is arrivied. A little PCB is external address decoder, 0xAxxxx Range, configable per DIP Switch.
I have connect him with seconds Trio64V+ prototype and it doesn't make someone sign.
I have configed DIP switch to 0x0xxxx and computer make lifesign with wreid pictures.

FUCK ! I/O Access is not independent of SAUP1/2 Access.. I haven't found this notice in datasheet..
I/O Addres range is only first 64kb Range. ( up to 0x0FFFF)

I have modified external address decoder: I/0 and 0x0xxxx Address or memory and 0xAxxxx -> active. (easy, DIP switch was connected to VCC, now I/O (from VLB) drive it. I/O is low active)
Now it runs, as imagined. Good, next step: Address decoder on old prototype will be modified for linear framebuffer.

awesome.

Has there been any progress?

Madao wrote on 2021-01-09, 15:14:

I have check with S3VBE20 on native MS-DOS, not Windows. -> 64MB location is hidden in ROM. Your notice with driver for Windo […]
Show full quote

I have check with S3VBE20 on native MS-DOS, not Windows. -> 64MB location is hidden in ROM. Your notice with driver for Windows, it looks good.

PCB is arrivied. A little PCB is external address decoder, 0xAxxxx Range, configable per DIP Switch.
I have connect him with seconds Trio64V+ prototype and it doesn't make someone sign.
I have configed DIP switch to 0x0xxxx and computer make lifesign with wreid pictures.

FUCK ! I/O Access is not independent of SAUP1/2 Access.. I haven't found this notice in datasheet..
I/O Addres range is only first 64kb Range. ( up to 0x0FFFF)

I have modified external address decoder: I/0 and 0x0xxxx Address or memory and 0xAxxxx -> active. (easy, DIP switch was connected to VCC, now I/O (from VLB) drive it. I/O is low active)
Now it runs, as imagined. Good, next step: Address decoder on old prototype will be modified for linear framebuffer.

Any progress?

Nice work. I bet a lot of people are interested in this. keep up
Also, at later stages if possible add a feature connector 😀

Even better, add an advanced feature connector that can be configured as either input or output.

No much news.

But spin-off with Trio64V+ VLB is successfull. I make think about their gerber file. I think: I sell pcb with compoment list.
ROM came from Gainward graphics card with Fake-DRAM. This ROM make it to second fastest VLB card by letter/VGA mode.
But sometime instability with diagnose-tools, which it assert PCI function and didn't run on VIP Motherboard (i had Soyo 4SA2 )
Despite this fact is Trio64V+ VLB very stable and fast.

Could you share ROM from STB Powergraph 64 Video VLB ?

advanced fearture connector, honestly, you need it ?
Adding of AFC ist possible, it is not a big work.

Virge VLB.. i think, it would be a winter-project. Problem is yet MMIO and PCI-config-space and my movitation.

Greetings
matt

that looks very nice!
I would certainly be interested in buying pcb/bom 😀
I see no issue sharing a vlb VGA BIOS nowdays... even back then bios updates were just shared as images for anyone to get

This is awesome ~

Very cool!

Ahhh another awesome retro hardware remake. I'm going to be so broke heh, love it!

Also looking for Powergraph File.

If you release files its soon buyable on chipkin from Russia 🇷🇺
Why not instead profit yourself from your work.

The Card runs fine for me, but on 33Mhz Bus only.
Going higher does not work on HOT 491P.

Madao wrote on 2021-07-18, 11:15:

advanced fearture connector, honestly, you need it ?
Adding of AFC ist possible, it is not a big work.

It might be nice to have this if you just want to use the card for the VGA core, and chain it to something else for high resolution Windows graphics.
The regular feature connector actually works pretty well in this regard, but you can't use high/true colour modes in DOS.

Anonymous Coward wrote on 2021-07-20, 10:54:

The regular feature connector actually works pretty well in this regard, but you can't use high/true colour modes in DOS.

The standard feature connector can pass 16 and 24 bit pixel values, it is done using more bus cycles. That's how, for example, my 3DO Blaster is able to work with 16 bit color mode in Windows 3.1. It's taking 2 cycles on that 8 bit pixel bus. VAFC is cool because you get a much wider pixel bus, so you don't have to take the additional cycles.