Posts by Stephan Scheuer

Danke! Das werde ich jetzt gleich mal testen. Einzig, das beim Decompilieren die Steuercodes den Bildschirm vermüllen, habe ich noch nicht gelöst bekommen.

Das sich dadurch die Textfarbe ändert, ist noch dass geringste Problem. Kann man die Auswertung der Steuercodes, durch den Basic Interpreter, unterdrücken?

Wenn in einer Variable z.B. ein String von 40 Zeichen abgelegt wurde, kann man die maximal auf dem Bildschirm auszugebenden Zeichen festlegen? Auf z.B. maximal 10 Zeichen.

Ich hoffe, dass alle Arbeiten zum Wochenende abgeschlossen sind. Dann wird der Decompiler nachmals an diversen Kompilaten getestet.

Übrigens, ich habe heute zum Erstenmal geschafft, P-Code im RAM der Supercpu ab Bank $031000 auszuführen. Das eröffnet ganz neue Möglichkeiten.

P-Code von mehreren Megabyte Länge sind dann kein Problem mehr. Am Runtime Code muss ich aber auch noch einiges abändern oder neu coden.

Zudem bin ich am Überlegem, ob ich die Sprungtabelle in Bank $00 belasse, oder für diese eine eigene Bank reserviere.

Gruß: Stephen

Was ich gebrauchen könnte, wäre ein Buch, "Nützliche Pokes für alles mögliche und unmögliche".

Die Eingabemasken habe ich schon fast fertig. Alle Basic Befehle habe ich nochmals als Data Zeilen angelegt und Dimensioniert, so das man mitverfolgen kann, welcher

Pcode gerade abgearbeitet wird. Der Decompiler soll den Nutzer soviel Informationen wie möglich bereitstellen, damit auch geschützte Compilate, decompiliert werden können.

Kompiliert wird der Decompiler mit den Basic Boss und allen nutzbaren Direktiven. Die Teste sind diesbezüglich auch erfolgreich verlaufen.

Das hatte ich auch schnell festgestellt. Trotzdem ist das eine elende frickelei, bis das alle vernünftigt arrangiert ist.

Unten sind einige Bilder vom zu 99,9% fertigen Decompiler. Die Namen der Bilder sagen aus, was da gerade passiert.

Der Decompiler erzeugt meiner Meinung nach, den besten Basic Code aller bekannte Decompiler für den C64

Holy Moses C-Base CBASE hatte das Programm in etwa 3 Minuten fehlerfrei, mit allen Extensions decompiliert.

Vielen Dank, das funktioniert super. Das mit der Bildschirmmaske ist eine ganz üble fummelei.

Danke, werde ich gleich mal schecken.

Sorry ich hatte vergessen, ein Stück aus meinem Decompiler zu Posten. Seltsam, das bekomme ich hin....

Das ist mir jetzt recht peinlich, aber ich komme nicht darauf.

Auf dem Bild unten, sieht man verschiedenen Werte, die auch soweit ok sind. Nur der Wert oben rechts will nicht so, wie ich möchte.

Das Problem ist, dass von 1-stelligen bis 5-stelligen Werten alles dargestellt werden kann. Die alten Werte bleibt jedoch auf dem Bildschirm stehen und wenn jetzt

ein ein- bis 4-stelliger Wert dargestellt wird, kann mann das nicht erkennen. Oben rechts auf dem Bildschirm ist real "156" und nicht "15619"

Wie kann ich elegant den Bereich vorher löschen, so das die Werte ablesbar sind. Die länge der Zahl ist vorher nicht bekannt. Zudem wird die Schleifte von 30 stellen aus de Programm angesprungen.

Disk2EasyFlash only working with programs that use kernal-load $FFD5. All other loadings, for example "rom_acptrj = $ee13" or on-the-fly leveldecruncher don't work.

also "jsr $f4a5" to load datas don't work.

Quote from Bodhi1969

Quote from Stephan Scheuer

Achso... Ich schaue mir das gerade mal an. Im Moment ist das für mich noch undurchschaubarer.

Ich habe mir in Notepad++ extra das Basic v2 definiert. Dazu ein Stie, der mir die Basic Befehle, je nach Ketegorie in eine andere Farbe darstellt.

Hallo Stephan Scheuer, wärst du so freundlich, den Style des Basic V2 zur Verfügung zu stellen? So etwas suche ich schon länger.

Aber klar doch. Einmal Basic in bunt und auch 65816/6502 farbig. Beide Farbstyles sind noch nicht fertig, aber schon ganz brauchbar.

Bitte mit der Importfunktion einfügen. Endeungen für Basic-Code ist .bas und für Assembler .asm

Könntest du Bitte andere Disk2Easyflash Spiele mal kurz antesten?

Die Spieledateien von "The Train" haben keine ungewöhnlichen Adressierungen.

Ich danke dir. Das werde ich jetzt gleich mal im Code einbauen. Alle anderen Bugs sind sogut wie behoben.

Ok, dann werde ich nachher mal anfangen. Das sollte nicht allzu schwierig sein.

Im Moment (seit Tagen) code ich an meinem Austro Recompiler.

Problem 1: Wenn das Pi-Zeichen vorkommt, gibt es einen "Illegal opcode Error in xxxx"

Problem 2: manchmal beginnt die Zeilennummerierung um einen vermindert zu früh, ohne die Sprünge anzupassen.

Problem 1 "PI" habe ich leider nicht als Zeichen definiert.

Problem 2: Im Moment habe ich keine Ahnung, warum das so ist.

Wurde das mit disk2easyflash erstellt?

Ich könnte das sonst mal richtig an das Easyflash anpassen.

Danke, für die Info.

Bezieht sich das jetzt auf die Werte, die ab der Adresse sehen oder als Platzhalter für die Werte,

die dort ab der Adresse eingetragen werden? Das einzige was konstant ist, sind die Adressen der Werte.

Die Adresse der "pcode variables" , ist abhängig vo der Länge es Compilates.

Der "pcode restart", ist auch abhängig vo der Länge es Compilates.

Die Startadresse der "pcode data" sollte immer gleich sein.

Die Startadresse des "pcode star"t, ist abhängig vo der Länge der Datazeilen.

Quote from enthusi

da braucht es nur einen Disassembler

...und viel Arbeit, naja je nachdem wie lang der Quellcode ist. Bei "Wolfenstein-3D", die SCPU-Adaption, 10 Bänke, ab $200000 voll mit 65816-Code, dürfte das wohl Jahre dauern.

Quote from Endurion

Irgendwann muss irgendjemand mal einen Übersetzer für die diversen Dialekte machen. Außer Kickass mit seinem kruden Scripting-Geraffel

Das währe ein Meilenstein der Softwareentwicklung auf dem 64. Ein Programm, dass alle Pseudo-OP-Code oder gleich den ganzen Quellcode, der wichtigsten Assembler hin und her konvertieren kann.

Das wird aber mit Sicherheit ein Traum bleiben.

Ich denke mal, das ich das EQU auch verstanden habe.

; end of runtime

pcode_variables equ 00 ; - ab byte 00 gleich nach "end of runtime" die "pcode_variables" vectoradresse

pcode_restart -- equ 06 ; - ab byte 06 die "pcode_restart" vectoradresse

pcode_data ---- equ 08 ; - ab byte 08 die "pcode_data"

pcode_start ---- equ 10 ; - ab byte 10 dann der "pcode_start"

Quote from Endurion

Das könnte sta ( $fe ), y sein sollen

Siehe Bild. Das steht für STA $00FE,Y.

Das W Steht für Word, also eine 16Bit Adressierung. Beim ACME kann man das so machen: "STA+2 $00FE". Eine erzwungene 16Bit Adressirung.

Oder man schreibt einfach "STA $00FE,Y"

Für die Equal Sache habe ich genauere Infos als Bild hochgeladen.

Ohh, super. Ich danke dir.

Gegoogelt habe ich auch und auch in diverse Handbüchern nachgeschlagen. Nur habe ich nichts gescheites gefunden.

"STA.W $00FE,Y" ; - alles klar, das ist eine erzwungene Adressierungsart. Warum das so gemacht wird, entzieht sich meiner Kenntniss.

"STA $FE,Y" gibt es leider als 6502-Befehl nicht.

Ich habe gestern versucht einen Quellcode in das ACME-Format zu portieren. Leider sagen mir einige dieser Codes überhaupt nichts.

Wie sehen die ACME-Anweisungen der unten aufgeführten Anweisungen aus?

dc.b ; - könnte für Byte stehen. Im Quellcode sind auch texte gemischt mit Bytes so gekennzeichnet,

sta.w ; - sagt mir gar nichts.

equ 0 ; - noch weniger

equ 10

ds.w ; - könnte für word stehen

seg.u

Auch wird gefixt, die End of P-Code Erkennung ($4F). Einige Decompiler schießen weit über das Ziel hinaus. Wenn das Passiert, dann das Decompilieren abbrechen (Reset)

Das Sternchen "*PRG" entfernen und ein Validate ausführen. Danach sollte der Basiccode nutzbar sein. Achja, denn Müll am Ende des Basiccodes auch entfernen.