Posts by robak29

    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?

    Quote

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

    Hoffentlich ist nichts Wichtiges verloren gegangen.

    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.

    Files

    • stripdocs.7z

      (18.89 kB, downloaded 15 times, last: )

    ... 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?

    ....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.

    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.


    Quote

    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.

    Der "wilde Klammernsetzer" Decompiler hat das fehlerfrei decompiliert. Kein Wunder, wenn um jeden Ausdruck oder Vorzeichen oder was weiß ich nicht, der BasicCode mit Klammern zugemüllt wird.:)


    22808 if(((len(df$)<8)or(df$(1)=(chr$(10)+chr$(5))))or(left$(df$,1)="("))then:dt=0:gosub16368

    Ich selbst setze gernal mal eine Klammer zu viel, als eine zu wenig. Das verstehen dann auch Leute wie ich, die die ganzen Operatoren-Präzedenzregeln (jede Programmiersprache kocht hier zwar ein ähnliches, aber eigen gesalzenes Süppchen) gerade nicht parat im Kopf haben. Hat auf das Kompilat jedoch keinen Einfluss, solange kein Optimizer seine Finger im Spiel hat.

    Dieser Thread ist für mich ab sofort der heilige Decompilier-Nachschlage-Thread!

    Und wie bist Du denn darauf gekommen, dass Du Zeile 22808

    Code
    1. 22808 iflen(df$)<8ordf$(1)=chr$(10)+chr$(5)orleft$(df$,1)="("thendt=0:gosub16368

    so anpassen musst:

    Code
    1. 22808 iflen(df$)<8ordf$(1)=(chr$(10)+chr$(5))orleft$(df$,1)="("thendt=0:gosub16368

    Gab's da einen Syntax-Fehler beim kompilieren?

    Wer schon immer wissen wollte, wie der
    Kopierschutz der "Heureka Teachware"
    Lernsoftware funktioniert,hier ist
    die Beschreibung dazu.

    Du hast dann in dem Anhang dazu geschrieben:


    Quote

    Es ist auch möglich den Kopierschutz zu deaktivieren :-)

    oder wer im cracken gut ist, decompiliert das Programm

    und entfernt den Kopierschutz.

    Ich habe in meinem dekompilierten ALI V4 nachgesehen, wie ich das gemacht habe (was jetzt nicht heißen soll, dass ich im Cracken gut bin).

    In Zeile 9330 wird in kl ein Messwert eingelesen, der dann in 9433 ausgewertet wird.

    Ich habe den P-Code dann so geändert, dass folgendes draus wird:

    Code
    1. 9433 pokeob,0 : rem (po=0andkl>25.4)+(po>0andkl<33.6)

    Man sieht also schön, dass da eine Toleranz, was den Messwert angeht, vorhanden war.

    Wahrscheinlich bedeutet po=0 Zeitnahme bei dem einen Track und po>0 bei dem anderen.


    Achja, da war noch was:

    Code
    1. ; ------------------------------------ ; checksum routine
    2. 11064 pokeob,0
    3. 11067 pokeob+1,p%
    4. 11072 pokeob+2,j
    5. 11077 pokeob+3,p
    6. 11082 rem sys52968
    7. 11090 j=0:REM j=-1e+09+peek(ob)+256*peek(ob+1)+256^2*peek(ob+2)+256^3*peek(ob+3)-zz
    8. ; ^- patched
    9. 11134 pokeob,j<>0
    10. 11139 return

    Nun angenommen, man möchte den dekompilierten Code zum Laufen bekommen. Wie würde ich da rangehen:

    Erstmal die künstlichen CLRs raus. Dann alle GOTOs und GOSUBs verfolgen, um rauszubekommen, welcher Code gar nicht angesprungen wird.

    Bei jedem nicht angesprungenen Code-Schnipsel zweifeln, ob das so richtig ist.

    Beim ersten Betrachten des Kompilats sehe ich zwar interessanten Code (d.h. einen der nicht nach Müll aussieht), z.B. ab Zeile 8106 ...

    ... der aber nie angesprungen wird. Also würde ich annehmen, dass der Decompiler etwas übersehen hat und würde den Anfang mit dem P-Code vergleichen. Oder?

    Zeile 8110 und 8117 wird auch nie angesprungen, obwohl die Variable uh und al später doch verwendet werden. Nur eine Ablenkungstaktik?


    Die ganzen Bytes, die nun CLRs sind ($5a ..., $59 ...): Kann es nicht sein, dass die Runtime doch irgend etwas damit anstellt (spezielle Opcodes, die ignoriert werden, oder - schlimmer - doch etwas tun)?

    Wie könnte das vor dem Kompilieren ausgesehen haben, im ursprünglichen Basic-Programm?

    Eine Möglichkeit meinst Du wäre, dass man da nach dem Kompilieren einige Bytes geändert hat, um das Dekompilieren zu erschweren.

    Aber woher wusste man, dass man das tun kann, ohne die Runtime instabil zu machen?

    PS: Die Firma, Heureka Teachware gibt es auch schon länger nicht mehr.

    Gibt es denn einen Rechteinhaber heute noch oder einen Rechtsnachfolger?

    Ich würde ihn jetzt nicht gerade darauf ansprechen (außer vielleicht nach einem Autogramm fragen, oder Selfie, wie das heute genannt wird), aber ich denke ja: http://www.peter-ostermann.de/

    Heute haben wir https://www.stephenwolfram.com/: Entwickler von Mathematica, der Wolfram-Language und vielleicht einer unfizierten Theorie von allem -:)

    Damals hatten wir P. O.

    This is all very interesting of course, but I have to question the motivation. I of course understand software developers have to feed their family, but could we not shackle teachers and our children with a copy protection to make their job of teaching our children and learning harder?


    Certainly it could just have been licensed to the school system in such a way where they had the rights to copy the disks and use them how they needed them?

    I'm afraid I didn't get your point. As I wrote in my last post we reveal (just like real archaeologists) another piece of otherwise lost (C64) history with every decompiled program. Nobody questions putting copy protection on software. But copy protection sometimes makes software lost in time. IMHO Heureka hadn't lost much sales in the eighties because of it's excellent copy protection methods.

    Our motivation to do what we do is to understand copy protection methods, put compiled programs to undestandable form and looking at them celebrate and respect the developers of those times.

    Ich habe mich eben gefragt, ob Du einiges davon überhaupt mal releaset hast. Aber wenn ich 1 und 1 und MST und MSR zusammenzähle, dass scheint es zumindest auf CSDB einiges von Dir zu geben. Die Liste dort hört ja gar nicht auf. Oh man...


    Auch auf die Gefahr hin, dass ich etwas abschweife:

    Es ist dann wohl nur eine Frage der Zeit (oder bereits der Fall?) dass Du Dir auch DTL-Basic und vor allem die Dekompiliermöglichkeiten ansehen wirst. Es sollen ja massenweise Spiele damit erstellt worden sein (v.a. einige Strategic Simulations-Titel). Es gab mal eine sehr interessagte Diskussion auf https://csdb.dk/forums/?roomid…cid=112786&showallposts=1 in der jemand ein sehr gutes Dekompilat präsentiert hat, aber den Decompiler bis heute für sich behält... :-( Sogar der Autor von DTL-Basic hat sich da zu Wort gemeldet und sich gewundert, dass sich im Jahre 2016 noch jemand für seine Arbeit interessiert. Es sagte dabei auch, dass ihm in den ganzen Jahren nur ein funktionierender Crack seines per Dongle geschützten Compilers untergekommen ist.


    Wie dem auch sei: Mit jedem dekompilierten Programm enthüllen und bewahren wir (ganz ähnlich wie die echten Archäologen) ein weiteres Stück sonst verlorener (C64-)Geschichte.

    Und hier nun OPTI-MA Decompiled. Viel spass damit.:)

    Hammer!

    Ich werde wahrscheinlich länger brauchen zu erfassen und zu verarbeiten, was Du da eben verschickt hast, als Du für's Cracken und Aufbereiten gebraucht hast.

    Bin momentan in so etwas wie in einer Schockstarre... <aufdenbildschirmstarrdummgrinsundungläubigmitdemkopfschüttel> :-)

    Bitteschön.:)


    Vielleicht kannst du damit (compiler infos.txt) auch was anfangen.

    Na klar!

    Ich habe mir dafür sonst immer Scripte gemacht, wie z.B. das angehangene. Sowas wird mit Deinen Infos natürlich einfacher.

    Ich habe damit z.B. mal für den Rechenlöwen von Westermann (Cartridge, siehe Anhang) dem Decompiler auf die Beine geholfen.

    Das Ergebnis: D64-Image: RechenLoewe.7z und Ausdruck: rechenloewe23.pdf.

    Falls es interessiert... Die Firmware für den 1520 wurde ausgelesen, analysiert und ist im Netz zu finden. Sind nur 2 KB. Es wäre also kein Problem die ganze oder Teile davon mit einem anderen Rechner zu verwenden.

    Man könnte noch erwähnen, dass neben dem 2K ROM lediglich 64 Byte(!) RAM in dem 6500/1 vorhanden sind. Ich finde es immer noch unglaublich, wie die Entwickler das Plotter-Betriebssystem da reinbekommen haben (Vektor-Zeichensatz, Plotter-Steuerung, Busroutinen, Befehlsinterpreter).