SUN OBP / PROM Spielerei

  • Ich habe vor hier ein wenig zum Thema SUN OpenBoot und PROMs zusammenzutragen. Das Ziel dabei ist natürlich dass das hier jeder der will nachvollziehen und mitmachen kann, also gerne Fragen stellen wenn etwas unklar bleibt! Und: es gibt hier (noch) sehr viel was ich nicht verstehe, ich freue mich also auch wenn jemand was besser erklären kann!


    Auslöser ist die Frage von ThoralfAsmussen in einem anderen Thread, wie man sich denn anzeigen lassen kann welche Auflösungen denn der Framebuffer unterstützt. Damit fangen wir mal ganz einfach an und sehen dann wie weit das am Ende führt :)


    Ich nehme als Test-System hier eine SPARCstation LX, angeschlossen über seriell damit ich die Ausgabe leicht mitprotokollieren kann. Bei mir ist auto-boot? = false und diag-switch? = true gesetzt damit ich direkt in das OpenBoot komme und die Info über SBUS Devices angezeigt wird:

    Ansonsten mit Stop-A bzw BREAK den Bootvorgang abbrechen und auto-boot? und diag-switch? entsprechend setzen mit setenv auto-boot? false.


    Das OpenBoot stellt uns eine Art Datei-System mit Devices zur Verfügung. Mit der Info oben finden wir auch den richtigen Weg zu den SBUS Devices:


    Jetzt muss man noch wissen welche der SBUS Karten die integrierte ist (@3,0) und welche die zusätzlich verbaute (@0,0). Wir sehen uns die integrierte an:

    Hier sehen wir schon welche Auflösungen die Karte definiert. Gesetzt werden diese bekanntlich mit zB setenv output-device screen:svga60.

  • Ein SBUS Gerät (wie hier die cg6) muss eine Art Firmware (FCode) haben die das Gerät identifiziert und evt eine Art Treiber darstellt. Bei einigen Geräten ist die Firmware sehr kurz und besteht nur aus wenigen Variablen die das Gerät identifizieren und so dem Betriebssystem ermöglichen den richtigen Treiber zu wählen, bei anderen ist die Firmware selbst schon recht kompliziert damit das Gerät schon verwendet werden kann bevor ein Betriebssystem geladen wurde. Letzteres ist der Fall bei der cg6, weil ja schon beim Bootvorgang eine Ausgabe auf dem Bildschirm erfolgen soll!


    Diese Firmware (FCode / PROM) einer SBUS Karte ist in einer Variante von Forth-83 geschrieben. Den Prozess des übersetzens von Forth in FCode nennt man neu-Deutsch "tokenizen", den umgekehrten Vorgang "detokenizen". Literatur hierzu ist Writing FCode 2.x Programs (802-1941-10_Writing-FCode-2.x-Programs.pdf). Wenn man sonst nichts über Forth weiß sollte man sich zumindest folgendes merken: Forth ist (wie zB auch PostScript) eine Stack-basierte Sprache und verwendet eine sogenannte umgekehrte Polnische Notation, d.h. man schreibt etwa 3 4 + statt 3 + 4. Die Parameter werden also immer vor der Funktion auf den Stack geladen!


    words listet die im FCode definierten Worte (~ Funktionen) auf. Mit see wort können wir uns die Definition anzeigen lassen, also das Wort detokenizen:

    Es wird dabei zwischen externen und internen Worten unterschieden. Der words Befehl listet nur die externen Worte und der detokenizer zeigt auch nur die externen Worte an und lässt für die internen die Adresse stehen, daher die Hexadezimalzahlen in Klammern.

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

  • Zum Glück gibt es einen Weg sich auch die internen Worte noch anzeigen zu lassen: wir müssen nur im OpenBoot fcode-debug? = true setzen und ein reset durchführen. Nachdem das geschehen ist zeigt words alle Worte an:

    Auf diese Weise können wir uns im Prinzip den kompletten FCode anzeigen lassen. Ich möchte hier in weiteren Beiträgen gerne zeigen dass das natürlich auch einfacher und besser geht :)


    PS: Die Sch**ß Beschränkung auf 10.000 Zeichen geht mir vielleicht auf die Nerven! Wäre ja schön wenn die Zeichen-Anzahl wenigstens beim editieren angezeigt würde...

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

  • Statt mit Hilfe des OBP mühsam den FCode auszulesen möchte ich jetzt direkt das PROM einer SBUS Karte einlesen und detokenizen. Per SBUS Spezikation muss jede SBUS Karte ein 32k EPROM haben das in die ersten 32k des SBUS Speichers der entsprechenden Karte gemapt wird.


    Fangen wir mal mit dieser Karte an, einer Magma Parallel Port Karte:



    Das schöne daran ist, dass das EPROM gesockelt ist und dass wir es so leicht auslesen können :) In einem folgenden Post werden wir sehen wie man auch ohne EPROM Leser weiter kommt.


    Nachdem das EPROM eingelesen ist (siehe Anhang), wollen wir uns mal den Inhalt ansehen. Erstmal unter Linux mit:


    Ahja, steht zumindest schonmal was von MAGMA drin :)


    Warum sehen wir 2 mal den gleichen Inhalt, einmal an Adresse 0x0000 und einmal an 0x4000 ? Ich vermute mal dass da die höchste Adressleitung des EPROMs nicht verbunden und damit bei schwebendem hohem Adress-bit keine Probleme auftreten wurde der Inhalt einfach zweimal geschrieben.

  • Für den nächsten Schritt (das detokenizen) brauchen wir eine Entwicklungsumgebung.


    Es gibt für Linux das Program gforth mit dem man Forth code auch detokenizen kann, ich bin allerdings mit dem Ergebnis nicht so zufrieden: das Ergebnis ist sehr "low level" forth code der schwer lesbar ist (außerdem ist gforth schon zu doof um little-endian vs big-endian zu verstehen...)


    Stattdessen verwende ich hier das Paket SUNWfcode von Sun selbst (Anhang: SUNWfcode.tar.gz.bin - bitte Endung .bin entfernen).


    Mein Entwicklungssystem ist eine SPARCstation 20 mit Solaris 7. Das Paket sollte auch unter Solaris 2.5(.1) und 2.6 laufen, evt auch unter weiteren Versionen. Auf meinem Solaris 10 System will es nicht funktionieren: es lässt sich installieren, liefert dann aber nur core dumps.


    Wer ein frisches Solaris 2.x hat sollte bedenken dass gzip nicht installiert ist und erstmal auf einem anderen rechner gunzippen. Dann installieren mit (als root in /tmp):

    Code
    # tar xif SUNWfcode.tar
    # pkgadd -d .
    
    The following packages are available:
      1  SUNWfcode     OpenBoot Fcode Tokenizer and tools
                       (sparc) 2.6,REV=97.11.23.15.22
    
    Select package(s) you wish to process (or 'all' to process
    all packages). (default: all) [?,??,q]:


    Jetzt muss noch /opt/SUNWddk/tokenizer dem Suchpfad hinzugefügt werden, sonst findet der detokenizer hinterher das forth nicht.

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

  • Wirklich gut. Und daß man da die Geräte mit ls anzeigen kann, ist mir auch noch nicht über den Weg gelaufen. Und "words" auf Kartenebene ist auch mal cool.

    Bin gespannt, wie das mit dem Auslesen funktioniert. Muß aber nicht alles heute sein.


    Auf dem Archi geht das auch, die EPROMs direkt auslesen. Das ist überhaupt relativ ähnlich, nur daß da nicht noch ein komplett programmierbares "BIOS" druntersitzt.

  • Jetzt wo wir eine Entwicklungsumgebung haben, können wir uns mal den FCode der Magma Parallel Port Karte genauer ansehen. Dazu brauchen wir das oben angehängte EPROM image auf dem Solaris System und verwenden den eben installierten detokenizer:

    Code
    $ detokenize magma-00-05000-00-rev-b3.bin
    FCode-version1 
    \  Image Size     h# 3000000  bytes.
    " MAGMA_Sp" encode-string " name" property
    " MAGMA,P1_Sp" encode-string " magma_prom" property
    " 2 7 8 9" encode-string " intlevels" property
    " d" encode-string " chiprev" property
    " 25" encode-string " clock" property
    my-address my-space h# 10000 reg h# 5 0 obsolete-fcode 
    end0

    Das sieht ja schonmal halbwegs brauchbar aus.


    Leider ist das SUNWfcode Paket eigentlich etwas zu neu mit dem Ergebnis dass hier ein "obsolete-fcode" angezeigt wird. Jetzt fängt die Handarbeit an: wir sehen uns nochmal das hexdump an und versuchen rauszufinden welche bytecodes welchen forth-Worten entsprechen. Alle benötigten Infos (bytecodes) stehen aufgelistet (vorwärts und rückwärts) im Appendix A des oben angehängten Writing FCode 2.x Programs.


    Arbeiten wir uns mal rückwärts von Ende des Programs zurück:

    Code
    [...]
    10 00 01 00 00  #h 10000    \ 10 xx xx xx xx gibt eine Zahl, #h ist eine tokenizer Anweisung für hex.
    01 16           reg
    10 00 00 00 05  #h 5
    a5              0           \ die Zahlen -1, 0, 1, 2, 3 haben spezielle bytecodes weil sie so häufig sind.
    01 17           intr        \ das war der obsolete-fcode.
    00              end0        \ ende des Programs!
    
    ff ff ff [...]              \ FCode ist vorbei, jetzt kommt Datenmüll bzw. unbeschriebenes EPROM.


    Jetzt wo wir das Problem mit dem obsolete-fcode gelöst haben, sind wir auch schon so weit dass wir zumindest aus dem Forth code schonmal den ursprünglichen Binärcode reproduzieren können:


    Der Binärcode ist identisch zu dem im EPROM mit ausnahme des zweiten bytes (das ist nur eine Versionsnummer und nicht weiter wichtig.)

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

  • Was ich gerne machen würde ist folgendes:

    1. Das EPROM eines cg6 Framebuffers auslesen.
    2. Das Image detokenizen und bearbeiten bis sich der ursprüngliche Binärcode reproduzieren lässt.
    3. Den Code ändern. Insbesondere weitere Auflösungen hinzufügen. Evt gehen auch neue Oszillator-Frequenzen auf diese Weise, da habe ich aber die Hardware noch nicht gut genug verstanden.
    4. Den veränderten Code in ein EEPROM schreiben und hoffen dass er funktioniert.
    5. Profit :)

    Mal sehen wie weit wir hier kommen!


    Jetzt zu den Schwierigkeiten: das EPROM auf den meisten SBUS Karten ist verlötet. Auslesen lässt es sich trotzdem ganz leicht unter Solaris in etwa wie folgt: (das ist jetzt auf meiner SPARCstation 20, also andere devices als in der LX)


    Zum Glück kann das OpenBoot mehr als man so denkt und wir können das laden des internen EPROMs für eine SBUS Karte ausschalten und stattdessen ein Image über TFTP laden wie beim Netboot! Das ist extrem hilfreich für die weitere Entwicklung!


    Am Ende müsste man dann natürlich das EPROM der SBUS Karte auslöten und durch ein neues EEPROM ersetzen. Ich überlege mir auf einer meiner cg6 einen Sockel einzulöten.

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

  • Wirklich gut. Und daß man da die Geräte mit ls anzeigen kann, ist mir auch noch nicht über den Weg gelaufen. Und "words" auf Kartenebene ist auch mal cool.

    Bin gespannt, wie das mit dem Auslesen funktioniert. Muß aber nicht alles heute sein.

    Ich beschreibe erstmal was ich schon gemacht habe, danach wirds dann länger dauern weil ich parallel an dem Projekt weiterarbeite (und zwischendurch auch mal "richtig" arbeiten muss...)


    Von meinen Punkten im letzten Post habe ich die ersten 2 erledigt, für den 3. muss ich noch sehr viel lesen bevor ich das (vielleicht) auf die Reihe bekomme.

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

  • Ich hatte beschrieben wie man das EPROM einer SBUS Karte unter Solaris einfach mit dd einlesen kann. Das gleiche habe ich auch für den onboard cg6 Framebuffer der SPARCstation LX versucht, leider ohne Erfolg. Irgendwie wird anscheinend der onboard Framebuffer anders behandelt und der FCode nicht in den SBUS Speicherbereich abgebildet.


    Also versuchen wir es anders :)


    Der FCode für die onboard cg6 ist im OBP enthalten, wir müssen ihn nur finden. Der FCode fängt immer mit ff 00 (alt) oder ff 03 (neu) an. Ein image des OBP lässt sich leicht einlesen (lx-obp.bin) und wir werden schnell fündig:

    Code
    $ hexdump -C lx-obp.bin | grep -A 5 "fd 03"
    00010b60  c2 08 04 00 fd 03 3d ea  00 00 26 bc cc 12 05 63  |......=...&....c|
    00010b70  67 73 69 78 01 14 12 04  6e 61 6d 65 01 10 12 0d  |gsix....name....|
    00010b80  53 55 4e 57 2c 35 30 31  2d 31 36 37 32 01 19 12  |SUNW,501-1672...|
    00010b90  07 64 69 73 70 6c 61 79  01 1a b6 09 63 6f 70 79  |.display....copy|
    00010ba0  72 69 67 68 74 08 00 b7  12 2d 43 6f 70 79 72 69  |right....-Copyri|
    00010bb0  67 68 74 20 28 63 29 20  31 39 39 30 20 62 79 20  |ght (c) 1990 by |
    $ 


    Die ersten 8 bytes (angefangen mit fd 03) sind der FCode Header. Bytes 3 und 4 sind die Prüfsumme, dann zwei Nullen, und zuletzt 2 Bytes die die Länge (inkl. des Headers selbst) angeben. Wir müssen also 0x26bc Bytes ab Position 0x10b64 aus dem OBP Image auslesen:

    Code
    $ dd if=lx-obp.bin bs=1 skip=68452 count=9916 of=sun-sslx-cg6.bin


    Das ganze kann man jetzt wieder wie zuvor detokenizen (Anhang: sun-sslx-cg6.detok.txt.)


    Den ge-detokenized-en Code muss man jetzt erstmal bearbeiten bevor der brauchbar ist! Mindestens müssen erstmal die Zahlenpaare (8,i) in Klammern entfernt werden zB in vi mit s/(8,[0-9]*)//g . Diese sind Kommentare des detokenizers die Nutzer-definierte Worte zählen und sind für uns unerheblich und mit den Zahlenpaaren haben wir keinen gültigen Forth Code!


    Jetzt tritt leider auch wieder das gleiche Problem auf wie schon bei der Magma Karte: der detokenizer kennt einige Worte nicht und ersetzt sie stattdessen durch obsolete-fcode. Außerdem macht der detokenizer noch (mindestens) folgende Fehler:

    • Der detokenizer erkennt korrekt externe Worte und markiert sie als external, "vergisst" aber das nach dem Wort wieder auf intern zurückgestellt werden muss durch die Anweisung headers.
    • Es werden alle return stack Befehle ersatzlos ausgelassen.

    Das ist ziemlicher Murks und führt dazu dass man sehr viel von Hand nacharbeiten muss. Also immer wieder tokenizen und sich die unterschiede zwischen den hexdumps des originals und des rekonstruierten Binärcodes ansehen. Ich bin kurz davor mir meinen eigenen detokenizer zu schreiben!

  • Topp. Auf die "Feinheiten" der OBP Version hinzuweisen wäre topp .. habe ich bei dem 4.7.1 der Blade 150 feststellen müssen!


    Aber genau solche "Anleitungen" sind sehr hilfreich.

  • Topp. Auf die "Feinheiten" der OBP Version hinzuweisen wäre topp .. habe ich bei dem 4.7.1 der Blade 150 feststellen müssen!

    Ich werde versuchen das zu machen soweit ich kann. Allerdings muss ich dazu sagen dass ich keine so modernen SUNs mit OBP 4.x habe... meine neueste SUN ist eine Ultra 60 und die hat noch OBP 3.x.


    Für das was ich hier mit der LX / CG6 jetzt erstmal mache arbeite ich mit OBP 2.x, teilweise mit 1.x Einfluss.

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

  • Ich bin ein ganzes Stück weiter und habe die Hoffnung dass ich bald nie gesehene Auflösungen programmieren kann :sunny:


    Lange bekannt ist die folgende Geschichte: die Auflösungen werden durch solche strings programmiert:

    Code
    : r1280x1024x76 " 135000000,81128,76,32,64,288,1280,2,8,32,1024,COLOR,0OFFSET" ;

    Details dazu wie das geht und was die einzelnen Parameter bedeuten finden sich in der SUN Framebuffer FAQ.


    Das "Problem" an der Sache ist, dass leider nur bestimmte vorprogrammierte Pixel Clock Werte verwendet werden können. Ich denke aber da lässt sich was machen :)


    Die LX (und auch die TGX+) verwenden einen ICS1562 User Programmable Clock Generator, und der kann natürlich viel mehr Frequenzen als SUN hier so vorprogrammiert hat.


    Relevant für uns sind hier die Forth Worte ics???, diese legen fest welche Werte in die Register 0-12 des ICS1562 geschrieben werden.

    Code
    : ics135        0 1 0 a 6 0 0 1 8 5 4 0 3 ;


    Wie man da jetzt andere Frequenzen programmiert habe ich im Quellcode kommentiert (das steht natürlich im datasheet zum timing generator):


    Jetzt muss man nur noch passende Werte für M, A, R, und S ausdenken. Eine Tabelle als Hilfsmittel für M und A gibt es im datasheet.


    Bisher ist alles nur graue Theorie, aber ich werde die Tage mal sehen ob ich hier die VESA Auflösung 1600x1200x60 auf meiner LX mit VRAM hinkriege. Wenn das alles so funktioniert wie ich mir das denke sollte das mit den folgenden Zeilen hinzukriegen sein:

    Code
    : ics162      0 1 0 a 6 0 0 1 8 6 6 0 3 ;
    
    : r1600x1200x60 " 162000000,75000,60,64,192,304,1600,1,3,46,1200,COLOR,0OFFSET" ;


    Ich hänge hier mal den aktuellen Zustand des von mir kommentierten source code an: sun-sslx-cg6.fth.txt. Es fehlt noch so einiges was ich bisher nicht verstanden habe und/oder wozu die Doku fehlt. Der Source Code lässt sich in dieser Form mit dem SUNWfcode tokenizer zu exakt dem original PROM übersetzen.


    Relevante Dokumente wurden hier schonmal im Forum hochgeladen im Faden CG6 Doku . Außerdem hat hier jemand das PROM einer IPX kommentiert. Leider hatte der Herr alles mit see Wort ausgelesen und dabei auch einige Fehler gemacht. Trotzdem ein sehr aufschlussreiches Dokument!

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

  • Erfolg! :sunny:


    Ich habe die vorprogrammierten Auflösungen 1280x1024x76 und 1600x1280x76 im Forth Code ersetzt durch die VESA Standard-Auflösungen 1280x1024x60 und 1600x1200x60, tokenized, etc, EEPROM geschrieben und eingebaut.


    Erster Test mit 1280x1024x60 auf meinem Belinea 1705 G1:


    Läuft!


    Jetzt zu 1600x1200x60. An meinem HP ZR24w Monitor angeschlossen kommt leider kein Bild. Und zwar mit keiner der Auflösungen, also keine Ahnung was da los ist. Der Monitor ist sehr wählerisch was das Eingangssignal angeht, sollte aber eigentlich die VESA Auflösungen können. Vielleicht ist die SYNC Polarität falsch oder sowas? Die kann ich (soweit ich das bisher gesehen habe) nicht programmieren, und um ehrlich zu sein weiß ich auch nicht wie die bei den SUNs eigentlich ist.


    Also noch ein Versuch, diesmal mit der AV.IO HD USB Video Capture Card (weil ich sonst keine geeigneten Monitore habe.) Erster Versuch mit 1600x1200x60:

    Sieht ja schonmal ganz brauchbar aus und ist auch tatsächlich in 1600x1200x60 :) Das Bild ist etwas nach rechts veschoben, das lässt sich aber mit v4l2-ctl justieren:


    (Die Farben sind leicht gegen einander verschoben, das liegt aber an einem billig-Adapter und tritt mit besserem Kabel nicht mehr auf.)


    Läuft also :juchee:


    Psst: Die Spielerei mit der LX hilft leider nur denjenigen die eine LX mit dem extra 1MB VRAM Modul haben. Nach diesem Erfolg bin ich jetzt aber motiviert mir auch meine TGX+ genauer anzusehen. Die haben nämlich 4MB Speicher und damit gibt es die Hoffnung diese für 1920x1200x60 zu programmieren!

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

  • Genial Malte! Ich würde mich dann für solch ein EPROM gern auf der Liste eintragen, die sowas käuflich erwerben wollen! Bombe!


    Ja bitte für die Pizzabox ebenso könnte mir vorstellen, dass OPENSTEP die neuen Settings dann auch anbietet.


    Ps: VSIMM für die LX und SS20 habe ich mir bestellt.

  • EEPROM schreiben und zuschicken kann ich gerne machen, muss nur erstmal Nachschub bestellen.


    Läuft deine LX schon? Falls ja, kannst du mir sagen welche OpenBoot Version du hast? Falls das eine andere als meine (2.10) ist könntest du mir das evt mitschicken damit ich es auslesen kann?


    Wo hast du denn für die LX ein VSIMM gefunden? Das würde mich interessieren.


    Ich denke mal ich sehe mir als nächstes die TGX+ an. Das ist aber mehr Arbeit weil das EPROM verlötet ist.


    Für die SX in der SS20 muss ich mal sehen. Der Code ist anders als für die CG6 und es gibt anscheinend weniger Doku dazu. Außerdem bräuchte ich dafür auch erstmal ein VSIMM... Es gibt aber zumindest schon Leute die darauf halbwegs erfolgreich 1920x1080 hinbekommen haben. Nicht mit VESA Standard Timings, aber immerhin. Da sollte aber auch noch mehr rauszuholen sein!

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

  • Achso, falls die LX noch nicht läuft würde mir schon die Nummer auf dem OBP reichen, also die 525-xxxx-xx . Es gibt mindestens die OBP Versionen 2.9, 2.10, 2.12, 2.14, und 2.20, jeweils in mehreren Varianten. Ich habe in meinen beiden LX jeweils nur 2.10.

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

  • So, weiter gehts mit einer kleinen Spielerei.


    Das OpenBoot bietet eine Möglichkeit ein eigenes (OEM) Logo einzustellen, indem man die NVRAM Variable oem-logo?=true setzt und in der Variable oem-logo das Logo speichert. Dabei ist das Format einfach eine 512 Byte Zeichenkette (also 4096bit) die für jeden Pixel des 64x64 großen OEM Logos anzeigt ob dieser weiß oder schwarz (bzw. sun-blau/weiß) ist. Es gehen auf diese Weise also nur monochrome Logos!


    Das bekannte SUN Logo findet man im PROM direkt hinter dem CG6 FCode (siehe auch meine Kommentare im Quellcode):


    logo.jpg


    Indem man das PROM ändert kann man aber auch sein eigenes 100x100 Pixel großes Bild mit 256 Farben (aus 24-bit) als Logo verwenden. Zum Beispiel die allseits beliebte Lena:


    lena.jpg


    Direkt hinter dem CG6 FCode im LX PROM findet man:

    Code
    00013220  64 64 ff ff ff e7 76 6c  6d 70 5b c9 aa 85 2d 64  |dd....vlmp[...-d|
    00013230  70 8c 72 00 41 54 64 7c  76 00 70 7a 6a 23 62 25  |p.r.ATd|v.pzj#b%|
    00013240  4a a1 b4 83 8a 5d 1e 4b  1e 38 5c 44 0a ba 39 76  |J....].K.8\D..9v|
    00013250  83 4b 6d 5e 00 7e 84 90  19 78 1a 80 76 4e 7d 61  |.Km^.~...x..vN}a|
    00013260  5d 3c 3c 3a 00 bf 27 42  38 28 62 8e 5a 81 84 7c  |]<<:..'B8(b.Z..||

    Die ersten 2 bytes sind die Breite und Länge des Logos, dann folgt eine Farbpalette mit 256 Einträgen die jeweils aus einem rot, grün und blau Wert bestehen. Anschließend dann 100*100 Pixel jeweils als Farbwert (aus der Palette.) Wichtig dabei ist noch dass Farbe 0 Weiß und Farbe 255 Schwarz sein müssen weil dies die Vorder- und Hintergrund Farben des sonstigen Textes sind.


    Woher kenne ich das Format des Bildes? Dazu muss man nur die entsprechenden Funktionen im weiter oben angehängten LX CG6 PROM Quellcode lesen.


    Ich habe mir ein kleines Programm geschrieben um Bilder vom SUN Rasterfile Format in das hier verwendete Format umzuwandeln. Die beiden Formate sind sehr ähnlich und das Programm entsprechend einfach. Den Quellcode lade ich zusammen mit allem anderen hier noch hoch.


    So, jetzt noch ein weiterer Schritt: das SUN Font finden wir auch im PROM:

    Code
    0000c390  66 6f 6e 74 00 00 00 0c  00 00 00 16 00 00 00 02  |font............|
    0000c3a0  00 00 00 20 00 00 00 e0  00 00 00 00 00 00 00 00  |... ............|
    0000c3b0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    0000c3c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
    0000c3d0  00 00 00 00 06 00 06 00  06 00 06 00 06 00 06 00  |................|
    0000c3e0  06 00 06 00 06 00 06 00  06 00 00 00 00 00 06 00  |................|
    0000c3f0  06 00 00 00 00 00 00 00  00 00 00 00 00 00 19 80  |................|

    Die ersten 4 Zeichen geben den Hinweis. Dann Breite (0x0c) und Länge (0x16) der Zeichen, also ein 12x22 Font. Was die (0x02) bedeutet weiß ich nicht. Folgen noch 0x20, das ist das erste folgende Zeichen (Leerzeichen) und 0xe0 (224), das ist die Anzahl der Zeichen. Also Zeichen von 0x20 bis 0xff. Dann folgen die Zeichen selbst, immer 2 Bytes pro Zeile und 21 Zeilen pro Zeichen. Ok, 2 Bytes verstehe ich noch, da werden einfach die letzten 4 bits ignoriert. Aber warum nur 21 Zeilen? Vielleicht ist die letzte Zeile einfach immer leer? Mal sehen.


    (Psst: Das SUN Font gibt es hier, das hilft dabei das Format zu verstehen.)


    ImageMagic kann schon TTF in beliebige Bildformate umwandeln, in diesem Fall bietet sich das XBM (X BitMap) Format an. Also musste ich nur noch ein kleines Skript drum herum schreiben um das beste Font aller Zeiten (Comic Sans MS) in das entsprechende Format zu konvertieren. Jemand anderes hatte zum Glück schon eine monospace Version von Comic Sans erstellt :)


    Der erste Versuch sah dann so aus:



    Man sieht (mindestens) 2 Fehler: die Zeichen sind gespiegelt und abgeschnitten, und es gibt teilweise irgendwelche Pixel unter den Zeichen. Okay, also was den ersten Teil angeht muss man die bits in der Kodierung umdrehen (MSB und LSB vertauscht.) Der Zweite teil hat auch eine einfache Erklärung: die Zeichen haben 22 Zeilen, aber nur 21 werden gespeichert. Die letzte Zeile ist dann immer die erste des nächsten Zeichens. Mit dem SUN Font funktioniert das, mit diesem hier leider nicht.


    Also nochmal an das Skript gesetzt und alles ein wenig kleiner gemacht damit immer eine Zeile frei bleibt. Jetzt sieht das Ergebnis doch schon viel besser aus:



    Ob das jetzt alles sinnvoll ist oder ein Sakrileg muss jeder für sich entscheiden ;)

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

  • Geht dass auch umgekehrt? Ich habe eine Ultra 10 mit einer Elite 3D Grafikkarte. Die zeigt beim Booten eine schöne "barocke" Sonne (ich weiss nicht, ob das die richtige Bezeichnung für den Stil ist) an. Ich hätte immer gern diese Grafik gehabt. Ich habe sogar schon dran gedacht, die Grafik zu fotografiern und dann nachzupixeln.

  • Verstehe ich richtig dass du gerne das alte CG6 Logo auf der Ultra 10 mit Elite 3D hättest? Ich vermute das ist machbar.


    Ich finde von der Elite 3D Bilder mit gesockeltem und mit verlötetem PROM. Je nachdem ist das halt unterschiedlich viel Arbeit.


    Könntest du das PROM auslesen wie ich in diesem Beitrag weiter oben beschrieben habe? Dann würde ich ja gerne schonmal sehen ob ich dieses Sonnenlogo extrahiert bekomme. Ich bin nicht sicher wie die AFB Geräte heißen, da müsstest du dich mal unter /devices umsehen.

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

  • Verstehe ich richtig dass du gerne das alte CG6 Logo auf der Ultra 10 mit Elite 3D hättest?

    Nein, ich wollte an der Sun selbst nichts verändern. Ich hätte einfach gern das Logo der Elite 3D als Bitmapdatei. Dann könnte ich es z.B. hier im Forum als Avatar verwenden. Oder ich könnte es auf ein T-Shirt drucken. Oder...

    Meine Sun ist im Moment nicht aufgebaut. Das müsste ich mal wieder tun.

  • Ich habe mich nur mal kurz bei meiner Ultra 60 unter /devices umgesehen und auf die schnelle nicht gefunden wie man das PROM der Karten auslesen kann. Dass geht sicher irgendwie, ich kann dir aber gerade nicht sagen wie. Ich sehe es mir bei Gelegenheit noch mal genauer an. Meine Elite 3D habe ich auch mal rausgekramt, die hat leider ein verlötetes EPROM, ich kann es also auch nicht so ganz einfach mal eben ausbauen und auslesen.

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

  • Ich habe mich gerade mal an die TGX+ gesetzt. Der gleiche 1600x1200x60 VESA Modus läuft auch hier perfekt. Bisher bin ich noch nicht so erfolgreich damit irgendwelche 1920x1080 oder 1920x1200 Modi zum laufen zu bringen. Mein bisher bestes Ergebnis ist dieses: (edit: nach einer Weile sieht es dann wie auf dem 2. Bild aus und wird fast lesbar.)



    Das ist natürlich noch nicht so toll...


    Eingestellt war hier eine 193MHz fast-VESA Auflösung. Eigentlich sollten das 193.25MHz sein, das lässt sich aber nicht erzeugen von dem timing chip. Evt. ist diese Abweichung das Problem? Ich habe auch diverse "reduced blanking" Modi getestet, die liefern aber praktisch kein Bild.


    Bisherige Experimente waren allerdings auch alle mit der AV.IO HD Video Capture Card. Ich versuche mal einen passenden Monitor zu organisieren für die weiteren Tests.

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

    Edited once, last by mdx ().