486er mit Problemen

[SX1Freak]

Ja, Dos4gw hatte ich auch gleich dran gedacht. Autoexec/Config Einstellungen waren da nicht mehr so entscheidend.......

386DX40/TsengET4000 :-)

 

[Nigg]

Moin,

ich habe nicht alles bis ins Detail gelesen, aber ich wollte darauf hinweisen dass eine Cyrix CPU verbaut ist. Bitte erwartet nicht die völlige Kompatibilität und Stabilität eines Intel-Pendants aus dieser Epoche. Ich hatte damals selbst zwei verschiedene Cyrix-Modelle und da machte Windows selbst teilweise schon Probleme. Ob das nun an der Kombination Mainboard/Chipset/CPU lag oder an der nicht in Gänze gesicherter Kompatibilität, vermag ich nicht zu sagen, aber die Software war eben meist mit Compilern gebaut, die auf Cyrix an der Stelle wenig Rücksicht nahmen.

 

[stickedy]

Die Cyrix 486er waren an sich reine Klone von den Intel-Prozessoren. Da gab es keine Probleme. Probleme haben nur die späteren 5x86 und 6x86 gemacht bzw. machen können. Aber Doom und Duke Nukem haben da sowieso nicht dazu gehört, das hab ich beides mit einem Cyrix 5x86 gespielt.

Ich tippe auch auf einem Problem mit der Soundkarte o.ä., also IRQ oder DMA Adresskonflikt.

Edit: Ich muss mich korrigieren, die Cx486 waren doch keine Klone, sondern Eigenentwicklungen. Probleme dieser Art sind dabei aber trotzdem nicht zu erwarten...

 

[MR2]

Hab die SB16 bekommen. Alte Maestro Treiber ausgeklammert, neuen PNP Manager und SB16 Treiber installiert. Funktioniert soweit gut unter DOOM. Gleiches Fehlerbild. Das es kaum an der Soundkarte liegt hab ich mir schon gedacht, aber ich wollte eh immer eine für die Wand haben:-)

Ich tippe wie gesagt darauf, dass ein RAM-Chip einen weg hat. Um das zu verifizieren empfehle ich "checkit3/4" und den Ramtest mehrmals durchlaufen zu lassen. Wenn der OK ist, dann lass ggf. mal 3dbench eine weile laufen, ich glaube nicht an das NT, vielleicht ehr hat das Mainboard ein paar aufgeblähte Kondensatoren....checke das mal.

Ich hab mir mal das Checkit gezogen, auf die HDD kopiert und ausgeführt.
Sämtliche Benchmarks laufen sauber durch, RAM mehrfach getestet, Mainboard komplett geprüft. Ohne Fehler.

Ich hab ja das Standard Bios geladen. Ist da noch was auffällig?
Dieses Local Ready Delay hab ich testweise schonmal auf Delay 3T geändert gehabt. Denke müsste die Latenz anheben.

Wenn das Bios so passt...Was bleibt mir noch?
1. Netzteil tauschen. (liegt nahe bei dem Alter!) Gibt ja Adapter ATX auf AT. Aber bei dem Schalter bin ich mir nicht ganz sicher wie das gelöst wird..
AT Netzteile neu, für Industrie scheint es nicht mehr zu geben.

2. Grafikkarte tauschen.


3. Außerdem würde ich mal das Board bzw. die Elkos genauer anschauen. Schade das es keine neuen 486er Boards gibt, neue C64 und Amiga Boards sind kein Problem, aber alte X86er leider nicht.. Ich würde eins kaufen :-)

 

[mchawk777]

Naja, wenn ich ChatGPT etwas glauben schenken darf, dass ist der Cyrix 486er nicht ganz so 100 %ig IBM-PC-kompatibel:

Cyrix-CPUs, vor allem die frühen 486er und deren Klone (wie der Cx486S, Cx486DX, 5x86 usw.), hatten kompatibilitätstechnisch so ihre Eigenheiten – besonders in Kombination mit DOS-Extendern und manchen Speichermanagern wie EMM386.

Warum Cyrix problematisch sein kann:

1. Nicht ganz 100 % i486-kompatibel:
   
   • Besonders was bestimmte Prozessorbefehle oder Cache-Handling betrifft, was z. B. DOS4GW oder Protected-Mode-Anwendungen irritieren kann.
2. Fehlerhafte oder fehlende FPU-Emulation:
   
   • Manche Versionen hatten keine FPU (wie der Cx486S), und DOOM mag das zwar umgehen, aber DOS4GW oder andere Module könnten trotzdem auf Probleme stoßen.
3. Timing- und Cache-Issues:
   
   • Gerade mit VLB-Boards und "exotischeren" Chipsätzen (OPTi, UMC etc.) kann das zu kuriosen Abstürzen führen.
4. Nicht optimal unterstützte A20-Gate-Schaltung:
   
   • Das kann HIMEM oder DOS4GW aus dem Tritt bringen, wenn es nicht sauber gemacht ist.
5. EMM386 kann sich auf Cyrix anders verhalten:
   
   • Es gibt Dokus, die explizit vor der Verwendung von EMM386 auf Cyrix-CPUs warnen, da das Zusammenspiel mit bestimmten Chipsätzen oder BIOS-Versionen zu Speicheradressierungskonflikten führen kann.

---

Was man da machen kann:​

• Testen, ob DOOM im Real-Mode mit nur HIMEM läuft, wie schon gesagt – am besten ohne EMM386.
• CPU-ID prüfen, falls möglich – manche Cyrix-CPUs hatten "Hidden Pins" für Kompatibilitätsmodi (z. B. die berühmten „WB/WT“-Jumper für Cache).
• DOS4GW gegen einen anderen DOS-Extender tauschen, z. B. DOS32A – wäre aber eher was für Bastler.

 

[MR2]

Die Spiele liefen damals aber auch auf cyrix CPUs problemlos. Soweit ich das in Erinnerung habe, hatten einige Kumpels diese CPU und niemals Probleme.
Zumindest hängt, resetet der Rechner bei Doom, Duke, aber auch Monkey Island. Manchmal nach 5 Sekunden, manchmal 2 Minuten.
Bevor ich die CPU tausche, erstmal das Netzteil. Ich denke, das ist wohl am naheliegendsten.
Ich hoffe es ist nicht das Board....

Will die CPU natürlich nicht ausschließen, aber ich glaube nicht. Dx2 und dx4 hab ich zumindest noch in der Sammlung:-)

 

[mchawk777]

Naja - die Fehlermeldung deutet halt auf RAM-Probleme hin. 🤷‍♂️
Anyway: Es wird eh im Ausschlussverfahren enden - da kannst Du natürlich auch mit Netzteil und CPU anfangen. 😉

...oder mal Memtest zu Rate ziehen? 🤔

 

[MR2]

Memtest hatte ich eine Version gezogen, die ging überhaupt nicht. Ich versuche das aber noch einmal.

Der RAM Tester in dem "checkit" lief immer sauber durch.

Hab halt schon verschiedene RAM Module durchprobiert. Komplett verschiedene. Bisher liefen alle. Der Fehler änderte sich nicht.

Memtest probier ich noch mal...


Weiß jemand wie ich den E/A Schalter am ATX Netzteil anlöte? Adapter gibt's ja.
Gibt es Netzteil Empfehlungen?
Oder ich finde jemand der das Netzteil recappt.

--------
Hab n ATX zu AT Adapter bestellt. Mit integriertem Schalter.

Ich berichte...

 

[stickedy]

Was mir gerade einfiel: Ist der Prozessor richtig gejumpert? Also 33 MHz x 3 und nicht 50 MHz x 2? 50 MHz FSB lassen den VesaLocalBus idR instabil werden und das wiederum könnte die Probleme verursachen.

Edit: und nochmal zum Prozessor, STMicro hat den Prozessorkern bis 2008 gefertigt und verkauft für embedded Systeme, das hätte wohl kaum funktioniert wenn es Inkompatibilitäten gegeben hätte, so dass noch nicht Mal Doom funktioniert

 

[MR2]

Mal ganz vorsichtig gesagt. Im Moment läuft er...
Hab jetzt ne halbe Stunde Doom gespielt. Mit der sb16 hab ich Musik nebenbei, das hatte ich mit der terratec nicht. Da war nur soundFx zu hören.

Ne S3 Grafikkarte hab ich noch gehabt, verbaut und nach wenigen Sekunden abgestürzt...
Dann ins BIOS. Eine Einstellung gemacht, seitdem läuft er.
Muss dann erstmal ne leere CD suchen, Wolfenstein passt leider nicht auf Diskette:-)
Prince of Percia dagegen schon. Von Disk auf HDD kopiert, gestartet und läuft. Herrlich!
Wie in alten Zeiten...

Erstmal DOS Spiele zusammen suchen. Ich trau mich noch nicht zusammen zu bauen 😜
Aber erstmal sieht's gut aus!

Xenon2 hatte keinen Soundblaster Sound? Wusste ich gar nicht!
---------------------
https://stackoverflow.com/questions/27087912/write-back-vs-write-through-caching

Lösung:
hatte "L1 Cache Update Scheme" von Wr-Back auf Wr-Through gestellt.
"The L1 cache WT/WB option in the BIOS is controlling the chipset and for software control of WB mode on Cyrix CPUs."

"Write-Back is a more complex one and requires a complicated Cache Coherence Protocol(MOESI) but it is worth it as it makes the system fast and efficient.

The only benefit of Write-Through is that it makes the implementation extremely simple and no complicated cache coherency protocol is required."

https://forum.huawei.com/enterprise.../667215004455288832?blogId=667215004455288832

BACKGROUND INFORMATION​

The cache mechanism includes write-through and write-back.



Write-through: Write is done synchronously - both to the cache and to the backing store.



Write-back (or Write-behind): Writing is done only to the cache. A modified cache block is written back to the store, just before it is replaced.



Write-through: When data is updated, it is written to both the cache and the back-end storage. This mode is easy to slow in data writing because data has to be written to both the cache and the storage.


Write-back: When data is updated, it is written only to the cache. The modified data is written to the back-end storage only when data is removed from the cache. This mode has fast data write data will be lost if a power failure occurs before the updated data is written to the storage.

​

Aber erstmal weiter testen...

 

[Nigg]

Wie gesagt, ich hatte mit Cyrix damals arge Probleme. Ich war zwar noch jung aber habe schnell diverse Unterschiede zu Intel 486DX2 oder K5 erkennen können was das "Verhalten" angeht. Die CPUs an sich mögen auch gar nicht alleinig die Ursache gewesen sein. Die oft mit Cyrix kombinierten Chipsätze von VIA aber beispielsweise schon. Und eben die Software.

 

[xxMuahdibxx]

@Nigg da geht es aber um die cyrix CPUs ab 5x86er... Oder K6..

Die 486er waren nicht auffällig.

 

[Nigg]

Ich weiß nicht was du mit "da" meinst, ich habe doch ganz klar geschrieben dass sowohl die früheren als auch die älteren Klone Kompatibilitätsprobleme hatten. Es wurde zuletzt eben nur unerträglich.

Der 486DLC(?) machte schon alleine wegen dem Cache Probleme und so ziemlich alles was Timing-relevant ist, zickte rum (quasi alle performancekritischen Games). Dazu kamen Sachen die gar nicht liefen, weil undokumentierte CPU Features. Das weiß ich deshalb weil meinem alten Herrn seine frühe CAD/Hauseinrichtungs-Software Arcon eben nicht mehr lief, nachdem er auf Cyrix war. Quasi alle nicht-VIA-Boards brauchten Jumper-Einstellungen oder BIOS-Updates damit sie überhaupt annähernd rund liefen.

Ja, an und für sich funktionierten sie. Aber nimm mal nen billo-Chipsatz von VIA dazu, irgendeine pseudo kompatible Sound Blaster Karte, S3 oder Diamond Grafik und Netzwerkkarte dazu und du hast eine Möhre, die damals zweifelsohne so verkauft wurde, aber schon nach kürzester Zeit einfach nicht mehr stabil lief. Das wird Dekaden später nicht besser sein.

 

[xxMuahdibxx]

VIA hatte gar keine Chipsätze für den 486er ... daher meine Frage .
Ach doch die Wiki kennt einen.

Aber die Cache Problematik war eher was im professionellen Umfeld und nicht beim spielen.

 

[Nigg]

Äähm, VIA hat sowohl für i386 als auch 486 Chipsätze gebaut, VIA Pluto usw. Und auf das "professionelle Umfeld" bezogen: Für die meisten Heim-PCs waren diese Anwendungen ja "anspruchsvoll". Es brauchte keinen CAD oder Mathematik-Kram um da in Probleme zu geraten. Nur um das mal zu untermauern, habe ich nun auch mal recherchiert:

Wing Commander III - Kackt ab mit Cyrix im Ladebildschirm
Quake - Sobald L1 Cache aktiviert ist stürzt Quake direkt ab, ohne Cache stabil
Fast Attack Submarine Warfare - stürzt sporadisch ab, weil es AMD und Cyrix als 486DX erkennt obwohl diese keine FPU haben. Spiel kackt sporadisch ab, lädt oder startet nicht.
Formula 1 96 - Bricht ab wenn Cyrix drin ist

Ich denke das sollte an populären Beispielen reichen!

Dazu kommen halt etliche Anwendungen, die man als professionell bezeichnen kann oder auch einfach nur als "neu", z.B. MIDI-Software und Sequenzer, die auch nicht liefen.

Noch mehr? OK. Hier mal ein paar Apps und bekannte problematische Hardwarekombos:

Soundblaster AWE64 - lief nur mit FPU uneingeschränkt
Photoshop - ebenfalls wegen FPU
Linux - weil bei den ersten Cyrix 6x86 die CPUID-Instruktionserkennung deaktiviert war
Futuremark / 3DMark 99 - wegen CPUID und RTSC-Instruktionen
Autodesk - Hänger und Abstürze, Hersteller empfahl auf Pentium zu wechseln oder Patches zu suchen


Allgemein hat die Community davon einige Sachen gepatched, aber es war eben Frickelig und ohne Internet kam man an vielen Stellen sowieso nicht weiter.

Ich denke, das genügt um meine Aussagen zu untermauern.

 

[cptlars]

Bei sonem alten Teil würde ich wohl erstmal die Wärmeleitpaste erneuern... die dürfte inzwischen ausgetrocknet und hart sein.

Ich würde auch sonst erstmal alle überflüssige Hardware rausnehmen und dann testen.
8 MB RAM sollten beim 486er für den Anfang reichen.

Je weniger Fehlerquellen du hast umso besser kannst du Fehler identifizieren.

 

[xxMuahdibxx]

@cptlars die Teile sind noch mit passiven Kühlkörper ausgestattet... Sorry waren bei den größeren schon aktiv..

Wärmeleitung war da noch nicht das wichtigste..und wenn hätte ich eher Angst das der verklebte Kühlkörper Teile der CPU mitreißt.

 

[MR2]

@cptlars

Problem ist behoben, siehe ersten Thread.
Jetzt kein Absturz mehr.

Habe gemerkt das das Laufwerk keine CD-RWs liest, die habe ich noch da...
Mal paar CDRs suchen

 

[stickedy]

Welchen Chipsatz hat denn das Mainboard? Mit WriteThrough statt WriteBack verliert man einiges an Leistung. Normalerweise sollte WriteBack bei nicht-Intel-Chipsätzen mit den Cyrix-Prozessoren laufen.

Btw: AMD hat zur 486er-Zeit nur die Intel-80486 kopiert, da ist quasi Null-Eigenentwicklung drin. Auch der 5x86 war nur ein umbemannter 80486. Den Pentium durfte AMD nicht mehr kopieren, deswegen kam der K5 (viel zu spät) als Eigenentwicklung. Den K6 hat man eingekauft mangels eigenem Design.
Cyrix hingegen musste alle Prozessoren von grundauf selber entwickeln und dabei die Intel-Patente umgehen, z.B. beim 5x86 (da ist intern nix vom 486er übrig) den Speicherzugriff taktversetzen. Und ähnliche Späße. Deswegen kommt es bei den 5x86 und 6x86 gerne Mal zu Problemen, die aber im Grunde lösbar sind, instabil ist da nichts. Und die Stabilität gilt genauso für den Cx486 (auch wenn Wing Commander III tatsächlich nicht läuft)!

 

[xxMuahdibxx]

Schön das es so geklappt hat..

ist ja auch einiges an Zeit her ;-)