Posts by IceFire

    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. :spitze:

    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.

    Files

    • 3dfxvsm.zip

      (72.89 kB, downloaded 63 times, last: )

    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:

    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.

    Files

    • 3dfxvs.zip

      (263 kB, downloaded 76 times, last: )

    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).


    Code
    1. mkdir bin
    2. cd bin
    3. 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

    Code
    1. 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:

    Code
    1. fxgasm_tool/bin/Debug/fxgasm.exe -inline > fxinline.h
    2. fxgasm_tool/bin/Debug/fxgasm.exe -hex > fxgasm.h

    The 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:


    Code
    1. mkdir bin
    2. cd bin
    3. 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

    Code
    1. 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:

    • Die gut funktionierenden Treiber von SFFT und Amigamerlin sind leider nicht Open-Source, eine weitere Entwicklung ist da wahrscheinlich nicht möglich.
    • Die Treiber-Leaks von 3dfx, die wohl irgendwann mal 2002 aufgetaucht sind, sind für mich nahezu unbrauchbar. Die Toolchain ist sehr veraltet (MSVC6, DOS-Tools). Wahrscheinlich müsste ein großer Teil neu geschrieben werden.


    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?

    1. Einige Sektionen des Treibercodes sind in assembler geschrieben, der leider für die x86 Plattform entwickelt wurde. Für x64 Entwicklungen würde ich vorschlagen, diese Sektionen in C neuzuschreiben, und sich auf den Compiler zu verlassen.
    2. Der 2D-Kern der Voodoos arbeitet mit GDI und DirectDraw, beides Sachen, die in modernen Betriebssystemen veraltet sind. Eventuell macht es gar keinen Sinn, den 2D Treiber zu portieren - falls es überhaupt geht?
    3. Die Glide API sind die Treiberkomponenten im Userspace. Damit das alles funktioniert, braucht man einen Kernel-Treiber (dafür suche ich noch eine passende Implementierung).
    4. Am einfachsten ist wohl die Entwicklung der Treiber für die Voodoo2, und nur für Glide.
    5. Treiberentwicklung ist schwierig reinzukommen. Die Toolchain braucht lange zum Installieren, und die Tools sind veraltet. Die Entwicklungs-Infrastruktur müsste modernisiert werden (CMake, CI, eventuell sogar Docker?).
    6. Der Code muss für moderne Compiler kompatibel gemacht werden.
    7. Für mich persönlich ist ein großes Problem, Treiber zu debuggen und zu testen. Ich habe darin keinerlei Erfahrung drin. Ich kann den Treiber bauen, aber ob er funktioniert, ist eine andere Sache :D


    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.

    Es ist schön, mal eine Diskussion über E-Autos zu lesen, die nicht sofort unter der Gürtellinie endet. Die Fähigkeit, relativ sachlich zu diskutieren, und die Meinung des anderen zumindest zu akzeptieren, ist in dem Forum außergewöhnlich gut repräsentiert. Das meine ich absolut ernst.

    Wenn es um Elektroautos geht, ist meine Meinung gespalten. Die Abkehr von fossilen Brennstoffen ist notwendig, und für den Einzelverkehr sind Elektro-Autos die bisher technisch beste Lösung. Dazu müssen diese Autos aber auch angepasst sein. Diese Autos brauchen keine 800PS oder 1000km Reichweite, wie die Premium-Hersteller suggerieren. Das kostet unnötig Ressourcen, und anstelle eines solches Luxus-E-Autos könnte man zwei kleinere E-Autos bauen.


    Ich finde, die Diskussion "E-Autos vs Verbrenner" geht aber am Kern des Problems vorbei. Das Hauptproblem ist der hohe Lebensstandard, und dass sich die Menschheit an die Annehmlichkeiten auf Kosten der Umwelt gewöhnt hat. Ein Flug nach Asien verursacht pro Person so viel CO², wie ein ganzes Jahr Auto fahren. Die Person, die auf Flugreisen verzichtet, schützt die Umwelt daher besser als die Person, die sein Verbrenner durch ein E-Auto ersetzt. Der Flugverkehr ist auch nur ein Teil, die Schifffahrt, Industrie, Baubranche, etc. tragen alle ihren Teil zum CO² Ausstoß bei.


    Ein Hauptproblem ist hier die Illusion, dass Technik und Wissenschaft Lösungen finden, ohne dass wir uns auch nur im kleinsten Maße umgewöhnen müssten. Das wird nicht funktionieren. Ich persönlich denke, dass wir das Klima nur dann effektiv schützen können, wenn der wohlhabende Teil der Menschheit seinen Lebensstil ganz beträchtlich ändert. Das Auto durch ein E-Auto zu ersetzen hat vermutlich einen kaum messbaren Einfluss auf die Klimagasemissionen.


    Wieso sind dreitägige Business-Trips halb um die Welt immer noch Gang und Gebe? Warum sind Inlandsflüge nicht verboten? Wieso müssen wir immer unseren Nachbarn mit dem größeren Auto beeindrucken? Wieso gibt es in 90% der Büros keine Mülltrennung? Wieso gibt es in vielen Dörfern am Samstag und Sonntag keine öffentlichen Verkehrsanbindungen? Wieso bekommen E-Autos massive Förderungen, aber die öffentlichen Verkehrsmittel nicht? Wieso wird man komisch angesehen, wenn man für seinen Urlaub eine Woche An- und Abreise mit dem Zug einplant? Wie können wir aufstrebenden Entwicklungsländern glaubhaft vermitteln, dass immer größere Wohnungen, Autos und Lebensstandards eben nicht proportional mit mehr Lebensfreude einhergehen?


    Das sind Fragen, die ich mir persönlich oft stelle, und leider oft keine Antworten finde. Das interessante hier ist, dass nur ein kleiner Teil der Fragen von individuellen Personen oder Technologie beantwortet werden kann. Bei den meisten Fragen sehe ich die Verantwortung in der Politik.

    Dieser Thread ist auch super! Ich liebe Elektronik-Reparaturen! Interessant, wie Du den Fehler mit dem OpAmp gefunden hast - ich hatte letztens auch einen defekten Komperator. Meine Variante war ein Toshiba TA75393. Der lief nach dem Einschalten genau zwei Takte, dann hatte er genug vom Komperieren. Wieso die Teile kaputt gehen, obwohl sie innerhalb der Spec betrieben werden, ist mir ein Rätsel.


    Wie reparierst Du defekte Lötaugen? Ich nehme immer super feine Kabel, aber das sieht etwas unschön aus.

    Größten Respekt auch für das Reverse-Engineering der Spannungsversorgungsschaltungen. Das Problem mit den alten Kondensatoren ist nicht zu unterschätzen. Wenn Spannungsregler wegen kaputten Kondensatoren ihre Arbeit nicht mehr machen können, kann man an den daran angeschlossenen Bauteilen für nichts mehr garantieren. Hast Du Lust, die Schaltpläne online zu stellen, oder möchtest Du diese lieber für Dich behalten?


    Elektronik, vor allem Elkos, altern leider. Die Voodoo Karten sind mittlerweile über 20 Jahre alt, ein Austausch der Kondensatoren ist in dem Alter schon sinnvoll.


    Sehr schön gefällt mir auch die Reparatur des abgerissenen Lötpads.


    Wie sieht es denn mit der Ersatzteillage aus? Hast Du Probleme, die ICs oder Bauteile noch zu bekommen?


    Ich repariere gelegentlich alte Digitaltachos aus den 80ern (siehe Bild). Dort kommt man noch super an alles ran, aber ICs, die seit '92 nicht mehr produziert werden, sind teilweise leider nicht mehr zu bekommen. Ich arbeite dann mit Ersatzschaltungen, oder neueren ICs - funktioniert, sieht aber aus wie Kraut und Rüben. Es ist wahrscheinlich sinnvoll, sich die kritischen Teile auf Lager zu legen.

    Very cool. I remember buying a brand new PowerColor Voodoo3 about 15 years ago in some electronic store in Nowhere, Paraguay, while on vacation. Luckily I resisted the temptation to open the box. I vividly remember the face of the store owner - he was surprised, and seemed happy to found an idiot who finally bought this "Ladenhüter" and outdated piece of hardware.


    I just bought my first Voodoo after roughly ten years: A V3 PCI! https://www.ebay-kleinanzeigen…-1999/1857607348-225-3058

    Ich war damals ein grosser Freund von Adventuregames, denn fuer Actiongeladene Spiele war mein PC zu schwach (ich bin ja leider ohne eine Voodoo aufgewachsen). Neben Titanic faellt mir spontan noch Monkey Island ein, was ich gerne gespielt habe - das ist aber vom Genre schon wieder ziemlich woanders...
    Also, wenn jemand noch ein aehliches Spiel einfaellt - ich wuerde mich sehr freuen :)

    Ich schreibe diesen Post aus zwei Gründen:
    Zunächst einmal - kennt Ihr das Spiel "Titanic - Adventure out of Time"? Das ist ein Adventure-Spiel aus dem Jahr 1996, in dem man in die Rolle eines Geheimagenten schlüpft, welcher auf der Titanic diverse Rätsel lösen muss, um die Zukunft zu verändern - d.h. wenn man seine Mission erfolgreich abschließt, verändert sich der Verlauf der Geschichte und Dinge, wie beispielsweise die Weltkriege, finden nicht statt. Was mich an dem Spiel aber besonders fasziniert, ist die Art, wie es einem in das Jahr 1912 und auf die Titanic zieht. Ich habe das Spiel damals, ein paar Jahre nach der Veröffentlichung neu gekauft ( :D ) und habe als Kind stundenlang vor dem Rechner verbracht und fühlte mich in der Zeit, als wäre ich direkt auf der Titanic. Für mich ist dies das beste Spiel, das es jemals gab.
    Nun mein erster Punkt: Vielleicht gibt es bei Euch auch einige, die das Spiel kennen und gespielt haben und vielleicht meine Begeisterung nachvollziehen können. Könnt ihr mir vielleicht ähnliche Adventure-Games vorschlagen, die in einem historischen Kontext gesetzt sind und so unheimlich spannend sein können? :D Mir ist dabei unwichtig, ob es von 1996 oder fast neu ist - ich würde mich über Vorschläge sehr freuen.


    Zweitens möchte ich etwas Werbung für ein Remake-Projekt machen. Eigentlich mache ich das nicht, aber da mich das Projekt so fasziniert und ich so begeistert von Ozeanlinern bin und ich denke, dass es hier vermutlich auch den einen oder anderen gibt, der das Thema spannend findet, verstoße ich mal gegen meine Prinzipien. Eine Gruppe aus 3D-Modellern und Programmierern möchte eine Art Remake des alten Titanic-Spiels
    entwickeln . Es soll ein 3D-Spiel mit einer verzwickten
    Story und komplizierten Verschwörungen. Im Prinzip ist die Idee nichts besonderes - was mich aber an diesem Projekt total begeistert, sind die absolut realistischen 3D-Modelle, die einem das Gefühl geben, man befände sich persönlich an Bord der Titanic. Ich will niemanden dazu überreden bei dem Projekt beizutragen - mir geht es lediglich darum, Usern mit ähnlichen Interessen ein cooles Projekt zu zeigen: https://www.indiegogo.com/proj…or-and-glory-phase-3#home

    Ohje, das sind aber traurige Nachrichten! Turrican war, soweit man jemanden über das Internet kennenlernen kann, ein äußerst sympatischer Mensch und es ist sehr schade, was ihm passiert ist. Was für ein grässlicher Tod!
    Ein Kranz finde ich eine gute Idee. Schließlich hat er viel Zeit in unserem Forum verbracht und somit gehörte unsere Community ja auch ein bisschen zu seinem Leben, oder? Was meint Ihr? Ich würde mich also auch an einem Kranz beteiligen.