Dass 386er Bretter nur die ×9 organisierten Module (SIMM, SIPP) unterstützen, scheint eher die Regel als die Ausnahme zu sein.
Als Fan von RAM-Maximalbestückungen könnte das ja für dich von Interesse sein, kannst ja mal schauen ob bei deinem 386 A11 (Adress-Line für 16 MB Module) verkabelt ist.
Von fisseligen Lötarbeiten bin ich aber aus "optischen" Gründen gar kein Fan mehr. Alles kleiner RM2,5 muss nicht mehr … fortschreitende Vergreisung halt.
Laut Doku ist bei den drei aufgebauten 386ern und den beiden aufgebauten 486ern nur mit je acht SIMM Slots an Bord jeweils bei 32 MiB RAM = 8× 4 MiB SIMM Schluss.
Einzig ein 486er, der zwei PS/2 Slots und vier SIMM Slots an Bord hat, kann laut Doku 128 MiB RAM = 2× 32 MiB PS/2 FPM + 4× 16 MiB SIMM. Da limitiert jedoch die VL-Bus-Grafikkarte, die ihren Adressbereich unsinnigerweise bei 62 MiB einblendet, weshalb in der Kiste aktuell bei 48 MiB RAM = 2× 16 MiB PS/2 FPM + 4× 4 MiB SIMM Schluss ist.
Die Diagnosekarte ist dieses einfache
Prinzipiell interessant, nur werde ich vor der Alpenfahrradtour nix mehr bestellen, damit kein Kram während der Tour ankommt. Danach kann man für 12,- € + Versand nicht sooo viel falsch machen.
XT-Bus-Slots:
Die Leiterbahnen sind zwischen den beiden XT-Bus-Slots und den unbekannt vielen (4 ?) ISA-Bus-Slots durchgeschliffen. Die musst Du also so oder so wieder durchgängig machen. Dann könntest Du auch wieder zwei neue XT-Bus-Slots einlöten. Die ausgelöteten XT-Bus-Slots würde ich direkt entsorgen.
RAM:
Die 72-poligen PS/2-Module gibt es in den Versionen FPM und EDO. Ein PS/2 FPM Riegel ist elektrisch die Zusammenfassung von vier SIMM Riegeln. Da sollte also elektrische Kompatibilität gegeben sein. EDO ist elektrisch inkompatibel zu FPM, wird also auf dem Brett mit sehr hoher Wahrscheinlichkeit nicht funktionieren. Solltest Du das Brett in Gang bekommen und es hapert nur am RAM, kann ich Dir evtl. 4× 1 MiB SIMM zukommen lassen. Angeblich lassen SIMM sich recht einfach durch Anlöten von Drähten an die Kontakte zu SIPP umbauen, habe ich aber mangels Bedarf nie probiert.
Diagnosekarte:
Taugt die was? Würde mich grundsätzlich mal interessieren.
Soundkarte:
In einem meiner 386er steckt eine "Best Union Electronics MF-1868" mit ESS 1868 Chip und PnP-IDE-Port, wobei am PnP-IDE-Port ein CDROM-Laufwerk hängt. Das geht grundsätzlich also. Auf dem 386er (i386DX-33 + i387 16-33; 32 MiB RAM) läuft Linux mit Kernel 2.4.33.3, der das ISA-PnP unabhängig vom BIOS übernimmt. Der Treiber für den PnP-IDE-Port ist gut versteckt im Kernel, der Soundtreiber kommt bei Kernel 2.4 noch extra als alsa-Treiber. Unter DOS hast Du die Soundkarte ja in Gang gekriegt. Das sollte also auch auf dem 386er gehen, sofern mit dem DOS-Treiber das im BIOS fehlende ISA-PnP umgangen werden kann. Es gibt für DOS auch CDROM-Treiber, denen IRQ und I/O-base des IDE-Ports, an dem das CDROM-Laufwerk hängt, als Parameter verabreicht werden können, womit ebenfalls das im BIOS fehlende ISA-PnP umgangen wird.
FPU:
Die lohnt sich nur, wenn Du auf der Kiste ein Programm laufen lassen möchtest, das nach damaligen Maßstäben ohne FPU unerträglich lahm oder gar nicht läuft. Beispiele: AutoCAD für DOS läuft meines Wissens gar nicht ohne FPU. Der Linux-Kernel muss ohne FPU die "math emulation" nutzen, wodurch Linux dann wie 'ne Schlaftablette läuft.
Das SoaD Cover ist ja mal geil. Kannte ich gar ned
Dass ein Violoncello ähnlich bratzen kann wie eine verzerrte E-Gitarre, war mir bekannt, aber "Double Bass Drumming" auf einer Djembe kannte ich vorher auch nicht.
System of a Down - B.Y.O.B. (Cello Cover)
und hier mal die "andere Richtung":
J. S: Bach: Suite Nr. 1 für Violoncello solo G-Dur BWV 1007 – Prélude (E-Guitar cover)
Ist aber Overkill für eine treiber senke. Aber ein Backup wäre nicht schlecht.
Eine externe HDD ist in Verbindung mit moderner Hardware einfach nur noch eines: unendlich lahm!
Zudem ist eine SSD in einem robusten Gehäuse wesentlich weniger stoßempfindlich als eine externe HDD. 
Daher spiele ich mit Linux seit einigen Jahren. Ich komm inzwischen gut damit klar, nur einige Programme vermisse ich schmerzlich.
Das ist völlig normal, war vor über 20 Jahren, als ich umstieg, auch nicht anders. Erfahrung sagt aber, dass sich für die meisten Programme recht zeitnah brauchbarer Ersatz findet, und diesbezüglich ist die Situation heute deutlich entspannter als vor 20 Jahren. Problematisch wird es nur bei irgendwelcher Supersommersonderspezialsoftware wie etwa Maschinensteuerungen oder vielleicht auch einigen Spielen und Simulatoren. Vor 20 Jahren gehörten in diese Kategorie auch so Software wie Notensatz, Vektorgrafik, FEM, CAD oder Buchhaltung. Heute ist es eher so, dass man nur wechseln wollen muss.
OT: Als dieser Thread erstellt wurde, lief hier noch die Kiste mit dem FX 8350 drin, weshalb ich mit "Nein, meine Hardware gibt es nicht her" stimmte. Nach dem Hardwareupgrade auf den Ryzen 7 5800+ im Arbeitsrechner und den Ryzen 5 5600+ im Software-Ausprobierrechner wurde auf Windows 11 umgestellt, wobei das allerdings nur sehr selten genutzt wird, weil normalerweise Linux läuft. Windows 10 läuft hier nur noch auf einer Museumskiste, der der Internetzugang unter Windows im Herbst 2025 genommen werden wird. Auf Arbeit wird das noch Gewürge werden, weil da noch Hardware – Dort laufen noch einige AMD FX, und die sind eher nix für Windows 11. – gekauft werden muss, und wenn es dumm läuft und die Lizenzrettung über das Microsoft-Konto nicht mehr funktionieren sollte, auch Windows 11 Lizenzen. Der Chef hat aber 'nen Igel im Portemonaie …
Im UEFI-Bios ist ein Home-Key hinterlegt, das WIN10 habe ich aber mal mit einem alten W7-Key in Pro umgewandelt. Das müßte ja beim Upgrade als digitale Lizenz übernommen werden, oder?
Die Betonung liegt auf dem Konjunktiv "müsste". Jede Änderung an der Hardware kann eine Neuaktivierung erfordern, und dann ist Schluss mit lustig.
Für den Fall der Fälle könnte ich vorher eine Art "Maintenance-WIN10" auf meinem Laufwerk D: installieren, damit ich an alles herankomme, falls beim Upgrade auf C: irgendetwas schief läuft.
Das kann vom Update aber auch zerlegt werden. Nur wenn Laufwerk D: eine zweite SSD/HDD ist, die vor dem Update abgestöpselt wird, passiert erst mal nix damit.
Aber wozu überhaupt der Aufwand? Vor so etwas macht man eh ein Backup. Und an den Kram selbst kommt man auch mit einem Live-Linux dran. Anders als mit einem zweiten Windows sind da keine Wechselwirkungen mit dem ersten Windows zu erwarten.
Auf der Platte befinden sich ca. 1.3TB in über 600.000 Dateien […] welches beim Sichern auf eine ext. USB-Platte jetzt erstmal trotz USB3 über einen Tag dauern wird
Ist das etwa noch eine USB-HDD? Dann gibt es kein Mitleid! 
Stand der Technik ist eine PCIe 3.0 NVMe-SSD in einem USB 3.2 Gen 2-Gehäuse.
ein Bild von damals, als auch im Harz die Fichten noch Nadeln trugen
Auf den ersten Blick löst ein grid-Layout das Problem.
Die html-Datei wird dadurch etwas übersichtlicher. In der css-Datei ist es quasi egal.
Mit ganz alten Brausen wird sich das dann aber nicht mehr anzeigen lassen. Wenn ich das richtig verstanden habe, ist die Historie bei den html-Layouts: table → div → grid
Für eine Fotogalerie, die gleich die kompletten Bildsätze in voller Auflösung lädt, ist aber eh etwas mehr Bums in der Kiste und auf der Leitung erforderlich. Dafür ist 'n Athlon XP mit Windows XP und Firefox 48.0.2 wohl doch etwas zu schlapp.
Ach ja, die schwarzen Beerdigungsrahmen um die Bilder kommen natürlich noch weg. Die dienen hier nur dem Debugging.erl.
Und wenn schon grid, dann kommt das auch noch für die beiden anderen "Tabellen" (Text über Bildern und Fußzeile) statt div-Layout.erl.
zu früh gefreut 
Wenn unter einem Bild, das nicht am rechten Rand steht, die Bildunterschrift mehr Zeilen benötigt als bei anderen Bildern in der Zeile, passiert das.
Wieso passiert das und wie lässt sich das verhindern, sodass es keine leeren "Plätze" mehr gibt (außer evtl. ganz unten nach dem letzten Bild) und wieder alle "Plätze" innerhalb einer Zeile mit je einem Bild samt Bildunterschrift gefüllt werden?
Das passierte bereits mit <div class="gallery">, der Wechsel auf <figure class="gallery"> brachte dahingehend leider keine Änderung. Auch sonst änderte sich dadurch nix, nur die html-Datei wurde etwas übersichtlicher, da nun weniger geschachtelte <div> drin sind.
Das war inna Nacht ein 1. Schuss. Vorhin bei einer kurzen Fahrradrunde "für 'n Kreislauf" fiel die Entscheidung, die doch recht voluminöse Box rauszuschmeißen. Ein sich ändernder Mauszeiger, die sich ändernde Opazität des Bildes und ein dabei erscheinender blauer Rahmen um das Bild – Textlinks wurden und werden oftmals ebenfalls blau dargestellt – reichen hoffentlich, die Leute zum drauf klicken zu animieren. Durch den Rauswurf der Box sind zudem sowohl die html-Datei als auch die css-Datei etwas schlanker geworden.
Mit position: relative; ging das Zentrieren der Box irgendwie nicht, dafür traten unerwünschte Nebenwirkungen auf. Wahrscheinlich geht das nur mit Script, und das sehe ich für so etwas nicht ein, da das "Kanonen auf Spatzen" wäre.
Dass die "Masse da draußen" sich 'ne Fotogalerie auf dem Mäusekino rein zieht, ist schwer vorstellbar. Da drauf erkennt man doch nix. Minimal sollte es schon ein Tablet sein.
Hier läuft gerade ein kleinerer HTML-Nahk(r)ampf.
Seiten dieser Art sollen zukünftig in dieser Art angezeigt werden, also kein grundsätzlich neues Design, aber Änderungen in Details. "Unter der Haube" passiert dafür notwendigerweise einiges, so geht das nicht mehr in HTML 4, womit auch CSS nötig wird. JavaScript bleibt aber draußen! Insbesondere wird von table-Layout auf div-Layout umgestellt.
Was mich am obigen Ergebnis noch stört, ist die Einblendung des "tooltips" bei mouse hover unter den Bildern. Der soll eigentlich mittig in den Bildern eingeblendet werden.
Code wird bei Bedarf nachgereicht.
[quote='Arnulf zu Linden','RE: Dateisystem für Zugriff durch Linux und Windows']
In dem Zuge gleich 'ne Frage: Wie krieg' ich raus, über welchen Treiber auf ein Dateisystem zugegriffen wird?
Ein Blick in /etc/fstab sollte Klarheit bringen, in diesem Fall steht da ntfs-3g oder ntfs.
Hier zu Hause und auf Arbeit wird dafür (mit Linux Kernel 6.6 & Windows 10|11 – alles 64-Bit) exFAT genutzt, das mittlerweile quelloffen ist.
Nachteil: exFAT hat kein journaling, aber man hat ja ein Backup für den Fall der Fälle …
Kernel 6 bringt auch einen nativen NTFS-Treiber mit, womit NTFS-3G obsolet wird. Mehr als mal probeweise habe ich diesen nativen NTFS-Treiber (genauso wie NTFS-3G ) aber noch nicht benutzt.
FAT32 wird hier nur für Museumskisten benutzt, die maximal 'ne Distro mit Kernel 4 mit sinnvoller Performance stemmen können und daneben Windows 2000|XP|Vista drauf haben – ist dann auch in Hard- und Software alles komplett nur 32-Bit.
Hier würde ich eher noch mal schauen, ob nicht noch weniger reicht. Ist halt die 125W Version und etwas sparen wäre für alle Komponenten gut.
Hart weniger für Sockel AM2 bzw. Sockel AM2+ liegt hier inna Kramkiste, die sind also übrig:
Auf einem Athlon64 X2 4800+ (Brisbane) mit 8 GiB RAM lief hier anno knips mal kurzzeitig Windows XP 32-Bit + Gavotte RAM-Disk. Das wurde damals aber doch recht bald von Windows 7 64-Bit und Linux 64-Bit abgelöst. Und danach musste der Athlon64 X2 4800+ einem Phenom II X4 945 (3,0 GHz ×4; 95 W) Platz machen.
Ist eigentlich eine IGP schlimmer oder ein Turmkühler, nur damit wir einen Eindruck der Rangordnung bekommen
Mit der vorhandenen "chipset IGP" bremst Du Dir gnadenlos das System aus. "DDR2 shared memory" ist als Grafikspeicher in einer Kiste diesen Alters indiskutabel lahm, und durch "shared memory" sinkt auch die Speicherleistung und damit die Systemleistung insgesamt. Der Phenom II X6 1055T wäre dann schon ziemlich "Perlen vor die Säue". Wenn nur Windows drauf laufen soll, nimm die GeForce GT240 von michi.
Bei Benutzung eines Turmkühlers bekommen VRMs, Northbridge, Speicherriegel und falls genutzt die "chipset IGP" nahezu keinen erzwungenen Luftstrom ab. Das kann in einer für das Brett oder die Speicherriegel tödlichen Grillparty enden, was bei Hardware diesen Alters schade wäre.
Oder kurz gesagt:
Mit einem Turmkühler kann das Brett eine tödliche Überhitzung erleiden, mit der "chipset IGP" hingegen befindet sich die Seele in der Hand des Teufels. 
Laufen soll XP, daher die Hardwareauswahl.
Wieso soll da Windows XP drauf laufen? Das nutzt den 6-Kerner doch gar nicht richtig aus, und unterstützt in der 32-Bit-Version auch nur 3,25 GiB RAM. Den Rest der 8 GiB RAM könnte man nur über eine RAM-Disk zugänglich machen. Außerdem unterstützt Windows XP kein TRIM für die SSD.
Die vorhandene Hardware plus PCIe x16-Grafikkarte spricht eher für Windows 7 64-Bit. Das nutzt den 6-Kerner besser aus und auch die 8 GiB RAM. Zudem wird TRIM für die SSD unterstützt.
Geworden ists ein X6 1055T, 8GB RAM, 512GB SSD. Darf jetzt den Titel "Haupt-PC" tragen.
Wenn die Kiste für den täglichen Einsatz gedacht ist, wirst Du mit dem Turmkühler nicht glücklich werden. Setze einen top-down-cooler auf den Prozzi, z. B. den hier. Der lässt sich bei Bedarf bis einschließlich Sockel AM4 weiter verwenden. Dann kann hinten ein leiser 120 mm Miefquirl rein, und der Brüller vorne kann dafür raus.
Wenn auf der Kiste vornehmlich Windows und nur gelegentlich oder gar nicht Linux laufen soll, geht eine nvidia-Grafikkarte. Wenn regelmäßig Linux drauf laufen soll, ist eine Ati Radeon HD 5xxx, 6xxx oder 7xxx die deutlich bessere Wahl. Die Teile gibt es immer wieder mal für 'n schlanken Taler inna Bucht.
Inzwischen sollte dieses Fax Protokoll auch bei den Providern rar sein.
Wie soll die Verwaltung in Deutschland denn funktionieren, wenn das Fax nicht mehr funktioniert? 
Moin, so hier mal zwei Bilder,
Du bist nun schon der zweite, der in dieses Gehäuse reichlich Laufwerke gestopft hat.
Dieses Gehäuse steht hier zweimal. Im zweiten steckt der aktuelle Backup-Server (Basis: Ryzen 5 5600X). Das Gehäuse ist also auch heutzutage noch funktional.
