Persönliche Premiere: Custom Wasserkühlung im Rechner
Im April hatte ich hier im Blog mal einen in der Entstehung befindlichen Retro-Gaming-PC erwähnt und nun ist dieser fertig. Samt - und das war Neuland für mich - einer Wasserkühlung!Ambiente wie in einem Borg-WürfelJahaaaa - Wasserkühlung im Computer ist ungefähr so neu wie das Rad und das klingt jetzt so wie wenn jemand 2024 verkündet, er hat jetzt auch so ein Smartphone.
Aber:
Lasst mir den Spaß, denn für mich ist es trotzdem neu und ich freu mich halt - weil bei mir einfach nie viel Kohle für aktuelle PC-Technik da war und schon gar nicht für teuren Wakü-Kram.
Jedenfalls wollte ich nun endlich mal selbst eine Wasserkühlung verbauen. Und hab's durchgezogen:
Wen's interessiert:
Akasa 6x Lüftersteuerung als Frontmodul - umgebaut auf grüne LEDs
2x 128x64-Displays in der Front, angesteuert mit VFD-Studio 2
Das Gehäuse vom April war leider zu klein für all das und hatte keine Option den 240er Radiator zu verbauen, darum jetzt ein größeres Corsair-Case. Nur leider ohne Schacht für ein 3.5"-Diskettenlaufwerk, was ich sehr bedaure.
Dafür aber jetzt mit einem 200GB-Bandlaufwerk - das versprüht auch etwas Retro-Charme :-)
Ist das sinnvoll einen alten Retro-Rechner mit Wasserkühlung zu pimpen? Absolut nicht!
Hat's Spaß gemacht? Absolut ja!
Und ja, abgesehen vom GPU-Kühler sind die Teile der Wasserkühlung natürlich nicht historisch akkurat im Retro-Rechner. Gerne hätte ich da Vintage-Komponenten verwendet, aber die sind so schwer erhältlich, dass wir da jetzt mal ein Auge zudrücken.
Tatsächlich hab ich da aber trotzdem schon ein paar Teile gesammelt und die Idee, eine DIY-Wasserkühlung in meinen alten Pentium4-Rechner zu basteln. Das wird vielleicht ein Projekt für den Winter ...
Ob das ein Schuss in den Ofen wird?
Kind #3 zeigt neuerdings zaghaftes Interesse an PCs, Programmieren und Computerspielen. Klar, dass ich so eine Gelegenheit zur Nachwuchsförderung nicht verstreichen lasse und darum bauen wir zu Zeit den ersten eigenen Rechner aus meinen diversen Restbeständen an Computerkram.
Was da aber noch gefehlt hat, war eine halbwegs potente Grafikkarte. Also habe ich bei eBay eine gebrauchte GeForce 8800 erstanden. Die ist zwar uralt (anno 2007) aber aus Kostengründen soll das Ganze ohnehin ein Retro-PC werden.
Nur leider war die Karte zwar nicht mehr teuer, funktionierte aber auch nicht mehr richtig: das Bild hatte unter manchen Auflösungen Darstellungsfehler und es ließ sich partout kein Treiber installieren.
Sehr unbefriedigend, insbesondere da rein optisch kein Fehler zu erkennen war.
Also habe ich nochmals eine alte Grafikkarte gekauft. Diesmal eine ATI Radeon.
Und: Ebenfalls Fehler! 🙁 Genau gesagt sogar überhaupt keine Bildfunktion. *seufz*
Inzwischen sind wir bei Grafikkarte Nr. 3 angelangt (eine GeForce 570) und diese funktioniert auch einwandfrei. Aber so richtig Ruhe gelassen hatten mir die beiden Schrottkarten nicht, zumal beide Verkäufer schon recht glaubhaft versicherten, dass die Karten vor dem Versand noch liefen.
Nun ist es so, dass DHL & Co. leider bisweilen auch mal recht ruppig mit Paketen umgehen und es schon denkbar ist, dass dabei irgendwo irgendwas auf der Karte gerissen ist und nun nicht mehr richtig Kontakt hat. Und dann fiel mir wieder ein, wovon ich schon vor Jahren mal gehört hatte: Grafikkarten im Backofen backen um solche Risse im Lötzinn wieder zu schließen!
Das klingt freilich reichlich abstrus, aber alles was ich zu verlieren hatte war letztlich eine kaputte alte Grafikkarte. Also: Kühlkörper und Plastikteile abschrauben und rein mit der 8800er in den Ofen.
Mein Rezept: ich habe die Karte in den noch kalten Ofen gelegt, die Temperatur auf 160 °C gestellt, nach zehn Minuten für weitere zehn Minuten auf 220 °C erhöht und dann bei geöffneter Ofentür wieder eine Stunde lang abkühlen lassen.
Wenn es dumm ist, aber funktioniert, dann ist es nicht dumm.
Und: Funktioniert wieder einwandfrei! 🙂
Und noch besser: die Radeon-Karte geht auch wieder!
Das haben wir gut gebacken bekommen.
Ob das nun von Dauer ist? Ich weiß es nicht. Manche sagen, ihre gebackenen Karten liefen danach noch jahrelang, andere sagen, die Fehler waren nach ein paar Wochen wieder da...
Nehmt euch doch auch ein Glas Wein, heute philosophiert Herr Cypax mal ein bisschen vorm Kaminfeuer...
Vom Aussterben bedroht: alte Programmiertools
Wir haben einen Pkw, der ist 11 Jahre alt. Eine Waschmaschine, die ist 15 Jahre alt. Meine Nähmaschine ist über 30. Und im Keller ist noch ein Bakelittelefon aus den 1950ern angeschlossen.
All diese technischen Dinge sind immer noch in Betrieb, sehen nicht groß anders aus als ein Neugerät (ok, ja, das Telefon schon etwas) und funktionieren auch anno 2021 nicht grundsätzlich schlechter, als es ein Neugerät würde.
Deutlich anders sieht das schon bei den Computern aus. Und extrem auffällig ist der Technikwandel bei Handys.
Das ist mir letztens wieder so richtig gewahr geworden, als ich für den neuen Bombenwecker ein Nokia von 2007 wieder in Betrieb genommen habe, um dafür eine Anwendung zu programmieren.
2007 steckten Android und iOS noch in den Babywindeln und es war noch nix groß mit Smartphones, Apps und derlei. Die Handys hatten mickrige Grafikdisplays, wenig Speicher und "Apps" waren im Wesentlichen kleine Java-Programme, die in einer sehr rudimentären Laufzeitumgebung liefen.
Und normalerweise findet man im Netz ja zu jedem beliebigen Thema Informationen in unbewältigbarem Überfluss - um aber herauszufinden, wie und womit ich genau dieses Handy programmiere, wo man noch eine Entwicklungsumgebung herbekommt, wo eine Laufzeitumgebung und so weiter, musste ich erstmal richtig ausgiebig graben.
Und ja, gefunden habe ich dann letzten Endes schon noch irgendwie alles. Aber es stellte sich dabei auch dieser Eindruck ein, sich auf nahezu völlig ausgestorbenem Gebiet zu bewegen. Fast wie ein Archäologe.
Klar, von all den Bibliotheken, Konzepten und Quelltexten aus dieser Zeit ist natürlich auch einiges in Neuentwicklungen eingeflossen und lebt damit bis heute in gewisser Form weiter. Auch heutige Android-Apps beispielsweise basieren letztlich alle auf Java.
Und manche IT-Themen überleben sogar dauerhaft in kleinen ökologischen Nischen. So wie manche Bankenanwendung noch in Fortran geschrieben ist oder es immer noch Geldautomaten mit Windows XP gibt. Und folglich gibt es dazu auch noch entsprechende Nischen-Communities, wo auch heute noch zumindest geringe Aktivität besteht.
Bei der Handy-Anwendung á la 2007 hingegen stellte sich so ein richtiges Friedhofsgefühl ein.
Die Art, wie noch vor wenigen Jahren Handyprogramme entwickelt wurden, all die Forenbeiträge, Diskussionen, Tools und Tutorials sind mausetot und kommen auch nie wieder.
Da kommt man schon mal ins Grübeln, was das für eine bizarr kurzlebige Branche ist.
printf("Der Wert von Variable 'a' ist jetzt %d.\n", a);
Was meint ihr, gelingt es mir als Programmierer von BoeseFunktion() dass die Ausgabe in der zweiten Zeile Der Wert von Variable 'a' ist jetzt 0. lautet? Selbst wenn 'a' nur lokal der Main-Funktion bekannt ist?
Ich sage ja:
BoeseFunktion():
void BoeseFunktion(int tmp) {
int* pointer;
pointer = &tmp - 1;
*pointer = *pointer + 8;
}
Das funktioniert eigentlich ganz einfach. Mit pointer = &tmp - 1; hole mich mir einen Zeiger auf den ersten Funktionsparameter und reduziere die Adresse um 1. Auf x86-Systemen bin ich nun an der Rücksprungadresse von BoeseFunktion() auf dem Stack.
So sieht das im Speicher aus:
Und mit *pointer = *pointer + 8; erhöhe ich anschließend die Rücksprungadresse um 8 Byte, was gerade soviel ist um das a = 1; in main() zu überspringen.
Solches Gehacke mit Pointer-Arithmetik ist natürlich sowieso pfui. Aber was uns dieses Beispiel eigentlich lehren soll ist, dass man fremden Funktionen nicht trauen soll.
Es könnte schließlich sein, dass ich sie geschrieben habe... 😉
Schadensabwehr
Aber wie bekommt man nun das Problem in den Griff, dass Fremdcode, den man in so gut wie jedem Projekt findet, unbeabsichtigt oder beabsichtigt Unfug anstellt und Daten oder die Programmausführung beeinträchtigt?
Da gibt es mehrere Möglichkeiten. Unter anderem:
Logische Programmablaufkontrolle
Man stelle sich vor, jede eigene Funktion meldet sich bei ihrem Aufruf an einer zentralen Instanz mit einem eindeutigen Key. Die zentrale Instanz überprüft dann anhand einer Tabelle ob es in Ordnung ist, dass Funktion3 nun auf Funktion2 folgt oder nicht.
Bringt fremder Code - zum Beispiel eine defekte DLL - den Ablauf durcheinander so wird dies schnell aufgedeckt.
Voraussetzung für ein solches System ist natürlich eine deterministische Reihenfolge der Funktionsaufrufe.
Datenredundanz
Zuerst einmal sollten alle Daten, die irgendwie wichtig sind, redundant vorliegen; am besten redundant-invers. Das heißt, es gibt nicht eine Variable 'a', sondern z.B. 'unsigned char u8VentilSollwert' und 'unsigned char u8VentilSollwertInvers'. Das hat nicht nur einen eingängigeren Namen als 'a' sondern informiert uns auch gleich noch über das Präfix u8, dass es eine unsigned 8-Bit-Variable ist mit Wertebereich von 0..255.
In der einen steht dann z.B. 1 (binär 0000 0001) und in der anderen das Gegenteil, also 254 (1111 1110).
Vor Verwendung wird jedes Mal geprüft, ob die beiden Variablen noch Bit-invers sind und falls nicht mit Fehlermeldung abgebrochen.
Datensicherung
Wenn die Daten umfangreicher sind, gibt es die Möglichkeit sie mit einer Checksumme zu sichern. Wird die Checksumme oder die Daten beschädigt, so fällt dies auf, sobald man die Checksumme nachrechnet und mit dem Prüfwert vergleicht.
Und mit