Ich habe herausgefunden, dass man mit ;{ und ;} Code einfalten kann.
Ist das ein gewolltes Feature oder eine zufällige Sache, die dann eventuell nach einem Update nicht mehr geht?
Wenn gewollt, toll, benutze ich sehr gerne.
You are about to leave Forum64 to get redirected to the following address:
Please note, that the target website is not operated by us. We are not responsible for it's content nor does our privacy policy apply there.
Ich habe herausgefunden, dass man mit ;{ und ;} Code einfalten kann.
Ist das ein gewolltes Feature oder eine zufällige Sache, die dann eventuell nach einem Update nicht mehr geht?
Wenn gewollt, toll, benutze ich sehr gerne.
Ich habe herausgefunden, dass man mit ;{ und ;} Code einfalten kann.
Ist das ein gewolltes Feature oder eine zufällige Sache, die dann eventuell nach einem Update nicht mehr geht?
Wenn gewollt, toll, benutze ich sehr gerne.
Interessant. Geht das im Basic? Und führt es auch nicht zu "compilliertfehlern"?
Danke für Info bezüglich Suchen/Ersetzen, ist auf der Liste.
;{ und ;} ist eher zufällig, Einklappen ist offiziell nur bei !zone-Blöcken unterstützt.
Das Einklappen selbst hat keinerlei Auswirkungen auf Compilierung, aber { } in BASIC-Code schon eher
Sind local Labels in Macros (die mit . und @ ????) eigentlich local.
Oder anders formuliert, startet ein Macro einen neuen Scope?
Macros haben ihren eigenen Scope, wenn ich das nicht auch wieder verbaselt habe.
Das heißt locals (. @) sind local zum Macro?
Und Globals natürlich auch dort global?
Hab ich das richtig verstanden?
Mir ist gerade aufgefallen, dass Macros sich nicht in die !zone einfalten.
Anders formuliert, die !zone endet, wenn ein Macro kommt - faltungstechnisch.
Getestet:
Cheap local Labels gehen also nicht.
So, ich biete mal wieder etwas von meiner Macro-Spielerei an.
Habe ein neues Konzept.
Diese Version erkennt nun, wenn eine Branch zu weit geht. Bricht dann mit Error ab.
Dann muss man die eXtended Version verwenden: IF_EQUAL geht zu weit --> IF_EQUALx (x=extended) verwenden.
Ab jetzt erkennen die Macros auch, ob sie einen Branch oder einen JUMP verändern müssen. Ich pushe das vorher auf den Stack, verwende jetzt also pro Eintrag 2 Stack-Zellen. Außerdem gibt es für den Stack eine Debug-Ausgabe, damit man sieht, was am Stack ist.
Viel Spaß
Endurion: Falls du Zeit und Lust hast dir mal die Möglichkeit von optionalen Parametern anzusehen und vom Umwandeln von Variableninhalten (=Nummern) in Texte und dann das Einfügen in den Quelltext als Text, egal an welcher Stelle? Ganz großes Danke, falls du Lust hast.
War ne Frage dabei.
Sollte der Disassembler eigentlich schon funktionieren?
Bei mir funktioniert er irgendwie nicht.
Wieder ich
Folgendes:
Wenn ich mit der Maus über KOALA_HG gehe zeigt er mir in der erscheinenden Anzeige $208B8, 133304
Ist das nur n Anzeige Fehler oder funzt das so nicht?
EDIT: Fehler gefunden, saß vor dem Monitor
so passt es und rechnet korrekt
WalkThatWay: Der Disassembler funktioniert durchaus, aber wie so vieles ist er gewöhnungsbedürftig
Zuallererst muss man natürlich ein assembliertes File auswählen (in der Regel .prg)
Der Disassembler versucht, eine Startaddresse auszulesen (von einem BASIC-Starter mittels SYS). Falls das nicht vorhanden ist, fehlt ihm der Einstiegspunkt.
Du musst dann unter "Jumped at address" den Einstiegspunkt angeben und auf "add" klicken. Da können durchaus mehrere Sprungpunkte angegeben werden.
Der Disassembler versucht dann, an den angegebenen Sprungpunkten zu disassemblieren, und verfolgt auch Adressen von JSR oder JMP. Sobald da etwas erkannt wird, sieht man im "Disassembly"-Fenster das bisher Erkannte. Man kann jetzt on the Fly Labels und mehr Sprungpunkte angeben, die dann auch sofort umgesetzt werden.
Bei mir geht er recht gut.
Ich bin sehr zufrieden.
Würde noch die Bytes neben Adresse toll finden, aber super Tool.
Hat manchmal kleine Macken.
Beim Testen der IF habe ich z.b 150 nops erzeugt.
Die waren dann eine Liste von Bytes und keine Mnemonics.
@Endurion meine *.bin datei disassembliert er nicht so ohne weiteres. Ich probier mal deine Tips mit den Adressen aus.
ieee488-Jann-Datentechnik.bin
Mit dem Dis6502 geht sie einfach so zu disassemblieren.
Ich glaube jetzt habe ich es geschaft. $A000 ist die Startadresse.
Du musst dann unter "Jumped at address" den Einstiegspunkt angeben und auf "add" klicken. Da können durchaus mehrere Sprungpunkte angegeben werden.
Daran hat es gehapert. Bin halt auch nur einer mit unterentwickelter Klickkompetenz.
Ganz so einfach hinbekommen tut man die ganze Datei disassemblen aber nicht.
Diesen Thread hier bitte für Support/Fragen und für Endurions Updatemeldungen zum C64 Studio verwenden.
Wünsche zu neuen Features ab jetzt bitte hierher posten: C64 Studio - Features Wunschliste
Wenn ich was noch rüberschieben soll, bitte per PM melden. Der Thread hier ist ziemlich gross und unübersichtlich geworden, es ist schwierig das auseinanderzunehmen im Nachhinein.
Display MoreBei mir geht er recht gut.
Ich bin sehr zufrieden.
Würde noch die Bytes neben Adresse toll finden, aber super Tool.
Hat manchmal kleine Macken.
Beim Testen der IF habe ich z.b 150 nops erzeugt.
Die waren dann eine Liste von Bytes und keine Mnemonics.
Das meinte ich dann mit on-the-fly-Nachbessern. Da der Disassembler nicht sicher wissen kann, dass da jetzt Code oder Daten sind, muss man ihm mit einem weiteren Sprungpunkt auf die Sprünge helfen. So kann man sich dann langsam durchhangeln. So habe ich mich auch halbwegs durch Ghostbusters gefräst, und dann versucht, stückweise Code-Adressen und Unterroutinen zu erkennen und mitzunehmen.
Aber mir ist bewusst, dass der Disassembler bei weitem noch nicht optimal ist.
Ich glaube, ich bin wieder auf einen Bug gestoßen:
Oben Zeile 7 macht große Probleme. Bei 2-mal läufts, bei 3-mal meckert er etwas wie "Redefinition of label __hla_STACK9" und andere Labels auch.
Das ist aber auch NUR in DIESER Konstellation ein Problem. Ich könnte hunderte +__hla_PULL_STACK händisch hintereinander schreiben, er hätte kein Problem. Muss also irgendetwas mit dem !for oder !if zu tun haben.
Noch ein interessanter Aspekt. Schreibe ich ein "+__hla_PUSH_STACK *" zwischen 2. und 3. PULL, geht es auch wieder. Aber auch im Push werden dieselben Label verwendet, also warum der error "Redifintion"?
Habe das gesamte Projekt als Zip angehängt.
Meine Fresse, das ist mal ein Härtetest
Und auch interessant, der ganze Code aus dem Precompiled tut einwandfrei. Da muss ich tiefer graben.
Ha ha, ja, in der Tat.
Ich versuch diese EXIT_IF zu stacken. Damit er nacheinenander die Sprungziele befüllen kann.
Einfach, weils Spaß macht
Guck dir mal auch die anderen Macros an.
Da habe ich einiges schon, was deine Macros hergeben, verwendet.
Geht gut. Coole Sache! Danke für deine Arbeit.
In etwa habe ich den Fehler eingekreist, bei der Verschachtelung der Source-Infos mache ich offenbar die Verschachtelung der temporären Labels nicht richtig mit. Wenn es interessiert, temporäre Labels sind für mich diese Defines, die nur über einen bestimmten (voll ausgeklappten) Source-Code-Bereich einen bestimmten Wert haben. Wie zum Beispiel der Zähler bei einer !for-Schleife, oder eben Konstanten, die später umdefiniert werden)
Und wenn da zwei Bereiche überlappen, dann ist irgend etwas im Argen. In dem Fall offenbar meine Bereichsbestimmung
Schön anzusehen, wie das Studio immer weiter reift, Georg .
Bin ja etwas still gewesen in letzter Zeit, aber demnächst bin ich auch wieder am Ball mit meinen ganzen unvollendeten Projekten.
Danke, Gruß und schönes Wochenende, Georg .
Lieber Endurion, lieber Georg, vielen herzlichen Dank für Dein weiterhin grandioses Engaement. Dass Wünsche nach Abweichung von Industriestandard-Code an Dich herangetragen werden, tut mir persönlich sehr leid!
Mit einer Plug-In Schnittstelle könnten die daran interessierten Menschen Dein ganzes Studio de-standardisieren und sogar ein Basic V2.1 schaffen o. ä.
Wie weit Du auf solche Wünsche eingehst, liegt da bei Dir Schönes Wochenende!