From f89e6eaebf2da1a9fab06cd097a8f72b7faa3df3 Mon Sep 17 00:00:00 2001 From: chacha Date: Tue, 24 Feb 2026 01:54:51 +0100 Subject: [PATCH] Update Readme.md --- Readme.md | 427 +++++++++++++++++++++++++++--------------------------- 1 file changed, 214 insertions(+), 213 deletions(-) diff --git a/Readme.md b/Readme.md index 88f1242..d43131e 100644 --- a/Readme.md +++ b/Readme.md @@ -1,214 +1,215 @@ ---- -include_toc: true ---- -# 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 - +--- +include_toc: true +--- +# 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** \ No newline at end of file