Beiträge von Xaar

    Von Cirrus Logic gab's echt 'ne Menge an Grafikchips - wobei es da wohl auch recht potente Chips gab. Die CL-GD5401 ist btw. nicht mal eine "echte" Cirrus Logic - das ist 'ne umgelabelte Acumos AVGA1. Wenn ich das recht gelesen habe, hatte Cirrus Logic Acumos aufgekauft - und deren AVGA1 übernommen, da die schneller war als das Cirrus-eigene Design (CL-GD510/GD520) :D Die CL-GD5402 ist auch nur 'ne umgelabelte Acumos AVGA2


    Hab auch sone CL-GD Gurke im 386, glaub 5440? 5420?

    Nur Ärger mit.. Performance der Kiste fühlt sich Hart gebremst an unter Windows 3.11, also GDI Sachen. Alles was mit Video zu tun hat freezed die Kiste sofort, war aufm Congress echt ein Frust.

    Bestimmt 'ne GD5420 - die GD5440 war 'ne Low-Cost-GUI-Beschleunigerkarte, die GD5420 'ne Low-Cost-SVGA-Karte - ohne GUI-Beschleunigerfunktionalitäten (die kamen erst bei der GD5426/GD5428?).

    So eine GD5428 als ISA-VLB-Karte hab' ich hier aktuell noch im Nx586 drin. Ist ganz ok (sowohl unter DOS, als auch unter Windows) - aber 'nen Blumentopf gewinnste damit auch nicht :D


    Das Kompilieren des Linux-Kernels als "CPU & memory benchmark" … :D

    [...]

    28 MB passen aber nicht so recht auf eine Diskette. :trollface:
    TopBench müsste aber gehen, und "Landmark System Speed Test" verbirgt sich hinter …? LM60?

    So 'n Linux-Kernel-Back-Wettbewerb wäre echt interessant - aber auch langatmig und Energieintensiv je nach Rechnerausrüstung.

    Der Landmark System Speed Test ist im LM60 drin, jupp - "LM60" kurz für "Landmark 6.0" :D



    Das PCA-6134P hat dafür einen Jumper, Parity ein/aus, ganz easy. Tja hab ich jetzt auch so einen Jumper? Der Chipsatz kann Betrieb ohne Parity, es ist exakt der gleiche wie beim 6134P. Ich verhungere hier vor dem vollen Teller. Die 4Mx4 DRAMs haben dann noch nen komplett anderes Pinout, also solche als 4Mx1 missbrauchen (falls das überhaupt gehen würde?) ist auch fummelig. Aber evtl. die einfachste Lösung für mich..

    Also für ein "SBC-340" habe ich was gefunden - nur dürfte das nicht zu deinem Board passen - was so ein kleines "i" doch für einen Unterschied macht.
    Das ist bei solchen Industrie-Sachen leider immer 'n Frustthema, da dann noch was zu finden, wenn die Komponenten aus irgend einem Embedded-System stammen. :sideeye:

    Bootet das Board erstmal mit dem RAM, der mit dabei war (2x 1 MB?)?

    Cache hat der SBC scheinbar keinen drauf - und CPU-intern ist da beim Am386SX/i386SX auch noch nix dabei. Da wären dann eher die Ti/Cx486SLC was, deren interner L1-Cache pusht schon ordentlich.


    Benchmarks? Was nimmt man für 386er? In der Handhabung am einfachsten ist sicherlich ein Programm, dass von einer mit sys a: formatierten Diskette startet.

    Checkit hat 'nen Test für die ALU und die FPU integriert (als "Dhrystones" und "Whetstones") - das sollte bei 'nem 386-33 noch halberwegs gut nutzbar sein. Glaub' beim 486 war das aber z. T. schon am oberen Limit (weiß gerade nicht wo ich da immer Meldungen a la "Maximales Betriebsverhalten erreicht" erhalten habe). Sonst TopBench und den Landmark System Speed Test aus dem DOS Benchmark Pack von Phil's Computer Lab?

    Gut zu wissen. PC/104 find' ich zwar echt interessant von der Idee her, aber da alleine was in Richtung Grafikkarte zu finden, ist schon schwierig. Hab' selbst drei PC/104-Hauptplatinen hier (zwei mit 'nem Am5x86-P75, einen mit 'nem Pentium MMX, vermutlich 166 MHz), die z. T. sogar Ethernet OnBoard haben - aber Grafik ist da Fehlanzeige.

    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.

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

    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 8D Allerdings wirkt sich die höhere Taktung nicht überall positiv aus:

    20 MHz10,7844,01 MB/s38,16 MB/s13,64 MB/s24,22 MB/s
    25 MHz13,4855,42 MB/s47,69 MB/s17,08 MB/s30,53 MB/s
    33 MHz17,9974,53 MB/s63,61 MB/s22,93 MB/s41,05 MB/s
    40 MHz20,8068,48 MB/s76,39 MB/s23,25 MB/s37,11 MB/s
    50 MHz24,0952,47 MB/s95,44 MB/s21,96 MB/s31,17 MB/s

    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? :b5:

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

    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:

    Externer Inhalt www.youtube.com
    Inhalte von externen Seiten werden ohne deine Zustimmung nicht automatisch geladen und angezeigt.
    Durch die Aktivierung der externen Inhalte erklärst du dich damit einverstanden, dass personenbezogene Daten an Drittplattformen übermittelt werden. Mehr Informationen dazu haben wir in unserer Datenschutzerklärung zur Verfügung gestellt.
    - kommt also drauf an, ob an den RAM-Sockel alle Adresspins vom Chipsatz anliegen, oder ob eine fehlt.

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

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


    [...]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 :b2:

    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:

    Xaar64991642Intel Core i9 9900T8 Kerne, 16 Threads2,10 GHzDell OptiPlex 7070 Micro, LinuxLink
    Xaar60541549Intel Core i9 9900T8 Kerne, 16 Threads2,10 GHzDell OptiPlex 7070 Micro, Windows 11Link
    Xaar58011442Intel Core i7 9700TE8 Kerne, 8 Threads1,80 GHz-Dell OptiPlex 7070 Micro, LinuxLink
    Xaar54061343Intel Core i7 9700TE8 Kerne, 8 Threads1,80 GHz-Dell OptiPlex 7070 Micro, Windows 11Link
    Xaar56641509Intel Core i7 8700T6 Kerne, 12 Threads2,40 GHzDell OptiPlex 7070 Micro, LinuxLink
    Xaar53631435Intel Core i7 8700T6 Kerne, 12 Threads2,40 GHzDell OptiPlex 7070 Micro, Windows 11Link
    Xaar51181400Intel Core i5 9500T6 Kerne, 6 Threads2,20 GHz-Dell OptiPlex 7070 Micro, LinuxLink
    Xaar48391318Intel Core i5 9500T6 Kerne, 6 Threads2,20 GHz-Dell OptiPlex 7070 Micro, Windows 11Link
    Xaar37181179Intel Core i3 8100T4 Kerne, 4 Threads3,10 GHz-Dell OptiPlex 7070 Micro, LinuxLink
    Xaar35261122Intel Core i3 8100T4 Kerne, 4 Threads3,10 GHz-Dell OptiPlex 7070 Micro, Windows 11Link

    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.


    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.


    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.

    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?