[Suche] einen funktionierenden Weitek Abacus 3167 oder 4167

  • Hallo zusammen.


    Suche einen funktionierenden Weitek Abacus.

    Entweder ...

    1× Weitek Abacus 3167 - 25 Mhz

    ... oder ...

    1× Weitek Abacus 4167 - 25 MHz - alternativ auch 33 MHz


    zum Kauf, Tausch oder gar als Leihgabe für einige Monate.

    Angebote gern per PM.


    Besten Dank. Stephan

  • Kann man so sehen. Aber wenn man ein Mainboard hat, wo solch ein Sockel drauf ist, gillt für mich grundsätzlich folgende Devise: Nur ein bestückter Sockel ist ein guter Sockel. :prof:


    In dem Zusammenhang könnte ich für ein zukünftiges Projekt noch einen 4167 und einen Intel i860 (ohne XP) gebrauchen... (funktionsfähig natürlich!)

  • Habe ja nicht geschrieben, der Sockel (3167) wäre nicht "bestückt". Mainboards für 3167 und 4167 habe ich. Der Weitek-Sockel 4167 muss leider unbestückt bleiben, auf dem 3167 kann ich wahlweise einen...

    • Intel A80387DX-25 (installiert)
    • Cyrix FasMath CX-86D87-25-GP
    • IIT 3C87-25

    ... installieren.

  • Passt der 3167 in den 387-Sockel? (Das wusste ich garnicht...!)

  • Und wenn noch ein 2ter Chip auftaucht, hier wartet auch noch so ein Sockel auf Bestückung...

  • Gratuliere!

    Wie teuer war denn das Teil? *neugierig*

    Danke. Es war kein Schnäppchen, soviel sei verraten (>100) ::money::

    Die IC-Remarketing-Firmen wollen dafür i.d.R. etwas weniger, mit Auflagen an Mindestbestellmengen, üppige Versandkosten obendrauf (exkl. Zoll) und u.U. erfolgt Verkauf/Angebot einzig an Unternehmen. - Es läuft und ich bin zufrieden. Punkt. :)

  • SCO.... würg.

    Weniger wegen dem Unix als wegen dem Geschäftsmodell, andere vor die Gerichte zu zerren.


    Kann der 486 mit 64+ MB ausgestattet werden?

    Das ist fürs aktuelle OpenBSD die Mindestanforderung

    Das wäre ein richtiges OS, sicher und aufm aktuellen Stand.

    Keine Tinycore-Busybox-Spielerei.

    Ideal um die DOS-Platte übers Netzwerk zu sichern.


    Edit:

    Andererseits, könnte man das auch mit SCO oder Interactive machen?

    Und kann man SCO oder Interactive irgendwo downloaden oder ist das noch keine Abandonware?

  • 8-)


    Es läuft erst richtig wenn es unter UNIX läuft.


    >>>> SCO UNIX SVR3.2 Development System - Extension (Santa Cruz Operation) --> UNIX

    Auch wieder war! Folgt, ohne mich dabei auf einen zeitlichen Horizont festlegen zu wollen. 8)


    Kann der 486 mit 64+ MB ausgestattet werden?


    Edit:

    Andererseits, könnte man das auch mit SCO oder Interactive machen?

    Und kann man SCO oder Interactive irgendwo downloaden oder ist das noch keine Abandonware?

    Diese Hauptplatine (D534) unterstützt - soweit mir bekannt - bis 32 MB RAM. Das sollte für ein Net- oder OpenBSD (32Bit) für den Konsole-Betrieb genügen. Im PCD-3Msx/20 mit i386SX (!) habe ich 8MB RAM installiert und das geht irgendwie auch, nach Kernelanpassung - nicht toll aber wuselt vor sich hin.


    Im PCD-3M (mit Weitek 3167) läuft INTERACTIVE UNIX System V/386 Release 3.2, Version 4.1. Da gibt es gar eine Erweiterung (Facility) für den Weitek.


    Sollte dann auch mit SCO funktional sein. Die Pakete bzw. Installationsmedien dürften untereinander (System V, Release 3.2) eigentlich Verwendung finden, da das ABI (Application Binary Interface) keine verhindernden Abweichungen aufweisen sollte. Das werde ich demnächst probieren, mit Paketen von ISC + SCO. Beide sind bei archive.org, alternativ winworldpc.com, auffindbar.

  • 8-)


    Es läuft erst richtig wenn es unter UNIX läuft.


    >>>> SCO UNIX SVR3.2 Development System - Extension (Santa Cruz Operation) --> UNIX

    Für ISC INTERACTIVE UNIX hieß das Software Development System (SDS). Ich habe gleich mal beim UnixWare 1.0 PE in der VBox einen dry-run gefahren, da die Images 1.2MB Abbilder sind und mir kein 5.25" FDD nebst Disketten in HW vorliegt. Und was soll ich groß schreiben...


    Kernel Konfig mit Weitek-Module:



    SDS Install mit Markierung Math-Lib libm1167.a und C header für Weitek Abacus:



    Kein System ohne passenden Compiler/LinkEditor - LPI's New C ANSI C compiler macht es möglich:



    --> Schalter/Optionen -{1,3,4}167


    Stupides Hello-Programm übersetzt und gelinkt (erst mal ohne FPU-Routine), um zu sehen, das der Compiler grundsächtlich tut:


    Nächster Schritt: einige Beispiele, die auch in alten Benchmarks teilweise Verwendung finden umd ausgiebig von der FPU Gebrauch machen.


    So far

  • Wow, finden sich da evtl. auch Spuren einer Intel i860 Unterstützung?

  • escimo

    ich meine, mit FDFORMAT für solche Dinge auch schon 3.5"-Disketten auf 15 Sektoren/Spur formatiert zu haben (-> 1.2MB).

    Code
    1. Substituting diskettes of one density for
    2. diskettes of either a higher or lower density generally does
    3. not work. Data integrity cannot be assured whenever a
    4. diskette is formatted to a capacity not matching its den-
    5. sity.
    6. -M Writes a 1.2MB (3.5 inch) medium-density
    7. format on a high-density diskette (use only
    8. with the -t nec option). This is the same as
    9. using -m.

    Ich kann dies weder widerlegen noch bestätigen, da ich es bisher einfach nicht ausprobiert habe und ferner auch vollständig umgehen konnte: ich präferiere hierbei das Einbinden und Übertragen der Daten von Format <1200,ds,80,15,512> auf Format <1440,ds,80,18,512> -- Legende Format: cap(KB), sides, tracks/side, sectors/track, bytes/sec

    -- Test Vorabversion eines kleines Behelfsskriptes zur Einbindung und Übertragung der Daten von Image mit 1200KB auf ein Image mit Kapazität 1440KB , beides Dateisystem sysv. Bis jetzt alles i.O.



    Wow, finden sich da evtl. auch Spuren einer Intel i860 Unterstützung?

    Ich habe keine Referenzen auf i860 feststellen können.

  • Hier sind mal zwei Sachen, die eigentlich nur eines sind, in v1 und v2, die evtl. einen schönen Benchmark bieten.

    Auf einem halbwegs aktuellen Linux compilen sie zwar momentan nicht, aber das liegt wohl eher an einer Schreibweisenveränderung, meine Vermutung, die so ein alter Compiler evtl. noch kennt ( in gifcompr.c bei output() ).


    Sind Fraktale, die in ein GIF gerendert werden. Allerdings auf eine etwas seltsame Art - ist auch ganz instruktiv zum mal Anschauen ... ( return(point) direkt ins GIF für jeden Pixel einzeln ). Da da ja allerlei Multiplikationen etwa beim Mandelbrot eine Rolle spielen und außerdem noch auf die Bildgröße skaliert wird und man das dann auch einfach 25x hintereinander starten kann, sollte das einen schönen Benchmark im Sekundenbereich geben können.


  • Authentisches Kernighan & Ritchie (K&R) C. - Yeah!


    BTW: einige bekannte, alte Benchmarks und Demos kann man auch in MetaWare's High-C v3 Compiler-Paket finden, u.a.


    - LINPACK.C (SP / DP)

    - WHET_D.C (DP)

    - WHET_S.C (SP)

    - FBENCH.C (Raytracing Algorithmus)

    - MATMULT.C (Matrix Multiplikation)

  • Ja, witzig. Habe das mal angeschaut - nichts davon läßt sich ohne Umbau gleich benutzen. Muß wohl doch eine Weile schon durch die Welt "geistern".


    Eigentlich meckert er v.a. an den nicht vorhandenen Typendefinitionen in den Klammern der Funktionsköpfe herum. Schreibt man die da rein, geht es dann. Zumindest den FBENCH.C habe ich so zum Laufen bekommen.

    Das ist aber eher "unspannend", denn außer einer einzigen Zahl gibt der nichts aus.


    Dafür sind die WHETstone Teile ganz lustig - insbesondere das erste Testmodul hat anscheinend viel Einfluß aufs Gesamtergebnis. Und bei dem Test mit den Sprüngen (Modul 4), will man gar nicht wissen, was eine moderne CPU da eigentlich überhaupt draus macht ...

  • Das ist K&R C -Syntax, kein ANSI C. Die Typ-Definitionen stehen dabei zwischen Funktionkopf (...) und Rumpf/Body {...}. Ich probiere es die Tage selbst.


    Die Zahl mal verglichen mit den anderen Werten im Source? Auf welchem System und OS? Und schreibe jetzt net Xeon-W ;)


    Du hast auch nicht auf einen K&R-fähigen C Compiler zurückgegriffen oder nicht den erforderlichen Schalter/Option genutzt. Ich vermute mal GNU C Compiler. Version? Der Vergleich würde auch hinken, wenn man DOS und UNIX vergleichen würde. Allemal interessant. :OK:


    Das Gewussel hatte ich auch beim Übersetzen von Mesa unter SunOS 4.1.x, denn Mesa wollte per Anleitung einen ANSI C Compiler. Der on-board, K&R cc geht da wohl net (nicht probiert).


    https://sonnenblen.de/index.ph…61.msg38417.html#msg38417

  • Das ist K&R C -Syntax, kein ANSI C. Die Typ-Definitionen stehen dabei zwischen Funktionkopf (...) und Rumpf/Body {...}.


    Was auch seinen gewissen Charme hat.

    Aus einer logischen Perspektive macht das sogar relativ viel Sinn, weil sie dann an der gleichen Stelle stehen, wie die späteren, die innerhalb des Blocks noch kommen.


    Und dem Compiler wäre es ja wohl egal, ob der sich die Infos innerhalb zweier Klammern holt oder zwischen schließender Klammer und Blockbeginn findet. Der wäre damit evtl. sogar schneller. Es ist halt wohl die Lesbarkeit für Menschen, die das hat in die Klammern wandern lassen.


    Was mich aber v.a. erstaunt hat, daß der die Sachen nicht unbedingt "vordeklariert" haben will. Manches - in dem Fractalprogramm - läuft modern nur, wenn man es entweder umkopiert an eine Stelle weiter vorn, so daß die Funktionen bekannt sind, oder eben die Funktionsköpfe einmal alle "klassisch" nach oben reinkopiert, quasi als integrierte Header Definitionen. Das scheint das K&R einfach per default zu machen - vermutlich so wie ein 2-pass Assembler auch erstmal suchen geht, was da alles auf ihn zukommt, bevor er sich der eigentlichen Sache annimmt.


    Wenn Du auf die Schnelle einen Compiler-Switch weißt, mit dem man den gcc auf sowas umschalten kann ... schreib mal hier rein.



    Zu den FBENCH.C Werten ... die Liste ist wirklich lustig. Interessante Untereschiede. Was aber erschreckend ist, daß hier auf einem 2.4GHz AMD unter debian mit gcc in halbwegs aktuell (4.9.2)

    als Werte für "normal" 6698 und oft eher noch weniger, bzw. für den Modus (#define INTRIG) mit den expliziten eigenen Fließkommaberechnungen "10395" herauskommen.

    Natürlich nur auf einem Core, aber schon wenig - im Rahmen der Liste und dessen, was ich da zuvor erwartet hätte.