D. A. S. S. I.
ATARI 800/130 (Cross-) Disassembler


Dieses DASSI-Hilfedokument besteht aus 1 HTML-Seite und 1 eingebetteten Bild.

Inhalt:


Ein paar Vorbemerkungen:

D.A.S.S.I. und andere Disassembler

Zunächst erstmal kurz zur allgemeinen Arbeitsweise von Disassemblern. Man unterscheidet hierbei die erste und zweite Generation. Disassembler der ersten Generation, sogenannte 'Line by Line'-Disassembler übersetzen den Maschinencode Zeile für Zeile, Referenzen und Programmcodeverzweigungen werden nicht erkannt. Diese Art von Disassemblern dürfte vielen ATARI Usern von Speichermonitoren wie SUBMON (Burkhard Rau) bekannt sein. Disassembler der zweiten Generation 'analysieren' teilweise den Opcode und können so verfolgend disassemblieren. Somit können Datenfelder innerhalb des Opcodes erkannt werden. Ein weiterer hübscher Nebeneffekt ist die Erstellung von Referenzlisten. Hier nochmal eine kurze Übersicht:

Line by Line Disassembler (1. Generation): Verfolgende Disassembler (2. Generation) - DASSI:
  • sehr schnell
  • wenig Speicherplatzbedarf
  • Umsetzung auf ATARI möglich
  • keine Erkennung von Datenfeldern
  • kein automatisches Abbrechen der Disassemblierung
  • manuelles Eingreifen notwendig
  • hohe Laufzeit, da mehrere Pässe notwendig
  • höherer Speicherplatzbedarf
  • solide Umsetzung nur auf PC möglich
  • 80%ige Erkennung von Datenfeldern
  • Abbrechen der Disassemblierung bei zur Laufzeit berechneten Verzweigungen
  • manuelles Eingreifen notwenig

Leider ist es durch o.g. Vor- bzw. Nachteile nur sehr schlecht möglich einen Disassembler dieser Art auf dem ATARI zu implementieren. Wer es trotzdem schafft sollte sich auf alle Fälle mal bei mir melden !


Spezielle Assemblerfeatures des ATARI (65C02-CPU)

Die 6502 CPU besitzt einige Features die eine Disassemblierung teilweise sehr erschweren, zum anderen den Programmierer dazu verleiten 'unsauberen' Code zu schreiben:

All diese Punkte tragen nicht gerade dazu bei ein ganzes Programm 100% automatisch erfolgreich zu disassemblieren. Es ist also prinzipiell davon auszugehen das man sich bei der Analyse eines MC-Programms Schrittweise vortasten muss. Zu einem guten Ergebnis kommt man meistens nur durch wechselseitigen Einsatz des Debuggers und des Disassemblers.



Bedienung des Programms:

Die Haupteigenschaften von D.A.S.S.I.

Im D.A.S.S.I. Grundbildschirm befinden sich folgende Hauptseiten:

Die Seiten werden teilweise automatisch gewechselt um ein bedienerfreundliches Arbeiten zu ermöglichen (zum Beispiel ist nach dem Fileladen das Fileprotokoll aktiviert, nach dem diassemblietren das Disassemblerprotokoll...).

Jede dieser Seiten ist als separates ASCII-File verfügbar und kann daher auch mit anderen Editoren weiterbearbeitet werden. Extern bearbeitete (zusätzlich kommentierte) ASCII-Files können genauso von der internen Verlinkung angesprungen werden wenn folgendes ASCII-Zeilenformat eingehalten wird:

0000: Menemonic                 ; Kommentar
xxxx............................                 Adresse Hexadezimal: 0000-FFFF
....x...........................                 : Doppelpunkt nach Adresse ist Pflicht
.....x..........................                 Das Leerzeichen sollte eingehalten werden
......xxxxxxxxxxxxxxxxxxxxxxxxxx                 Rest der Zeile ist egal


Vorgehensweise beim Disassemblieren

Vorab einige Tips - (FAQ):

Schaltet das DASSI-Fenster in den Vollbildmodus, einige Fenster/Anzeigen sind unterhalb 800x600 nur schwer erkennbar bzw. mit dauerndem wechseln der Fensterpositionen verbunden! Ich werde keinen Schritt zurückgehen um das Programm z.B: auf 640x480 vollständig sichtbar zu machen, da ich mich in einem halben Jahr ärgen werde über die verschwendete Zeit, wenn bei ALDI 25" Monitore und P777 Standard sind. !!!

Ebenso verhält es sich mit der CPU-Rechenleistung. Also, wenns irgendwo (zum Beispiel während der Echtzeitdisassemblierung, unten rechts) zuckt und zerrt oder beim Hex/Ascii-Dump, dann mault bitte nicht über das Programm, in einem halben Jahr ist dieses Thema unerheblich. Ich habe das Programm auf einem 'alten' (kein MMX) P200 geschrieben (1024x768), dort läuft es in einer Geschwindigkeit mit der man sehr gut arbeiten kann.

Die Erzeugung von Refernzangaben im Sourcefile sollte ausgeschaltet sein sofern die Ascii-Texte nicht mit anderen Programmen weiter bearbeitet werden, da im DASSI stets alle Referenzen in Echtzeit in einem zweiten Fenster dargestellt werden, eine zusatzliche Angabe im Sourcefile 'zerreist' den Text und macht ein sauberes Lesen fast nicht möglich, für eine Weiterbearbeitung im Texteditor ist dies jedoch durchaus sinnvoll.

Die Referencelist-Erzeugung sollte normalerweise ausgeschaltet sein, sie benötigt rund 40% der Disassemblerzeit und ist zur Zeit noch nicht abbrechbar, also am besten erst zuschalten wenn alle analysierten Punkte markiert sind, oder um zwischendurch mal um einen Überblick zu erhalten.

Ein Disassembleraufruf der Adressen $100-$3ff (Systembereich) sowie $c000-$ffff (OS-Bereich) führen zum Abbrechen der Disassemblierung sofern diese Bereiche in den Voreinstellungen nicht als Programmcode freigegeben werden! Wenn also bestimmte Programme Routinen z.B. ab $100 (eigentlich Stackbereich) dann bitte das Häkchen in den Voreinstellungen setzen, ebnso wenn ein Programm analysiert werden soll das 'unter' dem OS liegt ($c000-$ffff).

Auf eine Menüleiste hab ich bis jetzt verzichtet da immernoch alle Funktionen über rechte Maustaste bzw. Toolbar erreichbar sind. Die Menuleiste schröpft die Gesamtansicht um eine Zeile, obwohl diese nur noch sehr wenig benutzt wird, da diese eine erheblich höhere Navigierzeit erfordert !

Die vom Disassembler benutzten OPCodes sind in einer separaten Ascii-Liste zugänglich (Ass65xx.tab, wird nach Programmeustart geladen!). Der Disassembler erkennt zur Zeit noch nicht alle möglichen illegalen Opcodes. Wer diese Liste ergänzt, um einige mir zur Zeit unbekannte (illegale!) Opcodes, sollte mir die Liste ebenfalls zuschicken, damit ich auch auf dem aktuellen Stand bin. Ebenfalls würde ich mich sehr über eine Angabe der Registermodifizierungen der jeweiligen Befehle freuen, da ich diese Funktionen dann in den integrierten Debugger übernehmen könnte.

Öffnen einer Datei zur Disassemblierung:

Es kann sich hierbei um ein ATARI-COM-File (Header $FFFF) handeln, oder um eine ATR-Diskette (Header $9602). Beim Öffnen eines COM-Files wird dieses in den Speicher geladen und analysiert, die Einsprungpunkte werden gemerkt. Beim Öffnen einer ATR-Diskette werden die Bootsektoren in den Speicher geladen, hierbei werden ebenfalls die Ansprungpunkte gemerkt. Das Protokoll des Ladevorgangs ist in der Liste 'Filestructure' nachzulesen. D.A.S.S.I. kann ebenfalls von außen (z.B: ATARI Filelister) per Kommandozeile gestartet werden. Hierbei ist einfach der Dateiname des zu disassemblierenden Files in der Kommandozeile als erster Parameter anzugeben. ATR und COM-Files werden am Header, nicht an der Endung des Dateinamens erkannt. Als zweiten Parameter kann man ein 'D' angeben um automatisch den ersten Disassemblerlauf zu starten.

Zur Anzeige von PC-XFD-Files sollte ein Startprogramm wie zB. der ATARI-Filelister von Burkhard Rau benutzt werden.

Aufruf des Disassemblermoduls:

Durch betätigen des Buttons 'Disassemblerstart' in der Toolbarleiste wird das Disassemblermodul aufgerufen. Achtung! Ist kein gültiges File geöffnet, ist dieser Button grau hinterlegt und kann nicht aktiviert werden! Der Disassembliervograng kann mehrere Sekunden (min. 486er/ Pentium) dauern und sich über meherere Pässe erstrecken. Ein Rollbalken zeigt den aktuellen Fortschritt. Nach dem disassemblieren kann in der Liste 'Logfile' der aktuelle Status abgelesen werden. Entdeckte Fehler müssen von hand nachkontrolliert und beseitigt werden, da durch diese ein weiteres Quellcodeverfolgen unter umständen nicht möglich ist. Der häufigste Fall ist hierbei das Auflaufen auf ein Datenfeld (ungültiger Opcode). Diese Datenfelder müssen von Hand als solche kenntlich gemacht werden. Unter folgenden Konstellationen versagt die automatische Datenfelderkennung:

Ein weiteres Problem ist das Abbrechen des Disassemblers da dieser Programmverzweigungen nicht erkennt. Dies kann in folgenden Situationen geschehen:

In all diesen Fällen ist der Debugger zuhilfe zu nehmen, neue Startpunkte des Disassemblers sind von hand einzutragen, der Disassembler muss anschliessend ein weiteres mal gestartet werden.

Aufruf des Debuggers:

Einen aktuellen Status der ATARI Register kann man in der Kopfzeile der Liste 'Sourcelist' ablesen. Bedient wird der Debugger über die Buttons:

Manchmal kann ein 'Hängen' des Debuggers vorkommen, da zum Beispiel ein Programmcode auf bestimmte Werte im Register $14 (wird im ATARI permanent inkrementiert) wartet, diese Funktionen werden jedoch von DASSI (noch) nicht simuliert! Ebenfalls hängt der Debugger gerne in Tastatureingabeschleifen o.ä., die DASSI auch (noch) nicht simuliert! Ein 'Hängen' lässt sich durch geringe, periodisch gleichmässige, Änderungen der PC-Register-Anzeige erkennen. In diesem Falle ist der Debugger mit Button 'STOP' abzubrechen.

Das Browsen im Quellcode lässt sich mit dem Debugger angenehmer gestalten, da man so schnell JMPs der JSRs verfolgen kann. Man braucht sich auch in diesem Falle die Ansprungadressen nicht merken, der Debugger verzweigt beim RTS wieder zur übergeordneten Routine.

Viele ATARI-COM-Files laden auf Adressen an denen sie nicht lauffähig sind. Hier leistet der Debugger ebenfalls gute Dienste. Meist besitzen solche Programme eine kleine Transferroutine, die den Speicherbereich kopiert und anschliessend den neuen Bereich anspringt. Beim ersten Disassemblierversuch bricht hierbei der Disassembler meist ab, da ja nicht wirklich transportiert wurde und somit meist auf dem Sprungziel ein BRK ($00) ihn erwartet. In einem solchen Fall benutzt man den Debugger wie folgt:

Der Debugger führt nun den ATARI-Opcode aus, d.h. er transferriert (relokiert) den Programmcode und bricht am Ende der Routine ab (Breakpoint). Nun kann man wieder das Disassemblermodul starten, das beim erneuten Durchlauf wesentlich weiter kommen wird...

Arbeiten mit dem Disassembler:

Da es prinzipiell* notwendig ist das Programm selbsttätig zu analysieren, ist es notwendig den Debugger bzw. den Disassembler während der Anlaysearbeit sehr oft zu starten. Ein zwischenspeichern der aktuellen Projektdaten sind über die Toolbar möglich (um am nächsten Tag weiterzumachen!)

* bei den von mir vollständig disassemblierten, zufällig ausgewählten, rund 20 Atari- Programmen, war es leider nur möglich eines, nämlich 'behind jacki lines' von Lucasfilm auf dem ersten Anhieb vollständig zu disassemblieren. Ich möchte dieses Prgramm nicht loben, es ist ganz einfach eines der solidesten Atari-Programme die je geschrieben wurden.

Einige Zusatzinfos:

Arbeitsweise des Disassemblermoduls

Arbeitet der Disassembler im Verfolgungsmodus, so analysiert dieser den Opcode ab den anfangs angegebenen Startpositionen (INIT,- EXEC- Adresse vom COM-File oder Startpunkte von Handeingabe). Der Opcode wird abgesteppt (verfolgt) und an folgenden Stellen verzweigt bzw. abgebrochen:

Alle Datenzugriffe (zB. LDA,STA) werden gemerkt und als solche im Listing sichtbar gemacht. Dabei bestitzt Programmcode gegenüber Datenfeldern Priorität, um eine ordentliche Darstellung von selbstmodifizierenden Code sicherzustellen.



An die ATARI-Freaks, Anmerkungen des Autors:

Dieses Programm ist FREEWARE ! Dieses Programm darf nur komplett und in Gesamtheit weitergegeben werden! Den Rest spar ich mir jetzt mal.

Wer will kann eine 3,5'' PC-Diskette mit der aktuellsten Programmversion und dem aktuellen Ausdruck dieser Anleitung zugeschickt bekommen (10,-DM inkl. P+V, bar oder Scheck).

Ich wollte eigentlich nur mal sehen wie sich ein verfolgender Disassembler mit automatischer Datenfelderkennung programmtechnisch umsetzen lässt (und etwas Windows-Programmierung üben). Ich bin mit dem Resultat (Disassemblermodul) ganz zufrieden, musste aber auch gleichzeitig, um ein Programm zu erhalten mit dem sich halbwegs Arbeiten lässt, einige Zusatzfunktionen einbauen, an die ich zuerst nicht gedacht habe. Eines dieser Features ist der Debugger, ohne den es bei ATARI-Programmen nicht weiter geht. Da ich gar nicht vorhatte solche Funktionen einzubauen (ein Debugger mit umfassenden Features kann ein eigenes Programm darstellen) sind die einzelnen Bestandteile nicht sehr ausgereift. Mir ist klar das die meisten Teile des Programms (Disassembler, Debugger, Hexeditor...) einer Vervollkomnung bedürfen um alle Funktionen abzudecken. Betrachtet das Programm also als Minimalversion.

Ich wollte kein 'cracker-program' schreiben (was soll überhaupt die Frage?) !!! Es gibt sowieso keine aktuellen ATARI-Porgramme mehr und wer die mittlerweile üblichen (symbolischen) 2,-DM für eine Originaldiskette nicht aufbringen kann sollte seinen ATARI einstampfen!!! Die Leute, die sich heutzutage mit Ihrem ATARI noch beschäftigen, betreiben dies mit einem sehr hohen ereifernden und emotionalen (und natürlich finanziellen) Aufwand, den es zu Glanzzeiten des ATARIs nie gab!!! Es braucht niemand zu versuchen mir zu erklären, das mein Programm nicht einer Weiterbildungsmassnahme enstpricht, sondern 'illegalen Copyrightverletzungen förderlich ist' !!!

Wer verfügt eigentlich heutzutage noch über das Wissen auf dem ATARI Copyrightverletzungen durchzuführen ???. Um es aber der Vollständigkeit halber zu erwähnen ... ' Die Benutzung dieses Programms ist nur zum Zwecke der Weiterbildung erlaubt !!! '

Falls ich einiges Feedback bekomme und Leute da sind die sich für Erweiterungen des Programms interessieren, werde ich über diese nachdenken (natürlich auch über eine bessere Hilfedatei). Ideen sind genug vorhanden (man sieht das an den grau hinterlegten Funktionen im Programm). Oder einiges anderes wie zum Beispiel:

Falls es jedoch keine weiteren Anfragen gibt, betrachte ich es als nettes, kleines, abgeschlossenes Experiment.

6.10.1998   André Bertram.


MacFalkner@aol.com (André Bertram)        HCRBurk@t-online.de (Burkhard Rau)