I would check for continuity on traces coming to/from the TMUs and RAM. Also, have you run mojo?

The output from MOJO looks like this, I do not think there is anything to go by. I also reflowed all VDAM chip legs for the TMUs but behavior remains

assasincz wrote on 2025-01-07, 20:39:

The output from MOJO looks like this, I do not think there is anything to go by. I also reflowed all VDAM chip legs for the TMUs but behavior remains

Okay, that's good that it can talk to everything in Mojo and the RAM enumeration is working properly for both TMUs. The fault in your original post is specifically a fault with the TMU memory rather than FBI. The game geometry and actual framebuffer look fine so there should be no issue with the FBI memory or chip.

Since Mojo is giving a good result for both TMUs, the next thing to try is disable the secondary TMU (the one nearest the VGA ports) by adding this into your autoexec.bat file: "SET SSTV2_NUM_TMUS=1".
List of environment variables: https://www.mdgx.com/3dfx.htm
Here's my experience with doing that to track down a similar fault to yours: Re: What retro activity did you get up to today?

If games still look messed up with that environment variable set then you know it's probably TMU 0 that's the issue. If it goes then you know it's TMU 1 that has the problem.

Seeing that your textures look seriously messed up, my guess is that quite a few data / address lines aren't working.
Once you know which TMU is bad, see / feel if any of the RAM chips around the bad TMU are excessively hot compared to the rest - but RAM chip faults are rare in my experience, they don't fail so often but the connections between the TMU quad-flat-pack chip and the RAM chips can go bad.
Inspect the resistor networks close-up around the bad TMU once you've narrowed down which TMU has the fault.
If no resistor networks look cracked then inspect the card close up for any impacts.
If there's no impacts / scratches evident then look close up at the TMU itself, see if any legs are touching / pushed together.

If no pins look obviously bad, again look close up and possibly push on some of the pins to see if any are loose. See this post here for the pinout of the TMU - confirmed to be the same for the Voodoo 1 & 2: 3Dfx Voodoo 1 - Low level hardware information and diagnostics thread
Specifically you mainly just need to check the TEX_DATA and TEX_ADDR lines - also check the corners of the chip first, they're more likely to come loose if the card takes an impact or has been bent at some point in the past.

Thermalwrong wrote on 2025-01-08, 16:48:

Okay, that's good that it can talk to everything in Mojo and the RAM enumeration is working properly for both TMUs. The fault in […]
Show full quote

assasincz wrote on 2025-01-07, 20:39:

The output from MOJO looks like this, I do not think there is anything to go by. I also reflowed all VDAM chip legs for the TMUs but behavior remains

Okay, that's good that it can talk to everything in Mojo and the RAM enumeration is working properly for both TMUs. The fault in your original post is specifically a fault with the TMU memory rather than FBI. The game geometry and actual framebuffer look fine so there should be no issue with the FBI memory or chip.

Since Mojo is giving a good result for both TMUs, the next thing to try is disable the secondary TMU (the one nearest the VGA ports) by adding this into your autoexec.bat file: "SET SSTV2_NUM_TMUS=1".
List of environment variables: https://www.mdgx.com/3dfx.htm
Here's my experience with doing that to track down a similar fault to yours: Re: What retro activity did you get up to today?

If games still look messed up with that environment variable set then you know it's probably TMU 0 that's the issue. If it goes then you know it's TMU 1 that has the problem.

Seeing that your textures look seriously messed up, my guess is that quite a few data / address lines aren't working.
Once you know which TMU is bad, see / feel if any of the RAM chips around the bad TMU are excessively hot compared to the rest - but RAM chip faults are rare in my experience, they don't fail so often but the connections between the TMU quad-flat-pack chip and the RAM chips can go bad.
Inspect the resistor networks close-up around the bad TMU once you've narrowed down which TMU has the fault.
If no resistor networks look cracked then inspect the card close up for any impacts.
If there's no impacts / scratches evident then look close up at the TMU itself, see if any legs are touching / pushed together.

If no pins look obviously bad, again look close up and possibly push on some of the pins to see if any are loose. See this post here for the pinout of the TMU - confirmed to be the same for the Voodoo 1 & 2: 3Dfx Voodoo 1 - Low level hardware information and diagnostics thread
Specifically you mainly just need to check the TEX_DATA and TEX_ADDR lines - also check the corners of the chip first, they're more likely to come loose if the card takes an impact or has been bent at some point in the past.

Thank you so much for advice. I did the action listed in sequence below top-to-bottom:

- inspected visually for broken traces, none found
- Reflowed all TMU VRAM solder joints and confirmed all legs continuity to the board
- checked continuity from all TMU and FBI pins to the traces and vias to confirm no solder legs are loose and none are shorted together
- measured resistance of all resistors and resistor packs on the card to prove all perform per spec and none are broken open
- by touch confirmed that no VRAM chips are warmer than the rest
- disabled TMU 0 (closer to ports) per your advice = the card seemed to work fine initially, but soon started to hang again and corrupt textures briefly appeared in System Shock 2, so I would say the behavior remains, although it takes a bit longer for the symptoms to appear
- I confirmed continuity of all legs of all texture RAM chips to correct legs of their respective TMUs (or elsewhere on card, like GND, VCC etc.) = all OK

Unless there is anything else to check, it seems to points to faulty VRAM chip(s) of TMU 1 (further from the ports) right?
I may try borrowing an oscilloscope from a friend of mine to check data flow, but I have never done that