Yes I read that but madao made it working at least in 2D mode under DOS with some modified video bios. Just want to know if current PCB is capable running Virge too with some jumper settings or if it would require some additional circuits ( I read about some signal delay line needed with 7474 - this is not present on current PCB)... Feipoa wanted to try it out witj soldering Virge but i didn't see the result.

RayeR wrote on 2024-07-05, 00:58:

Yes I read that but madao made it working at least in 2D mode under DOS with some modified video bios. Just want to know if current PCB is capable running Virge too with some jumper settings or if it would require some additional circuits ( I read about some signal delay line needed with 7474 - this is not present on current PCB)... Feipoa wanted to try it out witj soldering Virge but i didn't see the result.

I thought I posted the result in brevity somewhere. There's a long dialogue in PM to mkarcher, but there's no PM search feature on Vogons to hunt down my messages. Unfortunately, it was such a long time ago now that the results are very fuzzy. From my memory: No changes to PCB hardware were necessary. DOS works, but S3D won't. For Windows 95, have to use some driver workaround provided by mkarcher, but the 2D aspect will function. There wwere some issues with some software or features, but I forget which. I forgot the result with NT4. I ultimately removed the Virge chip and put the Trio64V+ back on.

Ok, thanks for info. Look if you made some photo of the card with virge to check if that config resistors was really the same as on triov64+. It still maybe important for someone who has PCI virge as donor instead of 64v+ and wants to run it mostly under DOS ( don't care about 3D). I just passed 4 PCBs to other users and keep only one with already soldered 64v+ so don't plan to experiment with the virge personally.
Anyway it would be usefull to have collected the info about issues with virge and how to overcome it , if it could be workarounded by some extra effort or hard limited by the chip... ideally link this info in 1st post for newcomers.

The Virge is a drop-in replacement for the Trio64V+ on the MK-765VL board. No need to adjust any configuration resistors. I do not remember how much BIOS adjustment was required in the end, but anything that uses the acceleration engine (which is a unified 2D/3D engine on the ViRGE) is prone to malfunctions and bus lockups unless special magic access sequences are performed to work around the buggy VL interface of the S3 ViRGE. A Trio64V+ BIOS is not going to work correclty. For example, clearing of the video memory when initializing VESA modes is performed using the acceleration engine. The Trio64V+ still uses the 8514/A-inspired 2D engine, whereas the ViRGE uses the aforementioned unified 2D/3D engine, which is not compatible to the Trio engine at all. In most regards except the acceleration engine, the ViRGE and the Trio64V+ are extremely similar.

I had Terminal Velocity working with patches to the game, but frankly, on a 5x86 the software rendering version just played better than the S3D version. This is not the fault of the VL bus, the same is true for ViRGE PCI cards. I did not enjoy the ViRGE experience until I tried a ViRGE/DX PCI card that clocks at 72MHz with texture filtering and perspective correction disabled. The default clock of the ViRGE of 45MHz or 50MHz is unusable for gaming at 640x400. On the other hand, game manufacturers liked that resolution, because they could use 2:1-upscaled assets designed for the 320x200 256-color VGA mode. The ViRGE on my VL card combined with the fast EDO RAM I got from Madao overclocks quite nicely up to 80+ MHz, which is a big improvement compared to 50MHz, but still doesn't reach the 3D performance of the /DX at 72MHz, especially with filtering and/or perspective correction enabled.

The one-clock delay introduced by a 74F74 is a partal workaround for the VL implementation issues of the Virge. As long as the acceleraton functons are not used (i.e. you are running VBE framebuffer-based applications only), the 74F74 is not required, IIRC. The delay introduced by the 74F74 makes 0WS operation impossible and thus is not desireable unless you use the acceleration engine.

Thanks for explanation. But why drivers for PCI card and vbios doesn't work while trio64v+ pci drivers and vbios works without modding? How hard would be modding it? As virge lacks 2D accel and rely on 3D that doesn't work it makes it worse performance under windows and other apps that can use 2D accel.

Trio64V+ driver uses IO-Address and oldMMIO (this mode is aviable on PCI and VLB)
Virge Win9x driver uses also newMMIO (only PCI) , it doesn't work on VLB.

This is what, i am (partial) understanding after disassembling of driver. And mkracher told similar.

Virge BIOS from PCI doesn't work on VLB card, because VESA feartures connector is enabled and it is multiplexing with RAM. -> heavy artifical in pictures.
mkracher has patched Virge BIOS and it works. ( feartures connector is not on same pin, depents of PCI/VLB mode)

At point: VIRGE VLB is a disappointed adventure.
I can only told: write new driver (IO & "only" oldMMIO) with workaround on buggy VLB interface. We would added few hardware as 74F74. (or Workaround in software -> partial 0WS is possible)

RayeR wrote on 2024-07-05, 20:52:

Thanks for explanation. But why drivers for PCI card and vbios doesn't work while trio64v+ pci drivers and vbios works without modding?

Madao wrote on 2024-07-06, 05:49:

Trio64V+ driver uses IO-Address and oldMMIO (this mode is aviable on PCI and VLB)
Virge Win9x driver uses also newMMIO (only PCI) , it doesn't work on VLB.

The point of "old MMIO" is that it makes the chip independent of I/O cycles, which can increase performance and allows easier integration in systems that do not support a dedicated I/O space. "old MMIO" has been introduced quite early in the S3 accelerator series. As it uses The address range A0000-AFFFF, it perfectly works on ISA cards, even if there is no address hole for high addresses, like you would need for an LFB. The first S3 chips were similar to the 8514/A: In "accelerator mode", the video memory is owned by the acceleration engine instead of the host bus. You can not directly access the video RAM on a S3 911 or 928 while the accelerator is enabled. If software wants to read or write video memory directly, it would need to turn off the acceleration engine, access video memory, and turn on the acceleration engine again. The design of the MMIO engine (which was not yet present in the 911) aims to make direct framebuffer access unimportant, by providing equal performance to a video drive if using MMIO. This includes a way of performing bulk video memory writes using "REP MOVSD" instead of "REP OUTSD". For this to work, the "video data exchange port", which is on a single I/O port on the 8514/A (and has been widedened to 32-bit by S3) is mapped into 32K of memory (A0000-A7FFF), so a read or write to any address in this 32K region is treated like an access to the video data exchange port.

Later S3 cards (don't ask me exactly, which ones, likely around the 964) did away with the limitation that you can't access a linear framebuffer while the accelerator is enabled, yet you need to ensure the accelerator is idle when you access the framebuffer. This way of operation uses the framebuffer as "linear framebuffer" into high memory, and keeps the A0000-A7FFF range used for MMIO. This mode obviously only works if the system supports providing access to a linear framebuffer, which is for example an issue in ISA systems with sufficient RAM. Also, most VLB-enabled S3 chips (maybe even all?) do not decode all 30 address lines (A2..A31) to reduce the pin count, but needs some external decoders. The consequence is that enabling LFB on those cards does not just require knowledge about the S3 chip itself, but also about external decoding logic. A well-made VL card with LFB support has a BIOS that already programs the LFB base address in the S3 chip (which always specifies all address bits A16..A31) to a range that is compatible with the hardware address decoder, and a driver should default to use the address already set by the BIOS. That's where S3VBE20 fails: It does not trust the BIOS of a VLB card to set up a valid base address, and insists on setting its own address.

With the Trio, S3 introduced a new "Trio MMIO" variant of "old MMIO". As the Trio is new enough to support MMIO and frame buffer access enabled at the same time, and not all system configurations allow a linear frame buffer, the Trio variant of "old MMIO" moved the command registers from A8000..AFFFF to B8000..BFFFF (the classic CGA memory range), abolished the memory transfer area at A0000..A7FFFF, and instead enabled a 64K framebuffer windows at A0000..AFFFF.

Up to then, MMIO registers are only accessible in the legacy VGA address space. You can't run a system with two S3 chips or an S3 chips and a second VGA-type graphics card, unless you do address remapping in glue logic. In the classic PC architecture, this was not percieved as an issue, as "the one and only non-MDA card" does not just occupy B8000..BFFFF, possibly A0000..AFFFF, but also the video BIOS at C00000, and the VGA I/O space at 3C0..3CF and the CGA I/O space at 3D0..3DF. With the advent of PCI and automatic resource configuration, as well as monitors getting cheap enough that multi-monitor setups started getting affordable and operating systems that supported multi-monitor setup, things changed. And this is when the classic S3 MMIO was renamed to "old MMIO", and a new MMIO mode was introduced with the Trio64V+: While you still can't move the classic VGA resources of the Trio64V+ or ViRGE, you can have them disabled. The card does not respond with framebuffer cycles in the A0000..BFFFF range while the LFB is enabled. Furthermore, the card does not respond with MMIO cycles in that address range, unless "old MMIO" (either the classic old MMIO or the Trio old MMIO) is enabled. So as long as you enable the LFB, disable old MMIO and disable I/O address response, the Trio64V+ and later chips can be operated in a "legacy free" mode, as any "well-behaved" PCI device should do anyway.

The key point of new MMIO is that the MMIO range is located next to the linear frame buffer in "high address space". To be exact, in new MMIO mode, the linear framebuffer is at the base address configured by the PCI BIOS, and the MMIO range is 16MB into that range. Everything that can be performed using classic I/O cycles can also be performed using MMIO cycles in the "new MMIO" range. This mode is the only mode supported by typical ViRGE software, and it is meant to simplify things: It allows coexistence with any kind of other graphics card (possibly you need to interact with I/O space once during boot to set up new MMIO), and it maps both the complete framebuffer and the MMIO space directly into processor-addressable memory. There is one key issue with new MMIO though: On the Trio64V+ and the ViRGE, the S3 chip only gets the address pins A2..A22, allowing a windows of 8MB! As the ViRGE only supports 2MB of video memory in VL configurations, this is not an issue for the LFB size. But as "new MMIO" is supposed to be located at "LFB base + 16M", there is no way for the ViRGE to distinguish LFB cycles from new MMIO cycles. The data sheet correctly points out this fact and explains that new MMIO is only available in PCI configurations (which do not use any address pins, as the PCI bus mulitplexes address and data on the same pins). The ViRGE has two input pins called SAUP1 and SAUP2. If exactly one of them is active, it indicates either "the first 8MB of address space" in which the Video BIOS, the I/O space and the classic VGA memory range is located or "the 8MB address space containing the LFB". It's obvious to see how this system supports "old MMIO" by mapping the MMIO into the "the first 8MB" and dedicating "the other 8MB" to the linear framebuffer, but this system obviously does not support "new MMIO".

While you could design a bridge that translates cycles that look like "new MMIO" to the VL bus into cycles that look like "old MMIO" towards the S3 chip, this translation logic will add extra decoding delay and make 0WS operation impossible in most configurations, removing much of the appeal of a ViRGE VL card. Instead of designing your own VL-to-VL bridge for an application like that, it would make more sense to use a VL-to-PCI bridge and run the ViRGE in PCI mode, which is known to be rock solid. A design like that also allows upgrading to a ViRGE/DX for better 3D performance. While this is a pragmatic solution, it is equivalent to just using a mainboard with PCI support and plugging a ViRGE PCI card into it. ViRGE PCI cards are abundant, and PCI-based 486 mainboards are also easily obtainable, so designing a roll-your-own VL-to-PCI implementation seems currently completely unappealing to retro hardware developers.

RayeR wrote on 2024-07-05, 20:52:

As virge lacks 2D accel and rely on 3D that doesn't work it makes it worse performance under windows and other apps that can use 2D accel.

I think you understood the issue correctly, but I will still point out to the public to avoid a common misconception: While the ViRGE no longer has the 8514/A-inspired 2D engine, the ViRGE unified 2D/3D engine is perfectly capable of accelerating 2D graphics in Windows, probably even better than the old Trio engine could do it. The advantage of the ViRGE engine is that it was designed after GDI got the de-facto standard for graphics card interfacing, while the 8514/A predates the dominance of GDI and is tailored towards the needs of AutoCAD in 1987 or around that time. While it is true that S3 added to that interface to make it better fit for GDI drivers, they did not change the core design until the ViRGE. I expect that a S3 911 acceleration driver still works on a Trio64V+ (of course, not exploiting the advanced features added by S3 in the mean time), but it will fail on the ViRGE.

It's not the new ViRGE engine in itself that "doesn't work", but the interface of that engine to the VL bus has design issues that go far beyond "new MMIO is not available in VL mode".

Again, mkarcher thanks for detailed info and your time, it helps me understanding it.
I don't have much knowledge about 2D/3D accels as there was not much documentation of proprietary chips (at least years ago).
My generic idea how it works was that it use MMIO, a single or multiple address range(s) for LFB and control registers, not needing IO access. It seems the same as Virge do. I didn't know about address decoding issue:

mkarcher wrote on 2024-07-06, 08:30:

There is one key issue with new MMIO though: On the Trio64V+ and the ViRGE, the S3 chip only gets the address pins A2..A22, allowing a windows of 8MB! As the ViRGE only supports 2MB of video memory in VL configurations, this is not an issue for the LFB size. But as "new MMIO" is supposed to be located at "LFB base + 16M", there is no way for the ViRGE to distinguish LFB cycles from new MMIO cycles. The data sheet correctly points out this fact and explains that new MMIO is only available in PCI configurations (which do not use any address pins, as the PCI bus mulitplexes address and data on the same pins). The ViRGE has two input pins called SAUP1 and SAUP2. If exactly one of them is active, it indicates either "the first 8MB of address space" in which the Video BIOS, the I/O space and the classic VGA memory range is located or "the 8MB address space containing the LFB". It's obvious to see how this system supports "old MMIO" by mapping the MMIO into the "the first 8MB" and dedicating "the other 8MB" to the linear framebuffer, but this system obviously does not support "new MMIO".

Hm, this seems to be serious problem it decodes only 8MB range. We could make some external address decoder that will generate a MMIO select signal when host will access to LFB base + 16MB - some way driving the SAUP1 and SAUP2 to let Virge know it gets MMIO access? Also we need to block writes of MMIO data to LFB to not corrupt the current image.

Also interesting idea would be to design some VLB2PCI bridge with some CPLD/FPGA that would do things in clean way and don't rely on problematic VLB compatible mode - no more VRAM size limitation, could be paired with any newer PCI GPU... But it would add some extra propagation delay on the bus and also requires knowledges of FPGA programming that's beyond of my scope... Anybody attempted to do this? Or did existed any commercial VGA VLB card with some proprietary bridge? I remember that later was used solutions with PCI2AGP and AGP2PCIE bridges but I doubt someone made this for VLB...

Maybe other approach - (re)write some Virge driver to use old MMIO if possible? But it's a lot work that doesn't worth.

I also think that for a common 486 system, who needs a better VGA let he use a 486 with PCI. One exception, I have a NegGen Nx586 VLB board that I think is quite rare, there was also a PCI MB version but no chance to get it so I'd like to put some better VGA there. I have only 2 VLB VGAs - Cirrus Logic and S3 Trio32 with 1MB so I think Trio64V+ would be good upgrade and I'll be satisfied even without Virge 😀

About 2D accel - yes OK 2D windows functions could be accelerated via that 2D/3D engine - if it would work, on PCI systems it would...
But for DOS programs e.g. AutoCAD would be better an older chip with 2D accel (8514/A like) as it couldn't utilize new 3D engine. I don't remember now it there was some RCPADI DOS drivers for Virge but probably not, it could be accelerated by older 2D chips like Vision 9xx or MGA1/II...

RayeR wrote on 2024-07-06, 15:20:

Hm, this seems to be serious problem it decodes only 8MB range. We could make some external address decoder that will generate a MMIO select signal when host will access to LFB base + 16MB - some way driving the SAUP1 and SAUP2 to let Virge know it gets MMIO access? Also we need to block writes of MMIO data to LFB to not corrupt the current image.

The ViRGE chip supports two address ranges. Of course, a decode is free to choose at what range which range is activated. I will call the range that is supposed to be at "all high addresses zero" the "primary range" and the range that is supposed to appear at a high address to map the frame buffer the "secondary range". You need to decode the primary range at address zero, otherwise VGA-compatible port I/O, BIOS access and legacy video memory access fails. You can decode the secondary range anywhere you like, as long as it does not conflict with other resources, like main memory. Obviously, you can decode an alias of the primary range at 16MB past the nominal LFB base address, but this will not do it. Suppose you decode the LFB at 8400'0000: The 2MB of the MK-765VL will appear at 8400'0000..841F'FFFF. You could decode an alias of the primary range at 8500'0000, which would be close to what "new MMIO" does, but it won't be exactly it: In this design, MMIO will be accepted at 850A'8000..850A'FFFF. New MMIO on PCI cards would instead appear at 8500'8000..8500'FFFF. There is no level combination of SAUP1/SAUP2 that opens the "New MMIO" window. Two of the four possible level combinations do not select the chip at all, and the other two access the "primary" and the "secondary" range as defined above.

RayeR wrote on 2024-07-06, 15:20:

Also interesting idea would be to design some VLB2PCI bridge with some CPLD/FPGA that would do things in clean way and don't rely on problematic VLB compatible mode - no more VRAM size limitation, could be paired with any newer PCI GPU... But it would add some extra propagation delay on the bus and also requires knowledges of FPGA programming that's beyond of my scope... Anybody attempted to do this? Or did existed any commercial VGA VLB card with some proprietary bridge?

There is the OPTi 82c822 VL-to-PCI bridge. There also is the VIA 82c505 VL-to-PCI bridge. I didn't check datasheets, but I expect these chips will work in your suggested application.

RayeR wrote on 2024-07-06, 15:20:

Maybe other approach - (re)write some Virge driver to use old MMIO if possible? But it's a lot work that doesn't worth.

That's how I started to look into the ViRGE VL project. Actually, porting drivers from New MMIO to old MMIO is often quite easy, as the only difference is the code that activates MMIO and the base address of the MMIO range. Most drivers use a dedicated 32-bit pointer to the MMIO base, or a dedcated selector, so this is also a single location patch. But alas, that's where all the issues with the broken VL bus interface of the ViRGE start.

The OPTI 82C822 offers dog slow Performance, its not really worth the effort.

Line 38 of the parts list says 74F245 then at the end 74HCT245 in the Mouser part number.
I know the F series are the fastest so the question here is does this card need the 74F245 or will a 74HCT245 suffice?

You can get F245 from Mouser too: https://cz.mouser.com/ProductDetail/Texas-Ins … FJjga6E0w%3D%3D
I used LCX245 as I had them spare parts, even faster...
We don't have schematics available yet but I guess they are placed on slow ISA part of the bus so shouldn't matter anyway...

Oh thanks... typo in csv file.

You can choose F oder HCT.

Speed is not critical. it is just ISA bus driver (from EPROM)

Madao wrote on 2024-07-18, 16:47:

Speed is not critical. it is just ISA bus driver (from EPROM)

So even the good old 74LS245 should be fast enough at that position. So if you have some of those at hand, and you would need to shop for faster parts, you might give the LS part a try.

Thanks everyone for clearing that up. I'm ordering from Digikey as shipping to Australia is free over $60 AUD.

The rest of components arrived yesterday so I finally was able to complette the PCB assembly. It runs at the first power on. I burned and tested both ROMs - 1WS and 0WS and found several other differences than just speed:

1WS
- is slower (as expected)
- VESA modes runs at 75Hz
- VESA mode exit back to text mode OK
- VESA BIOS correctly reports video mode list according to available 2MB VRAM

0WS
- is faster (as expected)
- VESA modes runs at 60Hz
- VESA mode exit back to text mode fails with blank screen/out of sync
- VESA BIOS incorrectly reports video modes that are not available with 2MB configuration - e.g. 1024x768/32bpp, when such mode is tried to set it result in blank screen

I also compared the speed in Doom against ISA OAK VGA on i486DX-33
VLB: 14,24 FPS
ISA: 9,31 FPS

She is beautiful, despite the long way to display. That pinout really does not help on this side of a card.

Putas wrote on 2024-08-21, 07:04:

She is beautiful, despite the long way to display. That pinout really does not help on this side of a card.

The pinout is likely primarily focussed on PCI cards. With the chip in "upright" position (mounted on the component side, text baseline facing the slot connector), on PCI cards, the VGA output will be left of the chip, so the way to display will be straight and short.

I tested 800x600 and 1024x768 modes on LCD and the image quality seems to be OK, I didn't see any extreme blur or other degradation compared to other cards so long traces are not an isue here. I'll have to load the patched S3VBE, normal doesn't work. Also S3VBEFIX.COM bank booster doesn't work, maybe need some mod for VLB too...

Can someone tell from where the 0WS ROM image came from? As there seems to be more differences. I though it was just patched few bytes from 1WS to 0WS...

RayeR wrote on 2024-08-21, 11:34:

I tested 800x600 and 1024x768 modes on LCD and the image quality seems to be OK, I didn't see any extreme blur or other degradation compared to other cards so long traces are not an isue here. I'll have to load the patched S3VBE, normal doesn't work. Also S3VBEFIX.COM bank booster doesn't work, maybe need some mod for VLB too...

The S3 VBE 2.0 Fix utility is not applicable to the Trio64, because that utility is meant to fix flaws with the VBE 2.0 implementation delivered in the BIOS ROM of later S3 cards. The Trio 64 (and the ViRGE) shipped with VESA 1.2 BIOSes. If you want to get VESA 2.0 support on that card with LFB, look at Re: S3 ViRGE VLB project (or " Making a Concurrent for Creative 3D Blaster VLB" ) and the followup post Re: S3 ViRGE VLB project (or " Making a Concurrent for Creative 3D Blaster VLB" ) . The "speedup" method by S3SPDUP does not work on the Trio64 in LPB+VL mode, as it is implemented on the MK-765VL. S3SPDUP replaces the "VGA-compatible" video memory window at A000:0 by a 64K "linear framebuffer-like window without VGA compatible processing", using the LFB logic in the Trio64 chip. This way of mapping the LFB into the low memory is inherently incompatible with the way the LFB interface of the Trio64 works in VLB mode.