Sun 3/50 ROM 2.7 - disassembly

    Hier die ersten Versuche/Schritte, das ROM 2.7 einer Sun 3/50 zu disassemblieren - Mitarbeit willkommen!

    Ich habe wenig Ahnung davon und noch viel weniger Kenntnisse!

    Die Schwierigkeiten sind Daten von Instruktionen zu separieren.

    Die Sun3/50 nutzt eine 68020 CPU.


    Ziele:

    Mal sehen, wie man ein ROM Disassemblieren kann.

    Ggf. das ROM etwas besser verstehen und sehen was da wann und wie passiert.

    Adressen der Zeichenausgabe und Eingaberoutinen ermitteln um ein kleines Asm Testprogramm zu erstellen (Hello World für Boot Prom).

    etc. pp.


    Ich habe den m68kdis von hier genutzt unter Debian 11:

    https://raine.1emulation.com/download/dev.html

    Gibt es auch hier:

    https://github.com/cr1901/m68kdis


    Lt Dokument: Sun-3_Customer_Maintenance_Training_Sep88.pdf - Seite 14 liegt das Boot-Rom an 0x100000. Deshalb habe ich diesen PC Offset genutzt:


    1. Zuerst PC Liste erzeugen mit Daten (-020 = 68020; -pc = PC Offset):

    m68kdis -020 -pc 0x100000 sun3-50-2.7.rom

    Erzeugt sun3-50-2.7.rom.s


    2. Mit ghex mir das ROM angesehen. An 0x10b970 beginnt Text/Daten (ab 0x10e42d-0x10fffd = 0xff = leer)


    3. Mit VI alle Zeilen aus sun3-50-2.7.rom.s gelöscht, bis Adresse 0x10b970 (9000DD + nnDD...) und als sun3-data.txt gespeichert.


    4. Mit awk die erste Spalte = PC Adresse gefiltert und 0x vorgestellt:

    awk '{print "0x"$1}' sun3-data.txt > sun3-data.lst


    5. Neuer Disassembler Lauf:

    m68kdis -020 -pc 0x100000 -n sun3-data.lst sun3-50-2.7.rom


    Ergebnisse im anhängenden Zip.

    ---


    Evtl. machen ich noch etwas falsch? Was könnte man noch verbessern?

    Wie kann ich Adresse = Labels zuordnen?


    ---


    VG Peter

    Zunächst mal zu meiner Reihenfolge:

    Bei 68k-Code, der ein Gerät startet, schaut man zuerst auf den Vektor "ganz unten" im Adreßraum, hier der Reset-Vektor ab $0000.0004.

    Ab dieser Adresse ist Code, d.h. die ersten Befehle nach dem Reset. Hier offensichtlich ab $0fef.00ee. Dort muß ein ROM eingeblendet sein. Ggf. ist zum Zeitpunkt des Reset das ROM bei 0 und an anderer Stelle eingeblendet.


    Typischerweise werden mit den ersten Befehlen ein paar Hardware- und CPU-Sachen initialisiert, Interrupts gesperrt, ggf. das ROM von der Adresse 0, wo es zum Reset-Zeitpunkt sichtbar sein mußte, ausgeblendet, damit dort für den normalen Betrieb RAM auftaucht, usw.

    Ab dieser Adresse hat man sicher Code, der sich (hier mit der Option 68020) als erkennbaren Code disassemblieren lassen muß. Von da an geht man am Besten "mit dem Finger" durch den Code und erhält mit Hilfe von bsr/jsr-Befehlen weitere Einsprungpunkte, an denen Code steht.


    Dann geht's irgendwann mal 68k-typisch weiter: die große Vektortabelle, die beim 68000 immer ab 0 steht, bei den späteren 680x0-CPUs meist ab 0, wird aufgefüllt. D.h. man hat weitere Adressen, ab denen sicher ausführbarer Code stehen wird.


    Das alleine ist manchmal eine Beschäftigung für mehrere Tage :)


    Im 3. Schritt hat man einen Disassembler (ich kenne den Deinen noch nicht :( ), der Labels aus dem restlichen Code generiert. Die kann man verfolgen, um zu entscheiden, ob es wirklich Code ist. D.h. man schaut sich die Stelle(n) an, an denen das Label benutzt wird, dann den Code oder die Daten, die ab dieser Adresse sind. Das sind wieder ein paar Tage :)


    Im 4. Schritt schaue ich mir die ROM-Datei im Hex-Editor an und suche Strings (oder ich nehme "kstrings" unter OS-9 :) ), um Anfangsadressen von lesbarem Text zu erhalten. Denen gebe ich aussagekräftige Namen, die mir an anderer Stelle im Code weiterhelfen können dessen Bedeutung zu verstehen. In Deinem Fall finden sich lesbare Bereiche ab $b880 und insbesondere ab $b970.


    BTW ganz am Ende steht $443b. Dem würde ich ein Label geben, denn das ist möglicherweise ein CRC über den ROM-Inhalt.


    Gruß, Ralf

    Wenn man das ROM in Ghidra auf Adresse 0xfef0000 (statt 0x100000) lädt, sieht die Sache schon wesentlich besser aus. Ghidra kann dann jede Menge Strings zuordnen.


    Wie ich drauf gekommen bin ? Ich habe absolute String-Adressen gesucht. Bspw. die von "No Keyboard Found: " (Anfangs 100bb32). Gab erstmal keine Treffer. Dann nur bb32 gesucht und bei (Anfangs) 100142a gefunden. Aber als 0xfefbb32. Bei 1001436 wird auf fefbb64 ("Using RS232 Port A as input!\n") referenziert. Dann war's klar.


    Anbei ein Screenshot von Ghidra nach der Analyse. Quasi lesbarer Code ;)

    Wow. 1GB Installiert mit openJDK11.


    Und ich denke, da muss man sich erst einmal zurecht finden :(


    Ich habe zuerst ein Projekt angelegt.

    Dann das ROM an 0xfef0000 geladen.

    Danach code analyse..


    VG

    Gibt es dazu weitere Tips?

    Umbenenen von Strings z.B. in MSG01 etc. Umbenenen von Unterroutinen..

    Am Ende des ROMs von 0xe42d - 0xffff ist wohl leerer Platz (oxff)(bis auf die beiden letzten Bytes=CRC?).

    Solche Bereiche sollten sich ebenfalls ausblenden lassen?


    VG Peter

    github.com/petersieg

    Rechte Maustaste hilft.

    Labels kann man mit "L" umbenennen.

    Daten kann man mit "Data" (im Rechte-Maustaste-Menue) einen Datentyp geben. Da kann man auch Arrays bilden und größere Bereiche zusammenfassen.

    Für Konstanten im disassemblierten Assembler gibts 'Convert'.


    Einfach ausprobieren. Im Toplevel-Menue des Listing-Fensters gibt es "Undo" und "Redo" Pfeile.


    Ich hänge mal den Stand meiner aktuellen Bemühungen an.