RetroLizard wrote on 2026-04-07, 13:18:

Is this able to be used on older linux distros from the early 2000's?

I don't know. Maybe?
Witchery is provided as standalone package with purpose-build environment and Witchery binary itself.
When it'll go in public beta probably its binary will work on random Linux systems.
That's not the point of the utility though. Making it work on whatever Linux system is very low priority task.

I have a few Obsidian 200SBi cards working. One of them is up and running as we speak, the other simply crashes when Windows' hardware detection tries to detect its PCI-to-PCI bridge. I can run some tests/upload some logs if you want.

subhuman@xgtx wrote on 2026-04-10, 04:41:

I have a few Obsidian 200SBi cards working. One of them is up and running as we speak, the other simply crashes when Windows' hardware detection tries to detect its PCI-to-PCI bridge. I can run some tests/upload some logs if you want.

I'd like to see what Witchery would say about the one that crashes Windows.

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

Results were: […]
Show full quote

Results were:

The attachment Screenshot 2026-02-24 19-38-07.png is no longer available

Full Log

The attachment 260224_18-39-49_witchery.log is no longer available

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

The attachment Screenshot 2026-02-24 19-41-41.png is no longer available

The attachment Screenshot 2026-02-24 19-42-41sm.png is no longer available

Hi because your FBI is ok - and because you turned off tmu1 same artifacts and turned off the back ram - its one of 3 things - bad TMU0 ram - bad TMU0 - or loose legs on the TMU or a failed broken resistors around the TMU 0- ive had similar texture artifacts and run witchery = FBI and ram ok = i replaced the ram on TMU0 and no improvement for me after turning every thing off - so that leaves a failed TMU0 in my case . if u can solder - a ram swap for TMU0 is doable - its also ram is more available than a TMU which has to come from a donor - either way you need a microscope and skills to get them on straight and soldered properly

what is your method to desolder and solder SOJ-40 chips ?
With hot air gun and soldering iron ?
With hot air gun, which temperature ?

@Fagear is there anything that would stop Witchery loading from FreeDOS? I formatted a USB with FreeDOS (Rufus) but when I run WITCHERY.BAT it starts to load but nothing happens.

zuldan wrote on 2026-05-04, 06:46:

@Fagear is there anything that would stop Witchery loading from FreeDOS? I formatted a USB with FreeDOS (Rufus) but when I run WITCHERY.BAT it starts to load but nothing happens.

Reloading from DOS into Linux is handled by LOADLIN.EXE, I don't have anything to say about its compatibility with FreeDOS.
Witchery is provided in two variants:
- to load from DOS (MS-DOS and what else LOADLIN is supporting)
- to load from Linux (as Linux binary)
If neither of variants work on FreeDOS... well, tuff luck. Witchery is Linux-based binary in its core. If there's no way to run Linux-binary from FreeDOS then FreeDOS will not be supported.

-

Hi!
I noticed on BuB's YouTube channel that a new tool had been released that lets you test the memory of TMUs.
https://gitea.chacha.ddns.net/chacha/V2TMUMemTester

Have you tried it yet?

https://www.youtube.com/watch?v=BVhEIGM3n0o

I just tried this utility on my P166MMX running MS-DOS 6.22. LOADLIN starts but as the Linux kernel starts booting I keep running into a Kernel Panic saying "Unable to mount root fs on unknown-block(0,0), is there a preferred Linux distro I should try to load the Linux binary directly?

The author recommends this distribution
https://gitea.chacha.ddns.net/chacha/RetroDebian

SylvainA wrote on 2026-05-29, 20:42:

I noticed on BuB's YouTube channel that a new tool had been released that lets you test the memory of TMUs.

I've seen that video but I'm doing my thing with TMU mapping at the moment.
And as far as I know that tool uses 3Dfx driver to access the board, that's no good for low level problems.

Yes, it does seem more appropriate to communicate with the graphics card at a low level rather than through software via a driver.
But in the meantime, this might be a workaround for non low level issues.
All the best for the work still ahead!

FYI

Try now to understand what that means 😀
I suppose to U13 memchip is dead ? R115 ?

Hello, New user here. My Q3d x-24 card is throwing up some serious errors, even though it looks to be in great shape. Witchery has me run it twice for both boards. One board looks to only need a memory chip. The main board suggests looking at ferrite beads, caps, chip u20, connections between that and u1, Y1, says maybe the xtal needs to be replaced??? Who should I contact to work on it? I 'need' this for my retro build. Still new to witchery or would post log file.

thanks

😀

quattro64 wrote on 2026-06-01, 19:16:

Hello, New user here. My Q3d x-24 card is throwing up some serious errors, even though it looks to be in great shape. Witchery has me run it twice for both boards.

Hi! Witchery does not fully support Q3D boards. Technically all V2-based boards are the same, that's required by 3Dfx datasheet. But PCB layouts, component markings and additional components can differ. Q3D is an extreme case of that.
At the moment Witchery can not distinguish between different Q3D boards (for some stupid reason Quantum3D decided to give identical Board ID and Clock ID to all its boards). So if Witchery sees Q3D board it assumes Obsidian S12 PCI variant.
X-24 (as well as 200SB(i)) is basically two V2 boards in one package, that's why Witchery sees two boards. Witchery will print designations based on S12 variant and that could be completely wrong for X-24 board.
I don't have direct access to any Q3D boards, so support is relying on owners of those boards to buzz out connections, create connection maps and other work. I even know at least a couple of people with Q3D boards but they seem to be very busy.

quattro64 wrote on 2026-06-01, 19:16:

One board looks to only need a memory chip. The main board suggests looking at ferrite beads, caps, chip u20, connections between that and u1, Y1, says maybe the xtal needs to be replaced???

Exact name and location of the RAM chip is unknown to Witchery (due to lack of support) but you can trust one thing: pin numbers on FBI chips (500-0009-01), those are the constant. You can ignore designations and follow traces from exact FBI pins that Witchery associates probable failures with.
I assume Witchery is telling you that RAMDAC is not supplying the clock properly to the other half.
U20 is the RAMDAC chip (same designation on both halves of X-24), look for components with "L" and "FB" nearby and test those for continuity (should be in Ohms close to zero). Also do the same to U23 chip (on the back side) - look for bad "Ls".

quattro64 wrote on 2026-06-01, 19:16:

Still new to witchery or would post log file.

It could help, probably.

Thanks, should help me start this process. Hopefully it is just cap/connection related. Otherwise I need to get a propper solder station/skills or find someone. either way this could be a long project, 🤣.

quattro64 wrote on 2026-06-01, 20:40:

Thanks, should help me start this process. Hopefully it is just cap/connection related. Otherwise I need to get a propper solder station/skills or find someone. either way this could be a long project, 🤣.

What country are you in?, so that potential repairers can judge viability.

USA