Greetings,

I’ve decided to post here my observations while troubleshooting a bricked Voodoo2 card, in this case, it was missing two EDO memory ICs, which were removed by previous owner.

When I got this card, few years ago, it was in a pretty bad shape, missing metal bracket, few SMDs and detached/shorted pins on FBI chip. Before inserting this card into PC, I’ve thoroughly inspected it and eliminated mentioned defects. To my surprise card was detected and I was able to install drivers, but whenever I’ve tried to run any glide/d3d application, it just kept hanging and I was getting either “glide2x.dll expected voodoo^2 none detected” or “memmap driver initialization failure” error messages. I knew that these errors were related either to FBI or missing memory ICs, so I began testing this voodoo by applying different environment variables in registry or by creating specific batch files: limited TMU memory to 2 MB, disabled 1 or both TMUs, disabled texturing, etc.

Tried basically everything that was possible in various combinations, but applications kept hanging and I was not getting any noticeable results from these settings until… recently I’ve found out that it is possible to LOG Voodoo’s while application is being loaded with “SSTV2_INITDEBUG_FILE” env. variable.

After logging the bricked Voodoo, I’ve noticed that it stops generating log right after initializing TREX registers and resetting TMUs. After discovering this, I’ve disabled registers initialization with “SST_IGNORE_INIT_REGISTERS” env. variable. Well, results were the same (apps hanging) which is normal as disabling registers initialization would cause even fully functional Voodoo to stop working.

At that moment I thought that this voodoo was a complete goner, until I reset PC and when it completely loaded, I got a weird error message which was caused by loading Voodoo2 control panel (it never loaded before, just kept hanging like any other related app!) it was something new, obviously, so I decided to run NFS2 SE with textures disabled, init. regs. enabled again and it LOADED w/o hanging 😀, though menu was pitch black, but I could hear menu sounds and could start race, at which UI was visible! Couldn’t believe my eyes… I still don’t get why it began working after disabling and re enabling init. registers.

Then the testing with different env. variables began again…

Bricked Voodoo2, A-Trend Helios 3D:

Close up of the damage:

I did some testing using 3Dfx tech demo “Donut” trying to figure out which TMU is being disabled by “SSTV2_NUM_TMUS” env. variable.

Results:

SSTV2_TEXMAP_DISABLE=0

1TMU – causes hanging;
2TMU – causes hanging;
0TMU – causes hanging.

SSTV2_TEXMAP_DISABLE=1

1TMU – runs;
2TMU – runs;
0TMU – runs, but just intro screen, then hangs.

Doing these tests I’ve concluded that:

- Both TMUs are functional (can switch them off and on, it affects FPS and surface lightning).
- FBI with its memory are fully functional (no broken/corrupted wireframes).

Screenshots:

Driver demo, bricked Voodoo2, textures disabled:

Good Voodoo2, textures disabled:

Good Voodoo2, textures enabled:

Donut tech demo, bricked Voodoo2, textures disabled, 2TMU, background off:

Good Voodoo2, textures disabled, 2TMU, background on:

Analyzing logs and card itself, I tried to figure out which TMU is primary (TMU[0]) and which is secondary (TMU[1]) on the card, as I have another Voodoo2 which produces corrupted textures while both TMUs are active. Disabling one TMU on it, textures are displayed as it should be (limiting TMU memory to 2 MB doesn’t help). Knowing which TMU is which, it would be possible to locate memory bank or TMU that is causing texture corruption (if anyone knows it, please reply here).

I’ve also analyzed memory configuration on both TMUs, it appears that each memory IC has it’s own address bus, so none of the ICs share same address lines in the same bank (while other EDO graphics cards or SIMM 72 module memory ICs do use same address lines). Also, each TMU has two memory banks connected to them, which are being controlled by two separate RAS lines. Memory ICs are electrically stacked on each other, only RAS lines separate them.

I’ve come up with two ideas on how I could “fix” and test this card at the moment:

1. Socket two ~40ns EDO ram ICs (I don’t have any faster laying around) into SOJ sockets and solder them to the PCB contacts via wires using dead-bug method and declock card.
2. Connect BANK0 (damaged) RAS line to the BANK1 (on the back side), converting it into 8 MB version.

The latter one seems way easier, I’ll try it first 😀