The cooling system assembled:

And the card with the cooling system installed:

Beautiful.

Quick question regarding an eventual release of the design files - I wanted to get a rough idea of how expensive it'd turn out, and looking up that FPGA it seems it already costs ~€2500 by itself [edit: Found another, similar one... -1FF instead of -2FF, but it still costs ~€2100), is that correct or do I have the wrong part?

Dammit....😮

cue "Hot Chocolate - You Sexy Thing"

elszgensa wrote on 2024-05-02, 11:48:

Beautiful.

Quick question regarding an eventual release of the design files - I wanted to get a rough idea of how expensive it'd turn out, and looking up that FPGA it seems it already costs ~€2500 by itself [edit: Found another, similar one... -1FF instead of -2FF, but it still costs ~€2100), is that correct or do I have the wrong part?

XC7K325T costs about $70 on Ali

The project is wonderful!

@elszgensa
The part number is XC7K325T, FFG900 package. Speed grade doesn't matter for this application, -1 is fine. Those are usual distributor prices, as Roman555 pointed out, they can be found cheaper. Lcsc stocked them a while ago for under 200$. Either way, one could replace the FPGA, even a small Spartan 7 can do the job.
The whole board won't be cheap to make, just the bare PCB costs a fair bit, as it has 16 layers.

@Boohyaka 😁

That's excellent news re: FPGAs, thank you. Gotta find me a better board fab shop though... dirtypcbs ain't cutting it this time.

That is one sexy card.

The PCI version will look like this:

Same size as the PCIe version. PCBs should arrive in about two weeks.

This is hardware porn on another level... Amazing work, @sdz!

Thank you Eivind!

It's great what you're doing but... I'm curious how you solved address space issue in v2. There is only 8MB for all tmu units. How it's possible to use 3 or 4 chips with 4MB each? According to the spec, there is only 8MB window for all of them. Even other companies didn't make such cards due to this limitation. The excuse that new drivers are necessary aren't explain it. Example diagram of 3 tmu working as 1-8MB too, coz it's only example, max mem for each chip is not a proof that all of them can work with max memory... That's why there no cards with 3/4 tmus and 4MB each. Seems 4444 is just a designer's dream and wish. With 8MB address space for tmu units is possible to use max 4 tmus with 2MB each, also 3 tmus with each 2MB... Dunno if config 4/2/2 or similar is possible. Can you explain it? I hope I'm wrong. 😉

edit: added 2 links to voodoo2 math in sli:
orig PL: http://3dfx.pl/cgi-bin/yabb2/YaBB.pl?num=1617221455/253#253
trans EN: https://3dfx-pl.translate.goog/cgi-bin/yabb2/ … tr_pto=wapp#253

That's a good point.
I presume the post you linked quotes the "VOODOO2 GRAPHICS HIGH PERFORMANCE GRAPHICS ENGINE FOR 3D GAME ACCELERATION" document.

"0x000000-0x3fffff Voodoo2 Graphics memory mapped register set (4 MBytes)
0x400000-0x7fffff Voodoo2 Graphics linear frame buffer access (4 MBytes)
0x800000-0xffffff Voodoo2 Graphics texture memory access (8 MBytes)"

The same document mentions 16MB maximum memory for 1 TMU , 3x TMUs with 16MB each configurations, and also SGRAM/SDRAM support , none of which are true. I haven't checked any source code regarding this, so I have no clue if that 8MB window is actually correct, and what the actual implications are.

Also I'm not sure if for a V2, having two TMUs with 4MB each would actually need a 8MB window instead of 4MB.

And there are cards on which the total TMU memory is greater than 8MB, Primary Image, Voodoo 1 based, has 3x TMUs with 4MB each, Primary Image Barracuda, Voodoo 2 based, has 3x TMUs with 4MB each.

There is only 8MB address space per all tmu units. I mentioned there can be "possible" configuration of 4/2/2 or 2/4/2 or 2/2/4 MB per 1 tmu of 3 if you want to use 3 tmu units and full memory space. There is option of course for 2/2/2/2 theoretical 4 tmus. In SLI mode you have 2 address space, so you can use twice more tmu units with the same memory, but this is different and still rule of 8MB exists. 8MB for tmus per card in SLI. That's why other solutions can be made. But not 4MB for fbi and 3x4MB for tmu on one card. It'll just don't work because of space address limit.

What does SLI have to do with this? The cards I pointed have 3x TMUs with 4 MB connected to each FBI (also 4MB).

It means that each tmu unit use only 2MB-4MB of mem depending of number of tmus, nothing else. 8MB is the max you can use for all tmus per one application. It means for one card 1 fbi+[1-4] tmu. In sli 2 fbi + [2-8] tmu.

Ok.

The Primary Image Barracuda (Voodoo 2 based) looks like this:

From the Primary Image Barracuda Glide driver documentation (where the 3dfx part of the card is connected to the PC via the PCI interface):

"3 TMU Operation
===============

Barracuda cards have 3 Texture Map Units (TMU's) on them. All other 3Dfx hardware
has 1 or 2 TMU's. The additional TMU provides 12MBytes of texture memory. It also
facilitates multi-texturing with one of the textures tri-linear filtered in a single
pass.

Some of the Glide structures defined in Glide.h have a fixed array size for the number
of TMU's using the GLIDE_NUM_TMU definition. By default this is defined to 2. To use the
third TMU, you need to build your application with GLIDE_NUM_TMU=3 defined in the
pre-processor definitions of the build settings. You should also link in the Glide2x3.lib
file instead of the normal Glide2x.lib. This will cause the Glide2x3.dll to be used at run
time.

When using 3 TMU's, you should not set the GrVertex.tmuvtx[2] values as these will be ignored.
Also, you should not use the GR_STWHINT_ST_DIFF_TMU2 or GR_STWHINT_W_DIFF_TMU2 hints for
the grHints() function. This is because the triangle setup engine in the PixelFX chip will
only setup the triangle parameters for 2 TMU's. Thus, the same data is sent to TMU2 as TMU1.

However, you can specify TMU2 for any of the grTexXXXXX() or guTexXXXXX() functions.

This allows you to set up single pass multi-texturing with the primary texture TriLinear
filtered in TMU's 1 and 2, and the secondary texture in TMU0. Alternatively, you can use
single texturing and simply use the additional TMU to provide an extra 4MBytes of texture
memory."

Primary Image Piranha (Voodoo 1 based) looks like this:

On the Piranha the 3dfx part can't be directly accessed by the host PC via the PCI bus, everything goes through the MIPS CPU. Regardless, the TMUs are still connected to the FBI, and the FBI is still connected through the PCI bus to the MIPS CPU.

From the Manual:

"Each pixel chain may have either 1, 2 or 3 Texture Units. The following effects
are available with these configurations:
1 Texture Unit -Dithered tri-linear interpolation.
2 Texture Units -True tri-linear interpolation or dithered tri-linear interpolation
with detail texture.
3 Texture Units - True tri-linear interpolation with detail texture.

In addition, the maximum size of the texture cache is 4MBytes, 8MBytes and
12MBytes for 1, 2 and 3 texture units respectively. The size of the texture cache
determines the total size of textures that can be used in any one view without
needing to resort to paging from main DRAM memory For optimum performance,
all the textures for all databases in use should fit in the texture cache.
"

Thx for extra info. Seems I had right. There was nothing done with extending address space window for tmus. Still 8MB and this implicts use of 3rd tmu to share same memory as 2nd tmu. Which makes these solutions in reality 2x12MB cards, not 2x16MB (including fbi: 4+8=12, but not 4+12=16). Usage of 3rd tmu is very, very restricted and it's just an ordinary hack and seems it's pointless in 444 mode because of:
* 3rd tmu uses copy of memory of 2nd tmu and in fact can't be programmed independently because of lack of registers in memory space for tmus, it could help to reorganize/decrease mem size per tmu to 2MB, but there will not be nice 444 in cards name, just poor 222 😉
* 3rd tmu can be used only for trilinear mode, does really it is worth all this work?
* 3rd tmu requires sacrificing of extra voodoo2 card (three total) for chips (2 tmus + 16 ram chips), it's just a waste
* enabling 3rd tmu requires recompilation of all existing drivers and tools, extra developing and testing which can be very difficult, time consuming or even impossible
* usage 3rd tmu in games/applications may require also creating additional patches for each app/game, another hills to reach
* there is probably more disadvantages with 444 tmus, you will find them for sure 😉

So, summing up: these solutions aren't real 4444 cards. And probably never be, due to limitation of 3dfx architecture. It's just a hack and fake 12MB for 3 tmus. The only nice things are hdmi and pci bridge, but using it with 3 tmus is a waste. IMHO.

Personally I'd rather go for triple?/quad sli with 2 tmus 4+4 for each fbi. Everything should work from a shot with existing drivers/tools. And can be possible to use original v2 cards without desoldering them 😉 But this is idea for another project.

Btw, by curiosity I checked mojo.exe, its source code and decompiled exe. And in fact, there is hardcoded max tmu units to 2, so you'll never check your 3rd tmu unit with this tool/glide until you recompile them all. Re-designing old gfx card isn't only a wiring chips, there must be also sw part done, because hw can't exist without sw, direct analogy is human body & soul 😉

Anyway, congratz to your hard work. I hope you'll finish your project, even with only 2 working tmus 😉

Cheers.

P.S. It'd be great if you could share any additional sources/docs/specs/schematics etc. related to these cards/chips, there is lack of such tech info, at least I can't find them 😉

From the extra info I posted it seems to me that you were wrong, but I'm not going to engage in this any further. You can personally call these cards how you want.
And you probably didn't read this part: "Alternatively, you can use single texturing and simply use the additional TMU to provide an extra 4MBytes of texture memory."