Gold Leader The hardware is there, and it is correct. However, without the Rush driver source code, not much progress is possible. I don't feel like decompiling and patching Rush drivers for the next year or so. The AT BIOS most likely has no impact on any of this.
Posts by sdz
-
-
I made this card to test if a Voodoo Rush with two TMUs can be made:
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.
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.
Here is the FJR pinout:
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.
-
Voodoo2 FBI and TMU pinout:
Voodoo2 schematic (not the regular one, but it shows how things are connected):
https://sdz-mods.com/wp-content/uploads/2024/09/V2_4444SX_PCIE_A01.pdf
Can't attach it here, as the file is too large.
-
Tweakstone Backfire Thanks!
Gold Leader Thank you!
Yes, I'm at x-3dfx as well, and made the 4444SX. But it's not a PCIe 200SBi, it's quite a bit different. There is also a PCI version of it, but I haven't assembled it yet.
-
-
Card11(Quantum3D Obsidian2 200SBi)*:
Card seems to function properly, however, video output and video passthrough works only when the Medusa cable is tensioned in a certain way:
Looking closer at the card, it had some mechanical impact in that area, the PCI bracket is bent, and so is the video connector:
Inspecting the area under the microscope revealed that some of the pins had cracked solder joints:
Resoldered all the pins, but that didn't actually solve the problem.
It's possible that some traces or connector pins are broken, so I removed the video connector (would have done that anyway, since it wasn't possible to bend it back in position).
The traces and connector were OK. However, when measuring the ferrite beads in this area, I got some inconsistent readings. If the board was slightly bent, the resistance would vary significantly.
While they don't look cracked at all, here's what happened after gently touching them with the soldering iron:
Replaced those ferrite beads, soldered back the video connector, and straightened the PCI bracket in a vice:
Card is working properly now.
-
Card10(Quantum3D 100SB)* :
Only half of it (the right half) is detected in device manager/by mojo:
To at least detect the FBI, not much is needed. Just the PCI to PCI bridge working (which it seems to be, since the second FBI is detected), FBI power and the FBI properly connected to the PCI bus. RAMDAC, RAM etc is not needed to detect it as a PCI device.
Checking the FBI0 area, a resistor connected to it is broken:
This should be a 1k resistor, and it's open. After replacing it, and adding the shade modules:
Why was that 1k resistor so important? It connects FBI pin 230 (PCI AD20 signal) to pin 224 (IDSEL pin). There is no way the device (FBI) would correctly work on the PCI bus with the IDSEL pin floating.
-
Card9(Quantum3D 100SB)* :
Card installs fine, both halves are detected in device manager:
However, when trying to open the Q3D settins page:
Running mojo under DOS just freezes:
Without the two shade modules, the card works fine. With just a shade module installed on the left side of the card, mojo still freezes. With a shade module installed on the right, mojo doesn't freeze anymore, however, we can see a second issue. More on that later.
So, the first and more major issue seems to be on the left side, when connecting the extra TMU.
This is how the FBI and the two TMUs are connected:
TMU0 solder joints are good, so are the passives in that area and the PCB traces. However, this pin of the J13 connector is loose:
After soldering it back on, and with both shade modules installed, Q3D settings can be opened:
But that's about it:
Checking mojo again, with the two shade modules installed, we can see that the left part of the card seems ok, but the right part has an issue detecting the RAM of the extra TMU:
Quickly inspecting the card on the microscope, the right Shade module connector (J17) is messed up:
Judging by how it looks, it likely left the factory like that. A pre-bent connector was soldered, and a couple of the pins were never actually soldered to the board.
After fixing that, the card fully works:
-
I have used Voodoo5 5500 DVI cards (via DVI output ofc) extensively under Windows XP, with either SFFT1.9 or amigamerlin 3.1 R1. Haven't seen any of the issues you are experiencing.
Regarding the no DVI output, if VGA and DVI are connected on power-up, only VGA output will work.
If only DVI is connected, and you connect the VGA after the system was started, both VGA and DVI will work.
This is how the VSA VBIOS is coded.
-
Design files for the VG 4440H:
-
@all Thanks!
Yes, it's a Precision M6800, probably the last good Precision laptop (IMHO).
At the moment, no. While V4 fits fine into a laptop, existing cooling system, keyboard and all (there is one installed in my Dell Precision M4800 for a couple of months now), the V5 M5800 needs a custom cooling system, as it is not possible to reuse the existing cooling solution. I haven't designed/manufactured it yet, as it will be quite expensive, and I wanted to see the card actually working before that.
-
Installed it into a Dell Precision, only overclocked the VSAs to 183Mhz, as I can't push it more until I have a proper cooling system.
-
Another addition to the 3dfx MXM family (probably the last one with VSA-100), MXM 3.0/3.1 type B 2x VSA-100 card:
Last night I assembled one PCB:
Tested the card in a PC for now, it works fine (HDMI and VGA output):
Laptop test will follow.
This card will require a custom cooling solution (heatspreader, heatpipes and fin stack) to use in a laptop, since the MXM standard wasn't made with dual GPUs on a single PCB in mind.
-
I have an update on this. While under XP, with V4 and V5 cards, SSFT and amigamerlin drivers, the issue happens, there is no offset under Windows98 with the official 3dfx drivers.
-
Yes, I have seen his 6000 cards.
It's possible that such an upgarde will exist at some point.
Making 8 or 16 VSA cards, while possible, will require a ton of work on drivers. It's not something that I'm willing to dedicate so much time on.
Next I'd like to make a 6000 with native HDMI out, and some other goodies, but I need an original card for reverse engineering some bits, and no one is willing to sell.
-
Today I had some free time and decided to finally address the image shifted to the right by 4 pixels bug.
First thought was that there is something wrong with the horizontal timings coming out of the VSA-100. The following is from the V2 documentation, but it also applies here (hsync polarity is inverted compared to the VSA-100, but that doesn't matter):
Adjusting the horizontal back porch (hBackPorch in the above diagram) was a good place to start. I modified the FPGA code to make it smaller by increasing (doubling) the horizontal sync pulse length (hSyncOn) in the above diagram.
FBI_HSYNC_IBUF is the horizontal sync signal coming from the VSA-100, hsync_out is the increased horizontal sync pulse that is fed to the TMDS encoder block, FBI_VIDEO_D0_IBUF is one of the 12 bits of RGB data sent by the VSA.
This did absolutely nothing.Next I took a closer look at the blanking signal coming from the VSA:
FBI_BLANK_IBUF is the blanking signal generated by the VSA, FBI_VIDEO_D0_IBUF is one of the 12 bits of RGB data sent by the VSA.
The video data is sent by the VSA exactly 4 pixel clocks after the blanking signal is deasserted. The delay is always 4 pixels clocks, regardless of the resolution. This seems wrong, and 4 pixel clocks correspond to the 4 pixels shifted to the right bug, so I delayed the rising edge of the blanking signals by exactly 4 pixels clocks from the FPGA, now it looks like this:blank_out is the delayed signal, that is then fed to the TMDS encoder block at the same time as the RGB data.
This is how it looked before:
And this is how it looks now:
The sticker is there as a reference.
This fixed the issue for all resolutions. Obviously, this fix applies only for the V4 M4800 and not regular DVI V4 and V5 cards. In the future I'll try to find an universal fix.
-
Card8(Quantum3D Obsidian2 X-24)*:
Mojo.exe found nothing wrong with the card, and the driver properly installs and detects the card.
Running a 3D application results in a black screen, and the 3D application is frozen.
I removed the daugther card, and without it installed it worked fine:
Taking a closer look at the card, the FBI looks like crap. Somebody either replaced it or resoldered it at some point, but didn't clean it after.
I plugged the card back in, and disabled the TMUs from autoexec.bat. The card worked fine like this:
So it's either something wrong with the TMUs on the daugtercard, of the FBI<->TMU connection. Since the FBI already looked like that, I checked the pins, and found this one loose:
Soldering it back on was really hard, the solder wouldn't stick to the pad or the pin. After doing this the card worked fine:
While the card worked fine at this point, it's not good to leave it like this. The FBI area looks really bad, and the fact that solder doesn't stick implies corrosion:
Next I removed the junked FBI, and this is how the PCB looked like:
It was way worse than it looked. Cleaning those pads up so that they accepted new solder took about an hour, and I destroyed 1 JBC tip.
After cleaning up it looks like this:
And the card with a new FBI installed, working fine:
All the corrosion was in the FBI area, on most of the pads. This happened because someone reworked it, and did not clean the flux. Some types of flux are corrosive, and can really mess the board if left there for a couple of years.
There was also a broken cap on the daugthercard, that was replaced as well. -
PG_123 You're welcome!
Card7(Quantum3D Obsidian2 X-24):
Card installs fine, and is correctly detected by mojo.exe:
Hower, it throws this error:
This usually means that something is really wrong with it. I removed the daughtercard, and it throwed the same error.
I then checked all FBI and TMU pins, checked all the traces, measured all resistors and verified that all RAM pins are actually soldered. Everything was fine.
The FBI had some previous rework done, so I started with it. I removed the bottom 4 FBI RAM ICs, same error. Replaced the top 4 FBI RAM ICs, same error. Removed the FBI and then tried with a known good X-24 card in the system. It throwed the same error.
At this point I soldered back the FBI and original RAM.The lesson here is that while the Q3D X-24 is almost identical to the Q3D 200SB, one is intended for the consumer market (X-24), while the other is intended for professional use.
If the professional driver is installed, it will NOT work with the X-24. It will identify that the card is not an 200SB/200SBi and throw an error that normally indicates a faulty card (instead of just saying "use the right driver" or "incompatible card").
While not a repair, I thought it is useful information. Use the appropriate driver or Fastvoodoo drivers (recommended only for testing, as using Fastvoodoo drivers on Q3D 200SB/200SBi/X-16/X-24 cards causes the TV out Chrontel encoder to get stupidly hot).Here's the card with some new solder joints, working fine with the consumer driver:
-
Card6(Quantum3D Obsidian2 200SBi):
Driver installs fine, and detects the card properly:
Running a 3D application either freezes or throws an "could not initialize glide rendering system" error. Running mojo shows that the second half of the card (right one) has issues regarding TMU0, either TMU or TMU RAM (or traces and series resistors):
TMU0 on the second half of the card is this one:
Checked the TMU pins, and these ones were all loose:
Soldered them back on, and now the card works fine.
-
Lotosdrache Nice!
Card5(Quantum3D Obsidian2 200SB):
Got this card a while back, sold as working. Sometimes it works, but most of the times it either prevents the system from starting up, or does this:
Taking a look at the card, someone replaced the PCI-PCI bridge IC, and did a rather poor job of it. Two pads were ripped, a bunch of capacitor are simply missing, and a few are crooked:
I removed the bridge IC (which had a lot of gunk under it), replaced the missing caps, and proceeded to fix the missing pads (they were not connected to anything, this is just for aesthetic reasons).
With a scalpel I removed pads from a blank VG 4400H PCB:
And mounted them on the 200SB card:
I didn't have a spare 21150 IC, so I straightened the pins and soldered it back on:
Now the system boots fine every time, and the card works nicely:
