8051 Disassembler

Thomas W. schrieb:
> Jedoch habe ich dann weder richtige labels

Woher soll der Disassembler auch wissen, wie die heißen sollen?

Thomas W. schrieb:
> weg um die #0C0h Sprünge zu entfernen

Seit Jahrzehnten programmiere ich mit dem MCS51, aber ich gestehe, dass 
ich mit deiner Aussage nichts anfangen kann. Was ist ein #0c0h Sprung?

Generell gilt, dass nach dem ersten Disassembler Lauf etwa 0.1% der 
Arbeit erledigt sind. Das Rückwandeln in lesbaren Quelltext kostet viel 
Geduld und Einfühlungsvermögen.

Viele Disassembler können keine konstanten Daten im Code erkennen, d.h. 
Werte und Texte werden in ein Befehlschaos umgewandelt, wobei die 
Synchronisation verloren gehen kann (8051: 1..3 Byte je Befehl).

Ein alternativr Weg wäre gewesen, das BIN-File hier zu posten, damit ein 
Mitleser "seinen" Disassembler darauf loslassen kann.

Es gibt Disassembler, die mehrere Durchläufe machen und damit interaktiv 
ein Steuerfile aufbauen, in dem diese "Stolperfallen" passend definiert 
werden. Disassemblieren ist immer ein mehrstufiger Prozess. Einfach mal 
ein Programm auf den Code loslassen und fertig ist Träumerei.

Beispiel "GD8051":
     :The 'controlfile' consists of entries of the form:-
     :# any line beginning with a '#' is a comment
     :Hd 1234 'header' -or- title of a subroutine
     :Cc 1234 this comment is tagged onto the line with this address
     :Cb 1234 this comment is written before the line with this address
     :Wc 1234:26     # defines word data, start address and count
     :Wo 1234        # defines word data
     :Wo 1234-1288   # defines range of word data
     :Lb 1234[,3456] # user defined label
     :Tx 1234,12     # defines text string and its length
     :Az 1234        # defines ascii zero terminated string
     :En 1234        # defines code entry address
     :En 1234[,2345] # defines list of code entry addresses
     :Er 1234;1256;3 # defines range of code entry addresses
     :Nw 1234 Word_Count  # defines name of ROM/external RAM address
     :Ni 56   Byte_Count  # defines internal RAM address name

Ok, vielen Dank für all eure Antworten.
Ich sehe schon, ich hab mir das wohl etwas zu einfach vorgestellt.
Ich dachte man könne einfach aus dem dissasemblierten code die werte 
entfernen, welche den Zeilensprung auf dem Display ausgeben und den code 
dann wieder assemblieren.
Ich habe sonst mal das BIN file angehängt.

Gruss,
Thomas

Hey vielen Dank Lothar :-)
Ich werde das mal so versuchen.

Georg G. schrieb:
> Das Rückwandeln in lesbaren Quelltext kostet viel
> Geduld und Einfühlungsvermögen.

Alternative: Die Einsprungstellen für den zu ändernden Code finden und 
auf den neuen Code in einem bisher ungenutzen Bereich vom ROM umleiten. 
Dann muss man den bestehenden Code nur so weit analysieren können, dass 
man diese Stellen findet. Zu echtem Quellcode umständlich 
rückzuübersetzen ist unnötig, im Binary patchen können reicht.

reas schrieb:
> Mist, zu früh abgeschicket:

Wenn du keine Antworten bekommst liegt es wahrscheinlich daran, dass 
hier niemand gern ein fremdes ".ZIP" öffnet!

Route 6. schrieb:
> dass hier niemand gern ein fremdes ".ZIP" öffnet!

Blödsinn.

Rufus Τ. F. schrieb:
> Route 6. schrieb:
>> dass hier niemand gern ein fremdes ".ZIP" öffnet!
>
> Blödsinn.

O.K. ich habe mich getraut, obwohl ich reas (Gast) nicht kenne.

Thomas W. schrieb:
> Dieses habe ich dann versucht mit dem d52 zu disassemblen. Jedoch habe
> ich dann weder richtige labels oder sonst was. Gibt es da einen
> einfacheren weg um die #0C0h Sprünge zu entfernen ?

Das Binary ist ein BASCOM8051 Kompilat.
Was ist jetzt genau deine Aufgabenstellung?
Was verstehst du unter "#0C0h Sprünge"? Der 8051 macht bei 0C0h einen 
PUSH ,bei Adresse 00C0h steht nicht wirklich ein sinnvoller 
Einsprungpunkt und wird auch nirgends im Binary augerufen.
Was willst du statt dessen?

gerade erst gesehen:
> Wenn man allerdings nicht in der Lage ist, diese Zusammenhänge richtig
> zu verstehen, hat man allerdings ein Problem.
Ich würde meine Hilfe gern zurückziehen, du A... (Eigenzensur)

Route 6. schrieb:
> Das Binary ist ein BASCOM8051 Kompilat.

Korrektur: Stimmt nicht.
Ich weiss jetzt auch, was das #0C0h Problem ist.
Ich hätte es anders, nämlich genau einmal gelöst, und nicht überall im 
Quelltext verstreut.

Das Original-Display ist HD44780 kompatibel und dort ist #C0h der Befehl 
zum Adressieren der zweiten Zeile. Der TO möchte aber ein neues Display 
verwenden, bei dem die Adressen anders sind. Deshalb muss er jetzt bei 
allen Text-Ausgaben den Befehl in #88h ändern. Erschwerend kommt hinzu, 
dass teilweise auch andere Koordinaten über Berechnungen adressiert 
werden. Also muss man das Programm disassemblieren und verstehen, die 
entsprechenden Stellen finden und dann das Binary patchen oder auch das 
Disassemblat ändern und zurückübersetzen.

Hi zusammen,

Vielen Dank für eure Antworten.
Ich habs jetzt mit der Hilfe von Georg hinbekommen, das binary mit dem 
GD8051 zu disassemblieren und mit dem as31 wieder zu assemblieren, das 
binary auf das Eeprom zu brennen und es läuft wieder.

Jedoch ist es genau so wie Mario schreibt... es ist wirklich Pain pur... 
das zeug ist über den ganzen code verstreut.
Ich habe schon beides probiert... einfach mal alle #C0h mit #88h zu 
ändern und auch die anderen Werte die #C0h überschreiten anzupassen um 
#38h kleiner.
Oder systematisch der Funktion für die Displayausgabe nachzugehen.
Das wäre hier O1153 und nur dort die werte anzupassen.

Mit der 1. Variante bin ich am weitesten gekommen, jedoch weiss ich 
nicht wirklich was ich sonst noch alles geändert habe ;-) mit der 2. 
funktioniert nur die hälfte der Displayausgabe richtig.
Ich finde das ist extrem verstreut. Ich hab das ASM file mal 
angehängt... die Änderungen sind mit ;-- kommentiert.

Mal noch eine andere Frage dazu, wüsste ev. jemand von euch ein mit dem 
originalen HD44780A00 kompatibles OLED welches ja auch ein 16x1 sein 
müsste aber wie ein 16x2 angesteuert wird ?
Dann würde ich nämlich einfach ein anderes Display nehmen.

Gruss,
Thomas

Thomas W. schrieb:
> müsste aber wie ein 16x2 angesteuert wird ?

Sorry ich meine natürlich ein 8x2...