Hello, Guest the thread was viewed59k times and contains 370 replies

last post from Goodwell at the

C64 Studio - Features Wunschliste

    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.

    Code
    1. 355 $080D !macro MOV16i LOOP+1, 1024 <--- echter Aufruf aus dem Source Code
    2. 356 $080D A9 00 lda #<1024
    3. 357 $080F 8D 1A 08 sta ╚LOOP+1╝
    4. 358 $0812 A9 04 lda #>1024
    5. 359 $0814 8D 1B 08 sta ╚LOOP+1╝ +1
    6. 360 $0817 A2 41 ldx #65
    7. 361 $0818 !end <--- Echtes letztes Byte $0818

    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.

    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:

    [External Media: https://www.youtube.com/watch?v=kiVu7CaMn1g]

    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.

    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.

    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:

    Code
    1. *=$033c
    2. lda $14
    3. bmi weiter
    5. !byte $2c ; "bit"
    7. weiter lda #$00
    8. sta $15
    9. rts

    wird im Disassembler:

    Code
    1. * = $033c
    2. lda $14
    3. bmi label_0341
    4. bit $00a9
    5. sta $15
    6. rts

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