TMS 7000 Decompilieren in Ghidra

[Johannes M. (jojo20)]

Hallo,

ich kenne mich ein wenig mit Ghidra aus und versuche gerade ein Programm 
gemacht für den TMS70C02 im Full Expansion Mode zu decompilieren.

Dazu habe ich folgendes Modul in Ghidra geladen: 
https://github.com/benpye/tms7000

In der Memory Map von Ghidra habe ich den ROM Speicher Bereich definiert 
und als Read Only markiert. Ebenso habe ich ein in der Schaltung 
vorhandenes externe RAM definiert und als RWX markiert.

Nun bekomme ich zwar relativ viel decompiliert, habe aber immer wieder 
Bereiche von Funktionen mit Daten die unbekannt sind. (Beispiel im 
Screenshot)

Was mache ich falsch?

Ich vermute Ghidra weiß nicht, dass der TMS im Full Expansion Mode 
laufen soll da ich auch Dinge sehe wie z.B. P13 = 0x12;

Letzendlich möchte ich ja nicht wissen welche einzelenen Schritt In der 
CPU laufen, sondern welche Adresse im RAM oder Rom gelesen wird. Ist die 
Frage ob das überhaupt möglich ist? Weil dafür letztendlich ja die 
ganzen ASM Befehle ablaufen müssen in der CPU, Ghidra müsste diese 
Muster nur zum decompileren in den C-Code erkennen können.

[Cartman E. (cartmaneric)]

Versuchs mal mit dasmxx.

"dasmxx provides a suite of disassemblers for a variety of popular 8-bit 
and 16-bit microprocessors."

Die TMS7000 Serie kennt so etwas wie "user defined opcodes".
Hast du das in Betracht gezogen?

[Johannes M. (jojo20)]

Den hatte ich auch gefunden, bin aber davor zurückgeschreckt erst alles 
compilieren zu müssen.

Außerdem bin ich denke ich nicht fit genug mit dem reinen Assemblercode 
um das rauszufinden, was ich rausfinden möchte.

Aber dann versuche ich mal dasmxx zu compilieren um das ASM Ergebnis zu 
vergleichen.

[Cartman E. (cartmaneric)]

Johannes M. schrieb:
> Außerdem bin ich denke ich nicht fit genug mit dem reinen Assemblercode
> um das rauszufinden, was ich rausfinden möchte.

dasmxx ist nur ein simpler Dissassembler und kein IDA Pro.
Er braucht u.U. auch Hilfestellung bzgl. der Speicherbereiche.

Aus den Beispielen:
ffirmware.bin
q,30
c8000

p804d Reset
p91a1 INT1_Handler
p91c3 INT2_Handler
p922e INT3_Handler
p9279 INT4_Handler
p9282 INT5_Handler

bf2d2

vfff4 Vector_Table
effff

[Johannes M. (jojo20)]

Es scheint so, als wenn Ghidra manchmal Daten als ausführbaren Code 
interpretiert. Also komme ich erstmal so weiter.

Allerdings hänge ich gerade ein wenig an der Funktion der die Checksumme 
des Eproms berechnet. Ich verstehe nicht wie die Checksumme genau 
berechnet wird.

Meine Vermutung ist, dass die Checksumme als 16 bit Wert an Adresse 
0x5000 steht.

Ich versteht es so, als wenn ab Adresse 0xf800 der Inhalt der Adresse in 
R98 addiert wird.

Aber bis wohin? Und eigentlich macht mit der Aufbau des Eproms Adresse 
0xf800 kein Sinn. 0xFFFF wäre logischer.

R88 wird in der Funktion gar nicht initalisiert. Wofür BTJO 
%0x1,R88,LAD_d489  geprüft wird verstehe ich gar nicht.

Zum Schluss dürfte dann der Wert aus Adresse 0x5000 mit der Checksumme 
aus R99 verglichen werden und JZ LAB_d4d5 entscheidedt ob die Checksumme 
korrekt ist oder nicht.

Kann mir jemand beim ASM Code auf die Sprünge helfen?

[Thomas Z. (usbman)]

Johannes M. schrieb:
> Kann mir jemand beim ASM Code auf die Sprünge helfen?

warum exportierst du das als jpg?. Jeder der aktive Hilfe will würde den 
Ausschnitt als txt zur verfügung stellen.

Übrigens: man kann Variablen auch sinnvoll umbenennen. R100 usw ist 
nicht so aussagekräftig. Ich bin mir sicher dass Ghitra auch erlaubt 
Kommentare zu vergeben.

Also in der Art

   MOVD  %0xF800, R98       ; Start_Value = 0xF800
   MOVD  %0x0000, R100      ; ChkSum = 0;
   ...