C64 Studio - Features Wunschliste

Gute Punkte, floats gibt es auch so halb, kommt auf die Liste

Lieber Endurion!

Ich arbeite ja mit diesen Strukturmacros.

Für das Erstellen des "Preprocessed File" würde ich mir einen Listingschalter wie zB "!liston" und "!listoff" wünschen.
Er sollte das Listen des Listings im "Preprocessed File" unterdrücken.
Der Sinn wäre, dass die ganzen hunderten Macrodefinitionen nicht im dem Listing im "Preprocessed File" stehen würden und das Programm bis zur Unkenntlichkeit entstellen würde. Weiter könnte man auch die Macro-Expansion auf die beiden !macro ... !end Zeilen beschränken, wenn man diese Befehel in der Macrodefinition gebrauchen würde.

Ein Schalter wie "!showmacrolineon" und "...off" sollte einen Comment über/unter der Expansion machen mit dem Originalemakroaufruf.

Ganz lieben Dank

Gruß, Thomas

P.S. Was meinst du in "floats gibt es auch so halb" mit "so halb"?

Mit so halb meine ich, dass es für die Value-Tables Routinen gibt, die mit floats rechnen, die aber im Assembler selbst nicht verwendet werden. D.h. das müsste man da dann noch mit rüberbringen. Und vor allem sicherstellen, dass man dann keine Seiteneffekte hat durch Rundungsfehler.

Den !liston bzw. !listoff verstehe ich nicht ganz. Es soll das Auflösen der Macros im "preprocessed file" unterdrückt werden?

!liston und !listoff soll grundsätzlich verhindern, dass, was auch immer im Source steht, in das preprocessed file kommt.

Steht dort eine Macro-Definition, dann sieht man sie nicht im prep file.

Überhaupt wäre es besser, wenn im prep file beim Macro-Expandieren auch nur der wirklich expandierte Code angezeigt wird.
Momentan ist es ja so:

Er zeigt also wirklich ALLES an, auch die nichtexpandierten Pfade der Defintion. Und diese ganzen Stack-Moves würde ich mit !listoff auch gerne unterdrücken können, selbst wenn sie expandiert werden.

Woher habe ich die Idee?
Der ursprüngliche Autor der Idee von den Struktur-Macros hat so einen Befehl in seiner Macro-Lib verwendet. Ich glaube - bin mir aber nicht sicher - es ist der Kowalski-Assembler?

Beispiel:

Das hier ist aus seinem "StackPop"

Somit sieht man das alles nicht im prep file.

Ah, verstanden. Danke!

In der Todo-Liste von V5.9 steht noch "• Syntax-Coloring -> Preview im Setting Editor mit FastColoredTextBox".
Das ist doch erledigt, so wie es jetzt ist, oder? Das Zusammenspiel sieht man ja dank Instant Refresh daneben in geöffneten Dateien.

Ich hatte ja neulich für den BASIC-Editor mit Font-Kombinationen experimentiert und war zum Schluss gekommen, dass der C64-Pro-Mono-Font eigtl. der einzig brauchbare ist. Für diesen kommen hauptsächlich drei bis vier Größen in Betracht. Die beiden Extrema 6pt und 12pt bilden das Original perfekt ab. Die Default-Größe 9pt liegt eben genau in der Mitte, ist leicht verzerrt, aber problemlos brauchbar. 11pt ist auch noch ok, 7pt nicht mehr so, 8pt und 10pt schlecht.

6pt ist zwar klein, aber dafür scharf und damit wunderbar geeignet für umfangreichere Programme, bei denen man mehr Übersicht braucht. Allerdings fiel mir auf, dass das auf die Anzahl sichtbarer Zeilen noch keinen Einfluss hat, da die Zeilenhöhe unabhängig von der tatsächlichen Zeichenhöhe auf 18px festgesetzt war. Ich hab jetzt mal die Zeilenhöhe freigegeben und durch Originalzeichenhöhe plus Zeilenabstand ersetzt. Ein Zeilenabstand von mindestens 2px ist notwendig, um Überlappungen zu vermeiden. Bei 3px Zeilenabstand und dem 12pt-Font ist es genau wie zuvor mit der festen 18px-Zeilenhöhe. 4px (als Default gewählt) ist ratsam für die kleineren Fonts. Bei 9px Abstand und dem 6pt-Font entspricht die vertikale Übersicht der vom Visual Studio. Man könnte zwar auch einfach einen festen Zeilenabstand programmieren, aber da das wahrscheinlich jeder anders haben möchte, sollte man sich das vielleicht besser selbst einstellen können.(?)

Hier mal kurz gezeigt:

Danke für die Gegenüberstellung, ich nehme das mal mit auf die Liste!

Der TODO-Punkt betrifft eigentlich die kleine Preview-Box im Dialog, man hat ja nicht immer gerade die passende Kombination an Fenstern im Hintergrund

Ich fände es gut, wenn es die Funktionen "Alle Zones zuklappen" und "Alle Zones aufklappen" gäbe.

Das mit den Variablen für BASIC (wenigstens V2) wäre tatsächlich sehr hilfreich. Bitte auf die "1. Liste" übertragen.

Schön wäre die Möglichkeit, das C64 Studio auch unter Linux kompilieren zu können. Unter Wine, also im 32Bit-Modus, läuft es nämlich leider nicht.

Hmm, bei mir tut es das.

Ich hab mir bei Ubuntu in der VM mit PlayOnLinux beholfen. Dazu muss da drüber auch .NET Framework 3.5 installiert werden (da gibt's noch so ein paar XP-Benutzer), das ist da aber nur ein Häkchen zu setzen. .NET Framework ist ja nicht von Haus aus verfügbar.

Ich würde ja zu gerne zumindest auf .NET Core portieren, das dürfte da auch deutlich zukunftsfähiger sein.

Entschuldigt, wenn ich es überlesen habe, aber ich habe weder hier noch in der Doku das passende gefunden.

Ich würde gerne etwas setzen, wie das hier: screen = $0400, um etwas wie sta screen zu verwenden.

Ist das möglich?

Zitat von DP64

Ich würde gerne etwas setzen, wie das hier: screen = $0400, um etwas wie sta screen zu verwenden.

Ist das möglich?

Ja - geht ohne Probleme so.

Hm... Ich könnte schwören, dass das bei mir nicht geklappt hat.

Habe Deinen Source jetzt mal abgetippt und funktioniert natürlich. Keine Ahnung, was ich falsch gemacht hatte

Danke!

Eine Unterstützung von XC=BASIC fänd ich toll.

Das ist eigentlich kein echtes Basic, sondern von der Programmierung her nur daran angelehnt. Der Code wird nicht interpretiert, sondern es wird durch XC=BASIC Assemblercode generiert, der dann mit DASM compiliert werden muss.

Es fehlt aktuell aber eine gescheite Entwicklungsumgebung.

Hmmm, das ist ja wie du sagst, kein echtes BASIC. Da wäre bestenfalls eine Code-Vervollständigung drin?

Alles andere macht dann ja der XC=BASIC-Compiler. Letzteres ist über einen Custom-Build-Step möglich.

D.h. ich kann über XC BASIC kompilieren?

Wie siehts mit dem Syntax Highlightning aus? Kann ich dafür eine eigene txt erstellen?

Wo stelle ich das ein?

Kompilieren müsste gehen, wenn C64Studio das wie ein Assembler-File betrachtet.

Syntax Highlighting hingegen ist nochmal ein ganz anders Ding. Das ist nicht wirklich konfigurierbar, als Ersatz für einen Texteditor ist es ja nicht gedacht. Das ist extrem auf reguläres BASIC sowie diverse Assembler-Varianten zugeschnitten.

Ich könnte das wohl wie Assembler behandeln, dann wären die Schlüsselworte eingefärbt. Das ist aber nicht mal eben. Die paar Kennworte schon, aber dem C64Studio das XC=Basic beizubringen ist aber schon eher aufwändig (dummerweise ist die Extension .bas mit BASIC verdrahtet, von der Steuerung wäre es aber eher wie Assembler)

Der BIT-Befehl wird gerne benutzt, um eine Einsprungstelle zu tarnen. Der Disassembler von C64 Studio erzeugt in solchen Fällen im Moment keinen assemblierbaren Code.

Bsp, aus:

wird im Disassembler:

... mit einem Sprung zu einem nicht-existierenden Label.

Ist das so gewollt? Damit man wenigstens den Sprung sieht, auch wenn es das Label gar nicht gibt?

Oder wäre es nicht sinnvoller, wenn ein Sprung direkt hinter einen BIT-Befehl zeigt, diesen dann nur als !byte-Wert anzuzeigen, so wie ganz oben..?

P.S. Wo finde ich diese todo.txt-Datei? Möchte natürlich keine ollen Kamellen bringen.

Oohh, der ist aber böse

Das ist ein ziemlicher Spezialfall, aber packe ich mal mit auf die Liste.

Vor allem ein Label, dass dann nicht eingesetzt wird, ist doof. Oberstes Ziel vom Disassembly, das soll erstmal ohne Handgriff zu dem exakt gleichen Binary führen.