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?
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?
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.
325VL-000 closed since 25.10.2020
08.11.2020
Pullup für VAFC ( Pin205-203 ESync, EVCLK, EVIDEO ) 10k-47k
*erledigt
DDC implementieren
*10.11.2020 Pin 205& 206 zu VGA Port verbunden und getestet -> funktionstüchtig.
*10.11.2020 CD4052B als Multiplexer einplanen, inklusive Pin 151 (GOP0 ) zu CD4052 A&B Eingänge.
*erledigt 15.11.2020
Debug LED D54-D57 verpolt
*erledigt 08.11.2020
VGA Footprint gegen 2.54mm austauschen.
*erledigt 08.11.2020
C21 um 1mm nach oben schieben (kollidiert mit EPROM Sockel)
*erledigt 08.11.2020
Debug LED alle ausrichten an eine Seite = Kathode, andere Seite Anode.
*erledigt 15.11.2020
Einzelgatter-Gehause (U6,7, 9 ) von SOT23-5 auf SOT323-5 wegen Verfügbarkeit austauschen
*erledigt 15.11.2020
ISA Slot um 0.3-0.5mm nach links verschieben.
*erledigt 15.11.2020
Config resistor pull up entfernen. (Trio64V+/ViRGE hat bereits interne Pullup )
*erledigt 15.11.2020
DEBUG J3 Anschluss 180° umdrehen
*erledigt 15.11.2020
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
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?
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.
Is klar, habe die Kollegen per PN angefunkt
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.
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.
Und die FPGA Voodoo 1...
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 )
Was Treiber angeht hat sich bisher nur einer gemeldet - leider mit Absage, sind halt Dosprogrammierer....
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.
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.
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 (Dafür bin ich immernoch sehr froh: Vision968 VLB (968VL) ist 50Mhz 0WS stabil )
Nächste kleine Ärgernisse: Platine aus China ist immernochnichtda
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.
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.
Eine Trio64V+ only PCB ist fertig bestückt und getestet.. (Kalte Lötstelle an DRAM nervt )
Eine Trio64V+ only PCB ist fertig bestückt und getestet.. (Kalte Lötstelle an DRAM nervt )
Beeindruckend! Du lässt nicht locker
Meine ist angekommen, habe sie noch nicht testen können da ich den AT DIN -> PS/2 Adapter verschlampt habe
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.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!