Thanks for your initial analysis.

I've attached the new compressed log file (using the -v option).

Thanks again for your help.

Next, I'd like to try swapping the two memory modules for ones from a TMU to see if that makes a difference. Would that make sense?

It's also worth mentioning that I received the card with a "defective" FBI chip. The chip had bent and broken pins. I soldered in a new chip (new old stock).

I've also checked the solder joints on the FBI chip for loose connections or solder bridges. I've also checked and resoldered the connections on the memory chips.

Attached are pictures of the card with defective pins and a picture with a new FBI chip.

I've noticed something in Witchery log :

1Checking I2C bus on GPIO...
2I2C bus disabled: no pull-up on GPIO detected!

I supposed it's not an error, since my Voodoo2 works perfectly. And I've seen this in other logs here too.
Do some V2 have i2c ?
Why this message ?
Not important, just curious 😀
My idea is maybe for some cards with tv-out, but it's just a guess.

DocStreamer wrote on 2026-02-15, 10:21:

I've attached the new compressed log file (using the -v option).

Thank's, there is a lot more info now.
There's clear indication that half of data bus of U20 and one bit on data bus of U18 are stuck. Control signals (that I've brought up in my previous post) are unrelated.

DocStreamer wrote on 2026-02-15, 14:49:

It's also worth mentioning that I received the card with a "defective" FBI chip. The chip had bent and broken pins. I soldered in a new chip (new old stock).

That's a very important info.
I'm comparing two things:

And I'm seeing a correlation...
You're saying that's a photo of the chip that was on the board before replacing and the Witchery log file is after replacement.
I can only assume that U20 RAM was fried due to prolonged short on its data bus, so replacing U20 should be on the table.
Not sure about U18's one defective bit though. It's connected to pin 27 of the FBI and it doesn't look like shorted or bent on the photo of the old FBI chip. Pin 26 next to it is a 3.3V power input but short to that would be indicated as "stuck high" not "stuck low" as in the log. Maybe U18 was also damaged somehow.
Probably there was ESD discharge from something that hit that old FBI around pin 50 and it brushed off around pin 27 and fried U18, I don't know. But it seems like U18 is also on the hook for replacement.

DocStreamer wrote on 2026-02-15, 10:21:

Next, I'd like to try swapping the two memory modules for ones from a TMU to see if that makes a difference. Would that make sense?

I'd take chips from one of the TMUs and put it in place of U20 and re-run the test. TMU can live without a RAM chip and there's no reason to install potentially bad IC there.
If that'll fix U20 and U18 will still be defective, repeat procedure with another RAM IC from a TMU.
But we are not sure about state of those RAM ICs on TMUs, those can be also be bad. Hopefully not.

nali wrote on 2026-02-15, 17:27:

I've noticed something in Witchery log :
I supposed it's not an error, since my Voodoo2 works perfectly. And I've seen this in other logs here too.
Do some V2 have i2c ?

Well, FBI markings are pointing to capacity of bit-banging I2C over certain GPIO pins:

And on Quantum3D boards there are those CPLD chips that are connected to those pins:

My problem with Q3D boards that those all use the same Board ID and Clock ID between all of those and it impossible to detect a board variant through standard 3Dfx means.
Don't get me started on Voodoos' Board ID and Clock ID mess, it's an embarassing mess.
I want to be capable to detect Q3D variant but for that I need somehow to find where to read some ID info. My only hope that it is possible through that CPLD. But there's no info on that that I could've find and I don't have access to any Q3D boards.
So I've added I2C detection and I2C address scan routines to Witchery to log whatever it can find through standard I2C.
I've tested that scan works but I'm yet to see a log from a Q3D board with that. I need some community help on that.

Thanks, that's interesting.

Fagear wrote on 2026-02-16, 02:05:

And I'm seeing a correlation... You're saying that's a photo of the chip that was on the board before replacing and the Witcher […]
Show full quote

And I'm seeing a correlation...
You're saying that's a photo of the chip that was on the board before replacing and the Witchery log file is after replacement.
I can only assume that U20 RAM was fried due to prolonged short on its data bus, so replacing U20 should be on the table.
Not sure about U18's one defective bit though. It's connected to pin 27 of the FBI and it doesn't look like shorted or bent on the photo of the old FBI chip. Pin 26 next to it is a 3.3V power input but short to that would be indicated as "stuck high" not "stuck low" as in the log. Maybe U18 was also damaged somehow.
Probably there was ESD discharge from something that hit that old FBI around pin 50 and it brushed off around pin 27 and fried U18, I don't know. But it seems like U18 is also on the hook for replacement.

Yes, that's correct, the Witchery Log was created after the FBI exchange, and yes, I also thought yesterday that it can't be a coincidence that exactly the pins that lead to the detective U20 are damaged.
The damage to the pins appears to have occurred during the removal of the heat sinks. However, the original owner of the card assured me that the card was no longer in use afterward.

Anyway, today I swapped the U20 for a memory chip from a TMU, and the U20 passed the tests. So I'll also swap the U18 for another memory chip from the same TMU and hope that this one works too.

What I also noticed in the log file, relatively near the beginning, is the following:

[2026 Jan 14, 14:28:45] [0;36mChecking FBI hardware initialization registers state...[0m [2026 Jan 14, 14:28:45] [0;33mWarning: […]
Show full quote

[2026 Jan 14, 14:28:45] [0;36mChecking FBI hardware initialization registers state...[0m
[2026 Jan 14, 14:28:45] [0;33mWarning: FBIINIT0 register is not at default value (0x00001c10 != 0x00000410, mask: 0x00001800)![0m
[2026 Jan 14, 14:28:45] [0;33mWarning: FBIINIT1 register is not at default value (0x002011a8 != 0x00201100, mask: 0x000000a8)![0m
[2026 Jan 14, 14:28:45] [0;33mWarning: FBIINIT2 register is not at default value (0x1824b0e0 != 0x80000040, mask: 0x9824b0a0)![0m
[2026 Jan 14, 14:28:45] [0;33mWarning: FBIINIT3 register is not at default value (0x00110001 != 0x001e4000, mask: 0x000f4001)![0m
[2026 Jan 14, 14:28:45] [0;33mWarning: FBIINIT4 register is not at default value (0x00000003 != 0x00000001, mask: 0x00000002)![0m
[2026 Jan 14, 14:28:45] [0;32mPassed: FBIINIT5 register is at default value (0x00000008) (raw: 0x00000088)[0m
[2026 Jan 14, 14:28:45] [0;32mPassed: FBIINIT7 register is at default value (0x00000000) (raw: 0x0000006e)[0m

What does that mean?

And the other question is, where can I get two new memory chips so I can fully populate the card again? I haven't been able to find the 110MHz ones anywhere yet. 😀

Here's the new log file. And don't be surprised, I just noticed that the date seems to be wrong on the test system.

Fagear wrote on 2026-02-16, 02:05:

My problem with Q3D boards that those all use the same Board ID and Clock ID between all of those and it impossible to detect a […]
Show full quote

My problem with Q3D boards that those all use the same Board ID and Clock ID between all of those and it impossible to detect a board variant through standard 3Dfx means.
Don't get me started on Voodoos' Board ID and Clock ID mess, it's an embarassing mess.
I want to be capable to detect Q3D variant but for that I need somehow to find where to read some ID info. My only hope that it is possible through that CPLD. But there's no info on that that I could've find and I don't have access to any Q3D boards.
So I've added I2C detection and I2C address scan routines to Witchery to log whatever it can find through standard I2C.
I've tested that scan works but I'm yet to see a log from a Q3D board with that. I need some community help on that.

I have Obsidian2 X-24 at hand. I can do some tests if you are interested. 😀 Just let me know.
Here are the logs of witchery -v for both parts of the card.

DocStreamer wrote on 2026-02-16, 16:31:

Anyway, today I swapped the U20 for a memory chip from a TMU, and the U20 passed the tests. So I'll also swap the U18 for another memory chip from the same TMU and hope that this one works too.

Great news! Glad U20 replacement worked. Witchery correctly pointed out the problem.
I've rechecked RAM pinout and pin 2 is also near +5 Vcc, not near ground, so it must be internal damage of U18 then.

DocStreamer wrote on 2026-02-16, 16:31:

What I also noticed in the log file, relatively near the beginning, is the following:
What does that mean?

Just some notes that FBI's hardware configuration registers are not in the default start-up state.
That can happen if some software had been run before Witchery's run after computer was reset.
Nothing to worry about.

DocStreamer wrote on 2026-02-16, 16:31:

And the other question is, where can I get two new memory chips so I can fully populate the card again? I haven't been able to find the 110MHz ones anywhere yet. 😀

Well... To repair my boards I've just bought more used and damaged boards.
I've seen 110 MHz/22 ns chips on some other boards but not very often.
I guess it's very difficult to find fast SOJ RAM chips as new nowadays.

Also, DocStreamer, I have a question for you: what Gainward board should run at, do you know?
Gainward has unique PCB design but Clock ID is set in a way that with normal drivers it should run at 77 MHz instead of regular 90 MHz. That's very odd to me. Why design a new PCB if you are not pushing clocks or adding some other features?

havli wrote on 2026-02-16, 19:04:

I have Obsidian2 X-24 at hand. I can do some tests if you are interested. 😀 Just let me know.
Here are the logs of witchery -v for both parts of the card.

Thanks!
It seems like "first half" has some pullup on one of the GPIOs but nothing responds as regular I2C device. "Second half" doesn't even have a pull-up.
Either I've got GPIOs mixed up for Q3D or CPLD does not support I2C operation and uses some proprietary protocol for communication.

DocStreamer wrote on 2026-02-16, 16:31:

And the other question is, where can I get two new memory chips so I can fully populate the card again? I haven't been able to f […]
Show full quote

And the other question is, where can I get two new memory chips so I can fully populate the card again? I haven't been able to find the 110MHz ones anywhere yet. 😀

Well... To repair my boards I've just bought more used and damaged boards.
I've seen 110 MHz/22 ns chips on some other boards but not very often.
I guess it's very difficult to find fast SOJ RAM chips as new nowadays.

I've seen some 125MHz 8ns chips on ebay recently if I remember correctly.

Is Witchery works with Voodoo 1 at all ?
Wonder if can use it to try to find any issues with V1

Here's my latest update. I also replaced the U18 today.

The card seems to be working now. Witchery ran through without any errors.

The only issue I had was a strange TMU message in Mojo. After restarting my PC, everything was back to normal.

I was also able to run 3DMark 99, and the card is displaying an image. Aside from the texture errors, which are caused by the missing TMU memory, the card is working.

Thank you for your help and, of course, for the great Witchery.

Hopefully, I can replace the missing memory soon.

Robx66 wrote on 2026-02-17, 14:40:

I've seen some 125MHz 8ns chips on ebay recently if I remember correctly.

Okay, thanks for the info. Maybe I'll get lucky and find some.

Fagear wrote on 2026-02-17, 00:30:

Also, DocStreamer, I have a question for you: what Gainward board should run at, do you know?
Gainward has unique PCB design but Clock ID is set in a way that with normal drivers it should run at 77 MHz instead of regular 90 MHz. That's very odd to me. Why design a new PCB if you are not pushing clocks or adding some other features?

Unfortunately, I can't answer that either. This is the first time I've ever held a Gainward Dragon 3000 in my hands.

Yes, it's strange that they chose their own design if there's no noticeable improvement over the stock design. I also don't have the original drivers for the card; I'm using FastVoodoo 4.6. Perhaps you could try finding the original drivers once the card is finished and run some tests with them.

The main reason for buying and repairing this card is so I can use it in SLI with my second Voodoo 2 12MB (3DFX V2-1000).

Robx66 wrote on 2026-02-17, 14:42:

Is Witchery works with Voodoo 1 at all ?

It does not (yet?).
Register-wise and hardware-wise V1 and V2 are VERY similar, but for some reason I have problems with writing to V1's registers.
You can run Witchery on V1 but it will fail tests due to this issue.
Probably its a Linux problem or something. Reading from registers is ok, writing silently fails (contents doesn't change).
But for testing register contents needs to be changed.
I don't know where the problem lies and why writing to V1 fails. If someone is familiar with hardware access in Linux and have some clues to what might be wrong - please tell me.
There's nothing stopping support of V1 except this Linux thing.

DocStreamer wrote on 2026-02-17, 16:23:

Here's my latest update. I also replaced the U18 today. The card seems to be working now. Witchery ran through without any error […]
Show full quote

Here's my latest update. I also replaced the U18 today.
The card seems to be working now. Witchery ran through without any errors.
I was also able to run 3DMark 99, and the card is displaying an image. Aside from the texture errors, which are caused by the missing TMU memory, the card is working.
Thank you for your help and, of course, for the great Witchery.

Great to hear! One more brought back to life. Good luck with finding RAM ICs!

First of all, thanks a lot for your awesome tool.

I am trying to repair a STB BlackMagic 3D 12MB (all RAM chips are in the front of the PCB). I already reflowed all pins and changed SMD Electrolytic Capacitors since one of them was apparently leaking and had damaged its pads. While doing so I was sure they were all fine, and Witchery detected a short I had left and pointed to the general area, I was really impressed with the quality of the feedback. After fixing that it now reads: "All tests passed successfully!"

Unfortunately it seems the errors I have are TMU RAM related, and of course that is still not supported in witchery. I wanted to ask for advice on how to proceed with diagnosis. MOJO detects it fine, drivers install fine and the board is detected under the Display Settings tab.

GLQuake runs with texture errors.

I changed SSTV2_TMU_MEMSIZE to 2 and SSTV2_NUM_TMUS to 1 and it made no difference, so we know it is on that side of the board. If ran with textures disabled, models and shading look good.

The Tomb Raider demo on DOS looks like so:

So basically I am asking for any advice on how to proceed to find the damaged RAM... Thank you again.

Artemio wrote on 2026-02-24, 06:47:

The Tomb Raider demo on DOS looks like so:

For Tomb Raider, it could be the usual wrong colors we get with a Voodoo2, unless we set a few variables :
set SST_GRXCLK=90
set SST_FT_CLK_DEL=0x4
set SST_TF0_CLK_DEL=0x6
set SST_TF1_CLK_DEL=0x6
set SST_VIN_CLKDEL=0x1
set SST_VOUT_CLKDEL=0x0
set SST_TMUMEM_SIZE=2

Artemio wrote on 2026-02-24, 06:47:

First of all, thanks a lot for your awesome tool.

Thanks!

Artemio wrote on 2026-02-24, 06:47:

I am trying to repair a STB BlackMagic 3D 12MB (all RAM chips are in the front of the PCB). I already reflowed all pins and changed SMD Electrolytic Capacitors since one of them was apparently leaking and had damaged its pads. While doing so I was sure they were all fine, and Witchery detected a short I had left and pointed to the general area, I was really impressed with the quality of the feedback. After fixing that it now reads: "All tests passed successfully!"

What was the problem that Witchery spotted?

Artemio wrote on 2026-02-24, 06:47:

So basically I am asking for any advice on how to proceed to find the damaged RAM... Thank you again.

Not from me yet... I want to get answers for this myself.
Still waiting for SOJ-40 sockets.

nali wrote on 2026-02-24, 20:23:

For Tomb Raider, it could be the usual wrong colors we get with a Voodoo2, unless we set a few variables : set SST_GRXCLK=90 set […]
Show full quote

For Tomb Raider, it could be the usual wrong colors we get with a Voodoo2, unless we set a few variables :
set SST_GRXCLK=90
set SST_FT_CLK_DEL=0x4
set SST_TF0_CLK_DEL=0x6
set SST_TF1_CLK_DEL=0x6
set SST_VIN_CLKDEL=0x1
set SST_VOUT_CLKDEL=0x0
set SST_TMUMEM_SIZE=2

Please note that clock phases are not universal to all boards.
PCB layout affects those. Reference PCB will have one set of "best phases", STB board will have another, Gainward will have its own.
Also optimal values can change with graphics clock.

For example, phase maps for different graphic clocks:

And phases for totally different PCB:

"SST_FT_CLK_DEL" is FT bus clock phase (vertical on the map), "SST_TF0_CLK_DEL" is TF bus clock phase (horizontal on the map).

Artemio , you can find best phases for your STB board by running as

1witchery -e64 -c90

(-c90 sets graphics clock to test at)
Working TMU #1 and TMU's RAM is not required.

nali wrote on 2026-02-24, 20:23:

For Tomb Raider, it could be the usual wrong colors we get with a Voodoo2, unless we set a few variables :

Thank you, I was not aware there were things to set I innocently ran the demo on DOS since it ran perfectly fine on a 3dfx Velocity 100. Will experiment with those as advised below.

Fagear wrote on 2026-02-24, 22:12:

What was the problem that Witchery spotted?

It reported this:

And there was a very small bridge between pins 22 and 23 in TMU 0 that my inspection had missed after reflowing, it was basically a flake of loose solder stuck behind the pins.

Fagear wrote on 2026-02-24, 22:12:

Not from me yet... I want to get answers for this myself.
Still waiting for SOJ-40 sockets.

Thank you, of course no rush at all.

Fagear wrote on 2026-02-24, 22:12:

Artemio , you can find best phases for your STB board by running as […]
Show full quote

Artemio , you can find best phases for your STB board by running as

Copy code to clipboard

1witchery -e64 -c90

(-c90 sets graphics clock to test at)
Working TMU #1 and TMU's RAM is not required.

Will check this, thank you again.

Results were:

Full Log

and it looks like so, colors are now correct but textures of course are wrong. Thanks!

Artemio wrote on 2026-02-25, 00:16:

And there was a very small bridge between pins 22 and 23 in TMU 0 that my inspection had missed after reflowing, it was basically a flake of loose solder stuck behind the pins.

Thanks for the info.

Artemio wrote on 2026-02-25, 01:52:

and it looks like so, colors are now correct but textures of course are wrong. Thanks!

Yep. One of the symptoms of fringe on the edge of failing phases is wrong color rendering (on textures) and small streaks all around: