When the second TMU is enabled in hardware, the card works fine, but with only 1 TMU actually used.

I have tried many regular drivers, the Q3D Ventana 50 driver, different BIOS images, even the Q3D Ventana 50 BIOS, no difference.

On a Q3D Ventana 50, when installing an Amethyst module, it freezes when running a 3D application (http://www.thedodgegarage.com/3dfx/).

The card layout looks like this:

Unlike the OG Voodoo, which has dual TMU support even in the retail drivers, the existing Rush drivers have no support for it.

Unless the Rush driver source code somehow appears on the internet, this is it for this card. (Edit: https://github.com/sezero/glide , VG96 sources seem to be there, so it might be possible).

It was an interesting test though, and I found out some new things, some of which weren't available on the internet, and I will describe below.

The Voodoo Rush chipset is made from: 2D IC (AT25/AT3D or the Macronix one), FJR (which stands for FBI Junior) and the TMU (which is the same TMU used on the OG Voodoo).

The 2D ICs are made specifically for Rush cards, it is not possible to use another 2D IC, as there is a dedicated bus for talking to the FJR (probably for memory arbitration).

AT25/AT3D are interchangeable, they have the same pinout.

Some articles mention that the Rush has low performance because the 2D IC and FJR fight for PCI access. While they do fight for access in many ways, the FJR is actually not connected at all to the PCI bus, only the 2D IC is connected there. Everything goes through the 2D IC.
The 2D IC and FJR share a small bus, called the THP bus. This consists of the following signals (seen at the FJR side):

Besides that, the FJR and 2D IC are connected to the same RAM ICs. Literally the full memory controller of the 2D IC connected to the RAM ICs connected to the full memory controller of the FJR. ADDR, DATA, RAS, CAS, OE, WE.

The 2D IC generates the FJR and TMU clock. Besides this, there is no other connection between the 2D IC and the FJR. This diagram shows the major components and how they are connected:

On AT25/AT3D cards, the clock generated by the 2D IC goes through an AV9170-1 clock synchronizer before feeding the FJR/TMU. This IC is used on all AT Rush cards out there. While some cards have an option to bypass it on the PCB, bypassing it will result in a non-working Rush. Possible reasons: DC offset on AT output clock/clock needs a negative phase offset for things to sync (the output of the AV9170 has a small negative phase offset compared to the input).

Early Rush Intergraph cards had a footprint for an oscillator. This would allow clocking the FJR/TMU from that oscillator, instead of the 2D IC.

It was never used, as there is no way to sync that clock to the AT IC. I did test this on an existing card (externally feeding a clock of the same frequency as the AT, but obviously the two clocks are freerunning), and it resulted in:

The later Intergraph revision removes that footprint and adds a regulator. That regulator is present on most late Rush cards, while the early ones (eg. the dual planar ) do not have it.

On early cards, 2D IC/FJR/TMU/etc are powered by 5V. On the later cards with this regulator present, 2D IC/TMU/etc are powered by 5V. The FJR is powered by 5.25V from the regulator.

Regarding clocks, the Rush was probably intended to be clocked much higher, there is a mention of 75MHz is some SDK documentation. However, there is really no signal integrity on the card.

As mentioned earlier, the FJR and 2D IC physically access the same RAM. This means, that while one IC or the other does RAM operations, there are huge stubs because the RAM is also connected to the other IC. To make things works, the BIOS IC also sits on a part of this bus, as well as parts of the VMI connector.

On earlier cards, eg. Hercules Stingray dual planar, the AT3D PCB has two of the RAM address lines are flipped (A0 and A7). On the expansion cards (that hold the 3dfx bits) there are resistors for selecting if it should invert those or not. Obviously they are flipped there as well, as it couldn't work properly if only one of the ICs flipped those.

Usually, swapping address bits is very bad, even for EDO RAM. I tested this on a V2 FBI, inverted two address lines, and the framerate was halved.

I did flip those address lines to the proper position on the Hercules Stingray dual planar card, there was no increase in performance. The card started working properly with the single planar driver though, which it didn't before.

Later single planar cards have all the RAM address lines in the proper order.

Digital video output (eg. HDMI) is not possible on the AT Rush. While the AT25/AT3D has a 16 bit parallel video output bus, some of those bits are multiplexed with the THP bus. 16bpp is not possible in 3D mode. 8bpp would be possible, but it makes little sense.

There are 3 pins, UNK_1, UNK_2, UNK_TP_1. UNK stands for unknown. UNK_1 and UNK_2 have strapping resistors, but I am unsure of the function. UNK_TP_1, on all Rush cards I looked at, is just connected to a test point.

Besides those two pins with strapping resistors, there are 4 more FJR straps that sit on the memory bus:

Their function is currently unknown.

FJR pinout:

Super cool.

This regulator LM317 generates a lot of heat. I add a heatsink for it.
And I always adjust the output voltage of this regulator 5.25-->5.00.
Why this regulator was introduced is a mystery to me. Perhaps, to take some energy from the 12 Volt line. Or maybe, it was planned to increase the clock frequency, for this they raised the voltage a little. There is a desire to remove this regulator and connect the FJR to the 5 Volt line.

It was added there for stability/increasing the clocks a little. Earlier cards, without that regulator, were clocked at 45MHz IIRC.
If it was just for decreasing the load on the 5V PCI line it would have been set to 5V output instead of 5.25V.
You can remove it and just feed the FJR with 5V. If it's stable at 50MHz, just leave it like that.

If it's specifically on 5.25V it feels like either getting more headroom for clocks or compensation for voltage drop over the traces under load. Especially if there is high load on the 5V rail, the 5V from the PCI connector would be anywhere but 5V, so having a precise known voltage is certainly helpful for good results.

Thanks for sharing all that knowledge with us sdz, that's again awesome to dig through!

sdz wrote on 2025-09-02, 09:44:

It was added there for stability/increasing the clocks a little. Earlier cards, without that regulator, were clocked at 45MHz IIRC.
If it was just for decreasing the load on the 5V PCI line it would have been set to 5V output instead of 5.25V.
You can remove it and just feed the FJR with 5V. If it's stable at 50MHz, just leave it like that.

Thanks for your help, this is very useful information.
I have two types of Rush on my desk right now, I measured them:
InnoVision 3DXRush (Alliance) with LM317 - 50 MHz
3Dfx Voodoo Rush A-Trend ATG-2476P (Macronix) without LM317 - 50 MHz

Can you modify the SST96 code in https://github.com/sezero/glide to address the other TMU? I don't know the register interface but it might be that you don't need to modify the driver at all - it might just do bar mapping on behalf of the glide library.

@tehsiggi glad you enjoyed it!

@furan I did take a look a while back. It should be possible, but it doesn't seem to be that straightforward.

Time to necropost. After a significant amount of effort (this is attempt number 4 or 5 at getting this working since I made the card), I got the Rush driver working with two TMUs.

So, was this worth it and made the Voodoo Rush actually better? Well, it is better, and was worth it as an experiment (also, first working dual TMU Voodoo Rush!):

Quake2, 640x480, single TMU, 2MB per TMU, 17.6FPS
Quake2, 640x480, dual TMU, 2MB per TMU, 27.2FPS

Quake2, 640x480, single TMU, 4MB per TMU, 17.6FPS
Quake2, 640x480, dual TMU, 4MB per TMU, 27.2FPS

Results averaged over a couple of runs. The extra TMU memory does work, but it doesn't help in this usecase. I need to clean up the driver source code, after which I'll upload it to github.

Interesting, so with the 2nd TMU enabled on a Rush you get performance landing between a garden variety Voodoo 1 and a Voodoo II huh?

Yes. Finally a Rush that doesn't suck.

17.6 to 27.2FPS in Q2@640x480 (on a 400MHz PII) is nice, but surely, it can do a little better.
Card runs at the default 50MHz, so I tried overclocking. It was only stable up to 53MHz. The only other working Voodoo Rush card I have is the Hercules Stingray 128/3D Dual-Planar. This card overclocks as badly as the VR4440, topped out at the same ~53MHz.

When running the VR4440 at more than 53MHz, I noticed some rendering errors that were very similar to what I observed on original Voodoo Rush cards, when clocking the FJR+TMU with an external clock source (instead of the clock supplied by the 2D AT IC). Which means that the 53MHz ceiling might be related to how the 2D IC and the FJR interract with the shared memory (even more confirmed by the the presence of the IDT9170B-01 clock synchronizer IC used on the AT* Rush cards. Without the phase difference it introduces, AT* Rush cards are not stable at all).

On regular AT* Voodoo Rush cards, the AT* feeds the clock to the IDT9170B that then feeds both FJR and TMU from the same output. On the VR4440, I kept the same IDT9170B, but also added an IC used as a clock fanout buffer (because there is an extra TMU on the card, so an extra load. Didn't feel comfortable feeding 3 ICs from the same clock output).
Now, from the clock fanout buffer, I made all clock traces equal (clock buffer to FJR = clock buffer to TMU0 = clock buffer to TMU1).

However, when I designed the card, I added another clock path to the FJR, which uses a short as possible trace (just in chase there was indeed a phase relationship between the AT* and FJR).

After moving two 0R resistors, the card now does 58MHz stable!

I have also tried to bypass the extra clock fanout buffer I added (so it resembles original Rush designs), with or without the FJR clock "bypass lane", and it's capped at 53MHz. So, bypass, and external clock fanout buffer = 58MHz.
Next, I tweaked some internal driver parameters (SST96_FT_CLK_DEL SST96_TF0_CLK_DEL SST96_TF1_CLK_DEL SST96_TT_CLK_DEL, can now be set externally with the new driver, same as then could always be set for a Voodoo/Voodoo2 card but never on the Rush for some reason).

This brought another MHz. Now the card does 59MHz stable, with no rendering errors. That gives another bump in Quake2 from 27.2FPS to 31.3FPS!

Congratulations on having the fastest Rush ever! It never occurred to me that a clock signal could be overloaded.

@Putas Thanks!

If anyone is interested, I uploaded the design files here https://github.com/sdz-mods/Voodoo_Rush_4440 .

Got nothing much to add other than saying I totally enjoyed reading about this effort. Congrats on making it work!

Awesome project.

Kinda curious what a third TMU would do for performance. Maybe not on a Voodoo Rush, but the Graphics and II did support that third one.

@NitroX infinity , out of the box, probably not much. There likely aren't any glide games that could make use of the third TMU. Going the miniGL route is probably the way to go and make some games actually use the third TMU.
At some point I'll start working on this again Voodoo 2 4444SX and get the thrid TMU up.