home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
World of A1200
/
World_Of_A1200.iso
/
programs
/
develop
/
d68k
/
d68k.doc
< prev
next >
Wrap
Text File
|
1995-02-27
|
31KB
|
790 lines
D68k Version 1.90 von Denis Ahrens 1993 ShareWare
D68k ist ein FILE-Disassembler für den MC68000,68010,68020,68030,
68040, FPU 68881,68882 und die PMMU 68851.
Man kann mit D68k alles disassemblieren was aus Hunks besteht, also
auch Objektfiles und amiga.lib's. Desweiteren kann D68k auch
Bootblöcke disassemblieren die als File abgespeichert wurden.
(Die ersten drei Bytes müssen den Text 'DOS' enthalten.)
D68k ist vollständig in MC68000 Assembler geschrieben, und
läuft nur mit OS V2.x oder höher ( dos.library >= 37, und wenn nötig
asl.library >= 37). Der Rechner selbst spielt keine Rolle.
Schnell muß der Rechner NICHT sein. Falls der ASL-FileRequester
benutzt wird, empfehle ich ASL.lib Version 38 oder höher.
D68k ist auf (m)einem Amiga 1000 mit MC68010 2MB FRAM und 130MB
Seagate AT-BUS HD unter OS2.1/3.0 geschrieben worden.
D68k wurde mit A68k 2.71 und bLink assembliert und gelinkt.
Das File-Datum von D68k muß mit dem im Programm übereinstimmen.
Der Source-Code ist ca. 13400 Zeilen lang (248kB).
Das Programm D68k ist SHAREWARE.
Aber es soll jeder selber entscheiden, was Ihm D68k Wert ist!
Für Leute die sich nicht entscheiden können, schlage ich DM 15,- vor.
Die Share-Ware Gelder setze ich für Fachliteratur ein.
(Habe aber noch NICHTS bekommen, SCHADE)
(Die Qualität dieses Programmes hängt davon ab (fast))
D68k sollte (darf) nicht benutzt werden um Schutz-Techniken von
Programmen zu entfernen.
Das Programm D68k darf nur ZUSAMMEN mit der Anleitung verbreitet werden.
Die kommerzielle Nutzung und/oder Verbreitung des Programmes
bedarf meiner SCHRIFTLICHEN Erlaubnis. Auch die Verbreitung in
KOMMERZIELLEN (gebührenpflichtigen) PD-MailBox-Systemen ist NICHT
gestattet.
Der Schreiber des Programms übernimmt keine Haftung für materielle
oder geistige Schäden, die durch D68k entstanden sind - entstehen werden.
Das Benutzen des Programmes geschieht auf EIGENE Gefahr!.
*******************************************************************************
SCHNELLSTART
Er wird über das CLI gestartet mit Angabe des Files das
Ihr disassemblieren wollt.
Man kann die Ausgabe mit Control-C jederzeit abbrechen.
Falls die Ausgabe im CLI-Fenster 'läuft', kann man mit einem Tasten-
druck die Ausgabe anhalten und mit einem Druck auf die Backspace-Taste
fortsetzen.
z.B.:
1> D68k ram:Prgs/exep04
würde so aussehen:
-------------------------------------------------------------------
01:D68k V1.xx MC68000-68040,MC68881/82,MC68851 Disassembler
02:Copyright DD.MM.93 by Denis Ahrens
03:
04:00000001 00288E20 00000040 00000004 00391828 00000000 00000000
05:
06: CODE ;000 000004
07:
08:000000 4AFC ILLEGAL
09:000002 4E71 NOP
10:
11: ;Hunk-END
-------------------------------------------------------------------
Die Zeilennummern am Anfang gehören natürlich NICHT dazu!
In der vierten Zeile sind StatusInformationen die NUR für mich
sind (zum debuggen).
Für Interessierte:
1. Langwort: Anzahl der Hunks (Nicht der Wert aus dem HUNK-HEADER!!)
2. Langwort: SpeicherAdresse der Hunktabelle
3. Langwort: Größe der Hunktabelle (Hunks * 64 Bytes)
4. Langwort: Länge aller CODE, DATA und BBS Hunks zusammen
5. Langwort: SpeicherAdresse der LabelTabellen
6. Langwort: Anzahl der gefundenen Labels
7. Langwort: Anzahl der sortierten Labels
In der sechsten Zeile steht der HunkName (CODE) mit der Nr. (0)
und der Länge in Bytes (#4).
In der achten und neunten Zeile steht (endlich) der PC
des Hunks, der MaschinenCode und am Ende das (der,die) Mnemonic.
In der elften Zeile kommt dann die EndHunk-kennung.
*******************************************************************************
DIE AUSGABE
Bei RELOCxx-Hunks (Reloc32,16,08) wird die Anzahl der zu korrigierenden
Adressen angezeigt. Das ist praktisch zum Optimieren eigener
Programme. Wenn man mit relativer Adressierung arbeitet, erkennt
man so schnell, ob man eine Zeile ohne relativ-code geschrieben hat.
Bei SYMBOL-Hunks die Anzahl der Symbole.
Bei UNIT- und NAME-Hunks werden die Namen angezeigt.
Bei EXTERN-Hunks werden die Inhalte der Typen <$80 angezeigt.
Wenn D68k einen Bootblock erkennt wird anstelle des Hunk-Namens das
Wort BOOTBLOCK ausgegeben. Die CODE-Größe ist auf 1024 Bytes minus
3 Langwörter beschränkt. (FileSystem-Kennung,Checksumme und Rootblock)
Um den Code mit A68k zu Re-Assemblieren muß man am Ende des
'Textes' ein " END" anfügen.
Eventuell muß man den Code noch an seinen persönlichen
Assembler anpassen (Ich hoffe nicht).
*******************************************************************************
EINIGE ERKLÄRUNGEN
Während die Power-LED dunkel ist, sucht D68k die Labels.
Wenn die LED wieder hell wird, sortiert D68k die Labels bis
die Ausgabe anfängt. (Hier kann man die Geschwindigkeit der
QuickSort-Routine beobachten.)
Wenn D68k einen Befehl NICHT erkennen kann, (und er kennt ALLE Befehle)
oder ein Befehl eine NICHT zulässige Adressierungsart hat, wird
er NICHT angezeigt (z.B. JMP D0 oder JSR (A0)+ ). Stattdessen wird ein
Word als Hexzahl ausgegeben.
Bei Befehlen mit Byte-Konstanten, bei denen das high-order-byte NICHT
NULL ist, wird auch das als illegaler Befehl interpretiert. Da aber
manche Assembler/Compiler das Byte per EXT.W zum Wort erweitern
(was FALSCH ist), wird bei negativen Bytewerten der Wert $ff im
high-order-byte eingetragen. Dies wird von D68k berücksichtigt.
Das high-order-byte muss also $00 oder $ff sein.
*******************************************************************************
Die NORMALE Methode (TRACE ist nicht eingeschaltet)
Der Nachteil liegt darin das bei der 'normalen' Methode nach einem RTS
zum Beispiel der Text 'topaz.font",0 auch disassembliert würde.
Dadurch entstehen wirre Befehle, weil sich Datas und Befehle oft nicht
unterscheiden lassen. Unglücklicherweise liegen die kleinen Buchstaben
als ASCII-Code bei $60-70, und genau dort sind die ganzen BRANCH- und
MOVEQ-Befehle. Durch die BRANCH Befehle werden Fehl-Labels erzeugt und
dadurch wird die Ausgabe undurchschaubar.
In manchen Disassemblern werden NICHT angesprunge Befehle im Code-
Hunk als Data-Zeilen angezeigt. Da dies nicht immer klappt, geht
das NICHT mit D68k. Bei der 'normalen' Methode werden im CODE-Hunk NUR
Datas angezeigt wenn KEIN Befehl erkannt wird. Wenn ein Programm nur
MC68000 Befehle enthält und Daten oder Texte von D68k als MC68010
Befehle (oder höher) erkannt werden, klappt das natürlich nicht.
Aber meiner Meinung nach haben Daten in Code-Hunks nichts zu suchen.
Falls D68k Libraries im Code-Hunk erkennt werden diese umgangen.
In PASS1 wird die Länge des Library-Textes übersprungen und in PASS2
wird auf Daten-Ausgabe umgeschaltet. Folgende Libraries werden
unterstützt falls sie an einer geraden Adresse beginnen:
68040.library dos.library
icon.library intuition.library
expansion.library utility.library
gadtools.library graphics.library
iffparse.library workbench.library
asl.library locale.library
bullet.library commodities.library
diskfont.library exec.library
.library .device
*******************************************************************************
DIE TRACE-Methode !!!!!!!!!!!!!!!!!!!!!!!!
Der Unterschied zur normalen Methode ist der, das D68k im ersten PASS
nicht einfach geradeaus durchdisassembliert, sondern bei einem
UNBEDINGTEM Sprung (BRA.x, JMP.x, RTS oder RTx) anhält und sich eine
Adresse holt, die vorher vermerkt wurde, und dort weiter
disassembliert u.s.w. Alle so abgearbeiteten Adressen werden als
Befehle markiert.
Falls ein Programm aber eine Adresse mit dem Befehl LEA in das
Adressregister A2 'ladet', und dann per JSR A2 verzweigt kann die
TRACE-Methode das nicht nachvollziehen. Die Befehle werden dann nicht
markiert und werden deshalb im zweiten PASS als Datas ausgegeben weil
D68k diese NICHT als CODE vermerkt hat. Um diesen Umstand auszugleichen
besteht die Möglichkeit, ein Text-File anzulegen das eine Tabelle enthält,
in der die Adresse(n) steht, die mit dem LEA-Befehl nach A2 geladen wurde.
D68k kann dann per Option das File einlesen, und die Adresse in die
interne SprungTabelle eintragen, um auch diese, vorher nicht erkannten
Befehls-abschnitte disassemblieren zu können.
BEISPIEL:
Man disassembliert den LIST Befehl folgendermaßen:
1> D68K "c:Loadwb" TO "ram:loadwb.asm" TRACE RLO
dann betrachet man das Ergebnis mit einem Editor und sucht Data-Stellen
die nach Befehlen aussehen. (Z.B. kurz vor dem nächsten Label steht der
Wert $4E75, der dem Befehl RTS entspricht)
Im T: Verzeichnis sollte jetzt ein File mit dem Namen 'JumpList.Loadwb'
abgespeichert worden sein. Ladet dieses File mit einem zweiten Editor
ein. Die Adressen die Ihr im letzten Schritt gefunden habt könnt
Ihr nun am ENDE diese Files eintragen.
D68k interessieren nur zwei Hex-Zahlen pro Zeile die mit einem Komma
getrennt sind und mit einem Dollarzeichen ($) beginnen. Das Hex-
Zahlenpaar muß (noch) am Anfang der Zeile stehen.
Als erste Zahl muß die HunkNummer, und als zweite Zahl die Adresse
eingetragen werden. Die Hunknummer steht immer am Anfang des Hunks
(an Adresse Null) im Dezimalformat. Ihr müsst also die Zahl noch
umwandeln.
________________________________________________
;
; D68k V1.83 JumpList for 'Loadwb' V38.9
;
$00015455,$00000470 ;Die File-Identifikation und File-Größe
$00,$00035E ;hier kann man Bemerkungen eintragen
$00,$0003B4
________________________________________________
Die Versionsnummer solltet Ihr auch eintragen. Dann kommt Ihr nicht
durcheinandner, wenn Ihr vom dem Programm eine neue Version erhaltet.
Wenn D68k eure JumpList nicht akzeptiert, dann stimmt die File-
identifikation in dem JumpList-File NICHT mit dem eingeladenen File
überein.
Speichert das File unter dem Namen 'JumpList.Loadwb' in diesem
Verzeichnis ab:
!!! SYS:Prefs/Presets/D68k/
Jetzt gebt folgende Zeile ein:
(Editor im hintergrund laufen lassen)
1> D68k "C:Loadwb" to "ram:Loadwb.asm" TRACE RLO JUMPLIST
Nun könnt Ihr wieder zum Editor umschalten und das File "Loadwb.asm"
nocheinmal einladen. Die vorher nicht erkannten Befehle sind nun
ordentlich disassembliert. Falls noch weitere Befehls-abschnitte
NICHT disassembliert wurden, könnt Ihr weitere Adressen in dem
JumpList-File eintragen und die letzten Schritte wiederholen.
Meistens genügt es, wenn man eine Adresse einträgt, denn hierdurch
werden meist weitere Adressen vermerkt wodurch ev. eine Ketten-
reaktion entsteht.
Als Editor emfehle ich CED. Dort kann man in einem Fenster (oben) das
File "Loadwb.asm" nach Adressen absuchen und in einem zweiten Fenster
(unten) das File "T:JumpList.Loadwb" bearbeiten.
------------------------
Wer es eilig hat, kann die fertigen JumpListen mit dem Verzeichnis D68k
in das SYS:Prefs/Presets Verzeichnis kopieren. Wenn Ihr die gleichen
Versionen der dortigen Programme 'besitzet', könnt Ihr diese gleich
benutzen, da ich die Adressen schon eingetragen habe.
Nochmal der vollständige Pfad der JumpListen:
SYS:PREFS/PRESETS/D68K/JumpList.Loadwb
------------------------
Es gibt zwei Methoden von NICHT erkannten Sprung-Adressen, einmal mit
Label und einmal ohne Label.
1.
Falls die von euch als Befehle identifizierte Routine ein Label hat,
kann man das File "Loadwb.asm" nach diesem Label absuchen (mit der
Editor-Suchroutine) und den weiteren gebrauch der Adresse verfolgen.
So stellt man sicher das es sich wirklich um eine Befehls-Routine handelt.
2.
Wenn der Routine kein Label vorangestellt ist, dann solltet Ihr das
File "Loadwb.asm" nach JSR's und JMP's durchsuchen. Wenn ein solcher
Befehl relativ springt (z.B. JSR (A0) oder JMP 0(PC,D0.l) dann solltet
Ihr verfolgen wie das Ziel des Sprunges errechnet wird. Falls kein
Sprung zu dieser Adresse zu finden ist, handelt es sich vielleicht um
eine 'tote' Routine die NICHT angesprungen wird. Wenn Ihr euch ABSOLUT
sicher seid, könnt Ihr diese Routine entfernen.
DIE TRACE-LOGIC (1)
Um die TRACE-Methode noch sicherer zu machen, werden von D68k
auch SprungTabellen erkannt die per JMP L000012(PC,D0.W) springen.
Diese Tabellen sehen so aus, wenn sie von D68k als solche erkannt wurden:
...CMPI.W #$0014,D1 ;Anzahl der Einträge
BGE.W L000016 ;Bei Überlauf verzweigen...
ADD.W D1,D1 ;Verdoppelung (wegen Wortgröße)
MOVE.W L00000F(PC,D1.W),D1 ;relative Distanz holen
JMP L000010(PC,D1.W) ;und springen
L00000F:
dc.w L000011-L000010 ;hier stehen die Differenzen
L000010: ;vom DIESEM Label aus
dc.w L000011-L000010 ;bis zum Sprungziel.
dc.w L000012-L000010
dc.w L000013-L000010
dc.w L000014-L000010
dc.w L000015-L000010
u.s.w....
Da die TRACE-Methode sehr gut ist, wird die DATALOGIC übergangen.
Auch die RTSLOGIC sollte ausgeschaltet werden. D68k sucht auch nicht
mehr nach Libraries, wie bei der normalen Methode.
*******************************************************************************
DIE OPTIONEN VON D68k:
? Listet alle Optionen auf
FILE: Als erstes wird natürlich der Filename des zu disassemblierenden
Files angegeben. Wenn man den Filenamen wegläst dann öffnet sich
ein ASL-File-Requester.
TO/K: Mit dieser Option kann man die Ausgabe in ein File umlenken
Das Intro und die INFO's werden nicht mit ausgegeben.
Dafür wird zusätzlich der VERSIONS-String ausgegeben, der
Name des Files und die Länge in Bytes.
NOPC/S: Dies MUSS angegeben werden wenn man re-assemblieren möchte.
Hierdurch werden der PC und die HEX-Codes weggelassen.
Das spart eine Menge an Zeit, und das ev. erstellte File
ist wesentlich kürzer.
INFO/S: Es werden ein paar Informationen zu dem File angezeigt
(FileSize, HunkAnzahl, Labels ...).
Die Informationen erscheinen nur im Ausgabefenster, das ist
nützlich wenn man die Ausgabe in ein File umlenkt und
trotzdem ein paar Informationen sehen will.
HUNKLAB/S:
Es werden die Label-Adressen von Symbol-Hunks aufgelistet.
Die Offets von EXT-Hunks werden angezeigt.
(Aber nur die des Typs < $80)
PROBIER DAS zum testen der Option: D68k LIB:amiga.lib hunklab
(Das ist praktisch um die neuen Offsets aus einer NEUEN
amiga.lib zu ziehen, falls man sie hat.)
NC=NOCODE/S
Die Ausgabe der Befehle wird unterdrückt. Das ist praktisch
wenn man NUR die DATA-Ausgabe sehen will, dann braucht man
nicht mehr ewig-lange CODE-Zeilen scrollen lassen.
ND=NODATA/S
Die Ausgabe des Inhaltes aller Daten-Hunks wird unterdrückt.
NB=NOBSS/S
Die Ausgabe aller BSS-Hunk Anweisungen wird unterdrückt.
------------------------------------
Die TRACE-Methode und ihre Optionen
TRACE/S
Mit dieser Option wird eine alternative Methode benutzt
um Labels und Datas in Code-Hunks zu erkennen. Es werden
alle Sprungmarken notiert bis ein UNBEDINGTER Sprung kommt.
Dann wird eine von den notierten Sprungmarken geholt und an
dieser Stelle wird weiter disassembliert.
Vorteil : Es wird nie in Datas disassembliert.
Nachteil: Falls per JSR (A0) gesprungen wird, kann diese Adresse
nicht notiert werden und demzufolge fällt dieser
Programmabschnitt (und dadurch ev. weitere) weg.
Am besten Ihr testet es mal mit dem LIST Befehl der 2.0
Workbench, einmal mit TRACE und einmal ohne.
JL=JUMPLIST/S
Mit dieser Option (nur zusammen mit TRACE) kann man bestimmen
das D68k sich 'notierte' Adressen aus einem File zieht. Dieses
File MUSS im Verzeichnis SYS:Prefs/Presets/D68k zu finden sein.
Der Name fängt mit "JumpList." an und endet mit dem Filenamen
den man zum disassemblieren angegeben hat.
In diesem Text-File können von Ihnen eingetragene Adressen
stehen, die D68k sich als abzuarbeitende Sprungmarken merkt.
Dieses gleicht den Nachteil der TRACE-Methode vollständig aus.
------------------------------------
Die folgenden Routinen sind nur für die 'normale' Methode
sinnvoll.
RLO=RTSLOGICOFF/S:
Wenn nach einem RTS Befehl kein Label folgt ist es ziemlich
unwahrscheinlich das Code folgt. Deshalb werden automatisch
nachfolgende Programmdaten als Hex-Datas ausgegeben.
Mit dieser Option kann diese automatische Unterdrückung der
Befehle hinter einem RTS Befehl abgeschaltet werden.
(Das gleiche gilt für die Befehle: BRA, JMP, RTD, RTE, RTM, RTR)
(Sollte bei TRACE-Methode benutzt werden)
DLO=DATALOGICOFF/S
Bei D68k werden NICHT erkannte Hex-Codes als Datas ausgegeben.
Weil der PC an diesen Hex-Codes sowieso nicht vorbeikommt,
können alle nachfolgenden Hex-Codes bis zum nächsten Label
auch als Datas ausgegeben werden. Mit dieser Option kann man
diese Logik abschalten und nur WIRKLICH nicht erkannte Hex-Codes
werden als Datas angezeigt.
(Schaltet die 'RTSLOGIC' auch mit aus)
OLO=ORILOGIC/S
Bei ORI.x Befehlen die aus zwei Wörtern bestehen und ein
Label zwischen den beiden Wörtern ist, wird ein Wort als
Data ausgegeben und die Befehlsausgabe mit dem Label
fortgesetzt. (Wenn nach einem RTS ein 'LeerWort' folgt um
die Routine durch vier teilbar zu machen, denkt D68k das das
ein ORI-Befehl ist. Mit dieser Option kann man diese Befehle
aussschalten.)
------------------------------------
Die folgende Routine ist nur zum Debuggen von D68k.
NL=NEXTLABEL/S
Mit dieser Option wird die Längendistanz bis zum nächsten Label
oder Symbol angezeigt (diekt vor dem PC). Wenn die NOPC-
Option benutzt wird fällt diese automatisch weg.
(Ist eigentlich mehr für MICH zum debuggen).
*******************************************************************************
WARUM ICH D68K GESCHRIEBEN HABE:
Ich bin neugierig und der DisAsm 1.05 war mir
1. zu langsam
und außerdem
2. benutzt er tausende von SPACE's (ich nehm TAB's)
3. er spinnt bei OS V36 und höher
4. zeigt zuwenig Nebeninformationen
5. ist nicht anpassbar (an meine Wünsche)
6. erkennt keine 68020.. Befehle
7. Kreuzberger Nächte sind lang.
(er war aber ein gutes Vorbild)
*******************************************************************************
WAS VERBRAUCHT D68K AN SPEICHER?
1. Die eigene Länge (is ja wohl logisch)
2. Die Größe des zu disassemblierenden Files (ach ne)
3. 128kB für die Labels
4. Pro Hunk nochmal 64 Byte (genauer Wert in der Status-Zeile (3.LW))
5. Falls die Trace-Option eingeschaltet ist nochmal ein sechszehntel
der Code-Hunk Längen. (Pro Wort ein Bit)
6. Falls die Trace-Option eingeschaltet ist 32kB für die Sprungmarken.
7. Falls eine JumpList eingeladen wird, wird dieser Speicher nur
kurzzeitig belegt.
*******************************************************************************
FEHLER:
Zeigt aus optischen Gründen keine Labels an ungeraden Adressen
im CODE-Hunk an (da dürften aber auch gar keine sein).
(teilweise behoben: Wenn Daten angezeigt werden, erscheinen auch
Labels an ungeraden Stellen)
Wenn ¡hr Fehler findet (besonders in der Umsetzung der Befehle)
meldet euch bei mir.
*******************************************************************************
WAS ICH MIR NOCH VORSTELLEN KÖNNTE:
- Gepufferte Daten-Ausgabe für eine bessere Output-Performance.
- Noch bessere Erkennung von Data-Segmenten in CODE-Hunks.
- Spezielle Behandlung beim disassemblieren von Libraries.
- Wenn Ihr Vorschläge habt, die ich realisieren kann, her damit.
*******************************************************************************
HISTORY:
V0.421 Mitte 91 (Größe ca. 10kb)
-VersionsNummer des Grundprogramms (ohne Labels)
V0.5xx Mai-Juni 92
-Labels sind dazugekommen (puh war das 'ne Arbeit)
V0.96 29-Jun-92
-Sortierroutine der Labels wurde insg. um den Faktor 2-3 beschl.
V0.97 29-Jul-92
-Die Data-Ausgabe ist nun brauchbar (hoffe Ich)
V0.99 29-Jul-92
-Die BSS-Ausgabe ist nun brauchbar (V0.98)
-Die Befehle ROXL.? und ROXR.? wurden falsch geschrieben
(ROLX.? und RORX.?)
-Die Reloc32-Zeile hat nun ein Semikolon
-Die Hunk-Namen sind jetzt zum Re-Assemblieren mit A68k an die
richtige Stelle gerückt
+++++++++++++++++++
V1.00 06-Aug-92
-Fehler bei MOVEP.W, es wurde immer MOVEP.WL angezeigt
+++++++++++++++++++
V1.04 20-Aug-92
- Effektive AdressierungsArt PCIndex mit Displacement wurde
vergessen. (Label wurde nicht angezeigt)
- Fehler bei PCIndirekt mit neg. Richtung in den Adressierungsarten-
Routinen behoben
- Bei dem Befehl BTST hatte Ich die AdressierungsArt #Konstante
vergessen
- Bei dem Befehl CHK wurde die #Konstante nur in Byte-größe angezeigt.
Es muß aber min. Wort-größe sein(Beim 68000/10).
- Ein GROSSER Fehler beim Überprüfen der möglichen AdressierungsArten
ist behoben. (JMP D0 ist nicht mehr möglich)
- Es sind AUßER den cpXXX ALLE 68020 Befehle dazugekommen
(Die neuen AdressierungsArten gibts auch noch nicht, mir fehlt das Buch)
- Die Option NOPC/S schaltet die ganzen Hex-Zahlen am Anfang der Zeile ab
- Unter DOS 1.3 läuft D68k nicht mehr (wegen ReadArgs, FreeArgs und
WriteChars.
- xxx.B (z.B. MOVE.B D0,A0) in ein AdressRegister gibt es jetzt nicht mehr
- Die Option TO/K zum umlenken der Ausgabe in ein File
- Die Ausgabe wurde etwas verbessert. Es werden jetzt nicht mehr
soviele Zeichen einzeln ausgeben, ist aber kaum schneller da sowieso
alles durch die _LVOWriteChars(a6) Routine gepuffert wird.
- Fehler bei der Ausgabe der letzten Zeile bei BBS und DATA Hunks beseitigt
- Labelsortier-Routine beschleunigt (2 mal, z.B. LHA von 37 auf 27 sek.)
- LED flackern bei vielen CODE-Hunks (z.B. amiga.lib) behoben
+++++++++++++++++++
V1.07 29-Sep-92
!!! - BÖSER FEHLER beim Schreiben der Mnemonics in ein File behoben
(halb mein Fehler, halb Commodores Fehler(?))
- Die Routine zum ermitteln der Labelnr. ist nun wesentlich schneller
(kürzerer Code (68010.. opti.))
- Anzeige der FehlerQuelle mittels IoErr() und PrintFault()
- Die Option INFO/S zeigt die Status-Informationen an, wenn sie
bereit stehen (Länge des Files, HunkAnzahl, LabelAnzahl...)
- Die 68881/82 Befehl FBcc, FDBcc und FScc werden erkannt
- einige Optimierungen bei der DATA-ausgabe.
- Option HUNKLAB/S dazugekommen (ist aber nocht nicht ganz fertig
zeigt bisher nur SymbolNamen)
- bessere Ausgabe von fehlsprüngen z.B. JMP $00(PC,d0.l)
+++++++++++++++++++
V1.50 23-Nov-92
- Bei Unit- und Name-Hunks wird der Name auch angezeigt
- Mit HUNKLAB werden jetzt auch Daten (Offsets) vom Extern-Hunk
aufgelistet (nur die des Typs < $80)
- Die Symbol-Adressen werden nicht nur aufgelistet, sondern auch
als Label angezeigt.
- Die Anzahl der Extern-Hunk Einträge wird jetzt korrekt angezeigt.
- Wenn externe referenzen vorhanden sind, werden diese im Code-Hunk
angezeigt (z.B. MOVEA.L _AbsExecBase,A6 ).
- Man kann jetzt die 'rts-logic' mit RLO/S abschalten (siehe oben)
- Die Ausgabe der CODE-, DATA-, und BSS-Hunks kann nun mit den
Optionen NOCODE, NODATA und NOBSS unterdrückt werden
- Enforcer-Hits durch das eventuelle Auslesen der Adresse $0 kommen
nicht mehr vor (ist aber ungetestet, hab keine MMU, bloß 'nen MC68010)
!! - MEINE SELECTIONSORT-Routine zum Sortieren der Labels wurde durch eine
QUICKSORT ersetzt. Vorher 35 sek., jetzt vier Sekunden für LhA.
- Das letzte Label eines Hunks, wurde immer als erstes Label im nächsten
Hunk angezeigt. Dies ist behoben.
- Bei dem, mit der TO/S Option, erzeugtem File ist jetzt das ExecutableBit
nicht mehr gesetzt.
!! - D68k erkennt jetzt ALLE CPU Befehle (bis einschließlich 68040)
(Ausnahme: Die cpXXX Befehle des 68020; sind aber identisch mit den
gleichnamigen F-Line Befehlen)
!! - Es sind ALLE 68881/82 Befehle integriert. Auch die Double- und
Single Precision des MC68040.
!! - Es werden ALLE 68851 PMMU Befehle erkannt.
!! - Die Adressierungsarten des 68020... sind vollständig integriert.
(Ich hab sie alle von Hand entschlüsselt, mit dem Newmodes File
von Carnivore/Beermacht; wenn was fehlt melden)
- Fehler beim Umsetzen der PC-relativen Adresse bei dem Befehl
BTST #Imm behoben (Fehler im AdressParser, SAS ASM 5.10b hat auch
Probleme)
- Fehler bei MOVE TO SR und MOVE TO CCR wurde behoben. Anstatt WORD
wurde ev. BYTE oder LONG angegeben (vom letzten Befehl).
- Es werden jetzt auch Reloc16, Reloc08 und DReloc16 erkannt und
zwingen D68k NICHT mehr zum Abbrechen.
(Werden aber noch nicht so unterstützt wie Reloc32)
- Die Anzeigenlänge der Hunks ist von vier Bytes auf zehn gestiegen.
Aus EXT. wird EXTERN, aus RE32 wird RELOC32 usw.
- Wenn ein CODE, DATA oder BSS Hunk ins CHIP-Ram geladen wird,
wird das auch angezeigt.(DATA CHIP, CODE CHIP oder BBS CHIP)
Für FAST-Ram gilt das gleiche.
- AusgabeFile wird nur erzeugt wenn vorher alles geklappt hat.
+++++++++++++++++++
V1.51 01-Dez-92
- Absturz bei File-Ausgabe OHNE INFO-Option beseitigt.
- Hunk-Fehlermeldungen bei FileAusgabe werden ab jetzt nur auf
dem CLI-Fenster ausgegeben.
+++++++++++++++++++
V1.52 29-Dez-92
- Anstatt DRELOC16 wurde DRELOC32 ausgegeben. Das ist behoben.
- Extern_Dext16 wird erkannt und ev. eingesetzt.
- Es werden jetzt mehr Extern_korrekturen unterstützt.
- Die Hunk-Sorten HUNK-LIB und HUNK-INDEX werden erkannt.
- Bei PC-Relativen Sprüngen (Bcc ,JSR $0000(PC) ,DBcc, FDBcc ,PDBcc
FBcc oder PBcc) mit einem Sprung-Displacement von NULL wird
kein Label mehr erzeugt.
- Der LPSTOP Befehl (MC68060!) wurde vier Bytes zu kurz angegeben (PASS 1).
- FLine-Befehls Erkennung (PASS 1) hat NICHTS erkannt. Das ist behoben.
- Anstatt FACOS wurde FCOSH ausgegeben. Das ist behoben.
- Kleine Unstimmigkeit bei SUBX (PASS 1) ist beseitigt.
- Bei einem Labelüberlauf (>32768 Labels) wird abgebrochen.
! - Wenn die File Option NICHT angegeben wird öffnet sich ein
ASL-FileRequester.
- Bei den BitField Befehlen wurde das Datenregister falsch angezeigt.
- Der 'SINGLE' (.S) Wert auf der Mnemonic-Seite wurde falsch angegeben.
- Reloc_Labels und Extern_Equates werden jetzt in Code- und Data-Hunks
angezeigt.
+++++++++++++++++++
V1.53 06-Jan-93
- Es werden auch Labels in Hunks angezeigt, deren Länge NULL beträgt.
(Ein einziges Label an Adresse Null (gesehen in small.lib))
- Ausgabefehler bei PMOVE-Befehlen beseitigt.
- Bessere Aussortierung von illegalen BitField-Befehlen.
- Kleine Ungereimtheiten bei BitField-Befehlen deren Adressierungs-Arten
nicht zulässig waren sind beseitigt.
- Bei FRESTORE fehlten zwei Adressirungsarten. (Die beiden PC-relativen)
- Fehler in PASS1 bei FSAVE, PSAVE, FRESTORE und PRESTORE behoben
- In PASS1 werden jetzt die Standard-Libraries erkannt und übersprungen.
Dadurch fallen die Labels weg, die erzeugt worden wären. In PASS2
werden anstatt der Befehle die Library-Namen ausgegeben.
+++++++++++++++++++
V1.54 18-Jan-93
- Bei CMPI.x fehlten die PC-relativen AdressierungsArten.
- Label-, Symbol- und Reloc32 Suchroutinen überarbeitet und beschleunigt.
- Bei ADDI.x und SUBI.x werden die Zahlen nur noch positiv angezeigt.
- Die Optionen NextLabel und OriLogicOff sind hinzugekommen.
- Falls Labels zwischen Befehlen existieren werden sie (an geraden
Adressen) angezeigt. Das sieht so aus: 000000 4BF9~0000 0000
Das ist ein LEA Befehl wo sich mittendrin ein Label an Adresse 000002
befindet. Dies wird durch ein '~' angezeigt.
+++++++++++++++++++
V1.55 23-Jan-93
- Fehler bei der UNIT- und NAME-HUNK Ausgabe der Version 1.54 behoben.
+++++++++++++++++++
V1.84 11-Feb-93
!!! - D68k hat jetzt eine neue Methode um Programme zu disassemblieren.
Man muß sie mit der Option TRACE einschalten. (Bitte oben lesen)
! - Falls die TRACE-Methode gewählt wurde, erkennt D68k C-spezifische
Jumptabellen die so angezeigt werden, das ein Assembler die
korrekten Adressen errechnen kann.
- Die Skalierung bei PC-Relativen Adressierungsarten wurde hinzu-
gefügt. {z.B.: L000001(PC,D0.L*2) }.
- Es wurden mehrere Fehler bei den neuen Adressierungsarten beseitigt.
- Der Asl-Requester wird mit etwas mehr Sicherheit abgearbeitet.
!! - D68k erkennt jetzt auch ABGESPEICHERTE Bootblöcke (File-Format).
- Wenn die Hunkgröße die Filegröße überschreitet wird eine Fehler-
meldung ausgegeben (z.B. bei gesplitteten Files).
- Die Anzeige der Extern-Listen bei der Hunklab-Option werden jetzt
bündiger ausgegeben, so das sie in einer Reihe stehen.
- Bei Reloc08 und Reloc16 Hunks wurde anstatt ein Byte bzw. ein Wort
IMMER ein Langowrort eingelesen um das Label zu erzeugen, wodurch
eine illegale Adresse entstand, die an den Sicherheitstests nicht
vorbeigekommen ist. Das ist jetzt behoben.
- Labelerzeugung durch Reloceinträge in Data-Hunks war fehlerhaft.
- Bei Bcc-Sprungbefehlen wird jetzt auch auf Reloceintrag überprüft. Das
heisst Bcc Befehle können jetzt auch auf andere Hunks zeigen! (A68k).
Beim Linken muß dann SmallCode angegeben werden.
- Falls das einzuladende File eine Länge vonn Null Bytes hatte, wurde
zwar abgebrochen (Speicherfehler!), aber das File wurde nicht ge-
schlossen. Jetzt wird es geschlossen und eine 'kann File nicht
öffnen' Fehlermeldung ausgegeben.
+++++++++++++++++++
V1.86 17-Feb-93
- Wenn ein Bootblock erkannt wurde, werden jetzt die ersten drei
Langwörter ausgegeben. (Kennung, Checksumme und Rootblock)
- Die Berücksichtigung des Externhunks wurde um Extern_Dext08 und
Extern_Dext32 erweitert.
- Die Hunks Hunk_DRel08 und Hunk_DRel32 werden jetzt auch erkannt.
(Wird aber sonst noch nicht berücksichtigt, weil mir der Zweck nicht
bekannt ist)
- Bei der Ausgabe WURDE der Name des Files durch die doppelte Belegung
eines FileInfoBlocks falsch ausgegeben.
+++++++++++++++++++
V1.87 22-Feb-93
- Der ILLEGAL-Befehl wird ab jetzt auch als Endpunkt bei der Trace-
Methode angesehen (Weil der PC hier nicht vorbeikommt).
- Datumformat wegen inkompatibilität zum Versionsbefehl geändert.
- Im Hex-Bereich wird zwischen einem Reloc32-Langwort ein Unterstrich
gesetzt (Nur im CODE-HUNK).
+++++++++++++++++++
V1.88 06-Mar-93
- Labeladressen an denen schon Symbole von einem Symbol-Hunk sind,
wurden trotzdem ausgegeben. Jetzt wird wieder der Symbolname als
Label ausgegeben.
- Guru3 bei SymbolNamensuche behoben.
- Symbolnamen wurden nur 16 Zeichen lang ausgegeben, das ist jetzt
behoben.
- Bei dem CAS.x Befehl wurden die beiden PC-Relativen mit den beiden
Absoluten Adressierungsarten vertauscht (die falschen Zwei wurden
akzeptiert und die richtigen nicht).
+++++++++++++++++++
V1.89 19-Apr-93
- Enforcer-Hits bei Aufruf des ASL-Requesters behoben.
- Enforcer-Hit beim Schreiben des Reloc-Identifiers "_" behoben.
- FBcc und PBcc als Springer deklariert, damit sie mit der Trace-
Methode funktionieren.
+++++++++++++++++++
V1.90 2-Aug-93
- Die Länge von LIB-Hunks wird jetzt korrekt ausgegeben.
+++++++++++++++++++
V1.91 23-Aug-93
- Die Ausgaberoutine ist nun gepuffert (FWrite()).
- Die FLine Befehle werden nun wieder nach Labels abgesucht.
(Ich habe vergessen dies nach dem debuggen wieder einzuschalten).
*******************************************************************************
Meine Adresse:
Denis Ahrens
Kommandantenstr.53
10969 BERLIN
DEUTSCHLAND
Tel: (030) 614-8979
MODEM: Nur unter Ankündigung