Beiträge von Xaar

Ohne den Thread hier misbrauchen zu wollen: Gibt's bei den ISA-Backplanes Unterschiede? Oder sollte mit so einem SBC-Board im 16-Bit-ISA-Format jede Backplane laufen?

Wenn ich mich noch recht entsinne, waren vor Allem die ersten Voodoo-Generationen (Voodoo Graphics und Voodoo² - glaube in Teilen auch noch die Voodoo Banshee und die Voodoo Rush) Vor Allem was für Windows 9x. Treiber gibt's noch im 3dfx Archive (z. B. hier als Backup noch vorhanden: http://falconfly.3dfx.pl/3dfx.htm).

Ansonsten macht die Ur-Voodoo vermutlich nur bei frühen Direct3D-Spielen und natürlich Glide-Spielen Sinn, zumal die Auflösung auf glaube 640x480 begrenzt ist bei der Karte.

Was haste denn da für einen Kühlkörper drauf, dass du 'nen Mobilen Pentium 4-M ohne Heatspreader und einen Desktop-Pentium 4 mit Heatspreader nutzen kannst?

Das mit dem "P4-M ist ein stromsparenderer Vorgänger zum Pentium 4 Mobile" stimmt auch nur bedingt. Der Pentium 4 Mobile (erschienen zwischen Juni 2003 und Januar 2005) war nur noch für dicke DTR-Notebooks vorgesehen, da der Pentium M mit seinem Erscheinen (ab März 2003) dem Pentium 4-M (erschienen zwischen März 2002 und Juni 2003) mit einem deutlichen Effizienz-Plus den Rang abgelaufen hat. So sonderlich groß Verbreitung dürften Pentium 4 Mobile da nicht mehr gefunden haben (v. A. die HyperThreading-Modelle) - bei 88 W TDP wäre da für ein Notebook auch eine überdimensionale Kühllösung notwendig.

Willkommen, du bist freigeschaltet

Hm, das stimmt auch wieder. Das Board mit dem U5SX ist auch das Neuste der drei - während die beiden anderen von Anfang 1993 sind, ist das mit dem U5SX von Mitte 1995.

Ich müsste mal schauen, dass ich alle CPUs auf dem gleichen Board teste - leider sind der i486SX-25 und der U5SX-33 beide verlötet - aber ich hab' ja gleiche Exemplare auch noch als PGA-Ausführungen hier

Btw.: Das Board mit dem U5SX drauf lässt mich ohne Probleme den Prozessor mit 20, 25, 33, 40 oder 50 MHz takten - einfach über ein paar geänderte Jumper. Die Integer-Performance kriege ich bei 50 MHz damit auf eine Wertung von 24.09 gepusht Allerdings wirkt sich die höhere Taktung nicht überall positiv aus:

Der Datendurchsatz beim L1-Cache-gestützten Lesen geht ordentlich hoch - aber sobald es zum Schreiben kommt, sinkt die Datenrate - um gleich mal 25 % im Vergleich von 33 zu 50 MHz, fast auf das Niveau von 25 MHz. Ich vermute mal, hier werden irgendwelche Wartezyklen reingeschoben, da sonst der Speicher oder der Chipsatz nicht hinterher kommt.

Hier noch die Screenshots von den 4 Versuchen abseits der 33 MHz (20/25/40/50 MHz):

Allgemein finde ich es interessant, dass die Schreibwerte gleich flott bleiben über den gesamten Bereich und auch bei größeren Blöcken als die Caches über denen der Lesewerte liegen. Mach' bzw. verstehe ich da was falsch?

Mal ein paar SpeedSys-Benchmarks von einigen heute getesteten Boards und CPUs (1. Bild mit Turbo, 2. Bild ohne Turbo):

Intel i486SX-25 mit 256 kB L2-Cache OnBoard und 8 MB RAM (8x 1 MB SIMM, 70 ns):

UMC U5SX-33 ohne L2-Cache und 12 MB RAM (4 MB + 8 MB PS/2-SIMM, FPM, 60 ns):

AMD Am486DX-40 mit 256 kB L2-Cache OnBoard und 8 MB RAM (8x 1 MB SIMM, 70 ns):

AMD K6-200 mit 256 kB L2-Cache OnBoard und 80 MB RAM (2x 32 MB + 2x 8 MB PS/2-SIMM, EDO, 60 ns):

Da es verschiedene Boards (und v. A. auch verschiedene RAM-Sorten) sind, ist das bei den 486ern natürlich nicht 1:1 vergleichbar. Dennoch nice, dass der U5SX in Sachen Datendurchsatz jenseits seines L1-Caches ungefähr das Niveau von den beiden anderen 486ern im Bereich des L2-Caches hält.

Leider scheint die Cacheable Area beim L1-Cache des U5SX nur 4 MB groß zu sein - zumindest meint ctcm16n das so. Egal, wieviel RAM ich dem Board verpasst habe, die Cacheable Area des L1-Cache wurde immer mit 4 MB angegeben - beim L2-Cache ist sie mit dem RAM gewachsen. Wobei das Board eh etwas merkwürdig ist: Scheinbar verträgt das sowohl FPM- als auch EDO-DRAM - und selbst mit einem 64 MB PS/2-EDO-DIMM ist es gestartet und hat die 64 MB voll erkannt. Bei zwei 32 MB PS/2-EDO-DIMMs hingegen kamen am Ende nur knapp 48 MB raus - aber auch ohne ein anderes Modul werden im 2. PS/2-SIMM-Slot maximal 16 MB erkannt (egal, ob das Modul nun 32 MB oder 64 MB hat). Aber ich vermute, hier läuft das Ganze alles Andere als im Rahmen der Spezifikationen

Ich weiß nicht, inwiefern die Angaben zur RAM-Konfiguration im Handbuch (https://theretroweb.com/motherboard/ma…4c054853011.pdf, Seite 29-31) bzw. in der TH99 (https://th99.bl4ckb0x.de/m/E-H/31760.htm) alle funktionierenden Kombinationen darstellt: Mit dem Jumper JP6 lassen sich die SIP-Module ja als Bank 0 und 1 konfigurieren, sodass die DIP-Sockel raus aus der Konfiguration sind. Allerdings scheint das Board nur Module mit Parity (also 9 Bit - sprich, bei den meisten Modulen mit 8 oder 2 Daten-ICs plus 1 Parity-IC drauf) zu unterstützen. Außerdem sind in den Konfigurationsangaben nur Module mit 256 kB oder 1 MB Kapazität aufgeführt. Kann sein, dass das einfach mangels damals vorhandener 4-MB-Module der Fall ist (dürften um 1990 auch extrem selten gewesen sein, falls es sie überhaupt schon gab), kann aber auch sein, dass die einfach prinzipiell nicht funktionieren.

EDIT: Adrian Digitals Basement hat interessanterweise gerade ein Video zu einem 286er Board mit SIPs (was im Prinzip auch ein 386SX sein könnte). Da wird das Thema mit den 4-MB-SIMMs auch angesprochen:

Bei Bedarf könnte ich dir aber auch, wie Arnulf, 30-polige SIMMs zur Verfügung stellen, davon habe ich eine ganze Stange. Die Umrüstung ist einfach durch Anlöten von Stiftleisten möglich. Wenn es der Platz her gibt und du noch 30-polige-SIMM-Sockel findest, könnte das Board auch auf den Betrieb mit normalen SIMMs umgerüstet werden.

FPU ist eher so ein "nice to have"-Feature - wie Arnulf schon schreibt, braucht die wenigste Software von damals welche. Wenn du preisgünstig einen 387SX irgendwo ergatterst, dann pack' ihn gern dazu - viel Software, die den wirklich braucht, wirds aber kaum geben

Was die Diagnose-Karten betrifft: Was haste denn da für eine? So ein ISA-PCI-Kombi-Teil?

Zitat von michi

[...]ein paar sind umständlicher (z.B. "alle optionen anzeigen" im Rechtsklickmenü im Explorer)

Das "klassische" Kontextmenü lässt sich unter Windows 11 auch wiederherstellen (so denn überhaupt gewünscht):
https://www.giga.de/tipp/windows-1…eigen-so-gehts/
https://www.deskmodder.de/wiki/index.php…fnen_Windows_11

Hab' ich bei meiner Testinstallation mit als Erstes getan - läuft bisher auch problemfrei. Werde ich wohl auch weiter nutzen, zumindest, solange die Programme, die ich nutze, keine Integration in das "neue" Kontexmenü bieten. Wie gut sich das nach einem Update auf ein neues Hauptrelease hält, weiß ich aber nicht.

Ansonsten finde ich, hat bei Windows 11 der Trend, in manchen Bereichen immer weniger direkt einstellen zu können, der auch schon unter Windows 8 und 10 bestand, weiter Einzug gehalten. Gerade solche Sachen wie die Anpassung der Taskleiste, des Startmenüs, der Fensterrahmen etc., die z. T. seit Windows 95 (Bei Fensterrahmen sogar weit davor) bis ins kleinste Detail einstellbar waren, sind mittlerweile wenn, dann nur noch versteckt irgendwo in der Registry zu bearbeiten. Dass ich abseits vom Anheften von Programmen an die Taskleiste mittlerweile mit Bordmitteln keine direkten Verknüpfungen mehr in der Taskleiste anlegen kann, find' ich bspw. doof. Ging zwar ab Windows 7 schon damit los, dass das nicht mehr Out of The Box dabei war, ließ sich aber noch einrichten - mit Windows 11 ist damit wohl jetzt gezwungenermaßen auch bei mir Schluss. Hab' da viele täglich genutzte Dokumente verknüpft, was wohl mit Windows 11 nimmer geht

Immerhin: Ich find' die Systemeinstellungen etwas besser gelungen als unter Windows 10 - auch wenn ich die verschachtelte Darstellung der mehreren Ebenen, wie es auch bei MacOS der Fall ist, nicht wirklich günstig gelungen finde. Trotzdem brauchste für Manches noch immer die alte Systemsteuerung.

Nochmal der OptiPlex 7070 Micro mit verschiedenen CPUs - und dieses Mal unter Linux auch mit Geekbench 6.3.0 statt der älteren 6.2.1. Daher ist zum Vergleich auch nochmal der i5 9500T mit aktuellen Ergebnissen mit drin:

Manfred Mann's Earth Band - For You

Kernel ist 'n aktueller drauf - heute erst wieder mal aktualisiert (weiß jetzt nicht genau, welche Version, aber auf jeden Fall neuer als 6.4).

Danke für die Links - schaue ich mir mal die Tage an. Ich glaub', ich muss auch meine damals von mrshadowtux adaptierte Installationsanleitung für Arch Linux auch mal wieder deutlich modernisieren - da war das Mounten der ganzen Partitionen und die Überführung in die /etc/fstab auch mit drin.

Zitat von Playitlouder

Damit sollte sich ne Partition mit dem neueren Treiber mounten lassen. "sudo mount -t ntfs3 /dev/sdb1 /mnt/Data"
In /etc/fstab dann wahrscheinlich ntfs3 als filesystem type angeben.

Hmm. In der /etc/fstab klappt das mit ntfs3 nicht - hab' aber auf die Schnelle nix gefunden, wie es sonst ginge. Ist wohl noch zu neu, finde da so einige (auch ältere) Verweise zu NTFS-3G, wobei da auch schon vor einiger Zeit wohl von ntfs-3g zu ntfs in der fstab gewechselt wurde.

Mal schauen - wird beim Testsystem ja eh alles neu aufgesetzt, da werde ich sehen, dass ich NTFS-3G gar nicht erst mit installiere.

Stimmt - hätte ich auch drauf kommen können. Da steht nur ntfs drin, also wirds wohl der Kernel-integrierte NTFS-Treiber sein.

Zitat von Arnulf zu Linden

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 …

Journaling wäre schon nice - aber gut zu wissen, dass exFAT mittlerweile auch unter Linux nutzbar ist.

Zitat von Arnulf zu Linden

Kernel 6 bringt auch einen nativen NTFS-Treiber mit, womit NTFS-3G obsolet wird.

Hab' gerade nochmal etwas nachgelesen: NTFS-3G ist scheinbar echt schon länger nicht mehr aktuell. Lt. Wikipedia ist seit Kernel 5.15 ein NTFS-Treiber von Paragon Software enthalten. Dann scheint's eher der integrierte Treiber zu sein, der da irgendwie was ausbremst. Ich muss mal bei meinem Test-System austesten, ob es da einen Unterschied macht, ob ich was auf eine NTFS-Partition auf der NVMe-SSD schreibe oder auf eine SATA-SSD.

In dem Zuge gleich 'ne Frage: Wie krieg' ich raus, über welchen Treiber auf ein Dateisystem zugegriffen wird? Die Installation auf dem A275 ist ja schon älter und habe ich zu einer Zeit eingerichtet, als Kernel 4.irgendwas aktuell war - da müsste der NTFS-Zugriff definitiv noch über NTFS-3G gelaufen sein. Vllt. ist da der alte NTFS-3G noch in Nutzung?

Hallöchen!

Perspektivisch plane ich, meinen Hauptrechner auf ein Dual-Boot-System mit Linux (vsl. Arch Linux oder evtl. auch Linux Mint) und Windows 11 aufzusetzen. Unter beiden Betriebssystemen will ich hier auf eine Partition lesend und schreibend zugreifen, auf der meine eigenen Dateien liegen.

Im "kleinen Format" habe ich das Ganze schon seit einigen Jahren auf meinem ThinkPad A275 hier am Laufen (mit Arch Linux und Windows 10 auf 'ner Crucial MX500-SATA-SSD, gemeinsame Partition mit NTFS formatiert). Allerdings habe ich hier gemerkt, dass die Schreibzugriffe beim Kopieren von Daten auf die gemeinsame NTFS-Partition extrem stark von der Geschwindigkeit her abweichen. Während ich unter Windows beim Kopieren von Daten auf die NTFS-Partition auf um die 198 MB/s komme, erreiche ich unter Linux mit ca. 55 MB/s nur gut ein Viertel der Schreibgeschwindigkeit. Das Lesen geht deutlich flotter. NTFS geht ja unter Linux über NTFS-3G, sodass ich davon ausgehe, dass die Performance unter Linux ein "Problem" mit NTFS-3G ist (wobei das eher ein "Komfort-Problem" ist, ich weiß).

Nun habe ich mal etwas rumgeschaut, was es noch so gibt, was unter Linux und Windows läuft. FAT32 wäre denkbar, fällt aber raus (alleine schon aus Legacy- und Dateigrößen-Gründen). Btrfs wird wohl unter Linux direkt unterstützt und für Windows gibts wohl mit WinBtrfs einen scheinbar stabilen Treiber - Erfahrungen damit habe ich aber keine.

Daher meine Frage: Hat jemand Erfahrungen bzw. Empfehlungen für andere Dateisysteme, die nicht gerade einen experimentellen Status haben?

Mein künftiges Testsystem für 'ne Parallelnutzung von Windows 11 und Linux am Desktop:

Ganz nice für eine 35-W-6-Kern-Non-SMT-Desktop-CPU

Das sind leider auch Registered DIMMs mit 3,3 V.

Speichertyp könnte EDO sein - leider hab' ich zu den SEC-ICs nix im Netz gefunden und die Beschriftung der µT-ICs des Moduls auf dem 1. Foto rechts oben ist leider verschwommen. Nach der Zugriffszeit-Angabe der SEC-ICs (-5) würde ich hier von EDO ausgehen - ich hab' hier Module von Sun Microsystems in meiner Ultra 5, bei denen die ICs eine ähnliche Bezeichnung haben (SEC KM48C8000BS-6 statt SEC KM48V8004BK-5). Die haben eine Kapazität von 128 MB mit insg. 18 ICs auf dem Modul (allerdings beidseitig).

Hilft also leider auch nicht weiter. Danke aber für's Nachschauen.

Oha, nicht mal mehr SDRAM? Also nix für 'n System vor 'nem Pentium 4 bzw. Athlon XP?

Zitat von Benjamin92

So etwas könnte ich tatsächlich haben, weil ich Teile eines Compaq Pentium Pro hier habe (Mainboard, CPU, Riser-Karte und eben auch Arbeitsspeicher). Ich suche es die Tage mal raus, die Module sahen wie SD-RAM aus, sind aber relativ groß (glaube sogar 1 GB).

Einzelne Module mit 1 GB für einen Pentium Pro wären aber extremst üppig - die "kleineren" Intel-Pentium-Pro-Chipsätze 450KX und 440FX unterstützen maximal 1 GB RAM, der "große" 450GX 8 GB. Die größten EDO-DIMMs, die ich habe, sind 128 MB - allerdings entweder 5 V Non-Registered (von IBM mit 36 ICs drauf) bzw. 3,3 V Registered (von Sun mit 18 ICs drauf).

Meat Loaf - Modern Girl

Tut mir Leid... Das wäre glaube ich was für meinen damaligen Compaq ProLiant 4500 oder 5000 gewesen, aber da hätte ich selbst auch noch genügend Module für.