S3 Vision 968 VLB Replica und Entwicklung des VirgeVL

  • Sicher das dass Rom die Virge nicht für PCI initialisiert?


    Und was ist mit den 4 MB die du oben erwähnt hast, ich dachte die Virge kann nur 2MB wenn sie per VLB angebunden ist?

    Von allen Dingen auf Erden ist die Intelligenz am gerechtesten verteilt: Jeder glaubt, er hätte genug davon.

  • 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)

    3 Mal editiert, zuletzt von matt ()

  • 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.

    Einmal editiert, zuletzt von matt ()

  • 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

    2 Mal editiert, zuletzt von matt ()

  • Hmm, ich frag mal drüben bei den Programmierern im "alten" Forum an.


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

    Problem in der Rom Adressierung? Sollte doch genauso sein wie bei der 986?

    Von allen Dingen auf Erden ist die Intelligenz am gerechtesten verteilt: Jeder glaubt, er hätte genug davon.

  • 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.

  • 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 )

    Einmal editiert, zuletzt von matt ()

  • Was Treiber angeht hat sich bisher nur einer gemeldet - leider mit Absage, sind halt Dosprogrammierer....

    Von allen Dingen auf Erden ist die Intelligenz am gerechtesten verteilt: Jeder glaubt, er hätte genug davon.

  • Also, es wird auch eine Änderung: Trio-Variant wurde aus VirgeVL abgesplittet und Trio-Variant wurde heute beim jlcpcb hochgeladet.


    Warum absplittern: Trio-Variant ist quasi fertig bis auf ROM-Anpassung. Wenn Design "safe" ist, dann kann ich Trio64V+ Sammelbestellung starten. Das mit Virge wird halt länger dauern. Das Trio64V+_Sammelbestellung wird in neue Jahr gestartet und ich eine Versprechen einlösen kann. Ob ich gleiche Platine für Virge nutzen kann, steht im Fragenszeichen.


    Ich habe jetzt funktionstüchtige S3d Game & Demo, der auf PIII-900 mitsamt Virge PCI läuft.

    Auf VLB -Karte fiert der ein, sobald S3d läuft. Ich habe eine Verdacht: S3d Demo und Game holt Adresse (= Location ) von lineare Framebuffer. Dank ROM gibt falsche Info mit Location von Framebuffer. Besagte Problem gab auch mit S3VBE20 und lineare Framebuffer: exkat gleiche Verhalten. Noch habe ich ROM nicht 100% durchgeblickt (ROM für Virge ist modifizierte Trio64V+ , beide hat gleiche Register bei VGA und EGA bis auf ID-Kennung)


    Ich muss nochmals in Datenblatt lesen, ob auch VLB Variant auch lineare Framebuffer mit bis zu 4/8MB-Segment (bei VLB gibt nur 2MB RAM) möglich ist. Falls nicht -> das erklärt, dass ViRGE VLB eine Totgeburt ist.


    Demo ? Ich fand zufällig S3DTK 2.6 (= S3d Toolkit, Entwicklungsumgebung mit Quellcode) , ich habe das auch Matze dieser Toolkit gegeben. Framebuffer-Adresse-Lese-Mechanismus ist leider in Library ohne Quellcode versteckt. Ich überlege, ob ich doch meine Software-Entwicklung verbessern müsste. (ich habe einige Software geschrieben, grösste Software war Firmware-Programmer über GPIB für Tektronix Digital-Oszilloskop. Allgemein ist meine Software-Fähigkeit eher niedrig.)


    Also, keine schöne Nachrichten, oder ? Aber ich gebe den nicht gleich auf.

    2 Mal editiert, zuletzt von matt ()

  • Also, ich habe gestern Datenblatt von Virge gelesen, auch in VLB Modus ist lineare Framebuffer bis zu 4MB (Fenster) möglich.

    Das ist erfreuliche Erkenntnisse.


    Dafür müsste ich Leiterplatte-Design speziell Adresse-Dekoder massiv umbauen.

    Änderung/Lösung :

    1.)SAUP2 (Register-Zugriffe) von 1GB zu 0xA0000-0xAFFFF umziehen und mit 16MB Offset zur SAUP1-Adresse hinzufügen.

    2.)SAUP1 (Speicher-Zugriffe) zur 64MB (oder andere) umziehen und VGA-ROM-Funktion deaktiveren, MMIO komplett deaktivieren.

    3.)VGA ROM-Zugriff per Konfig-Widerstand deaktiveren.

    4.) VGA ROM wird von eigene Adresse-Decoder gesteuert, statt von GPU. (leider funktioniert ROM-Zugriffe nicht ohne Abhängigkeit von SAUP1)

    ggf. VGA ROM modifizieren mit gernell deaktivierte MMIO.


    Ich werde aktuelle VirgeVL Prototyp modifizeren und eine kleinere Platine mit Adresse-Decoder (0xA0000) ist fertiggestellt. Platinen-Daten ist zur jlcpcb (über Kumpel hochgeladet)

    Ergebnisse ist leider erst in ca 2 Wochen zu rechnen (Platine_Fertigung und Versand dauert.)


    Platine mit dieser Änderung ist auch für Trio64V+ verwendbar, inklusive Betrieb mit S3VBE20 lineare Framebuffer-Zugriffe.


    Ich hoffe, dieser grosse Fix löst Problem mit lineare Framebuffer und S3d-Software läuft nun.


    Erklärung, warum grosse Änderung nötig ist.

    Trio64V+/ViRGE hat in VLB-Modus keine vollständige Adresse-Eingang. d.H. nur unterste 8MB Adressebereich wird direkt dekodiert. (Adresseleitung bis A22 ist vorhanden)

    Restliche Adresseleitung von A23-A31 ist nicht vorhanden und ist durch 2x Eingänge SAUP1 und SAUP2 ersetzt.

    SAUP1 = Speicherzugriffe

    SAUP2 = Registerzugriffe.


    Bisherige Lösung (abgeschaut bei STB Powergraph64 VL ) sieht so aus, dass SAUP1 in 0-8MB Speicherbereich wirksam ist.

    Ihr würde sagen: Es kollidiert mit System-Speicher. Ja, richtig ! Hier wurde oldMMIO aktiviert, der VGA&EGA-Register ins Adressebereich 0xA0000-0xAFFFF einblendet. Das ist "über 640kB Speicherbereich" (genauer 640-704kb Bereich). Oft ist dieser 384kb Speicherbereich für dieser Zweck und Boot-ROM (VGA Bios dito ) freigehaltet.


    Das bedeutet: Es geht, aber lineare Framebuffer ist unmöglich, denn es kollidierte mit Systemspeicher.

    Lösung: Man verschiebt SAUP1 Adressebereich zur andere Bereich, wo Systemspeicher nicht mehr drin ist. Das ist Lösung 2.)

    Next Problem: VGA ROM funktioniert nicht mehr -> System startet ohne Grafikkarte/hängt fest. - > Lösung 4.)

    Next Problem²: Zugriffe auf lineare Framebuffer bei 768-832kb könnte passiert, dass Rechner einfieren bzw. langsam. Grafikchip bremst System aus, wenn es auf ROM zugegriffen wird. (Ist gewollt , weil ROM langsam ist) -> Lösung 3.)


    Aber mit nur verschieben von Speicherzugriffe-Adresse wird Karte nicht starten, denn MMIO-Funktion greift ins "Leere"

    D.H. Registerzugriffe SAUP2 in Adressebereich einblenden , wo "oldMMIO" arbeitet. -> Lösung 1.)



    Ich sterbe ViRGE PCI Kompatibelität (ist auch wichtig für S3d Anwendung) an -> Lösung 1.) bei Punkt mit 16M Offset.

    Denn PCI hat feste Adressierungsschema für Framebuffer und Register. Register-Adresse hat 16 MB Offset zur Framebuffer-Startadresse. Bei SAUP1/2 Zugriffe habe ich völlige Freiheit über Offset. Um Kompatibelität zu wahren, ist 16MB Offset zwingend.

    Bloss kann PCI-System während Betrieb ihre Adresse-Offset ändern und VLB Karte nur per Löten bzw. DIP Schalter.


    Hardwareänderung : Minimum 3 Adresse-Decoder und paar TTL Gatter ist nötig. 2 davon ist 0x000A 0000 Decoder und einer ist einstellbare Decoder, TTL Gatter bildet mit einstellbare Decoder SAUP1/2 Decoder. Ich zeichnete morgen konzeptielle Schaltplan und berechne Laufzeit des gesamte Decoder-Geschichte. (bis 8ns geht )


    Mögliche Erfolg: PCI Treiber läuft nun mit ihm, was ich nicht glauben werde.



    Mögliche Problem: 0xB800-0xBFFFF ist andere MMIO-Adresse mit nur 32kB Fenster. Das hier fehlt es komplett. Wir müsste schauen, ob es verzichtbar ist bzw. einfach Spiegelung von 0xA0000-0xAFFFF ausreichend ist.


    Neue Erkenntnisse: Das erklärt warum S3 Vision und S3 Trio64v+ trotz "naja" Speicherdurchsatz (12-18MB/s) in DOS sehr schnell ist. MMIO sei dank ! I/0 Zugriffe ist langsam und es wird per S3 Chip intern direkt ins Speicher-Zugriffsbereich eingeblendet und System beschleunigt massiv.

    2 Mal editiert, zuletzt von matt ()

  • Nächste (heutige) Erkenntnisse: Trio64V+ und Virge (325) mag keine 50Mhz FSB.


    Ich habe auf Soyo's lahme Schnitte AMD 5x86 (3x Multi) mit 50Mhz FSB betrieben und Trio64v+ PCI zeigt Pixelfehler in VGA Mode (genau gleiche Bildfehler wie beim VLB-Karte)

    Alles klar: Dieser Chip ist wohl nicht dafür ausgelegt :puke (Dafür bin ich immernoch sehr froh: Vision968 VLB (968VL) ist 50Mhz 0WS stabil )


    Nächste kleine Ärgernisse: Platine aus China ist immernochnichtda:wolke

  • Na endlich ist Platine da !


    Flugs eine Decoder-Platine zusammengelötet und LED leuchtet, wenn es auf Grafikkarten per MMIO zugegriffen.

    Alles gut, dachte Matt und verbindet ihm mit vorhandene Adresse-Dekoder von zweite Trio64V+Prototype.

    System wacht nicht auf. Kurze Test: externe Adressedecoder auf 0x0xxxx (statt 0xAxxxx) einstellen. System wacht auf mit Bildchaos.

    dosreloaded.de/forum/core/attachment/48141/


    DRECKS !

    Auch IO-Zugriffe ist mit SAUP1/2-Zugriffe verandert.. Ich fand Hinweis von dieser Einschränkung NICHT in Datenblatt.:stinki

    Bisher nahm ich an, dass I/O Zugriffe unabhängig von Speicherzugriffe läuft.

    Erklärung: I/O Zugriffe findet nur in unterste 64kb statt (d.H. 0-0x0FFFF )


    Ich habe überlegen und gleichzeitig Anime gucken. Bis mir eine Blitz trifft.


    Warum überlegen? : Ich habe keine freie VLB-Slot mehr und vorhandene Platine sollte weitergenutzt.

    0xAxxxx Speicherzugriffe und 0x0xxxx I/O Zugriffe mit einzige Adressedecoder.

    Ich habe simple Lösung eingefallen und Platine geändert.

    Lösung: I/O Pin am VLB Bus steuert eingestellte Adressebereich. D.H. DIP Schalter Versorgungsspannung unterbrechen und (low-aktive) I/O-Pin treibt ihm an.



    OK, dann nächste Test mit lineare Framebuffer anfangen und da habe ich leider eine Denkfehler bei erstellen von externe Decoder gemacht.

    Ich lass mich irgendwie zu das einfallen.

    5 Mal editiert, zuletzt von matt ()

  • Es gibt kaum Fortschritt mit Virge VLB


    Ich habe endlich Karte mit geänderte Adressedekoder bestückt. ( Speicherzugriffe auf 0xA0000 bis 0xBFFFF und eiinstellbare Bereich ab 64MB eingeschränkt) S3VBE mit lineare Framebuffer stürzt weiterhin ab, allerdings mit Rückmeldung und Rechner ist nicht eingeforen.

    Terminal Velocity mit S3d wirft nach starten von Spiel raus, mit "no Virge "-Fehlermeldung.


    Das ist verdammt kleine Schritte. Vorher ist nur komplette Einfieren, wenn ich S3d fähige Game starte bzw. auf lineare Framebuffer zugreife.


    Ich weiss NICHT, wie findet Software (S3VBE20 , lineare Framebuffer bzw S3d game) heraus, wo ihre Adressebereich ist.

    Wenn es über PCI Config-space zugegriffen wird -> kein Wunder, dass es abschmiert. VLB System hat keine PCI Config Space.

    d.h. Ich müsste ne ISA Karte mit EPROM & Latch basteln, der PCI-Config Space emulieren. (Index 0xCF8 and Daten 0xCFC, i/O Addresse)


    Das ist warum ich schreibe: verdammt kleine Schritte.

    Einmal editiert, zuletzt von matt ()

Jetzt mitmachen!

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