Creator 3D Auflösung im PROM einstellen

  • Da der Opensourcetreiber die Auflösung nicht verstellen kann und die Karte ohne einen Sun Monitor die Auflösung auf (für TFTs unscharfe) 1152x900 einstellt , habe ich mich mal etwas durch das PROM der Grafikkarte gewühlt.


    Für die älteren Grafikkarten ist dies Dokumentiert

    https://docs.oracle.com/cd/E19…9-05/6jdmq4ikq/index.html


    aber für die Creator 3D gibt es unter Solaris ein Tool (ffbconfig) zum Umschalten und daher ist das bei der Karte nicht vorgesehen. Auch auf dem Web hab' ich nichts gefunden. Da die Programme für OpenBoot alle in Forth geschrieben sind und man die original Funktions- und Variablennamen anzeigen lassen kann, ist es nicht besonders schwer, den Treiber zu hacken. Eine Schande, dass es OpenBoot praktisch nicht mehr gibt.


    Die einfachste Möglichkeit ist, die Routine, die die "Sense" Leitungen des 13W3 Monitorkabels abfragt, durch die gewünschte Zahl zu ersetzen.


    https://en.wikipedia.org/wiki/DB13W3

    http://www.sunhelp.org/faq/FrameBuffer.html


    Für 1280x1024x67 (SenseID 4) erstellt man folgendes Skript mit nvedit:

    Code
    probe-all
    dev /SUNW,ffb@1e,0
    patch 4 rd_monitor_id set_rt_id
    device-end
    install-console
    banner

    Die Kommandos probe-all, install-console und banner dienen dazu, dass das Skript an der richtigen Stelle im Bootvorgang ausgeführt wird ( siehe OpenBoot 3.x Command Reference Manual, Seite 37). Zeite 2 selektiert die Creator Karte im DeviceTree und Zeile 3 ersetzt in der Funtion "set_rt_id" die Funktion "rd_monitor_id" durch den gewünschten SenseID Wert 4.


    Nach dem Booten kann man im Wesentlichen das selbe mit folgenden zwei Kommandos im PROM erreichen:

    Code
    400 500 400 0 0 80 40 " /SUNW,ffb@1e,0" " ffb_change_scrn_params" execute-device-method 
    4 " /SUNW,ffb@1e,0" " restart" execute-device-method

    Die Methoden kann man nicht direkt aufrufen, da jeder Hardwarezugriff sonst in einem MMU-Fehler endet. Hat etwas gedauert, bis ich auf den oben beschriebenen Umweg gestoßen war.

    Ähnlich könnte man auch Auflösungen einstellen, die die Grafikkarte aus den EDID Infos eines Sun Monitors auslesen würde. Da für mich aber SenseID 4 genügt, hab' ich die vermutlich etwas einfachere Route gewählt.

    C64 / Amiga 500, 1000, 1200, 2000 / SUN IPC, SparcStation 5, Ultra 1, Ultra 10 / MiSTer FPGA / ULX3S

  • Man muss dazu

    Code
    setenv fcode-debug? true

    eingeschalten haben, da sonst die nötigen Labels den Fcode Tokenizer nicht überleben. Könnte man sicherlich auch ohne direkt in den Speicher schreiben, wäre aber nochmal Aufwand, die Adresse zu bestimmen. Zudem könnte die stärker von der Version der Grafikkarte abhängen.

    C64 / Amiga 500, 1000, 1200, 2000 / SUN IPC, SparcStation 5, Ultra 1, Ultra 10 / MiSTer FPGA / ULX3S

  • Nice!

    D.h. du hast in das Package " /SUNW,ffb@1e,0" reingeschaut (words, ls) und bist die Wörter einzeln durchgegangen (see)?

    Wie lange hast du dafür benötigt? Ich habe ewig nichts mehr mit einer Ultra gemacht.


    Den Param fcode-debug? auf den Wert true zu stellen ist nötig, wenn man auch noch die Header der Wörter ausgegeben haben will. So viel habe ich im OBP aber noch nicht fummeln müssen, wollen schon. Dabei ist es es bis jetzt geblieben. Ich hoffe ich kann jetzt in der Weihnachtszeit mal wieder ein wenig mit der SS2 (FCode 2.x) im OBP spielen, Forth auf 32-Bit Steroide ist 8)


    Laut "Writing FCode 3.x Programs • February 2000", Seite 38ff wird noch "un/select-dev" angegeben. Das auch mal probiert, da ja etwas mehr gemacht wird als beim einzelnen dev


    ok " /SUNW,ffb@1e,0" select-dev

    ok patch (...)

    ok unselect-dev


    Bei den älteren Sun 18,1" Flachbildschirmen kann man die Interpolation zur nativen Bildschirmdiagonale bzw. den gesamten Sichtbereich noch abschalten, dann ist das Bild knackenscharf, hat aber einen schwarzen Rand. Ist mir bei der SS2 mit 1152x900 aber egal. Einige andere Nicht-Sun Flachbildschirme verhinderten eine Interpolation ggf., wenn das Videosignal am analogen Eingang einging. Die neuerenFlachbildschirme machen das meist nicht mehr oder bieten nicht mal mehr eine Option in den Settings des OSD um die Interpolation (Skalierung) bei Non-Native Auflösungen auszuschalten bzw. zu verhindern.

  • Ja, ich hab mir per serieller Verbindung mit words alle Methoden ausgeben lassen und dann ein Skript geschrieben, das für jedes einzeln see ... aufruft. Wenn man da die Ausgabe mitschreibt, hat man praktisch ein komplettes Listing des Treibers. Darin musste dann eine Funktion sein, die die EDID und SenseID infos in Auflösungen übersetzt. Die sieht man da sofort, ist eine lange Liste mit case Anweisungen.


    Ich hab' nur etwas gebraucht um zu merken, dass man Funktionen nach dem Tokenizer nicht mehr global ersetzen kann, da der die Adressen der Funktionen fix in den Bytecode schreibt. Zuerst wollte ich die Funktion rd_monitor_id einfach neu definieren, aber das interessiert den bereits übersetzten Code nicht. Insofern muss man sich eine geeignete Stelle suchen, an der man mit patch weiter kommt. Das überschreibt dann einfach den Code in einer bestehenden Funktion.


    Hat so grob 'nen halben Tag gedauert. War aber auch meine erste halbwegs ernste Auseinandersetzung mit FCode. Das nächste Mal wär's deutlich schneller. Zumindest in einem ähnlichen Fall, wo klar ist, nach welcher Struktur im Code man sucht.


    Ah... das mit dem select-dev wusste ich nicht. Vielleicht solle man die Dokumentation wirklich mal lesen. Ich denke, das braucht man aber nur, wenn man Methoden aufruft, die auf den Speicher zugreifen. Vermutlich muss da die MMU erst in den richtige Modus versetzt werden. Also als Alternative dazu, für jede Anweisung " /SUNW,ffb@1e,0" " <Anweisung>" execue-device-method eintippen zu müssen, wie ich das oben gemacht habe.


    Für patch genügt es, wenn man an der korrekten Stelle im DeviceTree ist. Das ändert ja nur im normalen Speicher den Bytecode.


    Für die Console ist 1152x900 schon OK. Aber ich hatte es nicht geschafft, die Auflösung in Xorg zu ändern. Und in X sind dann alle feinen Linien unscharf, wenn die Auflösung nur knapp nicht gleich der physikalischen des TFTs ist und das Ding interpoliert. Nur einen Teil eines 19" 4:3 TFTs zu nutzen ist auch keine zufriedenstellende Lösung.


    Wenn man nur Solaris laufen lassen will, braucht man das ja auch nicht. Da gibt's eine Configdatei, die für X mittels ffbconfig die gewünschte Auflösung einstellt.

    C64 / Amiga 500, 1000, 1200, 2000 / SUN IPC, SparcStation 5, Ultra 1, Ultra 10 / MiSTer FPGA / ULX3S

  • Sehr schön, danke für die Beschreibung!


    Um welche Creator handelt es sich denn? Die in meiner Ultra-2 lässt sich einfach per output-device auf verschiedene Auflösungen einstellen.

    Suche: SGI Indigo (gerne IP12), DEC/DIGITAL CRT Monitor und ein VT240 (inkl. Monitor).

  • Das ist die Creator FFB2+ aus der Ultra 10. Die Möglichkeit, dass als

    Code
    setenv output-device screen:r1280x1024x67

    zu machen kannte ich nicht. Muss ich mal ausprobieren. Die Values gibt es bei meiner Creator, aber nur, wenn man FCode-debug? einschaltet. Bei der Rage64 auf dem Board sind die Variablen global, verschwinden also unabhängig von der Einstellung nicht.

    C64 / Amiga 500, 1000, 1200, 2000 / SUN IPC, SparcStation 5, Ultra 1, Ultra 10 / MiSTer FPGA / ULX3S

    Einmal editiert, zuletzt von R4M ()

  • R4M Lässt mich staunend und mit Fragezeichen über meinem Kopf zurück. So muss das! :shock::grübel::applaus:


    Wie hat du die Ausgaben weggeschrieben? Per Papier + Stift?


    Probiere ich mal an meiner SS2. An die U60 wie auch die B2k komme ich diese Jahr nicht mehr ran.


    ATi Rage64 klingt nach U5/10.

    In FFM liegt noch eine Floppy-Halterung nebst Floppydrive. Magst du die - geschenkt - haben? Sonst geht das nächstes Jahr es in den Werkstoffhof. Wäre schade drum, wenn jemand noch das passende Gerät hat.


    Mich beschäftigt aktuell leider noch ein defektes Netzteil zu einer SS2. Ich sehe ohne Messungen da keinen Fehler... man merkt mit der E-Technik habe ich es nicht so. Messgerät und Löt-Utensilien liegen praktischerweise auch nicht vor Ort :rolleyes:

  • In FFM liegt noch eine Floppy-Halterung nebst Floppydrive. Magst du die - geschenkt - haben? Sonst geht das nächstes Jahr es in den Werkstoffhof. Wäre schade drum, wenn jemand noch das passende Gerät hat.

    Die Floppy könnte ich wirklich brauchen. Die in meiner U10 hab' ich bisher noch nicht zum laufen gebracht.

    C64 / Amiga 500, 1000, 1200, 2000 / SUN IPC, SparcStation 5, Ultra 1, Ultra 10 / MiSTer FPGA / ULX3S

  • Um welche Creator handelt es sich denn? Die in meiner Ultra-2 lässt sich einfach per output-device auf verschiedene Auflösungen einstellen.

    Das funktioniert tatsächlich! Steht leider nicht im Handbuch zu den Framebuffern.

    https://docs.oracle.com/cd/E19…7-0438-10/817-0438-10.pdf

    Hab' die Suns erst seit zwei oder drei Monaten... und keinerlei Grundwissen. War aber wie gesagt ein guter Anlass, sich mal näher mit FCode auseinanderzusetzen.

    C64 / Amiga 500, 1000, 1200, 2000 / SUN IPC, SparcStation 5, Ultra 1, Ultra 10 / MiSTer FPGA / ULX3S

  • Wie hat du die Ausgaben weggeschrieben? Per Papier + Stift?

    Nee... für Papier und Stift wäre das zuviel Arbeit.

    Ich hatte die serielle Leitung nicht exklusiv mit gtkterm offen und das kann ein Logfile schreiben. Mit einem Skript hatte ich dann die Befehle direkt an die Console geschickt, also sowas wie echo see $WORD > /dev/ttyUSB0

    C64 / Amiga 500, 1000, 1200, 2000 / SUN IPC, SparcStation 5, Ultra 1, Ultra 10 / MiSTer FPGA / ULX3S

  • Die Floppy könnte ich wirklich brauchen. Die in meiner U10 hab' ich bisher noch nicht zum laufen gebracht.

    Ich packe mit rein was zur U10 in FFM noch rumliegt, wo ich aber erst wieder Anfang nächstes Jahr hinfahre (Corona sei Undank).

    Beim Floppy keine Garantie: liegt schon einige Jahre (trocken) auf Halde, im Gegensatz zum Vorbesitzer anscheinend. Die Gummifüße für die U10 hatte ich mir vor über 15 Jahren mal gekauft aber aufgrund fehlender U10 nie benutzt. K.A., was mich geritten hat das zu kaufen.



    Nee... für Papier und Stift wäre das zuviel Arbeit.

    Ich hatte die serielle Leitung nicht exklusiv mit gtkterm offen und das kann ein Logfile schreiben. Mit einem Skript hatte ich dann die Befehle direkt an die Console geschickt, also sowas wie echo see $WORD > /dev/ttyUSB0

    Da habe ich einfach den falschen Schluss gezogen, weil ich vom Bildschirm auf direkten Konsolenzugang geschlossen hatte. An die zu bevorzugende Remote-Konsolenverbindung hätte ich selber kommen können. So ist es auch gleich viel bequemer. ;)