When I put the strap resistor back to its original position for 8-chip operation instead of 4-chip, disappointment ensued.

Oh I also skipped a bit where the card didn't work after swapping the correct chip because of an unsoldered pin. Prior to that the card was displaying lines all over the place from where I was trying to resolder the pins without enough flux, that got fixed ages ago though.

From here, the card would give an error the moment it moved onto Bank 1 of memory, the 800025 hexadecimal address is 8388645 in decimal so just over the 8MB boundary:

I swapped chips pretty much at random because my understand of what I was seeing was limited, it took a few hours of bashing against this to understand what's what. Eventually I started lifting Data pins on individual memory chips to see what would change, to get a value similar to the one it's displaying above where the common elements are: Above 8MB and ending in "5".
To try to find the fault here I've listed DQ2 away on Bank1-Chip4 - notice that I'm not soldering it to Ground or VCC, I quickly found that messing with Data lines like that breaks the data line for everything on that bus, so Bank 0 - Chip 4 was broken when Bank 1 - Chip 4's DQ2 was hooked up to Ground:

Isolating it results in the pin floating so it could be either high or low without the memory chip affecting that result.

Notice that the test now shows an error ending in "F". It took me a while to cotton on to what was happening, I tried a few more just lifting the pins at the edge of a chip so it's easy to get to then put back:

• Lifting DQ3 on bank1-chip2 (bits 32-63) resulted in errors ending in "4"
• Lifting DQ3 on bank1-chip1 resulted in errors ending in "0"
• Lifting DQ29 on bank1-chip1 resulted in errors ending in "3"

Then I removed Bank1-Chip1 and tested without it fitted to see what would happen:

And the resulting error confirmed it:

Now the errors go 0-1-2-3-5. That means that if the address value ends in 0,1,2,3 then it's an error on Chip 1. It can be broken down like this:
If an address value ends with this hex value, it means:
0 - CHIP1-DQ0 TO DQ7
1 - CHIP1-DQ8 TO DQ15
2 - CHIP1-DQ16 TO DQ23
3 - CHIP1-DQ24 TO DQ31
4 - CHIP2-DQ0 TO DQ7
5 - CHIP2-DQ8 TO DQ15
6 - CHIP2-DQ16 TO DQ23
7 - CHIP2-DQ24 TO DQ31
8 - CHIP3-DQ0 TO DQ7
9 - CHIP3-DQ8 TO DQ15
A - CHIP3-DQ16 TO DQ23
B - CHIP3-DQ24 TO DQ31
C - CHIP4-DQ0 TO DQ7
D - CHIP4-DQ8 TO DQ15
E - CHIP4-DQ16 TO DQ23
F - CHIP4-DQ24 TO DQ31

That matches up with the original fix on the first bank of memory. That's great right? Then surely just replacing Bank 1 - Chip 2 will fix the card, right? 😁 😁 😁

Now that I knew the fault was somewhere on Bank1-Chip2, I tried swapping the chip for a replacement but it made no difference. I had a suspicion that would be the case - the error value never fluctuated, always just wrong at the same bit in the same way.
Thinking about it

• It's not an address pin because it appears to be getting values for most of that 8-bit cell of memory
• Since Bank 0 has all of its Data bits working, if there's a problem it's probably a trace that goes from a Bank 0 data pin into the Bank 1 data pin
• Swapping the chip didn't help so we know it's not a chip fault
• Need to narrow down what we're seeing for this error value - what data pin is this 00010000 really referring to?

Since we know that "5" means the 2nd set of 8 data bits on Chip2, that should mean DQ8 to DQ15 is where the problem lies.

Btw if you're using VMTCE to troubleshoot, this could mean could mean bank 1 or bank 0, they're sharing the trace, though you can figure that out from the faulting address value being under or over 8MB / half the card memory.
Additionally, lifting a pin is fairly easy if you use a small-ish tip, not much flex and you need a craft knife blade - that's thin enough and gives a good angle to carefully wedge out the pin to be isolated.
To aid in locating the pin to be isolated, I took a well-lit picture just above the memory chip in question, then in paint.net overlaid the datasheet's pin diagram on top of it to see which Data bit is at which pin.

To test, I tried disconnecting DQ15 and that gave this result:

So DQ15 is the left-most bit! That means VMTCE displays memory blocks as 8-bit groups going from highest value on the left to lowest (LSB?) on the right:
15 - 14 - 13 - 12 - 11 -- 10 -- 9 -- 8
0 -- 0 -- 0 -- 1 -- 0 -- 0 -- 0 - 0

Data Bit 12 is the one that has no connection! 😁 That even makes sense - this card had some corrosion from poor storage or something and I had tried cleaning up the pins around that chip but there was a problem hiding underneath:

So there's vias going from the front of the card to the back and the one connecting Data bit 12 on Bank1-Chip2 has no connection to the main trace anymore. We'll just fix that with a bodge wire because I don't want to remove the chips front & back:

Now the memory checks out - I have no idea whether it'll work properly for games yet but now I can install drivers which I'll do soon.

I hope this information is helpful to others, it should be useful knowledge for repairing not just a Voodoo Banshee card, but should also be applicable to the Voodoo 3 and lots of Nvidia cards. Now that I know this much I should have another go at repairing this GF4-Ti4200 with bad memory.

Now for a repair that's not successful - here's a 3Dfx Voodoo 3, it has 16MB of SDRAM and one of the bits is bad. I caused this, I was fitting one of those big zalman passive heatsinks on it and while tightening the screws heard a 'pop' and now the video output is broken.

It's fair game for testing though and this should be helpful for anyone else repairing a Voodoo 3 in future, especially since the Voodoo 3 is one PCB layout, my ELSA Victory II is a rather specific board. The V3 differs from the SGRAM equipped Banshee card because its memory chips are just 16-bits wide, that means every single chip contributes to the 128-bit data bus for the video card's memory, no real memory banking going on either.
This means that the straps I mentioned in my previous post do nothing at all on a Voodoo 3, just tested it by moving them and the card still sees itself as 16 Megabytes when configured for 1-bank operation with 8-megabit DRAM. That does limit us to testing the full memory at once.

However, because there's no banking, that means that shorting a data pin to ground has no adverse affects on the rest of the bus since each data pin is unique to each memory chip. That means I can short a convenient data pin to its nearest ground to determine which chip results in which end-value in VMTCE. For my testing, I shorted DQ1 (Data bit 1) of an SDRAM to VSSQ (Ground for data bus pins):

Just a little bit of solder which cleans up easily afterwards:

It results in an error like this:

In fact, this is the original error that the card had. Notice that it results in lines down the screen rather than small lines / noise at intervals, that means there's a signal/trace/pin-connection problem rather than a memory chip problem from what I understand so far. It could mean a pin is not connected to the PCB or could even be disconnected on the GPU itself.
This errors ends in "7" and is bit -----x--, what does that mean?

Well here's a reference picture of what I found bit errors on each chip segment resulted in:

Because it ends in "7", that means the broken data line is on chip U8 and is the upper half of the data lines. Because of how VMTCE displays the bit order I've laid out the diagram to make that easier to follow. If we count from DQ15 down to the 6th data pin, that's DQ10 on U8 that has failed.
It's soldered down correctly and I doubt that the chip is damaged - given where my heatsink was applying pressure I believe that the trace for U8-Data10 has broken away under the GPU. Maybe Oskhar could fix this but it can stay where it is for now.

So this results in a no-fix but now you should be able to pinpoint memory faults down to individual chips & pins on a Voodoo 3 with VMTCE 😀

This method of test is applicable to any memory bus where memory banking is not used, because that shares data pins across the chip's data pins. It's safer to do than lifting pins which on small TSOP packages like this could easily result in broken chips, the legs are too small and short.
Technically this method of memory diagnostic should be applicable to any card with TSOP memory like Geforce and Radeon cards up to the point they moved to BGA memory.

Ah yes, this looks Perfect 🤣 Here's the Voodoo Banshee again now that I can install drivers, not quite 100% working as I'd hoped even though it passes memory tests:

Still looks like a framebuffer issue rather than the card being actual toast since games *d0* run. 24-bit display mode looks pretty much fine as well, just 256, 16-bit and 32-bit have lots of corruption. Dropping the memory clock changes / lessens the corruption. I guess I need to now see if VMTCE can do some more thorough testing than setting static values.

edit: wow, unreal and Deus Ex actually look quite good and not horrifically glitchy. Textures and polygons are mostly fine, with a couple of graphical lines showing up occasionally for a split second a time.
If the memory is linear with the memory layout like: I guess that means it would be framebuffer then polygon stuff, then textures. Perhaps that would mean the error is in the lower part of memory or bank 0.
Maybe I should swap out the mis-matched ISSI chips for Samsung ones. And fix those address lines at trace-level rather than a bodge wire.

Now that I've got this knowledge, if the card can display on the screen then I can run VMTCE from a floppy disk which auto logs to log.txt on the disk.
With that I was just able to find a solder bridge I'd accidentally created between data bits 12 & 13 on RAM chip 1 and that took about a minute. I'm currently dismantling the Elsa Victory II Banshee card because that horror on the screen lead me to pulling RAM chips bank0-chip2 & bank1-chip2 - I've drilled holes through the vias that had corrosion under those chips and uh, that was probably a really bad idea but the card still runs. It cost me all my small carbide drill bits 😠

Here's the floppy disk image that's set up to to log to a file with no user intervention. Make sure the system can boot from floppy and then boot up with the video card to be tested - the display can be garbage it'll still work. Wait a minute for it to start which it should go from displaying a text mode screen to 640x480 VGA mode. After 30 seconds of testing you'll hear the floppy drive going kchnk-kchnk as it starts writing the log file to disk.

To stop the test and have it write to the disk fully, and avoid damaging the FAT / log file data: Press Escape and then Enter and wait a few seconds. The computer should then reboot and the floppy disk can be removed to check the log data. Here's what my soldering error & missing chips look like:

1LOG FILE: "a:\log.txt".
2[10.12.23 22:47:48] Test started...
3Processing offscreen...
4Error at [00096001] must be FF, but found CF (bits: 00110000)
5Error at [00096004] must be FF, but found 18 (bits: 11100111)
6....
7Error at [000964C6] must be FF, but found 18 (bits: 11100111)
8Error at [000964C7] must be FF, but found C6 (bits: 00111001)
9Error at [000964D1] must be FF, but found CF (bits: 00110000)
10Error at [000964D4] must be FF, but found 18 (bits: 11100111)
11Error at [000964D5] must be FF, but found C6 (bits: 00111001)
12Error at [000964D6] must be FF, but found 18 (bits: 11100111)
13TEST CANCELED
14Some ERRORS FOUND, use arrow keys for scroll results log or press ENTER to exit...

This is very useful information. Thanks so much for sharing this. I always hoped there was a better way than just randomly replacing SDRAM chips until artifacting disappears. The next time I come across a Voodoo 3 with memory troubles, I will definitely refer to this thread 😀