Some (slightly outdated) screenshots:

Thanks! Was waiting for this. Got a Voodoo 2 card for some time which has issues. Hopefully it will be help to point out where the problem is.

Yoghoo wrote on 2026-01-25, 17:43:

Thanks! Was waiting for this. Got a Voodoo 2 card for some time which has issues. Hopefully it will be help to point out where the problem is.

I hope it helps.
Either way would like to see a log file (it's saved in the launch folder).

Looks good! I'm having a Voodoo2 12MB card coming my way so I planning to give your software a try.

Thank you so much, mojo is very limited and this will help a lot.

Darkblue wrote on 2026-01-25, 21:39:

Thank you so much, mojo is very limited and this will help a lot.

I'll be honest, MOJO literally does almost nothing. It initializes stock 3Dfx driver and asks it for all the info then prints it out. No real diagnostics is happening.
RAM size determined by three write-reads at the boundaries of 1/2/4 MiB per chip and that's all. No RAM filling, let alone march tests.
And if anything is wrong with RAMDAC, clock paths or whatever, MOJO will loop and hang the system.
Also, MOJO breaks completely on "too fast" CPUs (P-III 700 and above).

Witchery is build to work on very broken boards. It'll work correctly even on this:

Great work, thank you!

I have at least one defective Voodoo2, so I'll test it. Curious what the output will be 😀

I have one that says 8MB RAM instead of 12, but works without problems.... Now i will try to find where the problem is 😀
Thaaankssss

Fagear wrote on 2026-01-25, 18:05:

Yoghoo wrote on 2026-01-25, 17:43:

Thanks! Was waiting for this. Got a Voodoo 2 card for some time which has issues. Hopefully it will be help to point out where the problem is.

I hope it helps.
Either way would like to see a log file (it's saved in the launch folder).

Here's the log file. End result was: All tests passed successfully. But I guess as the proper TMU tests are not implemented yet it's probably that one of the TMU's is not working correctly.

It also said that it's an Unknown Board ID. The board is from Diamond Multimedia Systems (MON 3D II PCI 12MB MOSEL / Rev: A).

Yoghoo wrote on 2026-01-26, 21:04:

End result was: All tests passed successfully. But I guess as the proper TMU tests are not implemented yet it's probably that one of the TMU's is not working correctly.

Yep, at least now you are sure that RAMDAC, FBI and its RAM are ok.

Yoghoo wrote on 2026-01-26, 21:04:

It also said that it's an Unknown Board ID. The board is from Diamond Multimedia Systems (MON 3D II PCI 12MB MOSEL / Rev: A).

That's strange. Diamond Multimedia should have 0x09 Board ID, yours have 0x01.
Witchery rightfully tells you too look at strap resistors, those set Board ID (but Witchery assumes you have a reference board, so suggestions are for that).

Your's missing bit 3 in that, check R62 and R80 above RAM ICs at the bottom right.
R62 (top one) should be absent, R80 (bottom one) should be present:

Fagear wrote on 2026-01-26, 23:05:

Yep, at least now you are sure that RAMDAC, FBI and its RAM are ok. […]
Show full quote

Yoghoo wrote on 2026-01-26, 21:04:

End result was: All tests passed successfully. But I guess as the proper TMU tests are not implemented yet it's probably that one of the TMU's is not working correctly.

Yep, at least now you are sure that RAMDAC, FBI and its RAM are ok.

Yoghoo wrote on 2026-01-26, 21:04:

It also said that it's an Unknown Board ID. The board is from Diamond Multimedia Systems (MON 3D II PCI 12MB MOSEL / Rev: A).

That's strange. Diamond Multimedia should have 0x09 Board ID, yours have 0x01.
Witchery rightfully tells you too look at strap resistors, those set Board ID (but Witchery assumes you have a reference board, so suggestions are for that).

The attachment 2026-01-27 01.50.51.png is no longer available

Your's missing bit 3 in that, check R62 and R80 above RAM ICs at the bottom right.
R62 (top one) should be absent, R80 (bottom one) should be present:

The attachment 20140408_591916.jpg is no longer available

Thanks for the explanation. The photo is an exact match for my card. So R62 (top one) is absent and R80 (bottom one) is present.

Yoghoo wrote on 2026-01-27, 11:59:

Thanks for the explanation. The photo is an exact match for my card. So R62 (top one) is absent and R80 (bottom one) is present.

I'd check resistance of R80 and its connection to FBI pin 113, Board ID should not be 0x01.

Fagear wrote on 2026-01-28, 18:08:

Yoghoo wrote on 2026-01-27, 11:59:

Thanks for the explanation. The photo is an exact match for my card. So R62 (top one) is absent and R80 (bottom one) is present.

I'd check resistance of R80 and its connection to FBI pin 113, Board ID should not be 0x01.

Thanks. Just measured R80 and and guess it needs to be replaced (measured 1.4 kΩ). I know that pins 63 and 64 on the TMU (Bruce) are shorted but didn't check the rest yet. So more repair work in the future. 😀

Don't have time to pick it up the coming weeks unfortunately. Also need to order some 4.7kΩ 0603 resistors first.

Some pictures from development process:

Some "unintended" uses of Witchery:

• it can be used as quickstart on digital terms and data representation (witchery -q)
• it can display connection tables between FBI and different devices connected to it for different board layouts (witchery -istb conmap -u4)
• it can generate VGA output with only RAMDAC and FBI working, rendering using FBI only (witchery -t)
• it can test board overclock, providing reports for FBI rendering and FB RAM integrity (witchery -c105)
• it can test FBI -> TMU and TMU -> FBI buses for stability on different graphic clocks and also find the best phase combo for the PCB layout (witchery -e64)

Last two probably can be used to bin FBIs, TMUs and RAM ICs for overclocking and new PCB layouts debugging.

I love it! Seen some of it in use on BuB and keen to try it on a crusty old Voodoo2 I got off Ebay a long time ago.

Wow, thanks. Have been waiting on this for a while. Currently have 5 12mb V2's, and only one both passes BuB's VRM resistance check AND renders fine. The rest either render fine and fail the VRM check, or otherwise have rendering issues.
Ran witchery against the one I am using that passes and renders fine, but witchery says:
Pixel/video clock is out of range!
RAMDAC Xtal clock is measured as 0.041 MHz, but should be at 14.318 MHz
RAMDAC pixel clock test failed
Warning: FBI might not be getting pixel clock from RAMDAC!

Will have to wait until it warms up outside to set up an open bench test setup so I can get at the recommended test points while powered on.

Gaudeamus83 wrote on 2026-01-31, 16:58:

Ran witchery against the one I am using that passes and renders fine, but witchery says:
Pixel/video clock is out of range!

That's interesting.
What CPU your system is running?
According to the log file, chipset is ULi M1541, but CPU clock is all over the place: 825 MHz at "normal" run and 970 MHz at "verbose" one.
That test (pixel clock performance) requires stable high-precision timer-counter in the system to compare Voodoo against. But it seems like timer is not doing what is supposed to do.
If base clock (from CPU) is unreliable, this test will return unrelaible results.
Maybe there are some mitigations that could be done, but I don't have any systems with ULi chipset.
If your board renders fine, you can skip this test by adding "-e4" to the parameters.
Like:

1witchery -v -e4

Also, here is the list of launch parameters:

Fagear wrote on 2026-01-31, 17:40:

That's interesting. What CPU your system is running? According to the log file, chipset is ULi M1541, but CPU clock is all over […]
Show full quote

Gaudeamus83 wrote on 2026-01-31, 16:58:

Ran witchery against the one I am using that passes and renders fine, but witchery says:
Pixel/video clock is out of range!

That's interesting.
What CPU your system is running?
According to the log file, chipset is ULi M1541, but CPU clock is all over the place: 825 MHz at "normal" run and 970 MHz at "verbose" one.
That test (pixel clock performance) requires stable high-precision timer-counter in the system to compare Voodoo against. But it seems like timer is not doing what is supposed to do.
If base clock (from CPU) is unreliable, this test will return unrelaible results.
Maybe there are some mitigations that could be done, but I don't have any systems with ULi chipset.
If your board renders fine, you can skip this test by adding "-e4" to the parameters.
Like:

Copy code to clipboard

1witchery -v -e4

Also, here is the list of launch parameters:

The attachment witchery launch.png is no longer available

Running an AMD K6-III 450MHz with stock clock and voltage jumpers, on an ASUS P5A-B rev1.04. Your assessment tracks since I ran it against two other cards and all three failed at the same place. Each run, whether on the same card or another gave different TSC and Xtal frequencies. Will run it again on each card with -v -e4 and see what happens. Currently on the fully working card on 3/4 of stage 5.