Voodoo 2 (TMU) MemTest

Introduction

This tool is an attempt to assist troubleshooting Voodoo² TMU’s issues.

TMU system can be very hard to fix because there are so many connexions.

I developped this small tookit because at the time, one of my Voodoo2 was starting to have glitches and I could not figure out what was wrong.

I also had a 2nd one that I bought faulty and was struggling to repair.

Witchery was just out but did not support testing TMU memory.

So I found it funny to write a piece of code that tries to move data from CPU to TMU and vice-versa.

I found that the original 3DFX driver was actually doing a subset of what was needed, just to detect 8MB/12MB (and 4MB ?) Voodoo2 (Voodoo FX ?) boards.

That was the starting point, and after a lot of trials and error, I managed to transmit data to/from everywhere.

Note that this is a hoby project, done mostly for fun because buying another Voodoo2 would probably be cheaper than the time invested … :).

As this is an open-source tool, feel free to Fork, Raise Tickets or to send Pull-Requests !

Requirements

To build this tool you need GNU Make, GCC and Glide 2.x SDK.

Requirement to run this tools depends on the build platform and options.

If you are using the binary I am sharing here, then you need a 32bit Linux System with :

• a Kernel >= 2.6.24

• glibc >= 2.3.6

• working Glide 2.x drivers

• a pentium 3 (or better) micro-code compatible CPU

As a reference, the development & validation environement was :

• Debian Linux Etch (4.0) i386

• Debian official 2.6.24 Kernel recompiled with pentium III options

• my own build of (updated) glide drivers.

Status

Here is the [hopefully updated] project status. - [ ] Implementation - [X] test data (bit move) - [X] test data (random pattern) - [X] test address - [ ] test data (huge block) - [ ] test draw triangle shape (no texture) - [ ] CLI options - [ ] help - [ ] single test run - [ ] output failure results to file (TSV) - [ ] log level - [ ] log to file - [ ] fault analysis - [ ] Chore (might never be done…) - [ ] use fixed size types (e.g. FxUINT32 or uint32_t instead of unsigned long) - [ ] port / test on more modern build system - [ ] port to Windows or DOS - [ ] better Makefile - [ ] Gitea / Jenkins CI - [ ] Validation - [X] working Voodoo2 - [X] working Voodoo2 SLI - [ ] any RAM ICs - [ ] DQx - [X] short - [ ] force 0 - [ ] force 1 - [ ] floating - [ ] addresses - [X] short - [ ] force 0 - [ ] force 1 - [ ] floating - [ ] RAS - [ ] short - [ ] force 0 - [ ] force 1 - [ ] floating - [ ] CAS - [ ] short - [ ] force 0 - [ ] force 1 - [ ] floating - [ ] WE - [ ] short - [ ] force 0 - [ ] force 1 - [ ] floating - [ ] 1MB TMU test (faulty) - [ ] 2MB TMU test (= 8MB Voodoo2) - [ ] 4MB TMU test (= 12MB Voodoo2) - [ ] TMU0 or TMU1 only* - [ ] FBI to TMU1 fault - [ ] FBI to TMU0 fault - [ ] TMU1 to TMU0 fault - [ ] TMU0 to FBI fault - [ ] Documentation - [ ] CLI help - [ ] short youtube video - [ ] better explanation on how memory is accessed - [ ] Other / Ideas - [ ] integration with (or in) Witchery ?

TMU0 Memory test

Here is a simplified data flow diagram:

 ┌────────────┐  3  ┌───────────┐
 │            ┼─────►           │
 │    TMU0    │     │ TMU0 RAM  │
 │            ◄─────┼           │
 └──▲───────┬─┘     └───────────┘
    │       │    4
    │       │
 2  │       │  5
    │       │
    │       │
 ┌──┼───────▼─┐  6  ┌───────────┐
 │            ┼─────►           │
 │    FBI     │     │  FBI RAM  │
 │            ◄─────┼           │
 └──▲───────┬─┘  7  └───────────┘
    │       │
    │       │
 1  │       │  7
    │       │
    │       │
 ┌──┼───────▼─┐
 │            │
 │    CPU     │
 │            │
 └────────────┘

1. CPU configures texture base address and sends data to the FBI
2. The FBI streams the texture to TMU0
3. TMU0 writes the texture into his private memory
4. The CPU sends a request to TMU0 (through the FBI) to render a triangle using this texture (double the size triangle)
5. TMU0 streams the rendered pixels to the FBI
6. The FBI writes the pixel to the frame buffer
7. The CPU requests the pixels using the Linear Frame Buffer access
8. The CPU can compare the rendered value with the original texture

TMU1 Memory test

Here is a simplified data flow diagram:

┌────────────┐
│            │
│  TMU1 RAM  │
│            │
└──▲──────┬──┘
   │      │
 3 │    4 ┼
   │      │
┌──┼──────▼──┐  5   ┌────────────┐
│            │      │            │
│    TMU1    ┼──────►    TMU0    │
│            │      │            │
└── ──▲──────┘      └─────┬──────┘
      │                   │
2     │                6  │
      │                   │
┌─────┼────────────────── ▼──────┐  7  ┌───────────┐
│                                ┼─────►           │
│              FBI               │     │  FBI RAM  │
│                                ◄─────┼           │
└──▲───────┬─────────────────────┘  8  └───────────┘
   │       │
1  │       │ 9
   │       │
┌──┼───────▼─┐
│            │
│    CPU     │
│            │
└────────────┘

0. CPU configures TM0 to simply passthrough incoming TMU1’s pixel stream without modifications
1. CPU configures texture base address and sends data to the FBI
2. The FBI streams the texture to TMU1
3. TMU1 writes the texture into his private memory
4. The CPU sends a request to TMU1 (through the FBI) to render a triangle using this texture (double the size triangle)
5. TMU1 streams the rendered pixels to TMU0
6. TMU0 streams the rendered pixels to the FBI
7. The FBI writes the pixel to the frame buffer
8. The CPU requests the pixels using the Linear Frame Buffer access
9. The CPU can compare the rendered value with the original texture

Accessing different memory regions

TBD

Licence

GPL-3.0-or-later