Next (hard find ) fail: Pictures is shifted.

But this fail occurs only by VRAM mode and shift-result is depent of color depth. 256 color = 8 pixel shift, 16bit color = 4 pixel shift, 24bit = 3 pixel shift & wrong color, 32bit = 2 pixel shift.
Short explanation: VRAM Card from S3 run in text/VGA mode as convontial DRAM video card. It means: GPU take Data from VRAM and put it to DAC.
VRAM -mode: DAC got Data from VRAM and S3-GPU control clock to VRAM. This is why, S3 Vision968 is not superior in DOS-game/ textmode, their strenght is acceleration in high resolution mode.

Measure on VRAM-clock ( yellow wave = SC = shift clock = VRAM data-out clock )
Attention: SC clock is not same as dot clock. If 8bit color depth is using = 8x lower shift clock rate, because VRAM bus to DAC is 64bit width (64bit bus /8bit color = 8x clock divider ) Here runs SC with ~ 16,2 Mhz , dot-clock = ~ 130 Mhz (1280x1024 @ 72Hz, 8bit color )
It should starting at same time with blanking signal. But there didn't works correct, blanking came one clock pulse too early. (or clock pulse came to late..)

I found after few time cause for fail: I have drawing correct schematic from SPEA video card, but i haven't taken care by drawing schematic in kiCad *argh#+!"$*
Swapping of 74F74-input (Flipflop for delaying of blanking-signal) solves this problem.

Few screenshot

But card has yet only 2 MB VRAM, because: GPU , VRAM and DAC came from broken ELSA Winner2000AVI with 2MB VRAM.
I have buying 4 VRAM later and place it now on 968VL card.

A big problem: after short runtime: Pixel fail occurs.

I have changed RAS0 line resistor terminator from 33 ohm to 10 ohm -> problem solved.
Reason: RAS0 line drive eight VRAM, my guess was right.

A short video with solitar card jump , windows 95 solitare use mass bitBLT-function of S3 GUI accelerator.
https://youtu.be/RWqGmWDLkV4

Coutine, picture attach limit

After fixing of fail and mistake on first pcb , i am sitting again on kicad and make second version of PCB. Now it is final and free of fail...wait... i have forgotten check DDC Interface on first PCB....oh...there is also fail.. I make decision: i foregone DDC (= I²C ) Interface and keep one solder joint for IC empty .

A logo on bottom of PCB is neccesary, a "german" #9 *lol* #9 like put big logo on their video card.

Comparsion of first and second 968VL card

Data of 968VL from my design.

S3 Vision 968 GPU
2 or 4 MB VRAM ( EDO or FPM), TMS55160 or TMS55161
TVP3026 DAC (175 or 220 MHz )
and the most important data: VLB Interface.

ROM came from SPEA Mercury P64V, highest memory clock: 66Mhz, much higher than Diamond Stealth 64VRAM Video (55Mhz ?) Diamond ROM doesn't run well, because PLL-line is swapped and i have here a PCI- Diamond Stealth 64VRAM Video, it is honestly a bad designed card.
Diamond Multimedia keep TTL input open, DDC Interface nonfunctional, this is why, i choose SPEA for reference.
But someone would make notice, my card look like Diamond Stealth 64VRAM video VLB. Yes, but my reason was only: easy access to EPROM for update/change without pull of cards.

FAQ:
What chip from PCI card is useable as VLB? Yes, config strap resistor on memory line make this way possible.
Where got old GPU& DAC? in ebay exists NOS DAC and GPU. And i have here over 200 piece VRAM (TMS55161).
Stable on 40/50Mhz? : I haven't check it more than 33 Mhz VLB Clock. EDIT: 07.10.2020: Checked at 40Mhz FSB: Stable !
EDIT: 31.03.2021 Checked 50Mhz ZERO Waitstate stable .... holy shit

I make a lot of thought, should i make my design to open source, but i am not sure. Money is not reason, allmost i haven't interessing on $$.

Greetings
Matt

This is really cool. I enjoyed reading about it. Thanks for sharing.

I really like the description of debugging steps. It's very interesting.

Wow... just amazing 😀

awesome project!

you say SPEA didn't make a VLB version, but here smeone got a Spea V7-Mercury P64 VLB at least with the S3 Vision 964
Re: Bought these (retro) hardware today
...which incidentally looks very similar to your final design based on the Diamond Stealth 64 VRAM VLB

also you say you took the ROM from a SPEA Mirage P64V, the S3 Vision 868 PCI card? or is that a typo and you took it from a Mercury P64V as mentioned previously?
I happen to have a SPEA Mirage P64 VLB card, but that one is based on a Trio64 chip.
the naming schemes of these old cards are really confusing with the same name used across multiple generations ^^

Thanks for flower 😀

Yes, it is typo, Mercury P64V , not Mirage. (Topic is already corrected, thanks) ROM of Mirage P64V would run only in text/VGA-mode. (I haven't checked, 🤣 )
ROM came from Mercury P64V , which it exists never as VLB-card. But ROM is direct useable for VLB card. It doesn't make sensing, which interface.

I did know only four 968 VLB card: #9 motion FX771 VLB, Diamond Stealth 64VRAM Video VLB, Miro crystal 20SV VL (w 32bit DAC, based 964-Design) and mine.

Most 964 card has 32bit bus between DAC and VRAM and use external PLL-IC , while 968 runs most with 64bit DAC with internal PLL (TVP3026 / IBM RGB524).
This is why, modification of 964 card to 968 is not easy. I have here a dead Miro Crystal 20SV VL with 964 chip (show live, but freeze, if driver is loading)

Trio64 is very good choice for DOS gaming, it is faster than Vision-family.

greetings
matt

Great work!
Nice site - I only know tubes form guitar amps though.

very nice!
thanks for sharing!

Way to go! Good stuff, thanks for sharing.

Wow,

what impressive Work!

Please make VLB Virge!

Bravo...

What we really need is more ISA using better layers instead of cheap 2 layers and good filtering on VGA signals, cirrus logic or S3 305?

What experience and data sheets is needed, I do have knowledge in electronics and had experience in making circuit board which was mostly one layer.

Cheers,

Virge 325 Datasheet says VLB! 😁

Wow. That. Is. Awesome! 😁

matze79 wrote on 2020-09-20, 20:16:

Please make VLB Virge!

matze79 wrote on 2020-09-20, 20:37:

Virge 325 Datasheet says VLB! 😁
a

Virge 325 VLB, this is also, what i make thougt about. This chip is last S3 chip, which supports VLB.
Then is 3Dblaster VLB not only one 3D video card for VLB.

Virge 325 has few disavantage , if it runs with VLB: only half memory with cost of half bandwitdh or foregoning of VAFC-connector. 4MB RAM memory is only for PCI -interface. Of coruse , i foregone VAFC interface.
And i haven't understanding VLB-interface of Virge 325 to 100% (because, it haven't full address input for VLB, it need decoder = address range is a book with 7 seal, only information: over 4MB range)
Other way to solves this problem: buy /lent a Trio64V+ VLB, but i don't know one this card. ( Trio64 is not same, to much different )

At the rest: Designed of Virge /Trio card is easy and you can use all ROM from PCI -Virge (because PLL and DAC is internal ), but i am not sure anymore after reading of datasheet, because it should few register-setting of Virge for VLB. Pleas don't hit me, because reading of virge datasheet is long time ago. (half years)

But i say you: I am also very interessing on Virge VLB.

Interesting topic. I also thought about modding a Trio64/VLB card into a Virge/VLB card, which would be cool. I confused some things in the first run, but I got some of the stuff straight now:

• The Trio64 features "glueless VLB support". Glueless means that you can directly connect all relevant VLB pins to the Trio64 chip. The full glueless interface reuses some of the memory data pins for high address bits, so you only have a 32-bit memory interface in this mode. You can reconfigure the chip to only use 28 instead of 32 address lines (e.g. with external pre-decode) by setting CR68.7, so you (possibly) need some glue logic, but you can get full 64 bits on the memory interface. The VAFC (VESA Advanced Feature Connector) also shares pins with 64-bit memory, so you only can have one of these features at the same time.
• The Trio64V+ has two operation modes: A Trio64 compatible mode (which shares all features and limitations with the Trio64), and a native Trio64V+ mode, called the LPB mode. In its native mode, it supports the "Local Peripheral Bus" (LPB), which seems to be the foundation for the Scenic Highway MPEG decoder interface. In LPB mode, the VL interface is no longer glueless, yet you lose 4MB memory support in native/VL mode. In LPB/VL, you only have address bits up to A22 (addressability of 8MB), and you need an external decoder for the high address bit. You can no longer weasel around it by just supporting a 256MB address space (which you can in compatible mode). In LPB/VL mode, you get an 8-bit VAFC (full VAFC is 16 bits) or Scenic Highway (seems to be always 8 bits) interface and always 64 bit RAM, but no second bank, which limits memory to 2 Megabytes. The LPB modes "Video 16 in" and "Video 8 in/out" are not supported in conjunction with VL. (Also, as the Trio64 does not have LPB support, it also doesn't support these modes).
• The Virge is "pin-compatible to the Trio64V+" (quote from the data sheet), but I can't find any reference to the Trio64-compatible mode in the Virge datasheet. It most likely is only compatible to the Trio64V+ in LPB mode.

I could find Trio64 VLB cards on the internet, but it seems they are running the Trio64 in glueless VLB/32 bit RAM mode. I did not find Trio64V+ VLB cards (which most likely would be a Trio64 card with the chip replaced and running in compatible mode). This means I have very low hopes of finding a ready-made VLB card that can accept the Virge chip, we seem to need a design from scratch.

Incredible project 😀
I had actually considered to do something similar once I'm done with the ARGUS, as those S3 VLB rarely cards pop up on eBay and if they do they're usually quite expensive.
Looking forward to replace the CL5428 in my 486 system with your card once it's ready.

Wow nice project.

One suggestion: Translate your German text to English with https://deepl.com, this would make your text more readable but no offense! 😀

mkarcher wrote on 2020-09-21, 07:39:

Interesting topic. I also thought about modding a Trio64/VLB card into a Virge/VLB card, which would be cool. I confused some th […]
Show full quote

Interesting topic. I also thought about modding a Trio64/VLB card into a Virge/VLB card, which would be cool. I confused some things in the first run, but I got some of the stuff straight now:

• The Trio64 features "glueless VLB support". Glueless means that you can directly connect all relevant VLB pins to the Trio64 chip. The full glueless interface reuses some of the memory data pins for high address bits, so you only have a 32-bit memory interface in this mode. You can reconfigure the chip to only use 28 instead of 32 address lines (e.g. with external pre-decode) by setting CR68.7, so you (possibly) need some glue logic, but you can get full 64 bits on the memory interface. The VAFC (VESA Advanced Feature Connector) also shares pins with 64-bit memory, so you only can have one of these features at the same time.
• The Trio64V+ has two operation modes: A Trio64 compatible mode (which shares all features and limitations with the Trio64), and a native Trio64V+ mode, called the LPB mode. In its native mode, it supports the "Local Peripheral Bus" (LPB), which seems to be the foundation for the Scenic Highway MPEG decoder interface. In LPB mode, the VL interface is no longer glueless, yet you lose 4MB memory support in native/VL mode. In LPB/VL, you only have address bits up to A22 (addressability of 8MB), and you need an external decoder for the high address bit. You can no longer weasel around it by just supporting a 256MB address space (which you can in compatible mode). In LPB/VL mode, you get an 8-bit VAFC (full VAFC is 16 bits) or Scenic Highway (seems to be always 8 bits) interface and always 64 bit RAM, but no second bank, which limits memory to 2 Megabytes. The LPB modes "Video 16 in" and "Video 8 in/out" are not supported in conjunction with VL. (Also, as the Trio64 does not have LPB support, it also doesn't support these modes).
• The Virge is "pin-compatible to the Trio64V+" (quote from the data sheet), but I can't find any reference to the Trio64-compatible mode in the Virge datasheet. It most likely is only compatible to the Trio64V+ in LPB mode.

I could find Trio64 VLB cards on the internet, but it seems they are running the Trio64 in glueless VLB/32 bit RAM mode. I did not find Trio64V+ VLB cards (which most likely would be a Trio64 card with the chip replaced and running in compatible mode). This means I have very low hopes of finding a ready-made VLB card that can accept the Virge chip, we seem to need a design from scratch.

Hello

Yes, this is why, i make thougt about new project with Virge/Trio64V+ VLB. Not now, soon must bad windows 10 replaced ! I move slow to linux... 🙄
I would make a minimal Trio64V+/ViRGe design and Lattice CPLD as decoder for SAUP-input. We can config decoder. Without VAFC, without LPB-bus and 2 MB Memory.
Why not 4 MB video memory for card with VL-interface: SAUP2 is need for VL interface and there is OE1/RAS1 by PCI-mode. RAS1/OE1 is memory control line (upper 2 MB range)
ViRGe 325 can't replace Trio64 direct. Only Trio64V+ in LPB -mode can be replaced by ViRGe 325, as you said.

I must check: could Trio64VL ROM run into Trio64 PCI card and back? If yes -> way is free. I have few Trio64 video card from V7/SPEA, with both interface.
Glue-logic on VL-interface is reason for my doubt.

I have here a Trio64 VLB (Spea Mirage P64/VL , Board: P100 Version: V10 ) ) card, it has full 64bit memory bus.
VL interface of my Trio64 VL use a 74F27 as decoder for assert of SAUP-input , but not all upper address line would be decoding. (A27 and A29 contact missed) But i haven't make a note, which adress range will being asserted. It is one of fastest VLB video card for dos gaming (same as Trio32 ).

Ah , a side notice: I have soldered more 968VL card and one runs into VGA/text-mode without problem. pixel fail occurs , if it runs in VRAM mode.
Reason: two memory data line on S3 968 GPU is bridged (solder), both line is upper 32bit memory interface, which upper 32bit memory interface is not using in text/VGA mode.
It explains: no performance difference between Trio64 and 32 in text/VGA mode.

Greetings
matt

Storm82 wrote on 2020-09-21, 09:46:

Wow nice project.

One suggestion: Translate your German text to English with https://deepl.com, this would make your text more readable but no offense! 😀

Nope, i don't want translating my text , because my german is also not too good.