This Project was long on my imagination but i lack the skills to do it!

We really appreciate your work @ dosreloaded.

I don't think, Trio64 ROM runs on Virge board, because register is much others. I though same about Trio64V+, despite, i haven't compared register between both chip with datasheet.

i have in parents farm a miro media3D/SE, Virge 325 PCI card.

Greetings
matt

I have digged deep in Virge and Trio64V+ datasheet, today.

I think: recommend range for SAUP2 assert is 16-32MB Range and SAUP1 0-16MB Range, which only 0 - 4 MB is useable.
STB Powergraph 64 Video (a Trio64V+ VLB) has SAUP2 assert range above 1GB. It is possible, if VideoROM has routine, which access move from to 16-32MB range to 1 GB.

Agree ?

Greetings
matt

It is not a good idea to have the video card respond to physical addresses 16MB-32MB, as this conflicts with RAM on better 486 systems. Possibly SAUP2 is indeed used to access the "16-32MB range", not as physical address, but inside the memory space of the card (which can be relocated using PCI configuration registers on PCI cards). The 16-32MB range of the memory space of that card contains MMIO registers for the accelerator and even mirror images for the standard VGA registers.

Also, the card needs to have an input that tells the card that most high address bits are 0. The card needs to respond to 000A0000-000BFFFF, but it must not respond to 008A0000-008BFFFF. These two ranges have no difference in A2-A22, so the chip can not tell the difference. As the only two inputs to the Trio64V+ dealing with high address bits are SAUP1 and SAUP2, I conclude that if you want VGA compatibility with the legacy framebuffer address A0000 (also known A000:0000 in segmented notation), SAUP1 needs to be active only if all interesting high address bits are zero.

I don't think the Video ROM deals with accellerator access at all, so it does not care at what address SAUP2 is asserted to the card. The one thing that cares about getting SAUP2 hits will be the Windows driver. In the case of PCI cards, the windows driver is likely going to ask the PCI bios for the base address of the card to find the MMIO range. For VL cards, maybe the ROM has an S3 proprietary function that tells the windows driver that SAUP2 is enabled above 1GB (and as you need SAUP1 disabled, the register space is at 1032MB as you already wrote in the first post).

I will take a quick look at the Windows 95 driver for the STB Powergraph 64 and report back how they address the card.

Register is asserted over I/O Addresse or "old MMIO" at Axxxx Memory address range. As you said.
"New" MMIO use 16MB (= A24) range for register-access, but register range is only 64kb width. By PCI card, you can added this address range (register & video memory) with offset, Video ROM doing this routine. Trio64V+/Virge VLB cards address range is hardwired.

This is why, i tell: i would make others with decoder. SAUP1 = asserted, if all high address line above A23 are low. SAUP2 assert if 16-32 MB Range is selected and it is configable to other address range.

Ok, i wait about your answers with driver.
My software ablity is not good enough.
Thanks
matt

Madao wrote on 2020-09-25, 05:30:

Register is asserted over I/O Addresse or "old MMIO" at Axxxx Memory address range. As you said. "New" MMIO use 16MB (= A24) […]
Show full quote

Register is asserted over I/O Addresse or "old MMIO" at Axxxx Memory address range. As you said.
"New" MMIO use 16MB (= A24) range for register-access, but register range is only 64kb width. By PCI card, you can added this address range (register & video memory) with offset, Video ROM doing this routine. Trio64V+/Virge VLB cards address range is hardwired.

This is why, i tell: i would make others with decoder. SAUP1 = asserted, if all high address line above A23 are low. SAUP2 assert if 16-32 MB Range is selected and it is configable to other address range.

Ok, i wait about your answers with driver.
My software ablity is not good enough.
Thanks
matt

I managed to find a Windows 95 driver for the STB PowerGraph 64 Video, that should have the Trio64V+ chip on it. I am quite surprised to find the main driver as 16-bit code, just like as if it were a Windows 3.1 driver, but that might have been common practice at that time. That driver uses either the A8000 range for MMIO ("backwards-compatible MMIO") or the LFB base address + 16MB + 0x8000 ("New MMIO"). New MMIO is only enabled for PCI cards, so the driver I found does not use SAUP2 at all.

For further reference, this information has been obtained from a file called "STBPG64V.DRV", 82032 bytes, MD5 DA7F721349F97C41E69E22ED9DA684D0.

Your plan for SAUP1 sounds fine for backwards compatibility. If I understand the datasheet correctly, the description of SAUP1 and SAUP2 only applies "when its memory/register address space has been relocated above 4MB", i.e. CR59/CR5A is bigger than 0040. The datasheet does not explain what happens if memory/register address space is still at the default value of 000A, but obviously it responds to SAUP1=1, SAUP2=0 in that case, as the STB PowerGraph 64 wouldn't work otherwise. As I understand it, this means:

• For compatiblity, SAUP1 needs to be high if all high address lines are zero. VGA memory space would be inaccessible otherwise. If the window size is not set to 64KB, the whole system will break down because of bus conflicts in the range 0MB..8MB.
• For LFB access with a base address above 4MB (which you oviously want, because a 3D accellerator in a system with 4MB RAM or less is mostly pointless), SAUP1 must be active at the video memory base address. As you want a window size of 2MB at least (as your card will have 2MB of video memory), SAUP1 must no longer be active if all high address lines are zero.
• As moving SAUP1 out of the all-zero range, you immediately lose the capability to access the MMIO registers at A8000. Register access thus only can happen via I/O space (which only decodes 16 bits, so SAUP* is irrelevant), or by addressing using SAUP2.

I have no idea what SAUP1=0, SAUP2=1 does if the Trio64V+ has a base address below 4MB, because a seperate register space enable pin makes no sense. It would make sense that the Trio64V+ only responds to SAUP1=1, SAUP2=0 in "below-4-MB" mode. If that is indeed the case, the connection of A30 to SAUP2 on the STB PowerGraph card is not meant to enable register access at 1GB, but instead as a sixth high-address bit that is decoded to further limit the A0000.BFFFF mirrors. Including A30 into the decoded address lines makes some sense, because the Weitek 4167 numeric coprocessor is a local bus device residing at memory address 3GB..3.5GB, so Weitek access cycles have A30 high.

If I were to design the card, I would try to build the decoder like this:

• For compatibility with standard VGA, activate SAUP1 in the A0000..BFFFF range. Do decode all of A17..A31.
• Also activate SAUP1 in a dedicated VGA range (maybe base address 1GB). Decode only A23..A31.
• Activate SAUP2 at 16MB past the linear SAUP1 range.

Then you get the New MMIO layout at 1GB/1GB+16MB compatible with a PCI card configured with its base address set to 1GB. At the same time, you get VGA compatible operation at A0000..BFFFF. Unlike in PCI mode, you can't kill the A0000.BFFFF range if you want to operate the card in LFB mode. This means you sacrifice the possibility to run a MDA/Virge dual-screen setup. The mirror of 128KB of the LFB at A0000..BFFFF will be harmless otherwise. This scheme does not need to know whether the card is in compatible mode (framebuffer base below 4MB) or in linear framebuffer mode at the cost of needing to decode 15 address bits.

Hello

Thanks.
Very good proposal with address range. I'll save your idea.

I found also S3 Driver for Trio64V+ VLB on my floppy disc. I don't know, where have i it. Their INF file show me: no difference between PCI and VLB, both got same driver.
Trio64V+ has chip-marking: 86C765

• %S3765.DeviceDesc%= S3_3, S3765_VLB
• %PCI\VEN_5333&DEV_8811&REV_40.DeviceDesc%= S3_3, PCI\VEN_5333&DEV_8811&REV_40

Interessing notice: Trio64 and Trio64V+ has same PCI Vendor & Device ID, difference is only Revision.

Greetings
matt

Madao wrote on 2020-09-26, 07:35:

I found also S3 Driver for Trio64V+ VLB on my floppy disc. I don't know, where have i it. Their INF file show me: no difference between PCI and VLB, both got same driver.
Trio64V+ has chip-marking: 86C765

Interessing notice: Trio64 and Trio64V+ has same PCI Vendor & Device ID, difference is only Revision.

That's correct. It also says so in the Trio64V+ datasheet for CR2F (Revision level): "The Trio64V+ is differentiated from the Trio64 by a 4 in the upper nibble of this register.". The PCI revision field documentation has a similar text. I guess this is meant to let operating systems that only support the Trio64 use the Trio64V+ as Trio64 out-of-the-box. Pre-Trio64V+-drivers won't care about the revision, so they will work on Trio64V+ chips without modification.

The driver you attached behaves the same regarding MMIO: New MMIO is only used on PCI cards. As the driver you posted is a generic S3 driver, it makes very much sense, because S3 has no idea how vendors of different VL cards wired SAUP1 and SAUP2. The code for determining the MMIO mode is obviously generated from the same source code in both drivers.

Interessing, no difference by MMIO story.

Yes, i know about revision in datasheet.

Which art of disassembler do you use? IDA ?
I have here Virge Driver for Win95, can you look quick ?

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

greetings & thanks
matt

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

Which art of disassembler do you use? IDA ?
I have here Virge Driver for Win95, can you look quick ?

That driver is PCI only, according to the INF file. The driver does not seem to read the bus type from the chip, and blindly assumes PCI. It enables the "new MMIO only" mode, whereas the Trio drivers enabled "new + compat MMIO" on PCI boards, and "compat MMIO" on ISA/VL boards.

I am in fact using IDA, I own an older licensed version, but I guess 7.0 Freeware should also do.

Hello

I am back with first life sign of Virge...ähm...Trio64V+ VLB. I am waiting of Virge donate. ( one is in transit to me )

Trio64V+ is damn fast, faster than Trio64 VLB.
Of coruse, i use PCI Card-ROM from a trio64V+ with 45ns EDO RAM.
Card has 50ns EDO DRAM, DRAM-donate was a turkish made SAT-TV Receiver *lol*

I haven't check him with Windows 9x. But i feel good.

Beautiful card, isn't ? 😀

DOSbench.

Greetings
matt

Wow! You're awesome, Sir! Hat off!

Really cool project! If/when you get the Virge VLB working I'd be very interested in S3D and Direct3D performance.

SUPER amazing
makes me wonder why do I even bother getting some high-end S3 card now.... hmmmmm 😀

Awesome !

That didn't take very long. Great job!

Very awesome! Glad you have it working.

Nice. Any chance of Virge /DX also supporting VLB? It would be more attractive choice...

Madao wrote on 2020-11-06, 11:45:

Hello
I am back with first life sign of Virge...ähm...Trio64V+ VLB. I am waiting of Virge donate. ( one is in transit to me )

Great! How do you decode SAUP1/2 now?

Putas wrote on 2020-11-06, 15:49:

Nice. Any chance of Virge /DX also supporting VLB? It would be more attractive choice...

Sorry, that won't work. The S3 Virge (no suffix) is the last S3 chip with native VL support. Neither the Virge/VX nor the Virge/DX have a (documented) VLB mode.