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

escimo · Apr 4th 2019

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

deleted_01_21 · Apr 4th 2019

Navratil System Software Information zeigt das an.

Aus den S3UTILS die S3ID.EXE zeigt das an.

Die spezielle VBE20-Erweiterung S3VBE20 zeigt das an.

escimo · Apr 4th 2019

Na das ist doch mal was! Damit kann ich mich gezielt auf die Suche begeben. Dankeschön.

Hoffe das passt auf Disketten, denn die DOS-Partition ist mit 10MB absichtlich etwas kleiner geraten und schon voll

escimo · Apr 11th 2019

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?

ThoralfAsmussen · Apr 11th 2019

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

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

...

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

- -------- xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx ------ 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

escimo · Apr 11th 2019

Quote from ThoralfAsmussen

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.

Quote from ThoralfAsmussen

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.

Quote from ThoralfAsmussen

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

ThoralfAsmussen · Apr 11th 2019

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

Quote from escimo

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.

escimo · Apr 12th 2019

Komplexe Thematik.

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.

[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

ThoralfAsmussen · Apr 12th 2019

Quote from 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.

ThoralfAsmussen · Apr 12th 2019

Quote from escimo

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.

escimo · Apr 12th 2019

[1] Ui, viele Informationen! Mama!?

Ich lese mich ein. Vielen Dank!

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.

escimo · Apr 12th 2019

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?

Code

//   (C) Copyright 1995 by Metro Link Incorporated.
//   All Rights Reserved

[VERSION]
1.0

[MONITOR_DESCRIPTION]
Date                  = 1996/1/17;
FileRevision          = "1.0"
Manufacturer          = "Metro Link Inc.";
ModelNumber           = "VESA & Industry Timings";
MonitorType           = "COLOR";
CRTSize               = 0;                      // inches

//(...)

[PREADJUSTED_TIMING]
PreadjustedTimingName = "1280x1024 @ 60Hz";
HorPixel              = 1280;                   // pixels
VerPixel              = 1024;                   // lines
HorAddrLength         = 0;                      // mm
VerAddrHeight         = 0;                      // mm
PixelWidthRatio       = 1;
PixelHeightRatio      = 1;
HorFrequency          = 63.974;                 // kHz
VerFrequency          = 60.013;                 // Hz
ScanType              = NONINTERLACED;
HorSyncPolarity       = POSITIVE;
VerSyncPolarity       = POSITIVE;
CharacterWidth        = 8;                      // pixels
PixelClock            = 108.502;                // MHz
HorTotalTime          = 15.631;                 // (usec) = 212 chars = 1696 Pixels
HorAddrTime           = 11.797;                 // (usec) = 160 chars = 1280 Pixels
HorBlankStart         = 11.797;                 // (usec) = 160 chars = 1280 Pixels
HorBlankTime          = 3.835;                  // (usec) =  15 chars =  120 Pixels
HorSyncStart          = 12.387;                 // (usec) = 175 chars = 1400 Pixels
HorSyncTime           = 1.180;                  // (usec) =  15 chars =  120 Pixels
VerTotalTime          = 16.663;                 // (msec) = 1069 lines
VerAddrTime           = 16.006;                 // (msec) = 1024 lines
VerBlankStart         = 16.006;                 // (msec) = 1024 lines
VerBlankTime          = 0.657;                  // (msec) =    1 lines
VerSyncStart          = 16.022;                 // (msec) = 1025 lines
VerSyncTime           = 0.047;                  // (msec) =    3 lines

Display More

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.

escimo · Apr 13th 2019

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.

ThoralfAsmussen · Apr 15th 2019

Quote from 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.

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.

Quote from escimo

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

Quote from escimo

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.

escimo · Apr 15th 2019

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/

Quote

$ mv SUNWaccel.tar.zip SUNWaccel.tar

$ tar tf SUNWaccel.tar

(...)

SUNWaccel/boards/cirrus/5428-0.5.xqa

SUNWaccel/boards/cirrus/5428-1.xqa

SUNWaccel/boards/cirrus/5428-1b.xqa

(...)

SUNWaccel/boards/orchid/f1280+.xqa

(...)

SUNWaccel/boards/spea/mirage-1.xqa

SUNWaccel/boards/spea/mirage-2c.xqa

SUNWaccel/boards/spea/mirage-2b.xqa

(...)

SUNWaccel/etc/

SUNWaccel/etc/Xmessages

SUNWaccel/etc/Xtimings

SUNWaccel/monitors/

(...)

SUNWaccel/monitors/lcd/l194rh.vda

SUNWaccel/monitors/lcd/timings.vda

SUNWaccel/monitors/lcd/l194rh-2.vda

(...)

Display More

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

dr.zeissler · Apr 15th 2019

habe exakt die gleiche karte und mich auch schon gewundert,dass da immer nur 1mb angezeigt wurde.

escimo · Apr 15th 2019

Unter Solaris oder die Karte i.a.?

dr.zeissler · Apr 16th 2019

Nur m normalen pc

escimo · Apr 18th 2019

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?

dr.zeissler · Apr 19th 2019

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.

escimo · Apr 20th 2019

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)

Quote from Xaccel User's Guide, page 4 f. (ftp://...)

p.4 f (Intro)
The 1.0 server is X11R5 based; the 2.0 server is X11R6 based. The
server base has been in continuous development for over three
years. Early versions of the server were shipped as the freely
distributed X386 server (later, XFree86). Features of this server
include the following:

(...)

* Text based descriptions of configuration, graphics board
capabilities, and monitors permit easy site-specific or per
machine custom configuration.
* VESA VDIF files for describing the monitor allow the X
Server to use any resolution that the graphics hardware is
able to display, not just standard resolutions.

p.59 (File formats)

Xaccel uses 3 types of configurable files:

Xaccel.ini toplevel configuration file for the X Server
.xqa graphics board description files
.vda monitor description files (VESA Display Information Format)

Xaccel.ini points to the xqa/vda files used by the Server. All xqafiles
are found under $XACCELHOME/boards and the vda-files
are under $XACCELHOME/monitors.
All three file types share the same basic grammar, which is
modeled after the VESA SVPMI standard (VS911020) and the
VESA VDIF standard. The descriptions below borrow heavily
from both standard documents.

p.67 (XQA)

eXtended Query Architecture

p.73 (VDA)

VESA VDIF Files

Display More

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

Quote

p.69
RAMDAC RAMDAC used on this board.
Accelerated-X knows how to program
the following list of RAMDACs:
ATT20C490/ATT20C491/
ATT20C492/ATT20C493
ATT20C498
ATT20C505
Bt458
Bt481/Bt482

Display More

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

escimo · Apr 21st 2019

Typo: ATT20C490, nicht ATT20C491

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

escimo · Jul 14th 2019

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.

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

Tags