Interessant! Aus Taiwan hast Du noch keine bekommen? Viele PC-Freaks (im postiven Sinne), die ich in Asien kennengelernt habe, kommen aus Taiwan.
Komme die Linie aus China aus Hong Kong, Macao, oder Shenzhen (or woanders)? Ich frage deshalb, weil meine Freundin aus Macao kommt. Ihr Vater hat frueher (in den 90ern) in einem Elektronikwerk gearbeitet.
Aktuell suche ich mir Komponenten zusammen, um mir ein 3dfx PC zu bauen. Meine ganze Hardware ist in Deutschland, also habe ich mir hier (billig) PC-Teile ersteigert. Es war gar nicht so einfach, etwas funktionierendes aus der Jahrtausendwende zu bekommen, daher moechte ich Euch etwas davon erzaehlen. Bevor ich damit anfange, will ich nur sagen, dass ich viele der Probleme vermeiden haette koennen, wenn ich nicht immer das billigste Angebot genommen haette. Ich baue das Projekt zum Spass, und kaufe das billigste vom billigsten 
Angefangen habe ich mit einem Slot 1 System (P3V-4X), mit einem 600MHz Pentium 3. Das System bootet nicht. Eine Inspektion des Mainboards zeigte keine Schaeden, aber es zeigte weder einen Bildschirm, noch gab es irgendwelche Fehlercodes auf dem Speaker aus. Also das naechste Board, diesmal ein Sockel A ersteigert. Sockel A mit DDR RAM sind auch gar nicht mehr so einfach zu bekommen, aber da gab es noch ein OEM-Board (scheint von HP zu sein, "Quik Silver" ist aufgedruckt, AMD761 Northbridge und VIA VT82C686B Southbridge). Nachdem ich das Board bekommen habe, habe ich alles zusammengebaut, und es startete gar nicht erst, das System blieb komplett tot. Bei genauerer Betrachtung sah man, dass das Board mal auf den Boden gefallen ist (das PCB ist an einer Ecke ausgefranst), und ein Mosfet ist vom PCB abgerissen, mitsamt der Leiterbahn. Einen Ersatz-Mosfet habe ich aktuell nicht da, also habe ich einfach das naechste Board ersteigert - diesmal ein P4-Board (478, M7SXF). Das Board war voellig verdreckt, und beim Auspacken habe ich es eigentlich schon abgeschrieben:
Der Stecker fuer den CPU-Luefter war stuemperhaft ausgeloetet und getauscht worden, viele Pins verbogen, und ein Spannungsregler ist wohl mal so heiss geworden, dass er sich selbst abgeloetet hat, etwas verrutscht ist und mit anderen Komponenten einen Kurzschluss ausgeloest hat. Ich habe den Spannungsregler an seine urspruengliche Position zurueckgeloetet, den Luefterstecker ausgeloetet und das PCB gereinigt, und mal probeweise das System gestartet. Ich habe es nicht erwartet, aber das System hatte tatsaechlich einen POST-Screen! Yay!
Selbstverstaendlich habe ich nur eine olle Matrox-Karte zum Testen verwendet.
Angeblich hat das Board einen Sis-Chipsatz, auf der Northbridge steht aber "XP4 HT7645", auf der Southbridge "XP4 HT7961". Koennte das ein Lizenzbau von dem Sis-Chipsatz sein? Der Chipsatz sollte auch mit 3dfx-AGP-Karten funktionieren, oder?
Hi lao-koon! Danke! In Deutschland habe ich meine 3dfx-Sammlung noch, aber ich lebe mittlerweile in Japan, und habe leider keine 3dfx-Karte eingepackt. Ich werde aber schon noch etwas hier finden 
Ich schreibe ab jetzt in Englisch - die 3dfx Treiberentwicklung-Community ist so klein, dass ich die Sprachbarrieren abbauen moechte. Sorry!
----
Some more updates on the driver development. So far, I used a Win9x system to compile the drivers, which sucks because most modern development tools are not available.
I therefore tried to see if it possible to make compilation of the driver on a modern system possible (WinNT 10.0 64x).
The latest (Microsoft) toolchain that can still target Windows 98/Win2k is Visual Studio 2005, so I worked on porting the Win2k driver to VS2005. This was surprisingly easy, with only a few minor changes. Since the 2K driver does not have any 16 bit components, it can be easily compiled on Windows 10. All you need to do is to install Visual Studio 2005, set the envvars correctly, and build it.
For the 9x driver, it is a bit more tricky: the 9x driver contains some 16bit components (the DD16 directory). Originally, Microsoft intended users to compile the 16bit part with Visual Studio 152 (released in 1996). Unfortunately, VS152 cannot run properly on Windows 10 (at least I was not successful in getting it to run. It threw some "out of memory" or "file not found" errors).
The current de-facto standard for cross-compiling DOS/16bit applications from a modern OS seems to be the OpenWatcom 2 compiler, which runs on Win 64, but can cross-compile to DOS/Win9X/Win3.x. This is great!
Unfortunately, this requires rewriting some of the assembly code. OpenWatcom does not support mixing C code with assembler very well, and parts of the assembler routines need to be adapted for OpenWatcom.
I am currently trying to use the OpenWatcom compiler, but the linker from Visual Studio 152. Not sure if this will work.
Why am I doing this?
I am still hoping to establish modern driver development with a community, i.e. having the driver on some GitHub/GitLab, and everyone who is interested in working with it can just do a Pull Request introduce code changes.
To make sure this works, the driver should be automatically built in the cloud: perhaps with using Windows docker containers, that run as a part of a GitHub action, install all dependencies, build the driver, and upload the compiled driver as artifacts to GitHub, from where you can download & test it. This is what I have in mind. Of course, there are no Win9x docker containers available, so everything must be compile-able from a modern OS.
I would like to make this a full open source, community-driven project. It is a shame that so many new/improved drivers were developed, but since they are all closed source, all the progress that has been made on the sources is basically lost. SFFT has built a new D3D implementation, some folks have worked on Widescreen support, countless bugfixes,etc, but none of the sources are available.
The main issues I see here are:
- Porting the driver so that it can be build on a modern platform (ongoing).
- Find a possibility to put the copyrighted source code under version control and public access. I am thinking of using a private Github repo, where only 3dfx community members get access to.
- Automatically testing the driver for each build (that would be a bit difficult to realize).
- Documentation: we need information how to build/install/test/debug the driver. Ideally, these documentation should also be hosted on Git., together with the source.
Ich suche gerade hier in Japan eine Test-Voodoo5, um Treiber zu bauen und zu testen. Gerade ging hier diese schöne V5 AGP über den Tisch:
Bei dem Preis bin ich ausgestiegen. Ich warte auf eine billigere Karte, für meine Zwecke reicht auch eine verranzte Karte.
In Deutschland sind die Preise ja auch heftig https://www.ebay-kleinanzeigen.de/s-anzeige/3dfx…243198-228-9381. Bei der Karte fehlen schon Teile - ob die wirklich noch funktioniert?
Unterstützt Windows Me noch die Vxd-Treiber? Dann müsste das gehen. Zur Installation den letzten offiziellen 3dfx Treiber installieren, aber vorher die DLLs durch meine austauschen. Neustarten und hoffen dass alles funktioniert!
Hallo allerseits! Eine lange Zeit habe ich mich nicht mehr mit dem 3dfx Treibern beschäftigt - ich habe Job und Wohnort gewechselt, und das hat viel Zeit verschlungen. Vor einigen Wochen habe ich mir allerdings ein Thinkpad 240 gekauft, und nachdem ich das BIOS-Passwort entfernt und Windows 98 installiert habe, habe ich mich mal wieder mit der Treiberentwicklung beschäftigt.
Auf einem Win9X mit den ganzen Tools von damals ist das Kompilieren erstaunlich einfach, die alten Compiler sind etwas toleranter was schlechten Programmierstil angeht, und die 16-bit Teile lassen sich auch relativ problemlos kompilieren.
Jedenfalls konte ich jetzt den 3dfx Treiber für die V4/v5 für Win9x kompilieren, allerdings habe ich kein 3dfx-System zum Testen. Würde sich jemand anbieten, diesen Treiber auszuprobieren?
Man müsste einen orginalen 3dfx-Treiber nehmen, die DLL and VXD durch meine Variante ersetzten, und den Treiber installieren.
Das ganze ist ohne Gewährleistung, es besteht ein Risiko, dass das System nicht mehr booted (man könnte die DLLs aber über DOS vermtlich wieder durch die original-Versionen ersetzen).
Danke für die Bilder. Jetzt verstehe ich, was Du meinst. Wahnsinn (im positiven Sinne), was Du alles kannst und machst, um die Karten am Leben zu halten.
Mal ein Lagebericht aus Japan: Strom kostet hier aktuell 38Yen/kWh, etwa 26ct - die Tendenz ist steigend. Der Euro-Wert ist wegen des aktuell Wechselkurses unrealistisch günstig. Geringverdiener müssen massiv sparen. Die Regierung bittet die Bürger gelegentlich darum, Strom zu sparen.
Leider sind die Häuser so grauenhaft gebaut, dass man im Sommer das Haus mit der Klimaanlage runterkühlen muss, und im Winter elektrisch aufheizen muss. Doppelglasfenster sind erstaunlich selten zu finden, die meisten Häuser haben Einfachverglasung. Da die meisten Häuser nach 30 Jahren abgerissen werden, werden sie nicht besonders wärmeisolierend gebaut. Warmwasser wird auch elektrisch erzeugt.
Mein Lehrer meint, dass er wegen der Kosten weder Heizung noch Klimaanlage verwendet. Gekocht wird mit Gas, da habe ich die aktuellen Preise aber nicht im Kopf.
Wie kann man sich das vorstellen? Sind die Pads abgerissen, und du stellst die neu her?
Mich würde mal interessieren, wie Du die kleinen abgerissenen Lötpads an den RAMs auf der Voodoo 5 5500 ein paar Seiten vorher repariert hast. Abgerissene Lötpads sind für mich immer ein halbes Desaster, weil das am Ende oft hässlich aussieht, wenn man mit kleinen Kabeln die Leiterbahnen brücken muss.
Super Arbeit, und de Fotoserie finde ich witzig. 
Ich habe die Treiber mal mit einer Voodoo3 auf Windows XP ausprobiert, sie funktionieren natürlich nicht (war aber auch zu erwarten). Hat jemand Erfahrungen, ob man Windows irgendwie beibringen kann, Logs von der Treiberinitialisierung zu speichern?
Das Thema wird ziemlich schnell sehr komplex. Ich werde mich vermutlich eher auf die Glide APIs beschränken, die sollten etwas einfacher zu debuggen sein.
Und hier ist jetzt auch der Miniport Treiber (3dfxvsm.dll).
Ich habe jetzt verstanden, was der Unterschied zwischen dem Display-Treiber und dem Miniport-Treiber ist:
- Der Display-Treiber macht alles generische, z.B. Dreiecke zeichnen, Windows GDI usw.
- Der Miniport-Treiber macht alles hardwarespezifische, also die Speicherkonfiguration erkennen, erkennen, ob das Board FSAA kann.
Wenn man den Miniport Treiber neu kompilieren kann, macht das den Weg frei für eigene Hardware-Konfiguration. Eventuell könnte man den Treiber sogar für die Aalchemy-Boards portieren.
Normalerweise machst Du die detaillierte Doku über Git - jeder Git Commit enthält einen Satz Änderungen (die z.T. mehrere Dateien umfassen), und kannst das schön dokumentieren, was wo passiert. Daher auch meine Vorliebe für Github.
Die 9x Treiber sind nochmal stark anders, kann man aber auch auf die Zielliste aufnehmen.
So.... nach mehreren Stunden Arbeit ist der Windows XP Treiber jetzt durchkompiliert. Theoretisch sollte der Treiber unter Windows XP mit DirectX8 Support und auf V3/V4/V5 laufen.
Praktisch ist der Code irgendwie mit Klebeband zusammengewickelt, und wird zu 99% nicht funktionieren. Außerdem habe ich gerade kein XP Voodoo-System parat. Will ihn jemand mal ausprobieren? Ich würde im abgesicherten Modus starten, die alte 3dfvs.dll sichern, und durch meine Variante ersetzen. Am besten nicht auf einem besonders wichtigen System ausprobieren, falls der Treiber komplett Amok laufen sollte.
Ich habe den originalen 3dfx-Win2000-Treiber genommen, auf Cmake portiert, und mit den Windows XP Libs aus dem Windows Driver Kit kompiliert. Das ging zu 99% auch gut. Meine Toolchain ist Windows 10, MSVC2019, DX81SDK, Windows DDK für Windows Server 2003 Service Pack 1 (SP1)
Wie funktioniert der Treiber im Detail?
- 3dfxvs.dll ist der 2D / Direct3D / DirectDraw Teil. Dieser macht alles was irgendwie mit Windows zu tun hat.
- 3dfxvsm.dll ist irgendein Miniport Treiber - ich habe keine Ahnung was der macht.
- glide2x.dll, glide3x.dll sind die Glide Treiber. Diese sind ziemlich unabhängig von dem Hauptteil des Treibers. Ich vermute, das liegt daran, dass 3dfx anfänglich hauptsächlich Glide entwickelt hat.
- 3dfxogl.dll ist (vermutlich) der OpenGL auf Glide Wrapper.
Ich möchte meine Änderungen gerne open-source machen, falls jemand Interesse an dem Projekt hat, und eigene Treiber bauen will. Allerdings sind die 3dfx-Treiber offiziell nach wie vor closed-source, und jeder Dateiheader fängt in etwa so an:
/*
** Copyright (c) 1995-1999, 3Dfx Interactive, Inc.
** All Rights Reserved.
**
** This is UNPUBLISHED PROPRIETARY SOURCE CODE of 3Dfx Interactive, Inc.;
** the contents of this file may not be disclosed to third parties, copied or
** duplicated in any form, in whole or in part, without the prior written
** permission of 3Dfx Interactive, Inc.
**
** RESTRICTED RIGHTS LEGEND:
** Use, duplication or disclosure by the Government is subject to restrictions
** as set forth in subdivision (c)(1)(ii) of the Rights in Technical Data
** and Computer Software clause at DFARS 252.227-7013, and/or in similar or
** successor clauses in the FAR, DOD or NASA FAR Supplement. Unpublished -
** rights reserved under the Copyright Laws of the United States.
**/Ich glaube nicht, dass ich den Treiber einfach auf Github hochladen kann.
Eine Idee wäre, nur meine Änderungen auf Github zu laden, und den Treibercode mittels Script aus den Weiten des Internets zu laden, die Änderungen anzuwenden, und dann den Bauprozess zu starten.
Es wäre halt schon cool wenn man irgendwo in der Cloud eine Buildumgebung hat, sodass jede Codeänderung automatisch diese Umgebung antriggert, und am Ende ein fertiger Treiber herauspurzelt.
Cool! Genau das habe ich gesucht! Danke!
Nachdem die Glide APIs sich jetzt kompilieren lassen, wollte ich mal den V4/V5 Display-Treiber neu kompilieren. Dafür braucht man das DirectX 8 SDK, Dateiname "dx8sdk.exe", oder "dxsdk_aug08.exe". Leider habe ich das im Internet nicht mehr finden können. Hat das vielleicht jemand auf seinem PC?
Does anyone know where to get the kernel part of the 3dfx drivers? To explain this technically, a modern driver usually has two parts: the part in userspace runs with restrictions (e.g. no direct hardware access). this is the part the application using the driver talks to. In case of the 3dfx driver, this are the glide2x and glide3x.dlls.
To get a fully working driver, you also need to have the kernel part of the driver: this runs without restrictions in kernel space, and has direct access to hardware and memory mappings. The user space driver communicates to the kernel space part of the driver, which then does the actual work.
It seems to me that most drivers on the web only publish the user space part, not the kernel part. I would therefore be very interested in seeing an example of a kernel space driver for a Voodoo2, or perhaps others, for an NT based operating system.
For Win9x the things work differently, but I am not so much interested in building drivers for Win9x.
----
Well, for the glide user space drivers, I made some little progress and can compile both glide2 and glide3 now! Do you want to try it out yourself? It's quite fun to be able to build your own Glide libraries (even if they most likely don't work)!
I'll provide some basic instructions for the glide2x DLL for Voodoo2 below.
You basically need git, CMake, a C compiler (I tried both GCC and Visual Studio 2019), and, for 32bit builds, the assembler "NASM" installed.
Start by cloning https://github.com/Danaozhong/glide.
Next, you'll need to build a tool called "fxgasm". This fxgasm.exe is used to generate header files with memory locations, required by the actual driver compilation step later. Navigate to folder "glide2x\cvg\glide\src\fxgasm_tool", open a command prompt (e.g. CMD).
mkdir bin
cd bin
cmake ..This creates a directory to store the compiled libraries ("bin"). This is called an out-of-source build, because the generated binaries are not stored together with the code, but in a separate folder.
The cmake call will tell cmake to use the CMakeList.txt in the folder above, and generate a visual studio solution out of it. If you would run this from e.g. Ubuntu, it would generate a makefile.
If everything worked well, CMAKE should find the compiler, and you can build the fxgasm tool by
cmake --build .If that worked well, you have successfully built your first 3dfx software! search the directory for an executable called fxgasm.exe.
Generate the header files using FXgasm:
fxgasm_tool/bin/Debug/fxgasm.exe -inline > fxinline.h
fxgasm_tool/bin/Debug/fxgasm.exe -hex > fxgasm.hThe resulting fxinline.h and fxgasm.h should be located/copied in glide2x\cvg\glide\src directory.
Now, we can actually build the glide driver! Let's open a command promt in "glide2x\cvg". Same as before, let's start by generating an out of source directory, and invoke cmake:
mkdir bin
cd bin
cmake -G "Visual Studio 16 2019" -A Win32 -DBUILD_32BIT=ON ..This calls cmake and specifies that you want to build with Visual Studio 2019, want a 32bit application ("-A Win32"), and specify some driver-internal switches for 32bit (BUILD_32BIT). This CMake step will now also search for you NASM assembler, so make sure it is available in the PATH envvar.
If cmake was successful, start the compile process by
cmake --build .And after a few seconds you should receive your glide2x.dll, which is a 32bit DLL and should technically be useable on any 32bit NT-based OS. Since I have no idea how the kernel part of the driver looks like and many people have modified things in the glide libraries, the chances of them working are very, very slim.
The next step would now be to use e.g. an XP OS, put a Voodoo2 in it, try these libraries out, find out when / why they crash with a debugger, understand the problem, solve the problems in the code, and repeat.
Please, let's not discuss which OS or platform is the most suitable for 3dfx cards. I am interested in this topic of Windows driver development, first, to get a better understanding on how Windows drivers are written, and second, to see if it is possible to move the driver code to a state of the art development environment. So let's stay on topic on how this driver works in detail, and if we can get it to compile, at at some point maybe even working.
Using a modern development environment does not necessarily mean that the newly generated drivers don't work on older OS. I am quite curious how the newly built drivers built with a modern GCC version compete with the original drivers, that were probably compiled with MSVC6.
For now, my goal is to modernize the environment, and get things compiling. The first thing I did I removed the makefiles (I don't like them), and replace it by one single cmake file. I also added a CI job to build the drivers automatically. The idea is that developers who wish to try out driver development don't have to bother about having all the correct tools installed, and don't have to build themselves. If you want to change the driver, you just add your new code, and the cloud takes care of building the driver. You add your code changes, and a few minutes later you can download the completed driver, and test it.
At least for the glide3x.dll for the Voodoo2, I completed this step by now. This CI job here https://github.com/Danaozhong/glide/actions/runs/1203009582 will automatically build the library for Wndows and Linux in both x86 and x64 variants. You can see the download link in the github page, where the generated libraries are located. They probably don't work, but now it should be a bit easier to introduce new code changes and testing them.
Even though I can build some of the libraries now, doesn't mean I understand how they are working. I would be more than happy to get some insights from someone who has some experience with 3dfx driver development!
Habt Ihr mehr Informationen, ob aktuell noch Leute an der Entwicklung von (modernen) Treibern für 3dfx-Karten arbeiten? Ich habe etwas Erfahrung in der Entwicklung von Treibern für ARM Systeme, habe aber noch nie mit x86 gearbeitet. Interessant wären für mich persönlich Treiber für Win10 x64, meinetwegen auch für Glide only. Einerseits hätte ich gerne wieder eine Voodo im PC, und für eine gelegentliche Runde UT wäre so eine funktionierende Voodoo2 auch ausreichend.
Ich habe die letzten Tage mal viel recherchiert und bin zu folgendem Schluss gekommen:
Interessant sind wohl vor allem die Glide-Portierungen von Linux auf Windows. Dazu habe ich folgende gefunden:
1) https://github.com/sezero/glide -> das ist der Code der Glide API, der ursprünglich von 3dfx für Linux als OpenSource released worden ist, und später von Koolsmokey auf Windows portiert worden ist. Dieses Repo klingt für mich am vielversprechendesten, denn - kaum zu glauben - auf dem Repo gibt es hin und wieder noch Aktivität!
2) Der Source-Code von GlideXP (hier zu finden: http://wenchy.net/old/glidexp/). An dem wurde weniger modifiziert als am Koolsmokey Treiber Code, aber er scheint auch mit einer einigermaßen modernen Toolchain ausgerüstet zu sein.
Hat da schonmal jemand versucht durchzusteigen?
Welche Probleme sehe ich?
Ich habe die letzten 15 Stunden den Code von dem Koolsmokey Treiber angeschaut, und habe es zumindest mal geschafft, die Glide API 3 für x64 zu bauen (Glide3x.dll, gebaut mit Visual Studio)! Yay! Den GlideXP Treiber habe ich auch mal kurz versucht, aber der Koolsmokey klang von der Codebasis vielversprechender.
Aktuell schaue ich mir vor allem Punkt 5 und 6 an, da ich dort die meiste Erfahrung habe. Falls jemand Lust hat mitzumachen, würde ich die modernisierten Build-Scripts und Cmake-Umgebung auf Github veröffentlichen. Wie gesagt ist Treiberentwicklung für Windows ein eher unbekanntes Thema für mich.