Hallo Besucher, der Thread wurde 30k mal aufgerufen und enthält 143 Antworten

letzter Beitrag von Parser am

Kopierschutzverfahren gelüftet

    Zitat von Stephan Scheuer

    Gut, lieber eine Klammer zu viel, als nachher einen Compile error. Das Decompilat ohne Klammern ist 132 Blocks lang und das mit Klammern ist 144 Blocks lang. Der Größenunterschied,

    das sind nur die Klammern. Das Compilat wäre damit auch zu lang, und würde bei "Let's Go 5" andere Daten überschreiben. Klammern setzen ja, aber das ist zuviel das Guten.:)

    Dass es so einen Unterschied macht, hätte ich jetzt nicht gedacht.

    Ich dachte, die Ausdrücke würden vom Compiler auf eine Art Stapel zur Auswertung gegeben (so wie Forth rechnet). Dann würden die Klammern keine Rolle spielen. Aber ich habe mich länger nicht mehr mit dem P-Code beschäftigt.


    Zitat

    PS: Wovon ich immer träume, wäre ein P-Code Compiler mit 24Bit Adressierung. Dann könnte man den P-Code in der SCPU, ab Bank $02 also $020000 ablegen.

    z.B. 19,02,de,32 -> GOTO $02DE32

    Und ich träme davon zumindest den Decompiler in C# nachzubauen. Da kann man gewisse Optimierungen (Klammerminimierung usw.) ganz anders angehen, als mit dem MS-Basic V2. Deshalb bin ich aber auch so erstaunt, dass in den achziger Jahren jemand in diesem Basic symbolisch differenzieren konnte (gerade in ALI) und die Ausdrücke dann auch noch vereinfacht wurden. Allein das ist einen Blick auf den Souce-Code wert.

    ....Decompiler in C# nachzubauen....


    Immer üben, üben und nochmals üben kann ich da aus eigener Erfahrung nur sagen


    Und bei jeder Heureka Teachware ist der Kernal ab $E000 abgelegt. Bei meinen Cracks ist das die Datei "KLG". Die Ladeadresse der Datei $C000 stimmt nicht. Diese ist $E000

    Den ASM-Code hatte ich mal disassembliert und dokumentiert. Wo der jetzt rumschwirrt, weiß ich nicht. Auf DVD oder HDD ect. Muss ich mal bei Gelegenheit raussuchen..


    Hattest du dir diese Thread von mir mal durchgelesen?


    Austro-Comp Anpassung

    Zitat von Stephan Scheuer

    ....Decompiler in C# nachzubauen....


    Immer üben, üben und nochmals üben kann ich da aus eigener Erfahrung nur sagen

    Ich will den ja nicht selber schreiben, sondern nur nach C# umsetzen.

    Habe dafür 2009 (wie man sieht, komme ich schnell voran damit) bereits die wichtigsten Programmabschnitte dokumentiert (siehe Anhang Datei "decompiler v3.txt").

    (Die Art den Quellcode so zu dokumentieren lässt es zu, das Teil per Script wieder in reines Basic zurück zu verwandeln.)

    Die Änderungen der neueren Versionen sollten da recht einfach nachzutragen sein.

    Ich suche gerade meinen fast fertigen und funktionierenden Extensions Extraktor. Dieser arbeitet den P-Code rückwärts ab, um Fehler zu vermeiden.

    Nach dem Extrakten, füllt das Tool die Bereiche, wo die Erweiteungen im P-Code stehen, mit #$15 (CLI) auf. Die Erweiterungen können nach dem Decompilieren wieder eingefügt werden.
    Das Programm hatte ich mir mal gecodet, damit ich auch P-Codes, die aufgrund der Erweiterungen nicht decompilierbar sind, zu decompilieren.


    Anhang: Extrahierte Extensions als Basic Datei.

    Zitat von Parser

    ... wollte es nur noch mal kurz bildlich darstellen (Bilder überlagert; unten T2 und oben T31) ... die Prüftracks 2 <-> 31 gegeneinander. Was in den hervorstehenden Sektoren passiert, ist weiter zu erörtern, was die gemessene Schreibdichte innerhalb der Tracks betrifft.

    Könntest Du das Bild mir Hardware-Dummy genauer erklären?

    Wie ist das entstanden (Oszilloskop)? Welches Signal wurde gemessen? Am Lesekopf, oder hinter einem Lesekopf-Signal-Verstärker, wenn es sowas gibt)?

    Da sind sechs (mehr oder weniger) horizontale Streifen zu sehen (die drei unteren für T2 und die oberen für T31?) (vertikal ist die Signalstärke)?

    Warum drei pro Track (drei Messungen des gleichen Tracks)? Die Bildbreite ist immer ein ganzer Track?

    Zitat von robak29

    Habe dafür 2009 (wie man sieht, komme ich schnell voran damit) bereits die wichtigsten Programmabschnitte dokumentiert (siehe Anhang Datei "decompiler v3.txt").

    (Die Art den Quellcode so zu dokumentieren lässt es zu, das Teil per Script wieder in reines Basic zurück zu verwandeln.)

    Ich habe mal mein Perl-Script angehangen, mit dem ich meine Kommentare am dekompilierten Rechenlöwen wieder entfernt habe, um ein normales basic.prg daraus zu machen.

    Im "commenting" Unterorder ist zu sehen, wie ich automatisch die Separationszeilen nach goto und gosub einbaue.

    hallo, ich habe von Heureka noch folgendes original auf disk herumliegen. könnte da mal ein backup/nibble davon machen (kein kryoflux) falls ihr das benötigt.


    bruch trainer

    französisch lernprogram 1 - 4

    lesarning engliscsh green line 2 und 3

    learning englisch vokabeln 5 und 6


    bei bedarf einfach ein pm bitte.


    lg

    swasti

    Zitat von Stephan Scheuer

    Ohhh... Das ist ja wie Weihnachten und Ostern einem Tag. Danke. Wäre toll, wenn man diese zumindestens für den Austro-Comp und Austrospeed vollständig hätte.

    Interessant ist: Ich habe meine Liste aus Sicht des Decompiler-Sourcecodes erstellt. Deine Bemerkungen zielen eher auf die Runtime hin. Das sieht man z.B. an den Opcodes $3a-$3e ganz gut.

    Mein Ziel ist eine Liste zu haben, in der zu sehen ist, was macht ein Opcode in der Runtime aber auch, wie muss er wieder dekompiliert werden. Natürlich mit etwaigen Unterschieden der verschiedenen Compiler.

    Es wäre schön, eine sauber dokumentierte Disassembly der Runtime zu haben. Du hast für die Austro-Comp-Anpassung mit der runtime.tas bereits gut vorgelegt. Aber darin sehe zumindest ich nicht sofort, welcher Opcode von welcher Unterroutine abgearbeitet wird.

    Es tauchen bei Dir die Opcodes

    Code
    1. $72 error handler?
    2. $74 trap
    3. $76 resume
    4. $79 vol [arg]

    auf, die ich im Decompiler nicht gesehen habe. Ich frage mich, wann werden die verwendet?

    Zitat

    Sorry konnte nicht so schnell antworten, weil mir meine SSD abgeraucht ist.

    Hoffentlich ist nichts Wichtiges verloren gegangen.

    Nö. keine wichtigen Daten. Das was weg war, war das Betriebssystem und einige Installationen, die zwangsweise auf die C-Platte(SSD) mussten. Alles andere ist auf Platte D bis K. In gewissen Abständen

    wird meine Arbeits-HDD (c64-coding ect) auf einer Extenen HDD synchronisiert.


    Bei dem Runtime-ASM handelt es sich um den Austro-Comp 1E. Den hatte ich noch weiter Dokumentiert, nur nicht hochgeladen. Ich suche den mal raus.


    Wenn du wissen möchtest, wie der P-Code in der Runtime abgearbeitet wird, muss du im WinVice Monitor Brakepoints setzten. Meist reicht es diese bei den Indirect-indexed addressings wie z.B.

    lda ($32),Y zu setzen. Dann das Compilat laufen lassen und warten, bis der Monitor beim Erreichen eines Brakepoint startet. Nun kannst du per Einzelschritt und immer ein Blick auf die Registeranzeige, verfolgen ob gerade ein P-Code verarbeitet wird.


    Als Anhang, die aktuellset Runtime von mir.:)


    Achja, bei mir hat sich eine ganze Menge an geschriebener Quellcodes angehäuft. Siehe die beiden Bilder. Und das ist noch nichtmal alles. Vielleicht sollte ich mal ein wenig Ordnung reinbringen.

    Alle neuen Heureka Teachware Programme sind gepatcht. Danke an Parser für seine Arbeit.:)

    Die G64-Images sind lauffähig, vom Programmcode aber unverändert.

    Bei den Die D64-Images musste ich den Code patchen, damit diese funktionieren.8)


    Viel Spass mit der Software.


    In den Archiven sind:

    ------------------------


    Englische_Sprachübungen_2_3_-_Storytime_I_1988_Heureka_Teachware

    Englische_Sprachübungen_4_6_-_Storytime_II_1988_Heureka_Teachware

    Englische_Sprachübungen_2_3_-_Verbs_and_Sentences_1989_Heureka_Teachware

    Etudes_Francaises_Echanges_Edition_Courte_1_1988_Heureka_Teachware

    Etudes_Francaises_Echanges_Edition_Longue_1_1988_Heureka_Teachware

    Etudes_Francaises_Echanges_Edition_Longue_2_1988_Heureka_Teachware

    Etudes_Francaises_Echanges_Edition_Longue_3_1988_Heureka_Teachware

    Etudes_Francaises_Echanges_Edition_Longue_4_1988_Heureka_Teachware

    Green_Line_2_1989_Heureka_Teachware

    Green_Line_3_1989_Heureka_Teachware

    Let's_Go_2_1989_Heureka_Teachware

    Let's_Go_5_1989_Heureka_Teachware

    Opti-Ma_1988_Heureka_Teachware

    Red_Line_1_1989_Heureka_Teachware

    Scientific_Basic_1987_Heureka_Teachware

    Zitat von robak29

    Ich will den ja nicht selber schreiben, sondern nur nach C# umsetzen.

    "tlr" hat den Decompiler doch schon für den PC umgesetzt. Der hat zwar auch so seine Probleme mit Extensions, wie die C64 Vorlage auch, aber "normaler" BASIC Code lässt sich damit wunderbar decompilieren.

    Das hört sich ja suuuper an.:) Mit den Extensions kann ich ihm helfen. Wenn er online ist, schicke ich ihm mal den Extensions Extraktor.


    Das ganz seltene, unten angehangene Programm, ist mit dem Extensions Extraktor vorbehandelt, und danach ganz normal decompiliert worden. Das Programm hat Extensions ohne Ende.




    Sorry, Anhang vergessen.