TI486DLC-40 & ULSI DX/DLC 40MHz: Floating point exception

Ist der Koprozessor überhaupt mit 486er-Prozessoren kompatibel, selbst wenn er synchron mit 40 MHz zur CPU läuft? Ich finde den nur als ULSI US83C87. Auf der anderen Seite fügte die 80486-Familie auch keine neuen Fließkomma-Instruktionen hinzu.
Ansonsten gibt es hier ein Diagnose-Programm, das die Kompatibilität einer Fließkomma-Einheit testet: https://github.com/AstroVPK/paranoia (https://github.com/AstroVPK/paranoia/archive/master.tar.gz)
Zum näheren Debugging z. B. mit GDB kann man dieses mit -g -DNOSIGNAL bauen, damit es nicht eigenhändig Floating Point Exceptions abfängt.

Man sieht, die Dinger sind immer noch so unbekannt wie früher. Für Schnellleser: 386er Sockel, 486 angelehnte Instruktionen und ein sehr kleiner Interner Cache. Abar kein Co Prozessor.

Alles was ich je von den Dinger gelesen habe, war immer mit Problemen behaftet. Viele Boards waren nie angepasst, was heute alles mit Microcode und BIOS/UEFI Update bei einer neuen CPU Generation kam, kannten die Boards damals nie.

Hast du Testweise die Caches deaktiviert? Nen i386er läuft mit dem 387 Problemlos? Kann auch sein, das Instruktionen abgefragt werden, die CPU dann als 486er eingeschätzt wird, und dann aber nicht voll kompatibel ist. Beim 486er gabs ja nie nen CoProzessor. Alle SX schalteten sich komplett ab, wenn ein 487er eingebaut war, weil der ja nen DX mit 3 Pins vertauscht war.

Wenn man damals nicht irgendwas optimiertes für nen DLC hatte, machte das Ding mehr Ärger als Nutzen.

Interessanter Thread !
Nun, ich hab ein AMD 386DX40 Board da samt ich glaub auch ein ULSI-Co Pro.
Interessanterweise war der i386DX-25 mit Cyrix Co Pro den ich mal hatte - schneller als der AMD DX-40, was auf einen fehlenden Cache schliessen lässt.
Welche Cachearten waren da so verbaut ?? Meint Ihr, ich kann da auch L2 Module von 486er PCI Boards nehmen ??
Ja ich weiß, Ferndiagnosen dieser Art sind ohne Foto schwierig.
Stell ich später mal rein, aber mal vorab als Frage..

Hatte auch schon im Verdacht, dass die FPU überhaupt nicht richtig eingerichtet gewesen ist.

Zitat von Arnulf zu Linden

Für den ersten Anlauf: paranoia auf einem anderen 386er mit gleicher Softwarebasis – Geht auch ein stärkerer ia32, oder baut der Compiler dann Scheiße wegen des moderneren Prozessors oder neuerer Software? – bauen und dann auf der Problemkiste laufen lassen?

Es wäre vermutlich nicht so leicht gewesen. Das Programm an sich kann man leicht für die Zielplattform kompilieren (-march=486 -mfpmath=x87), aber erstens passt die C-Bibliothek wohl nicht zusammen und zweitens benutzt diese vermutlich immer noch die falsche Linux(-2.6)-ABI, falls man diese statisch kompiliert. Und erst eine Toolchain für uClibc zu bauen, was durchaus selbst noch Linux 2.2 unterstützt, wäre definitiv nicht zielführend gewesen.

Ok, ich hab das Board rausgefischt. Hm hab keine Ahnung, welches Board das ist, aber vielleicht erkennst du Merkmale Arnulf zu Linden ?
Die Bios-Batterie hatte ich mal abgelötet, damit sie nicht auslaufen kann.
Die Cache Module sind aufgelötet, aber für was ist der eine freie Steckplatz unterhalb der CPU?

Übrigens zu deinem anderen Thread drüben: Jetzt siehst, wofür eine Handykamera gut sein kann.

PS: Ich hab's !
http://www.amoretro.de/2012/08/pc-chi…c-tauglich.html
Ok, der Steckplatz Namens U32 versetzt das Board in den Write-Back Mode, was mehr Speed bedeutet. Hab gar nicht gewusst, dass es das bei 386ern überhaupt schon gab.
http://stason.org/TULARC/pc/moth…-386-M-321.html
Meine PC-Chips M321 Revision 2.3
http://www.amoretro.de/2013/01/pc-chi…otherboard.html

Wer kennt das noch ?
Ein DTK PEM-2500 i386-DX 25 Board mit Cyrix FPU.
Passt nur in einen Highscreen AT Big-Tower oder ähnliches rein, weil ist viel grösser als der Baby AT-Standard.
War bei mir 1996-1998 in Betrieb. Das war so flott, so das ich damit C&C1 tadellos spielen konnte.
Was hatte das als Mindestvoraussetzung? Glaub 486 DX-2 66.