231 lines
7.2 KiB
Markdown
231 lines
7.2 KiB
Markdown
---
|
|
include_toc: true
|
|
---
|
|
# Voodoo 2 TMU MemTester
|
|
|
|
## 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
|
|
|
|
### The Easiest way :
|
|
|
|
[RetroDebian Live](https://gitea.chacha.ddns.net/chacha/RetroDebian)
|
|
|
|
### The Hard way :
|
|
|
|
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
|
|
- [X] test data (huge block)
|
|
- [X] test draw no-mem (no texture)
|
|
- [ ] CLI options
|
|
- [X] help
|
|
- [X] single test run
|
|
- [ ] output failure results to file (TSV)
|
|
- [X] log level
|
|
- [ ] log to file
|
|
- [X] fault analysis
|
|
- [X] standalone easy tool (.exe or iso)
|
|
- [ ] 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
|
|
- [X] Gitea / Jenkins CI
|
|
- [ ] Validation
|
|
- [ ] test with debian standard glide drivers
|
|
- [X] working Voodoo2
|
|
- [X] working Voodoo2 SLI
|
|
- [ ] any RAM ICs
|
|
- [ ] DQx
|
|
- [X] short
|
|
- [X] force 0
|
|
- [X] 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
|
|
- [X] 1MB TMU test (= faulty voodoo2)
|
|
- [X] 2MB TMU test (= 8MB Voodoo2)
|
|
- [X] 4MB TMU test (= 12MB Voodoo2)
|
|
- [X] TMU0 or TMU1 only*
|
|
- [ ] FBI to TMU1 fault
|
|
- [ ] FBI to TMU0 fault
|
|
- [X] TMU1 to TMU0 fault
|
|
- [X] TMU0 to FBI fault
|
|
- [ ] Documentation
|
|
- [X] CLI help (integrated in the bin)
|
|
- [ ] short youtube video
|
|
- [ ] better explanation on how memory is accessed
|
|
- [ ] Other / Ideas
|
|
- [ ] integration with 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 draw a square
|
|
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 draw a square
|
|
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
|
|
|
|
|
|
## Note on driver aspect
|
|
|
|
This tool requires access to low level registers / structures that are not exposed outside Glide drivers.
|
|
|
|
For this reason, it is compiled using driver-internal headers.
|
|
|
|
The used driver and the requires headers has bee copied here.
|
|
|
|
It is possible that this tool will only work with the driver it is build accross.
|
|
|
|
## Licence
|
|
|
|
**GPL-3.0-or-later**
|