Hello, Guest the thread was called691 times and contains 40 replays

last post from Larry at the

Decompilertest an dem Programm Green Line 4 von Heureka Teachware

  • Ich habe gestern meinen zu 80% fertigen Decompiler an dem Programm "Learning English - Green Line 4" von Heureka Teachware getestet.

    Im Anhang ist das Decompilat im PetCat Format und eine lauffähige Version als D64 Datei. Bitte mit dem Notepad++ oder einem äquivalentes Tool ansehen und/oder bearbeiten.

    Für Interessierte geht nun auch ganz klar hervor, wie die Kopierschutzabfrage im Basic Programm gestartet- und das Ergebnis der Abfrage weiterverarbeitet wird.

    Ich denke mal, dass das Decompilat recht gut geworden ist. Auf ein Renumber und einem Basic-Packing habe ich verzichtet. Jeder Befehl hat soweit wie möglich eine separate Zeile.

    So ist alles übersichtlich und man kann den Basic Code auch gut bearbeiten. Der Decompiler kann, wenn alles fertig ist, auch ein Packing und ein Renumber, nur eignet sich der Basic Code dann nicht mehr zum edieren.:)

  • Soweit ich das, ohne den Original Quellcode zu haben, beurteilen kann, sieht das Decompilat sehr gut aus.

    Ich kenne ja inzwischen die diversen Problemchen der verschiedenen Decompiler und die sind hier alle nicht vorhanden. :thumbup:

  • Die Datei "LEA" im D64 ist das Austrospeed Originalcompilat (P-Code). Der PetCat Basic Code ist das Decompilat von der Original "LEA" Datei im D64.:)

    Ja Larry, so langsam wird der Decompiler was. Ist auch ein Akt, den Code soweit wie möglich zurück in einem guten/brauchbaren Basic-Code zu wandeln.


    @JeeK


    Es ist die Datei "LEA" im D64, die ich decompiliert habe. Ziel ist es , ein Decompilat zu erzeugen, welches nach einem weiteren Compilieren auch fehlerfrei

    arbeitet, ohne den Basic Code von Hand zu edieren.

    Viele Decompiler erzeugen unnötige "cmd,;" Befehle oder unnötigen "for..next" Basic Code.


    19956 j=1

    19957 forj=1to16


    Wobei Zeile 19956 nutzlos ist.


    Kurz gesagt, haben alle Decompiler mehr oder weniger blöde macken. Bei Basic Extensions decompilieren fast alle Decompiler nur Müll. Das Problem habe ich bereits gelöst.

    Bezugnehmend auch auf den älteren Thread


    Kopierschutzverfahren gelüftet


    PS: Larry, den original Quellcode hätte ich auch gerne.:)

  • Ja, kann ich gleich mal ansehen.


    Mal eine andere Frage für die Basic Profis. Warum funktioniert obriges Decompilat nicht. Warum funktioniert das darunterliegende Decompilat.

    Ich muss den Decompiler so coden, dass dieser funktionsfähigen Code erstellt. Im Moment steige ich da nicht so ganz durch, weil beide Basic Codes doch gleich sind.


    12336 open15,8,15

    12348 print#15,"u1:";

    12355 print#15,5;

    12357 print#15,0;

    12359 print#15,35;

    12362 print#15,11



    12336 open15,8,15

    12348 print#15,"u1:";5;0;35;11



    Parser .


    Hier Bitteschön.

  • Bei Beispiel 2 sind alle werte hinter print#15 an einem print#15 mittels ; gehangen. Die Syntax ist ansonsten mit der mehrzeiligen Basic Variante identisch.


    Ich muss den decompiler vermitteln, wann alle print#15 zu einem print#15 zusammengefast werden müssen, damit der basic-code funktioniert.

  • Das führt ebenfalls zu einem 31 Syntax Error.

    Das Problem bei M-R, M-E, U1 etc. Befehlen scheint zu sein, dass die nur in einer Zeile funktionieren. Warum ist mir aber leider auch nicht klar.

    ich habe dazu auch in diversen Floppy Büchern nicht dazu gefunden.

    Das Problem tritt auch auf, wenn Werte von mehreren Variablen per print# in eine Datei, z.B. SEQ File, geschrieben werden sollen. Innerhalb einer Print# Zeile geht es, über mehrere verteilt gibt es Syntax Errors.

  • Danke, das funktioirt seltsamerweise leider nicht. Larry sucht gerade in seinen Büchern nach der Lösung.


    Das funktioniert. Kannst du im Winvice Bildschirm reinpasten und starten. Vorher aber eine Diskette einlegen.


    12336 open15,8,15

    12341 open5,8,5,"#"

    12348 print#15,"u1:";5;0;35;11

    13000 close15:close5



    Das funktioniert nicht . Kannst du auch im Winvice Bildschirm reinpasten und starten.


    12336 open15,8,15

    12341 open5,8,5,"#"

    12348 print#15,"u1:";

    12355 print#15,5;

    12357 print#15,0;

    12359 print#15,35;

    12362 print#15,11

    13000 close15:close5


    Beide Codes machen exakt dasselbe, nur eine Version funktioniert. Ich muss nur wissen, ob das nur bei "U1",U2","M-R" ect. Befehlen so ist,

    um eine Decompilerdirective zu coden. Z.B. wenn "Ux"or"B-x"or"M-x" then strip all Print#x to one.

    Der Decompiler erstellt den Basic Code nach Code-Prinzip , obere kurze Version, weil untere lange Version in diesem Fall nicht funktioniert.

  • Also ich möchte mal behaupten, dass das generell bei print# (Richtung Floppy) der Fall ist. Die Frage ist, wie das bei anderen Geräten ist, wie Printer, Modem, Screen.

    Bei Input# tritt das jedenfalls nicht auf (AFAIK). Im Buch er 1571 steht dazu auch nicht, auch nicht im großen C64 Buch. Oder das ist gut versteckt.....

  • Das funktioniert nicht . Kannst du auch im Winvice Bildschirm reinpasten und starten.

    Das müsste man sich mal auf dem IEC-Bus anschauen.

    Ich habe solche Kommados vermutlich immer nur in einer Zeile verwendet, deswegen ist mir das nie aufgefallen.


    Mutmassungen:


    Im ersten Fall wird das wohl in einem String, also in einer Listen-Sequenz auf den Bus gegeben.

    Im zweiten Fall möglicherweise als mehrere Listen-Sequenzen. Das würde für die Floppy einen großen Unterschied machen.

  • Ich suche auch schon in meinem Basic-Code Sammelsurium nach eine Erklärung. Ich bin mir aber ziemlich sicher, dass ein "PRINT#xx" bei Zugriffe auf externe Hardware, nur

    einmal gesendet mit werden darf. Also "PRINT#xx" plus Befehlsstring. Ein mehrmaliges Senden des "PRINT#xx" Befehls, verursacht, vielleicht aufgrund eine Floppy-DOS Bug

    diesen Fehler.


    Wie war das noch


    10 rem gO

    list

    :)

  • Das ist kein Floppy-Bug, das ist das ganz normale Verhalten des Befehlskanals. Ein DOS-Befehl kann nur in einem Stück gesendet werden, also in einer einzigen Bus-Transaktion.


    EDIT: Beim Schreiben von Daten in REL-Dateien ist dieser Unterschied auch wichtig. Fünf PRINT#-Anweisungen hintereinander schreiben ihre Daten automatisch in fünf aufeinander folgende Datensätze. Fasst man die Daten vorher zusammen und schickt sie in einer einzigen PRINT#-Anweisung, würde nur ein Datensatz beschrieben (wenn denn die Länge passt).

  • OK, dass das kein bug ist, hatte ich gerade durch teste festgestellt.:) Das der Befehl in einem Stück gesende werden muss, wusste ich nicht.


    Danke für den Hinweis.:) Von Basic habe ich nun nicht mehr das große Wissen.



    PS: Warum muss der Befehl in einem Stück gesendet werden? Interessehalber mal diese Frage.


    Und warum wird nach


    10 rem gO

    list


    das angezeigt?


    10 rem gdata

    ready.