Der Decompiler ist in Zeille 25662, mit dem P-Code 123, ausgestiegen
Gerade frisch decompiled mit meinem Decompiler:
Hallo Besucher, der Thread wurde 38k mal aufgerufen und enthält 247 Antworten
letzter Beitrag von Primzahl am
(De)compiler v.3.0
- Stephan Scheuer
- Erledigt
-
-
Unterschied zu vorhin. Das ist das Overlay File, also ohne R/T code was ich vorhin auch mit meinem Decompiler verwendet habe.
Positiv: Decompile startet auch ohne R/T Code.
Meine Auswahl im Menü war erst 1 dann 0 (für Offset $1f93) (Austro 1e / Plum's Blitz).
-
So, ich hatte einen negativen Wert, und zwar -1. im DIM-Array CS(SP) gehabt. Das habe ich gerade gefixt. Du kannst die Test-02-Comp testen. Zwei Tester sehen mehr als einer.
Ich hoffe, das das die letzte Schote im Basic-Code war. Ohne R/T Code decopilieren, funktioniert bei meiner auch. Das hatte ich schon ganz am Anfang implementiert.
-
Wieder abgebrochen:
-
Ich schicke Dir das Diskimage als PN.
Da ist dann noch was anderes mit drauf
-
Dankeschön!
Alles anzeigenCode- an dem fehlerscreen von dir habe ich eben die nummer 1690 gelesen. das is
- die zeile 1690. jetzt weiß ich, wo der fehler liegt. den bug auszumerzen
- dürfte aufgrund der spar-basic-programierung nicht ganz einfach werden.
- -------------------------------------------------------------------------
- 1640 ifa<82then2050
- 1650 ifa=82then5600
- 1660 ifa<93then2050
- 1670 ifa<97then5620
- 1680 ifa<120then2050:rem auf crash screen stand 123 und das passt hier nicht durch
- 1690 zl=1690:rem zeilennummer
- 1700 goto6950:rem zum crash screen
-
Hast du Austrospeed 5E im Menü gewählt?.
So, das liegt daran, was von den Leuten so alles an Basic-Code compiliert wird. Ich muss für jede noch so exotische P-Code Konstellation eine Lösung finden. Und manchmal beissen sich die Lösungsversuchen.
Versuche mal die angehangene Test-01 Version.
Die läuft jetzt tadellos durch.
Der BASIC Source sieht auch gut aus.
-
Ich habe leider noch ein Bug... naja ein Bug ist es nicht wirklich. Ich habe ein Array zu niedrig dimensioniert. Ursprünglich dachte ich, dass ein DIMFO(200) reichen sollte.
Es reichte aber nicht.
Deshalb habe ich das in DIMFO(400) geändert. Multiterm v5c jetzt anstandslos decompiliert. Tija Shit Happens.
-
Konntest Du das Problem mit dem C*BASE File im Compiler beheben ?
Falls ja hätte ich noch die ungeänderte Version, die sonst bei allen Decompilern mit String too long Error abbricht.
-
Ich hatte vor einer Weile mehrere deutschsprachige Textadventures (Wanderung, sein letzter Trick, Harak Iri) vor mir wo ich mir nicht sicher war ob die (kompiliertes) BASIC oder ASM sind. Ein erster kurzer Blick mit dem Monitor hat eigentlich ASM suggeriert - bis ich auf den dritten Titel gestoßen bin, der exakt gleich aufgebaut war.
Ein BASIC-Zeile mit "SYS2076" oder "SYS2064" gefolgt von etwas Text (Copyright, Name des Spiels o.ä.). Dissassembliere ich ab $0810 bzw. $0810 sieht der Code folgendermaßen aus :
Also immer ein Sprung nach $0b41, plus der immer gleiche Code-Block ab $0b41.
Ist das irgendein bekannter Compiler, bzw. das Runtime-Environment eines solchen Compilers? Gibt irgendwo Infos, wie ich die Resultate diverser Compiler halbwegs schnell erkennen kann?
-
So, nach einiger Zeit und vielen Decompile-Tests habe ich es endlich geschafft. Das Programm ist fertiggestellt.
Viel Spass beim Decompilieren.
-
Die ungeänderte Version, die sonst bei allen Decompilern mit String too long Error abbricht.
Die kannst du mir gerne zukommen lassen. Ich werde versuchen, die ungeänderte Version zu decomplieren.
-
Das ist der Austro-Comp-E1, bekannter unter den Namen Simons-Comp.
Ah, klasse. Vielen Dank für die Info.
-
So, nach einiger Zeit und vielen Decompile-Tests habe ich es endlich geschafft. Das Programm ist fertiggestellt.
Super ! Bester Decompiler so far !
Allerdings hab ich mal wieder was zu meckern
1. "Schönheitsfehler": Manchmal wird ein Leerzeichen eingebaut nach einer öffnenden Klammer also "(" oder SYS oder POKE
Beispiel:
Nicht schlimm, fällt mir nur auf.
2. Fehler ?!: Habe vom C*BASE das unmodifizierte C/BBS genommen ohne Runtime Code und versucht zu decompilieren. Das geht noch in die Hose. Mit R/T Code läuft es sauber durch, auch da wo alle anderen Decompiler abbrechen.
3. Meckern auf hohem Niveau: DIMs könnten ggf. noch zusammengeführt werden und print / print# Ketten auch, wenn das geht. Im original BASIC Code sind die nicht einzeln. Das macht das BASIC File auch kürzer.
PS: Ich scheitere bei meinem Decompiler immer noch an der überflüssigen Variablenzuweisung vor FOR NEXT Schleifen und o.g. Problemen... Aber das ist ein anderes Thema.
-
teileweise schweren Bugs im Decompiler v3.2, wie zum Beispiel das, wenn bei Extensions mitten im Befehlssatz ein Doppelpunkt gesetzt wird, der Befehl davor auch verdoppelt wird
Ja da ist noch einiges zu tun bis es 100% ist. Die Doppelpunkte bei der c-bbs141 von mir im P-Code gesetzt, damit der Decompiler nicht mitten drin abbricht. Bad Code ist daher OK.
Manchmal scheint er das Ende von einer Extension nicht sauber zu verarbeiten. Danach läuft eine Variable li$ über und es kommt zum Abbruch.
Wegen oben genannter Fehler ist bisher immer viel Handarbeit nach dem Decompile notwendig. Aber so lernt man den Code kennen und kann man eben 8 Stunden am PC verbringen ohne Langeweile. Man muss es nur positiv sehen
