You're right, it's not directly the PCI reset signal, but it is a reset line for the TMUs.
The TMUs are chained, the data from TMU1 needs to go to the FBI, but it doesn't have a direct connection, it goes through TMU0. If TMU0 is busy with other stuff, it asserts the stall signal. Same goes for the FBI when TMU0 wants to output data, it has a stall pin.

sdz wrote on 2021-04-17, 17:29:

TMU pin 184 is a stall signal. The naming of TMU0/1 is correct in the diagram.
TMU pin 128/FBI pin 197, reset signal, from the PCI bus.

TMU pin 128 seems to be supply voltage - did you mean 208?
I still find it weird that the only other connection of that net seems to be pin 62 of the RAMDAC - which the datasheet describes as "Not connected – leave floating or tie to ground".

In other news I removed both TMUs and put the one from the left into TMU #0 position (on the right), pin 1 tied to ground, other inputs from TMU #1 I just left floating. Result: same symptoms, no clock on its clock output pins 40/41.

I thought, well, something is keeping the clock from running, maybe the RAM is causing problems. So I removed all eight RAM chips of TMU #0. First the top ones, then the bottom ones. Same symptoms, just once I saw "sst1InitRegisters(): Setting up FAST DRAM Configuration" when running mojo.exe.. whatever.

I still thought something is keeping TMU #0 from running its clock. There is a working clock input on pin 14 after all. With sdz's reset signal hint in mind I stared at the partially bare card again. TMU pin 186 stood out (the trace goes a crazy way all over the board!) and I traced it back to the 74AC244 (marked "AC244 XXAA9207" here). A standard buffer chip. Part of a reset circuit? No. It buffers the clock signal that the RAMDAC can be programmed to generate - until then I thought the FBI had its own PLL.. anyway, it's connected like this:

So there is another clock signal entering the TMUs and it's neither coming from the FBI nor from another TMU. Probably the core clock for the graphics engine in each chip, and the other clocks are just for shifting around data?!

Anyway, checking these with the scope, and what do I see? At one resistor there is nothing! At the buffer output pin? Yes there is! No way, is the trace broken? Yes it is!!

I fixed it with a piece of copper wire and sure enough the TMU responds properly now, more or less. It has no RAMs attached.

1DPMI: In DpmiHookFxMemmap, addr=90000000, size=01000000
2DPMI: Loading fxmemmap.vxd
3DPMI: mapping 90000000 size 01000000
4VoodooMEssage:  pSST: 0x0 data0: 0x0 data1: 0x90000001 fn: 0x1000000
5DPMI: VoodooMessage: NULL ptr
6Finally: 00000000
7Info for Voodoo board # 0:
8=====================================================
9Virtual Base Address:                       0x90000000
10Physical Base Address:                      0x90000008
11PCI Device Number:                          0x61
12Vendor ID:                                  0x121a
13Device ID:                                  0x2
14FBI Revision:                               2
15FBI Memory:                                 4 MB
16FBI PowerOn Sense:                          0x2
17TMU PowerOn Sense:                          0x11
18FBI DAC Output Color Format:                24BPP
19Scan-Line Interleaved?                      No
20TMU Revision:                               1
21Number TMUs:                                1
22TMU 0 RAM:                                  1 MB
23DpmiUnmapMemory
24DpmiUnmapMemory

Now I still need to put back the RAM chips and the other TMU. Wish me luck that I didn't fry anything with my soldering.

strobo wrote on 2021-04-18, 21:54:

TMU pin 128 seems to be supply voltage - did you mean 208?

Weird typo on my behalf, yes, I meant pin 208.

strobo wrote on 2021-04-18, 21:54:

I still find it weird that the only other connection of that net seems to be pin 62 of the RAMDAC - which the datasheet describes as "Not connected – leave floating or tie to ground".

Some V2 cards (IIRC even some Voodoo graphics) have a TVP3409 RAMDAC instead of the ICS5342. TVP3409 pin 62 is RESET.

strobo wrote on 2021-04-18, 21:54:

So there is another clock signal entering the TMUs and it's neither coming from the FBI nor from another TMU. Probably the core clock for the graphics engine in each chip, and the other clocks are just for shifting around data?!

That's correct, the RAMDAC provides clock for the TMUs and 2 clock signals for the FBI. FBI->TMU, TMU->TMU, TMU->FBI buses have their own clock.

strobo wrote on 2021-04-18, 21:54:

Anyway, checking these with the scope, and what do I see? At one resistor there is nothing! At the buffer output pin? Yes there is! No way, is the trace broken? Yes it is!!

Nice 😀

strobo wrote on 2021-04-17, 20:55:

Hi, the Voodoo 2 specifications by 3Dfx (rev. 1.16, found e.g. here just for reference) has a diagram on page 15 that shows the […]
Show full quote

SSTV2 wrote on 2021-04-17, 15:53:

Hi, how did you figure out which TMU is which (0/1), have you determined their locations by analyzing card or have you relied on some external source (datasheet/forum post)?

Hi, the Voodoo 2 specifications by 3Dfx (rev. 1.16, found e.g. here just for reference) has a diagram on page 15 that shows the flow of data from Bruce (TMU) #2 -> Bruce #1 -> Bruce #0 -> Chuck (FBI). I think the direction of data flow defines the numbering of the TMUs. TMU #0 must always be present for rendering, being the input to the FBI. In the diagram the flow starts at Bruce #2 which itself has no input from another Bruce.

Now to visual inspection of the card. Since the TMUs are identical, whatever is TMU #1 would have some inputs unconnected. Also you would find some output pins on each TMU that are either connected to TMU #0 or the FBI. It would go into TMU #0 where TMU #1 had unconnected inputs. Also refer to sdz's statements here: Re: Bare 3Dfx Voodoo 2 board pictures
With that in mind the arrangement on the Voodoo 2 reference card becomes quite obvious: the TMU on the left has a range of pins in the lower left corner collectively tied to 3.5V through a 4.7 kOhm resistor. The TMU on the right has these pins connected to the TMU on the left.
And when I say "obvious" I assume that people enjoy staring at board traces that frequently jump to the other side of the card where you quickly lose track of them - I do accept that others might feel differently.

I saw the terms "upstream" and "downstream" being used for TMUs. Upstream should be referring to the higher number (where data is coming from) and downstream to the lower number (where data is going to).

@sdz Thanks for checking, I tried to find PCI bus reset (PCI slot pin A15) on these pins but found no connection, just on FBI pin 11.
With the stall signal you mean that the receiver of data (e.g. FBI) tells the sender (e.g. TMU #0) "hey I'm not ready for new data", analogous to a FIFO full signal?

Very cool, so you have figured all of this by reverse engineering the card 😀. I had found out TMU priority not long after posting the thread, that you had linked here (with the broken Helios 3D V2), though I had to disconnect TMU memory BANK's RAS lines and switch TMUs ON/OFF via registry entries on a working card for that to happen. After seeing all this effort you went through, trying to bring that V2 back to life, makes me want to get back to that dead Helios once again.

If possible, could you check whether your card is able to run games/tech demos with only TMU #0 present (might require to set TMU count to 1 via registry)?

I had written in my post the following:

Doing these tests I’ve concluded that:

- Both TMUs are functional (can switch them off and on, it affects FPS and surface lightning).

This is not true, the thing is, once TMUs are disabled via registry entry, they are as gone as if they were desoldered, FPS increase and lightning change that I had seen back then was done all by the FBI chip, thus I don't know whether TMUs are functional and I don't have the means to test them. I had them switched places, but it didn't help, I also ran card w/o TMUs and it behaved exactly the same.

It works 😀

I resoldered TMU #1 and the RAM of TMU #0. First I was almost certain that TMU #0 had succumbed to the heat of my hot air gun:
- mojo.exe only returned the dreadful 57005 TMUs (0xDEAD)
- the clock TMU #0 -> FBI was only present on pin 40, not on pin 41
- the clock TMU #1 -> TMU #0 is always present on pin 41
But it seems that on my more modern test rig (Core 2 Quad Q9550 + FreeDOS) it takes around 10-20 runs of mojo.exe before that clock finally appears.. then it works until the next reboot. In the other PC (Celeron 400MHz + Win98 SE) the clock on pin 41 is also not present at boot, but running mojo.exe enables it immediately and everything is fine. I wonder what's going on there.

Then there were texture issues in Unreal, very similar to the first picture here: Does this look like a faulty Voodoo2, or something else is going on?
Also donut.exe crashed after a minute or two.
I had not bothered to check the RAM soldering so much and indeed some pins were loose. Fixed them, now both Unreal and the Donut demo seem to run perfectly. \o/
Playing a bit of Unreal and "feeling" the card working was immensely satisfying. I think you can imagine.

sdz wrote on 2021-04-18, 23:49:

Some V2 cards (IIRC even some Voodoo graphics) have a TVP3409 RAMDAC instead of the ICS5342. TVP3409 pin 62 is RESET.

Nice find! Good to have that sorted out. I should update my diagram and put it here.

SSTV2 wrote on 2021-04-20, 23:22:

If possible, could you check whether your card is able to run games/tech demos with only TMU #0 present (might require to set TMU count to 1 via registry)?

I think I need a break from soldering 😁 maybe my oscilloscope can help finding some clues. Would be great to see your Helios 3D fully alive as well.

SSTV2 wrote on 2021-04-20, 23:22:

I had written in my post the following:

Doing these tests I’ve concluded that:

- Both TMUs are functional (can switch them off and on, it affects FPS and surface lightning).

This is not true, the thing is, once TMUs are disabled via registry entry, they are as gone as if they were desoldered, FPS increase and lightning change that I had seen back then was done all by the FBI chip, thus I don't know whether TMUs are functional and I don't have the means to test them. I had them switched places, but it didn't help, I also ran card w/o TMUs and it behaved exactly the same.

What I did today was running the Donut demo and Unreal with some register entries (see example sstv2.reg file for anyone wondering where to put them, I hope it's correct). There I checked some signals with the scope.

- during normal rendering without disabled TMUs or textures I see activity on the RAS# pin of one of the TMU #1 RAM chips (U15) and on the data bus TMU #1 -> TMU #0
- there is always the clock (pins 40,41) and flow control signals (pins 26,28) between both TMUs, regardless of SSTV2_NUM_TMUS and SSTV2_TEXMAP_DISABLE
- with SSTV2_NUM_TMUS=1 or SSTV2_TEXMAP_DISABLE=1 there is no activity on the data lanes TMU #1 -> TMU #0
- with SSTV2_NUM_TMUS=1 but textures enabled there is activity on the RAM chips of TMU #1, at least on the RAS# signal of U15
- with SSTV2_TEXMAP_DISABLE=1 there is only short periodic pulses on that RAS# which are also there when the card is idle

Donut is cool, there is a hotkey to disable one TMU. Same behavior as with the registry key as far as I can tell.

SSTV2, I think your conclusion is correct that neither of your TMUs can be ruled out. What I can also imagine is that one of the TMU RAM chips is bad and interaction with it causes the hang. There should be a way to selectively test RAM chips. Is the texture RAM content identical/mirrored between TMUs? There is 8 MiB of addresses that are mapped for texture RAM, but with three TMUs there could theoretically be 12MiB of TMU RAM.

Regardless of that it should be simple to write a tool that writes to TMU RAM sequentially.. maybe it fails within a specific range of addresses that belongs to a specific RAM chip. Reading from texture RAM doesn't work directly but I think in some 3Dfx document they mentioned a way to render textures to the framebuffer RAM and read from there instead.

Fixing Missing legs is not very hard, i used a Dremel and sanded the Plastic until the carrier came out, then soldered wire to it and to the PCB.

matze79 wrote on 2021-04-27, 18:01:

Fixing Missing legs is not very hard, i used a Dremel and sanded the Plastic until the carrier came out, then soldered wire to it and to the PCB.

I mean hard is relative I guess. I've done it too. It's certainly harder than most basic soldering repairs

matze79 wrote on 2021-04-27, 18:01:

Fixing Missing legs is not very hard, i used a Dremel and sanded the Plastic until the carrier came out, then soldered wire to it and to the PCB.

Cool, yeah when you know you can expose this frame, even an idiot with an angle grinder can fix this. I'm glad I got some good advice on this thread so I had a bit of a plan.

The chip here has a pitch of about 0.4 mm and good magnification was helpful for soldering. I use an eyepiece from a stereo microscope that I found in the dumpster. Otherwise pentiumspeed does have a point that one could give it to a repair shop with proper equipment.

strobo wrote on 2021-04-25, 22:05:

What I did today was running the Donut demo and Unreal with some register entries (see example sstv2.reg file for anyone wonderi […]
Show full quote

What I did today was running the Donut demo and Unreal with some register entries (see example sstv2.reg file for anyone wondering where to put them, I hope it's correct). There I checked some signals with the scope.

- during normal rendering without disabled TMUs or textures I see activity on the RAS# pin of one of the TMU #1 RAM chips (U15) and on the data bus TMU #1 -> TMU #0
- there is always the clock (pins 40,41) and flow control signals (pins 26,28) between both TMUs, regardless of SSTV2_NUM_TMUS and SSTV2_TEXMAP_DISABLE
- with SSTV2_NUM_TMUS=1 or SSTV2_TEXMAP_DISABLE=1 there is no activity on the data lanes TMU #1 -> TMU #0
- with SSTV2_NUM_TMUS=1 but textures enabled there is activity on the RAM chips of TMU #1, at least on the RAS# signal of U15
- with SSTV2_TEXMAP_DISABLE=1 there is only short periodic pulses on that RAS# which are also there when the card is idle

Thank you! This is exactly what I wanted to know, so in theory the second TMU can be completely ignored (assuming that there are no shorts in data/address/control lines) once it gets disabled via registry, drivers then, of course, won't complain that it's bad or missing. Let's suppose that this is the case, then the fault should be somewhere in the FBI and TMU #0 interconnection.

strobo wrote on 2021-04-25, 22:05:

SSTV2, I think your conclusion is correct that neither of your TMUs can be ruled out. What I can also imagine is that one of the TMU RAM chips is bad and interaction with it causes the hang. There should be a way to selectively test RAM chips.

TMU, in fact, does not care whether it's interfaced to a defective DRAM or no DRAM at all, it would still map textures, though with no DRAM you'd just get black spots/lines or whole textures. Check this thread for an example on how V2 behaves with no/bad DRAM. I had replaced two bad DRAM ICs on a BANK0 and BANK1 of TMU #1, one chip was shunting internally (completely dead) the other was semi working. V2 did not crash even when I had removed DRAM IC on BANK0! Note that both TMUs were enabled.

strobo wrote on 2021-04-25, 22:05:

Is the texture RAM content identical/mirrored between TMUs?

Not really, buffer content differs even between banks of the same TMU.

Offtopic: Once I get out of the 486 Compaq LTE Elite repair/restoration limbo, I'll jump right onto that V2 😉

I've found the main cause of TMU inactivity on that V2 Helios... It was a bad via which was supposed to connect FBI pin 166 with TMU0 pin 18... The most disappointing thing about this whole ordeal is that I had checked the whole termination resistors array several times in the past between FBI and TMUs, even now, connections between them looked fine at first glance, I've found the culprit only by directly comparing pins on both TMUs.

Some diag info:

Mojo was always hanging on that card, it never did output a single line of information before, but it finally finished execution once I had disconnected the clock line for TMU0:

A similar sight, isn't it?

After the fix:

The culprit (below Ver:2.0 text):

Card at this moment:

Explanation for the 2MB and 4MB TMU memory report - I connected TMU0 RAS line of BANK0 to the RAS line of BANK1, DRAMs on the other side were not botched, fortunately. Card works flawlessly, no hangs or texture corruption were seen during testing, now a true restoration can begin.

Thank you Strobo for clarifying some things, heck knows if I would have ever found that damned via w/o your reverse engineering and schematics 😉

Also, congratulations on your V2 repair success!

bad via is the pita but more people to gather information is so useful. Bravo!

I had a low quality 30 simms with bad VIAs but would had to have tools to remove the chips to fix them is non-existent back in the day. Besides, they were 256K simms and was around 95's so I needed 1MB simms so that didn't happen.

Cheers,

SSTV2 wrote on 2021-05-03, 22:54:

I've found the main cause of TMU inactivity on that V2 Helios... It was a bad via which was supposed to connect FBI pin 166 with TMU0 pin 18...

Hi SSTV2,
Could you please tell me what VIA means in this context? Do you mean the traces, R51 or one of the resistor arrays? I have the exact same issue with my voodoo2 and would like to try find out what exactly you replaced or found to be faulty here.. thanks!

EDIT: nevermind, I think I just answered my own question - its the little holes in the PCB that connect to different sides/layers..