S3 Vision 968 VLB Replica und Entwicklung des VirgeVL

  • Achso, 4MB ist auf PCI Karte, da müsste auch eine Register intialisiert werden, um 4 MB (nur bei PCI) zu nutzen könnte. Bei VLB ist wegen "SAUP2"-(Speicher)-Zugriff auf 2MB limitiert.


    Mit dieser ViRGE ROM gibt massive Störung in Textmode, aber VGA (320x200x8 ) ist einwandfrei. VESA auch nicht ganz OK.

    Ich vermute irgendwo mit Timing in Register, der nur für PCI oder 4MB Speicher bestimmt ist.



    4 MB Initialisierung ist nicht Ursache für Bildstörung, denn gerade ist EPROM mit modifizierte ROM in Löschgerät.

    (bei modifizierte ROM habe ich SR_A (EGA sequencer Register, 0xA) 6te Bit gelöscht, der 4 MB RAM bestimmt ist (OE1 oder RAS1))


    Foto kommt schon.


    @matze, danke , ich teste mal. Negativ, das gab gleiche Verhalten mit Pentium 3 und Virge PCI.


    Kleine positive Signal gibt: S3VBE20 erkannt Karte eindeutig als "Virge (VLB)" mit lineare Buffer ab 64MB.. (hä.. laut Schaltung sollte nich sein)

  • ROM_Geschichte ist erledigt, da Trio64V+ ROM auch ohne Problem dafür verwenden lässt. Auch mit Trio64V+ ROM erkennt S3VBE20 ihm als Virge (VLB) einwandfrei.

    Aber Ergebnisse mit VBE2.0 und Trio64V+ und Virge VLB macht mich keinesfalls zufrieden: Framebuffer-> Abstürze. Einzige Problem bei Trio64V+ VLB

    Bei Virge ist einfach weitaus schwieriger bei Software-Seite.. :/

    Ich löte mal halbe "frei konfigierbare" Decoder drauf, für Framebuffer_Zugriffe auf Trio64V+ Prototyp. Register-Adress-Decoder ist glücklichsweise nicht nötig.




    Arbeit an Layout für zweite Vorserie ist gerade zur grösste Teil abgeschlossen. Wie gesagt: Falls Virge eine Flop ist, dann lebt Karte als 765VL weiter.

  • Also ich schreibe keine schöne Nachrichten über VirgeVL.


    Ich dachte bisher, dass ich mit Trio64V+ Treiber Virge wenigsten in 2D Betrieb zum laufen bringen kann .

    Leider ist meine fatale Irrtum auf Arbeit aufgefallen, als ich Register-Appendix von beide pinkompatible Chip las. Virge hat 2D und 3D Register wie afrikanische Dörfer names 2D und 3D zusammengepackt , währendessen bei Trio64V+ (und ebenso Vision) mit 0x02E8 Adresse-Offeset Schema arbeitet.


    Lösung gibt es, der aber mit meine Software-Fähigkeit nicht zu machen ist.

    1,) komplett neue Treiber für Win9x schreiben

    2.) vorhandene ViRGE Treiber Win9x modifizieren (PCI-Funktion (Configspace-auslesen) wegstreichen bzw. Register-Zugriffe mit Adresse-Offset 0xA 0000 festlegen) Arschkarte ist gezogen, wenn Framebuffer mit Fenstersgrösse über 64kb genutzt wird.


    Ich habe sogar Überlegung "Ich kann Virge VL spendieren, mit eine Bedingung: Treiber entwickeln bzw. anpassen."



    Zweite keine schöne Nachrichten.
    Trio64V+ & ViRGE auf VLB Brett ist mit UM4981 AIO Brett ist nicht 100% stabil . (selten gelegentliche Freeze)

    Mit PAT48AV läuft es bombenstabil, aber in 1 von 10 Kaltstart wird ROM nicht geladet.

    QDI Brett hat damit wenigsten Problem, eher: sogar keine Problem.


    Das riecht nach unausgereifte elektrische Eigenschaft von Adresse/Daten-Leitung.

    Grüss

    Matt

  • Ja, das riecht nach Adressierung-Problem. Denn ich habe Debug-LED eingebaut, der leuchtet, wenn auf ROM zugegriffen wird. In Schlechtfall ist es aus geblieben. Nur dieser Brett hat Problem damit. Restliche 4 Brett hat keine Problem, wobei es bei lahme VLB Brett nur kurz ausprobiert ist.


    Ja, du kannst Frage raushauen, aber nicht öffentlich. Denn Virge VLB zieht Leute wie Motte und Licht an.

  • Das war mir klar das die wie verückt sein werden wenn du dich an eine Virge am VLB Bus machst..


    Das ist vermutlich das Projekt überhaupt.
    Genauso wie GUS Nachbau.

    Achwas ... da ist/war das Interesse tatsächlich überschaubar. Wobei ich das ja auch bewusst ab 'nem Punkt klein gehalten hab, damit mir die InterWaves nicht ausgehen ;)

    Da werden Commodore/Amiga Projekte deutlich schlimmer sein.

    SYS1: Asus VL/I-486SV2GX4, DX2 @ 66MHz, 1MB L2 Cache, 16MB RAM, 1GB CF HDD, Cirrus Logic 5428 VLB, ARGUS Prototype Rev. 02 #0, umschaltbarer Covox/DSS-DAC, 2x LPT, DOS 6.22 + Win 3.11

    SYS2: PC-Chips M912, PODP5V @ 100MHz, 1MB L2 Cache, 16MB RAM, 4GB CF HDD, MK-968VL-002, ARGUS Prototype Rev. 01 #2, DOS 6.22 + Win 3.11

  • Also, an VirgeVL wird weiter gearbeitet.

    Da Treiber eh angepasst bzw. neugeschrieben wird, gibt eine Entscheidung:
    Hardware-Option: freieinstellbare Adresse-Dekoder fällt weg.
    Ich werde Chip und DRAM um mehre cm nach links verschieben und möglichsweise löst das Problem mit 50Mhz FSB (nach links verschieben = kürzere Leitung zwischen VLB und Chip.)


    Zweite keine schöne Nachrichten.

    Trio64V+ & ViRGE auf VLB Brett ist mit UM4981 AIO Brett ist nicht 100% stabil . (selten gelegentliche Freeze)

    Mit PAT48AV läuft es bombenstabil, aber in 1 von 10 Kaltstart wird ROM nicht geladet.

    QDI Brett hat damit wenigsten Problem, eher: sogar keine Problem.

    Dieser schlechte Nachrichten müsste ich redivieren, zwar zur postitive Sinne


    UM4981 AIO ist wie UMPAIO eine Kackbrett ! Billigstmaterial verbaut und gelegentliche Freeze ist durch L2 Cache-Sockel-Wackler verursacht !

    Nachdem ich es nachbearbeitet habe: Läuft stabil. Es ist aufgefallen, dass es auch mit 968VL gleiche Verhalten zeigt.


    ABIT AN4R307 (auch eine Müll-Brett) hat gewissene Problem mit ROM-laden, aber nur in Verbindung von IDE VLB Controller. (Gleiche Problem beim PAT48AV ) Als ich auf DTC2278 VLB IDE Controller umstieg, ist dieser Problem verschwunden. Ich habe noch nicht beim PAT48AV ausprobiert.





    Mittweile bin ich froh, dass 968VL völlig stabil in alle Scheiss-Situation. Am meiste bin ich froh, dass 968VL mit 50Mhz FSB 0 Wartenzyklus stabil läuft. Das ist schon krass !


    https://wellenkino.de/matt/sonst/968_drag.gif

    (Mit 968VL bei 1280x1024 x 16 und 486 DX2-80 )

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!