SPEA / V7 Mirage - Prüfung VRAM Größe ?

  • Hallo zusammen.


    Ich würde gern bzgl einer SPEA/V7-Mirage AT-Buskarte (S3 801) mit 2MB DRAM herausbekommen, wieviel Speicher vom Board erkannt wird. Kennt wer ein DOS-Programm, mit dem sich das definitiv feststellen lässt?


    Teststellung:

    PC: SNI PCD-4H, i80486DX, 32MB, AHA-1540CF, 3Com NIC, SB16, onboard Grafik deaktiviert

    Grafik SPEA/V7 Mirage AT 2MB DRAM, RAMDAC ATT20C490-110 (bis 110 MHz PixelClock) , 2 Bänke: eine Bank 8x 256x4 60ns verlötet, die andere Bank 8x 256x4 DIP 60ns gesteckt, BIOS V4.01

    OS: MS-DOS 6.0 (nur Test/Konfig), VESA Treiber nicht installiert. Standardbetrieb unter Solaris 2.4





    Programme ohne Erfolg

    speedsys.exe

    mscd.exe




    (kein VESA Treiber)


    Auch liegt hier eine Board-Revision 11 vor. Diese besitzt keinen Jumper (JP2) mehr für explizite Umschaltung von 1MB (Default) zu 2MB, was aber nix bedeuten muss.


    Da Solaris 2.4 x86 die Grafikkarte nich offiziell in der HCL listet, habe ich mich der Konfig zur Orchid Fahrenheit 1280+ bedient. Damit lässt sich 1024x768x8 @60Hz darstellen. Nach Anpassung des Konfigteils auf 2MB sowie der Auflösungen bis 1280x1024 steigt mein TFT aus (kein Signal), obwohl OpenWindows gestartet wird (auditive Rückmeldung).


    Kennt wer das Programm ("VIdeo Accelerator Diagnostics") ?



    Gruß, escimo

  • Sieht gut aus bis auf S3VBE20.EXE, was mit meinem Board nicht kompatibel zu sein scheint. 2MiB DRAM werden erkannt.





    Für Solaris 2.4 x86 habe ich eine Monitor-Konfig (Stichwort VDA) mit einer separaten VESA-Sektion [PREADJUSTED_TIMING] für "1280x1024 @ 60Hz" als PreadjustedTimingName angelegt.





    Damit konnte ich dem NEC MultiSync LCD1970NX zumindest ein Signal inkl Bild entlocken.




    Noch nicht perfekt, da einige Timings noch nicht stimmen. :/




    Zuordnung? Berechnung?

  • Wie ist das gemeint ? Die Datei wird in

    /usr/openwin/share/etc/devdata/SUNWaccel/monitors/*/*.vda

    gelegt und dann ... wer legt fest, daß die auch gefunden und benutzt wird ?


    Aufgefallen ist mir, daß Du ein Seitenverhältnis von 4:3 angibst , aber eine Auflösung von 1280x1024 das gar nicht hat. Das klappt nur mit so einer SUNtypischen Auflösung oder z.B. mit 1280x960.


    Außerdem ist mit 2MB komisch, daß da überhaupt ein Farbbild herausfällt. Das gibt die Karte bei der Auflösung eigentlich nicht wirklich her, oder wenn dann gerade eben. Denn: 1280x1024 sind ja bereits mit S/W (1Bit Farbe) 1,25 MB benötigtes VideoRAM; in deinem Bild sind aber schonmal rot-und-blau-und-schwarz-und-weiss bzw. türkis-und-hellgelb-und-grau-und-schwarz zu sehen, d.h. 2Bit Bitplane - also 2,5MB.


    Die Berechnung kann man VESA konform mit dem Unix Programm "cvt" machen:

    Calculates VESA CVT (Coordinated Video Timing) modelines for use with X.

    Dort fallen dann aber so Zahlen raus, die man evtl. noch anpassen muß.


    Prinzipiell gibt es für Horizontal und Vertikal je einen Startpunkt und dann kommt erstmal ein Schutzbereich in dem noch nicht gezeichnet wird. Diesen findet man links und rechts vom eigentlichen Bild sowie oben und unten. Dazu muß die Laufzeit vom Strahl für die Strecke bis zum Zeilenanfang bzw. Bildanfang berücksichtigt werden. Wenn man die Zeilenwerte addiert dürfen die nicht den maximalen Wert der Zeilenfrequenz von Karte und auch nicht den vom Monitor überschreiten. Gleiches gilt für die vertikalen Werte, wo die Summe nicht höher sein darf, als die maximale Bildwiederholfrequenz (ebenfalls wieder für Karte und Monitor einzeln). Damit man auf der sicheren Seite ist, soll da immer noch so ca. 10% "Puffer" drin sein, d.h. man benutzt niemals nie die volle mögliche Frequenz.

    Beides zusammen darf dann wiederum den Pixeltakt nicht übersteigen - d.h. Zeilenfrequenz * Zeilenzahlen <= Pixeltakt ist oberstes Gebot.


    b ------------------------------------------------------------ h

    s ------------------------------------------------------------ h

    s ------------------------------------------------------------ h

    - -------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------ h

    - -------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------ h

    - -------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------ h

    - -------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------ h

    ...

    - -------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------ h

    - -------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------ h
    s ------------------------------------------------------------ h

    s ------------------------------------------------------------ h

    s ------------------------------------------------------------ h

    s ------------------------------------------------------------ y


    s ... schutzbereich

    y ... vertikal sync

    h ... horizontal sync


    wichtig sind die Freibereiche (-) links und rechts vom Bild (x)

    sowie die schutzzeilen (s) oben und unten

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Wie ist das gemeint ? Die Datei wird in

    /usr/openwin/share/etc/devdata/SUNWaccel/monitors/*/*.vda

    gelegt und dann ... wer legt fest, daß die auch gefunden und benutzt wird ?

    Was glaubst du warum "kdmconfig -c" (bei Solaris x86) relativ lange braucht bis man den Startbildschirm sieht? Der geht alle bekannten (hinterlegten) Verzeichnisse durch und lädt sich die Infos aller vorgefundenen Dateien, die es braucht. ;)


    Aufgefallen ist mir, daß Du ein Seitenverhältnis von 4:3 angibst , aber eine Auflösung von 1280x1024 das gar nicht hat.

    Ja, ist eigentlich 5:4, aber hat micht erst mal nicht gekümmert, da es so bei allen *.vda mit 1280x1024 so angegeben ist. Ggf. wird das auch ignoriert bzw. steuert nichts. Bin ich noch nicht dahintergestiegen.


    Außerdem ist mit 2MB komisch, daß da überhaupt ein Farbbild herausfällt. Das gibt die Karte bei der Auflösung eigentlich nicht wirklich her, oder wenn dann gerade eben. Denn: 1280x1024 sind ja bereits mit S/W (1Bit Farbe) 1,25 MB benötigtes VideoRAM; in deinem Bild sind aber schonmal rot-und-blau-und-schwarz-und-weiss bzw. türkis-und-hellgelb-und-grau-und-schwarz zu sehen, d.h. 2Bit Bitplane - also 2,5MB.

    Mmm. :/ Also ich berechne den benötigten Videospeicher (plain) wiefolgt:


    ( <resolution_h> * <resolution_v> * <bit/px> ) / 8 bit = <min_Bytes_required>

    Beispiel:

    (1280 * 1024 * 8bit/px) = (je Pixel) = 1.310.720 Bytes/px / 1024 (kiB) / 1024 (MiB) = 1,25 MiB


    Da ist multiplan-buffering (double-buffering) noch nicht mit drin, klar. Zudem ist das bei X11 eher ein Richtwert, da immer etwas mehr Videospeicher benötigt wird als errechnet, bspw als Offscreen-Memory für Clipping verdeckter Fenster-Ausschnitte. Das hast du wahrscheinlich mit "Schutzbereiche" verdeutlichen wollen(?)

    cvt schaue ich mir an :thumbup:, kenn nur X.org/XFree86 Video Timings HOWTO und Online-Formulare wie hier oder hier. Bis jetzt musste ich mir da nie Gedanken machen aber der RAMDAC der Karte kann nur bis 110MHz, wo z.B. eine ATi Graphics Ultra Pro bis 135MHz hergibt. Aus dem Grund konnte ich die Monitor-Presets nicht mehr verwenden. Von den technischen Einzelheiten habe ich leider so bis jetzt überhaupt keine Ahnung. Lässt sich alles berechnen, muss nur noch rausbekommen wie.


    Da die Werte in der VDA-Datei aber entweder in usec (µs) bzw msec (ms) Einheiten angegeben sind, hilft mir "lines" nicht wirklich. Komplexe Thematik. Ich sollte auf Bildschirme verzichten und nur noch serielle Übertragungen durchführen ... die ich dann auch nicht verstehe. :fp:

  • Videospeicher - da habe ich irgendwie wohl das Umrechnen auf Byte etwas unterschlagen. Paßt also mit Deiner Variante besser.


    Da ist multiplan-buffering (double-buffering) noch nicht mit drin, klar. Zudem ist das bei X11 eher ein Richtwert, da immer etwas mehr Videospeicher benötigt wird als errechnet, bspw als Offscreen-Memory für Clipping verdeckter Fenster-Ausschnitte. Das hast du wahrscheinlich mit "Schutzbereiche" verdeutlichen wollen(?)


    Nicht wirklich. Schutzbereich ist evtl. ein schlechtes Wort dafür. Da sind einfach Bereiche, die nötig sind, bis der Strahl wieder ein ordentliches Bild aufbauen kann und der Zeilensprung quasi "abgeschlossen" ist. Vermutlich kann man den rechten Rand kleiner machen als den linken ohne Qualitätsverlust. Prinzipiell kann man da auch was darstellen - siehe C64 Overscan Demos.


    Das mit dem Pixeltakt ist halt primär das, was definiert, wie "schnell" das Bild sein kann, d.h. wie hoch Zeilen- und Bildwiederholfrequenz letztlich sein können. Und man sollte den nicht wirklich ausreizen, das mögen die alten Karten nicht so.

    Wenn Du einen TFT benutzt, kann man da auch noch die Randbereiche weglassen, die braucht der TFT ja nicht wirklich, weil dabei ja kein Rasterstrahl bewegt wird - für einen echten CRT wäre sowas aber wohl "tödlich".


    Die Rechnerei geht eigentlich so, daß man den Pixeltakt nimmt, davon 10% Sicherheit abzieht, dann durch die Summe aus Zahl der Bildschirmzeilen zzgl der Zahl der Zeilen für den Schutzbereich oben und unten teilt, das ergibt die Zeilenfrequenz, die möglich ist. Die darf nicht über den Spezifikationen von Monitor und Grafikkarte liegen und lieber bißchen unter dem jeweiligen Maximum. Dieser Wert geteilt durch die Summe der Pixel einer Zeile zzgl. der Pixelzahl für die Randbereiche ergibt dann die Bildwiederholfrequenz. Die sollte wiederum nicht schneller sein als der Monitor es zuläßt bzw. die Karte es "schafft" (besser wieder bißchen weniger, 5% oder so) und zusätzlich sollte sie noch so hoch sein, daß es nicht flimmert.

    Man hat also quasi viele lustige Parameter an denen man "drehen" kann - und jeder einzelne muß bestimmten Grenzen genügen. Wenn's nur ums Anzeigen geht ist es daher schon hilfreich nicht auf 72 Hz bestehen zu wollen, sondern erstmal mit 60 Hz Bildwiederholfrequenz anzufangen.


    Die Umrechnung von Sekunden in Frequenzen ist relativ simpel - weil 1 Hz = 1 s-1 , also 1 Mikrosekunde sind dann 1 / 0.000001 = 1000000 = 1 MHz. Und in "Lines" ist das dann in irgendeiner Form ein Produkt aus der Zeilenfrequenz und eben der Zeilenzahl, die in der fraglichen Zeit gezeichnet werden können, z.B. 1024 * 56kHz = 1024 * 1/56000 = 0.01828 Sekunden und damit 1/0.01828 = 54.68 Hz Bildwiederholfrequenz. Aber Achtung: Hier fehlen noch die "Schutzzeilen" oben und unten, d.h. effektiv sinkt die Bildwiederholfrequenz dann noch, weil noch Zeilen dazukommen, die ja auch Zeit brauchen, auch wenn sie eigentlich nichts anzeigen.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

    Einmal editiert, zuletzt von ThoralfAsmussen ()

  • Komplexe Thematik. :grübel:

    Damit wäre für mich das Thema zur Speicherfeststellung der Spea/V7-Mirage durch.


    [1] Offen bleibt die Zuweisung von sinnvollen (errechneten) Werten zur VESA-Auflösung 1280×1024 @60Hz der VDA-Konfiguration für den LCD. Welche Mappings bezogen auf die Tabellenwerte des Herstellers NEC, oben, würdet ihr verschieden zu meiner Auswahl setzen und warum? - Ich benötige Anreize. In der Zwischenzeit beschäftige ich mich weiterhin mit der Nachrechnung einer vorhandenen VDA-Konfig @72Hz, um auf des Rätsels Lösung für 60Hz zu gelangen. ::hacking::


    [2] Mit einer ATi Graphics Ultra Pro fällt es bei der LCD-Info wiefolgt aus:



    Lustig auch: mit beiden ATi Mach32 Graphics Ultra Pro AT-Boards 2MiB bleibt die Anzeige und Keyboard manchmal beim Beenden von X11 hängen. Liegt ggf auch an einem Patch von mir bzgl German KBD-Layout. Man sollte ggf nicht patchen ("never touch a running ...")

    Sind aber meine einzigen Boards die eine beschleunigte Anzeige unter X11 zu Stande bringen. Bei einem 486'er unter Solaris 2.x mehr als "nice to have" (Stichwort Hardware Cursor). Da kommt dann sowas nettes raus:


    Manchmal sind es auch kleine Figuren. Ein Lob auf telnet, damit kann ich das Teil von Remote zum Neustart bewegen.


    [3] Bei Accelerator-only Boards, wie der ELSA XHR 1280 Winner mit C&T 82C481 oder der Nanao/Eizo AA41 mit C&T 82C480 habe ich nach VGA-PassThrough, d.h. beim Übergang/Wechsel von VGA(-Board) in einen High-Resolution Modus (AccelBoard) unter X11 noch keinen Erfolg verbuchen können. Da steigt das LCD jedesmal aus. Mit einem CRT wahrscheinlich kein Ding. Die Konfigs sind (leider) SVPMI-Dateien, deren Syntax sich mir ebensowenig erschließt. Die /etc/openwin/server/etc/OWconfig enthält hier keinen Monitor-Eintrag (VDA). Somit k.A. was dann für eine Monitor-Konfig angezogen wird. ( ja, ist VGA-Pass-Through über den VESA Feature Connector)







    Gruß, escimo

  • [1] Offen bleibt die Zuweisung von sinnvollen (errechneten) Werten zur VESA-Auflösung 1280×1024 @60Hz der VDA-Konfiguration für den LCD. Welche Mappings bezogen auf die Tabellenwerte des Herstellers NEC, oben, würdet ihr verschieden zu meiner Auswahl setzen und warum? - Ich benötige Anreize.


    Na dann ... zum Punkt [1]

    Vielleicht solltest Du Dir mal klar machen, was es mit FrontPorchTime und BackPorchTime auf sich hat.

    https://en.wikipedia.org/wiki/…ructure_of_a_video_signal


    Das ist wichtig, weil dann nämlich evtl. klarer wird, wie die Werte in der Tabelle gemeint sind.

    Da die in Deiner selbstgabauten VDA Datei gar nicht vorkommen, muß man die nämlich noch gescheit "umrechnen". In dem Fall heißt das, daß man nicht einfach da die Werte übertragen kann. So trägst Du z.B. den Wert 2.30 µs für den HorizontalBackPorch einfach als HorBlankTime ein. Das zieht sich dann bei anderenWerten so durch - und stimmt nicht.


    Das Blöde ist halt, das man da verschiedene Werte zusammenrechnen muß, um auf den richtigen zu kommen. Dazu müßte sich eigentlich auch was in der Anleitung (man) zu diesen VDA Dateien finden lassen. Da muß so sinngemäß drinstehen - HorAddrTime entspricht dem dargestellten Bild o.ä. und ob die dann evtl. noch im "Zeitfenster" zentriert wird.


    Bsp: Dein Monitor möchte gern 2.30 µs BackPorch und 0.44 µs FrontPorch haben, dazu zusätzlich noch 1.04 µs SyncTime. In der VDA Datei ist das Bild aber gerade fertig gezeichnet (11.850) und exakt zu dem gleichen Zeitpunkt soll dann der Rasterstrahl ausgeschaltet werden und das Sync beginnen. Dabei würde ich dort durchaus auch die gleiche SyncZeit eintragen - also für HorSyncTime (1.04) - aber die anderen Sachen sind Summen (!), d.h. SyncStart sollte erst nach Bildbeginn + BackPorch + ActiveDisplay + FrontPorch sein.

    Alle Zeiten zusammen müssen dann mit der TotalTime übereinstimmen.


    Gleiches gilt auch für Vertikal - dort hast Du 1024 Zeilen + 3 Zeilen SyncTime + 38 Zeilen BackPorch + 1 Zeile FrontPorch. Das heißt, das Dein Gesamtbild ohne Sync gleich 1066 - 3 sein muß, und damit eigentlich der Wert für Bildende und SyncStart nicht der gleiche sein sollte. Je nachdem wo die Datei das Syncsignal "erwartet" müßte SyncStart also bei 0 sein und dementsprechend verschiebt sich alles andere oder Sync sitzt am Ende, d.h dann bei 1066 - 3, was in Zeiten einem 16.67 ms - 0.05 ms = 16.62 ms VerSyncStart entsprechen würde.


    An der Stelle hast Du zudem eine 0.005 , also Faktor 10 zu niedrig, in der Datei stehen; ich tippe auf Tippfehler. Aber schon das (VerSyncTime) auf den richtigen Wert setzen, könnte deutliche Besserungen bringen, nämlich dann, wenn das Solaris die Datei fehlertolerant auswertet und sich den Rest selbst aus der VerAddrTime ableitet, wenn da die Zahlen nicht wirklich passen.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Sind aber meine einzigen Boards die eine beschleunigte Anzeige unter X11 zu Stande bringen. Bei einem 486'er unter Solaris 2.x mehr als "nice to have" (Stichwort Hardware Cursor). Da kommt dann sowas nettes raus:


    zu Punkt [2]

    das sieht ja nach Textmode aus, und vtl. gibt es da bei der Darstellung einen Umrechnungsfaktor für den Zeilenbeginn - und der paßt halt nicht. Unter RISC OS gibt es sowas ähnliches, da heißt das EigFactorY und man kann damit quasi ein Bild virtuell in Stufen von 1x, 2x, 4x skalieren, d.h. eine große Auflösung auf einem Monitor anzeigen, der das gar nicht schafft. Sieht bißchen nach sowas aus, weil die Zeilen anscheinend immer um eine halbe nach oben versetzt sind, das weiße Bild genau den halben Bildschirm einnimmt und der Rest unten ist dann einfach VideoRAM oder Speicherinhalt, was hinter dem Bildschirmspeicher kommt.


    Kannst Du ja mal ausrechnen wie groß der VideoSpeicher ist, das zu Startadresse desselben addieren und ab da ein Fillkommando machen - da sollten sich dann die "lustigen Figuren" ändern.


    Den Verzerrungswert kann man vmtl. irgendwo eintragen oder dem Treiber "mitteilen" beim Installieren.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • [1] Ui, viele Informationen! Mama!? :baby:


    Ich lese mich ein. Vielen Dank! ::matrix::


    Eine manpage zur VDA konnte ich mit Schlüsselsuche "-k" nicht vorfinden.


    [2] Das ist die Anzeige nach Beenden der X11-Session, beim "Rücksprung" zur Konsole. Das kommt nicht jedesmal vor.

  • Hier gibt es eineDatei mit VESA-Timings timings.vda die auch einen Eintrag für 1280x1024@60Hz liefert. Die [OPERATIONAL_LIMITS] passe ich wieder an die Vorgaben aus der LCD-Doku an. Die Angaben bei [PREADJUSTED_TIMINGS] fallen nicht viel anders aus. Kommt es hier auf Hundertstel-Stellengenauigkeit an, da die Werte ganz minimal von der LCD-Doku abweichen, aber wenigstens vollständig berechnet sind?


    Eine ähnliche Timing-Datei wird mit Solaris 2.4 bereits mitgeliefert.

    Xtimings.txt


    Dann feile ich mal weiter an meiner fehlerhaften l194rh.vda (NEC MultiSync LCD1970NX) Xtiming-Datei.

    Einmal editiert, zuletzt von escimo ()

  • Habe die [OPERATIONAL_LIMITS] mit den für den LCD-Monitor gewünschten VESA-Auflösungen (800×600, 1024×768, 1280×1024 alle @ 60Hz) zusammengeführt (merge). Das macht eigentlich eine Berechnung überflüssig, dennoch schadet es nicht zu wissen wie man die Werte berechnet. Das einige Parameter mehr angegeben sind als ursprünglich scheint auch keine Rolle zu spielen. Es wird sich nicht beschwert (Fehlermeldung/Warnumg).



    Erste Tests mit drei Grafik-Chipsätzen (-Karten) zeigen die Wirksamkeit der Monitor-Timings:


    (1) D756 on-board Cirrus Logic CL-GD5428-80QC-A (RAMDAC integr.)

    1024×768×8 @60Hz


    (2) ATi Graphics Ultra Pro - Mach32 2200688003, separaer RAMDAC ATi 68775 BFN

    1280×1024×8 @60Hz


    (3) SPEA/V7-Mirage 2MB - S3 86c801, separater RAMDAC ATT20C490-110

    1280×1024×8 @60Hz (*)


    (*) Einzig für die SPEA/V7-Mirage hakt es am Rand rechts, hier extra provoziert durch Fenster-Verschieben (also bei Änderungen des Bildinhaltes).



    Das liegt aber nicht am Timing für den Monitor, sondern schlicht an dem von ThoralfAsmussen beschriebenen Maximalwerte-Verhalten, welches sich hier rächt. D.h. der kleine RAMDAC ist ausgereizt, um den bei 1280×1024@60Hz zu betreiben. Mit einer geringeren Vertikalfrequenz sollte das Phänomen nicht mehr auftreten.


    Dabei hatte ich für diese Grafikkarte die Orchid Fahrenheit 1280 Plus als Vorlage genommen und die Speichergröße sowie die Infozeile des RAMDAC in der XQA-Darei (FB-Konfiguratio) angepasst (ATT20C481 auf ATT20C480). Der Grafikchip war der selbe. Die RAMDAC PxFreq liegt beim ATT20C481, mit 130MHz etwas flinker. Zu Beginn hatte ich aus der Konfig daher die Werte 120.000 und 130.000 extra rausgenommen, mit dem Ergebnis, kein Signal am Monitor, einfach weil der RAMDAC die vom System geforderten, Signalwerte nicht mehr liefern konnte. Als ich die beiden Zeilen wieder in die XQA-Datei eingetragen hatte ging es wieder. Ich deute das Verhalten daher so, das mindestens der nächst höhere Wert (120.000 MHz) als Referenz herangezogen wird, um das "OK" für die gewünschten die Auflösung zu liefern (always < operatinal limit => 110MHz). Das war das erste Mal, dass ich die Werte überhaupt in so einer Datei gesehen habe. Normalerweise sind die nicht angegeben. Die DDX-Treibermodule (Device Dependant X) *.ddx lassen sich nicht ohne weiteres debuggen. Mit der Doku aber kein Problem. Schaue ich auch nochmal rein.


    Die SPEA/V7-Mirage wird daher nicht das bevorzugte Anzeigemittel zur Ansteuerung eines 19"-Monitors bei einer Auflösung 1280×1024 @60Hz werden. Geringere Vertikalfrequenz? Warum nicht. Dann kann ich gleich mal die Berechnungsvorschriften (Formeln) austesten. :)

  • Habe die [OPERATIONAL_LIMITS] mit den für den LCD-Monitor gewünschten VESA-Auflösungen (800×600, 1024×768, 1280×1024 alle @ 60Hz) zusammengeführt (merge). Das macht eigentlich eine Berechnung überflüssig, dennoch schadet es nicht zu wissen wie man die Werte berechnet.


    Die [OPERATIONAL_LIMITS] von da

    http://www.ibiblio.org/pub/his…MonitorConfig/timings.vda

    müßtest Du aber unbedingt an Deine Monitorwerte und Grafikkartenwerte anpassen. Die sind ganz gut hoche eingestellt. Als Limits funktionieren die sicherlich folgendermaßen - alle Monitormodi darunter werden eingelesen und deren Werte gegen die Limits getestet. Wird dabei ein Limitwert überschritten, wird der gerade getestete Modus nicht in die Liste der benutzbaren aufgenommen. Die Limits sind als die letzte Sicherheit, die Deine Karte/Monitor retten, wenn Du Dich "verbastelt" hast beim Mode erstellen.



    Dabei hatte ich für diese Grafikkarte die Orchid Fahrenheit 1280 Plus als Vorlage genommen und die Speichergröße sowie die Infozeile des RAMDAC in der XQA-Darei (FB-Konfiguratio) angepasst (ATT20C481 auf ATT20C480). Der Grafikchip war der selbe. Die RAMDAC PxFreq liegt beim ATT20C481, mit 130MHz etwas flinker. Zu Beginn hatte ich aus der Konfig daher die Werte 120.000 und 130.000 extra rausgenommen, mit dem Ergebnis, kein Signal am Monitor, einfach weil der RAMDAC die vom System geforderten, Signalwerte nicht mehr liefern konnte. Als ich die beiden Zeilen wieder in die XQA-Datei eingetragen hatte ging es wieder. Ich deute das Verhalten daher so, das mindestens der nächst höhere Wert (120.000 MHz) als Referenz herangezogen wird, um das "OK" für die gewünschten die Auflösung zu liefern (always < operatinal limit => 110MHz).


    Also, wo die Datei jetzt herkommt, erschließt sich mir nicht. Aber: Wenn Du den Pixeltakt austrägst, wundert es eigentlich nicht, daß da nichts mehr angezeigt wird. Das ist schließlich der Primärtakt aus dem alle anderen abgeleitet werden. Trag halt mal einen kleineren Wert ein und guck, ob ein Bild kommt.


    Wichtig bei solchen Basteleien ist, daß man den Überblick behält ! D.h. für jede Grafikkarte eine Extra-Datei(!) anlegen und diese wiederum nicht untereinander vermischen. Versionen langsamer Verbesserungen anlegen. Modes kopieren ist absolut OK und kleine Abweichungen im hundertstel Bereich stören i.a. nicht, man muß aber darauf achten, daß sie nicht nach oben abweichen !, d.h. die Taktgrenzen der Karte nicht überschreiten.

    (Richtig lustig wird das Spiel, wenn man auch noch die Monitore durchwechselt.)


    Kommt es hier auf Hundertstel-Stellengenauigkeit an, da die Werte ganz minimal von der LCD-Doku abweichen, aber wenigstens vollständig berechnet sind?


    Dabei ist aber wichtig, daß eine hundertstel Millisekunde eine Angabe ist, die sich in Abhängigkeit vom Pixeltakt verändert in ihrer Bedeutung - bei hohem Pixeltakt (230MHz oder so) ist der Rasterstrahl in der gleichen Zeit viel weiter unterwegs, als bei niedrigem Pixeltakt. Deshalb macht bei Karten mit kleinem Takt eine Abweichung dort nicht soviel aus, wie bei hohem Pixeltakt.

    Bei beiden gilt, daß die Obergrenzen (Pixeltakt, Zeilenfrequnz, Bildwiederholfrequenz) nicht überschritten werden dürfen - und da sollte der Limitseintrag auch sicherstellen.

    -- 1982 gab es keinen Raspberry Pi , aber Pi und Raspberries

  • Die OPERATIONAL_LIMITS habe ich von dem angepassten Monitorprofil/-Konfig übernommen.


    Es gibt für jeden Eintrag im kdmconfig eine eigene Datei. Einzig die Dateien unterhalb SUNWaccel/etc/ sind übergreifend, u.a. Xmessages, Xtimings


    In die GraKa-Konfig mal kleiner Werte reinzuschreiben werde ich nochmal probieren. 110 MHz Pixeltakt sind bereits vorab schon hinterlegt gewesen. Nur eben zwei, höhere Were auch, die ich eigentlich nicht drinstehen haben wollte.


    Ich hänge die Konfigs (alle) mal an. Meine sind u.a.

    boards/cirrus/5428-1.xqa

    boards/spea/mirage-*.xqa

    monitors/lcd/l194rh-*.vda

    Die timings.vda gehört nicht unterhalb ./monitors/lcd/

    Sind immer einige Tippfehler drin. - Fette Finger halt auf dem Handy. :fp:

  • Einen normalen PC habe ich auch, nur eben mit Solaris 2.4 auf Partition 2 und MS-DOS 6.0 auf Partition 1 mit - ich korrigiere - 2 MiB, nicht 10 MiB. Es handelt sich um eine abgespeckte Variante. Die DOS-Partition ist für die Konfiguration von Adptern vorgesehen, um u.a. den IRQ und I/O-Bereich/-Port anzupassen, wo es nicht per Jumper-Stellung realisierbar ist, wie bspw einer 3Com 3c509B-TP. Auch erfüllt die Partition einen weiteren, notwendigen Zweck beim Boot von Solaris im Zusammenhang mit einem Adaptec SCSI Ctrl.


    dr.zeissler Wieso konnte er bei deiner Karte nur 1 MiB erkennen? Die falschen DRAM's verwendet?

  • Keine Ahnung, sah aus wie 2MB wurde aber nur mit 1MB unter Dos erkannt (qview 1.03 glaube ich)

    Hab die dann wieder ins Lager gepackt und keine weiteren Tests vorgenommen.

    Beim A2000 hab ich auf der PC Seite eine Et4000 von Diamond mit 1MB verbaut.

    Reicht für den 286er mit 8Mhz.

    Die Spea hatte ich so wie sie ist gekauft.

  • Nochmal zur Klarstellung.


    Das was hier unter Solaris 2.x für x86 Plattform als SUNWaccel mitgeliefert wird, ist eine Distribution-Version des X Inside Inc. (später XiGraphics Inc.) ACCELERATED-X Graphical Display Server. Dieser wurde auch für andere Derivate und Plattformen (aus-)geliefert, u.a. SCO UNIX und ODT, ISC/SUN Interactive UNIX, BSD/386, Novell UnixWare, SNI SINIX-Z.


    Das Manual "User's Guide" beschreibt u.a. die Syntax der XQA- und VDA-Datei. Siehe Anhang für PDF (aus PostScript)

    Mit dem "RAMDAC" ATT20C491 hatte ich Glück, da der zufällig (auch) vom Accelerated-X unterstützt wird.

    Die Xaccel.ini gibt es bei Solaris 2.4 x86 in der Form nicht, da es noch einen SVPMI-Anteil unter /usr/openwin/share/etc/boards/svpmi gibt, der anders konfiguriert wird. Annahme: aus dem Grund wird eine Wrapper-Konfigurationsdatei /etc/openwin/server/etc/OWconfig "vorgeschaltet".

  • :argh:

    Hat wer es mal geschafft auf einer 8514/A-kompatiblen Karte, die mit einer separaten VGA-Karte (Pass-Through) verbunden wurde, diese in einen High-Resolution Mode zu versetzten und dabei auch noch ein Bild über die HR-Karte zu bekommen?


    Egal was ich probiere, es hat nicht bei einer HR-Karte funktioniert. Irgendetwas übersehe ich. :nixwiss:


    Folgende Vorkehrungen habe ich getroffen:

    * Keine Überschneidung bei Hardware-Resourcen (Interrupt Requests, I/O-Adressen, ROM-Adressen)

    * 19" CRT-Bildschirm Samsung SyncMaster 959NF mit DSub-15 und BNC Anschlüssen

    * Terminator am externen DSub15-Port des on-board "VGA-kompatiblen Grafiksubsystems (CirrusLogic CL-GD5428, 1MB)

    * VESA PassTrough über 26-poliges Kabel von on-board VGA zu dedizierter HR-Karte (ATI Graphics Ultra Pro, Mach32-Chipsatz), 8514/A Register-kompatibel

    * DSub15-zu-BNC Kabel von HR-Karte (ATI) an BNC-Anschlüße des 19" HR-Monitors

    * Auswahl Treiber ATI Mach32 + Auflösung 1024×768×8@60Hz

    * VGA-Anzeige an HR-CRT durch VGA-PassThrough (ATI) erfolgreich


    Bei Umschaltung in den HR-Modus wird keine Anzeige auf HR-Bildschirm sichbar, im Gegenteil es gibt kein Signal, womit der Monitor umgehen kann. ==> Wie kann das sein? - Beim LCD, ok, aber beim CRT???


    Vermutung: anstelle des Mach32-Treibers den nativen 8514/A Treiber nutzen

    Aber müsste das nicht auch mit dem Mach32-Treiber funktionieren? :/


    Es geht nicht darum diese Konstellation zu verwenden, sondern vielmehr um die Machbarkeit nachzustellen. Es zu lesen (sofern es was zum Lesen gibt) ist eine Sache, es anzuwenden...