C64 Studio - Entwicklungsumgebung

  • Hallo Endurion,

    ich habe ein unerklärliches Verhalten gefunden - kann auch sein, dass ich etwas falsche eingebe oder verstanden habe.
    Wenn ich den Pseudobefehl !Zone nutze, bekomme einen Fehler (Code E1303 - Expected single zone descriptor). Wenn ich !Zone mittels Semikolon markiere, klappt das Erstellen ohne Fehlermeldung. Jedoch kann ich die Zonen noch ein- und ausklappen.
    Ich weiß nicht ob das so sein soll oder ich etwas falsche mache......
    Bilder
    • alles_ok.jpg

      90,81 kB, 1.024×644, 17 mal angesehen
    • Fehlermeldung.jpg

      85,17 kB, 1.024×610, 13 mal angesehen
    • Semikolon_zone.jpg

      61,28 kB, 1.024×443, 13 mal angesehen
    Wer schreit, denkt nicht !

    www.dmhas.de / nas.dmhas.de/
  • DMHas schrieb:

    Wenn ich den Pseudobefehl !Zone nutze, bekomme einen Fehler (Code E1303 - Expected single zone descriptor).
    Der Name der Zone muss den Regeln für Bezeichner gehorchen (genau wie Labels) - die IDE erwartet also ein Argument, findet aber zwei. Änder den Namen von "Screen Tastaturbelegung" zu "Screen_Tastaturbelegung" oder "ScreenTastaturbelegung" und der Fehler verschwindet.

    EDIT: ACME sagt in solchen Fällen "Garbage data at end of statement", das ist sogar noch weniger aussagekräftig. Verständliche Fehlermeldungen sind schon ne Kunst für sich. ;)
    Yes, I'm the guy responsible for the ACME cross assembler
  • Mac Bacon schrieb:

    Der Name der Zone muss den Regeln für Bezeichner gehorchen (genau wie Labels) - die IDE erwartet also ein Argument, findet aber zwei. Änder den Namen von "Screen Tastaturbelegung" zu "Screen_Tastaturbelegung" oder "ScreenTastaturbelegung" und der Fehler verschwindet.
    Danke! Wiedermal sitzt der Fehler vor dem Bildschirm.

    Wie ist es mit dem Semikolon?
    Wer schreit, denkt nicht !

    www.dmhas.de / nas.dmhas.de/
  • Ne Anfängerfrage:
    Ich hab gerade in meinem Projekt eine .ASM und ein .BAS. Sehr übersichtliche Konfiguration also.
    Ich assembliere/compiliere beides als.PRG auf die Platte.
    Mit dem Basic-Programm will ich die Assembler-Sachen testen.

    Auf welchem Wege bekomme ich nun beide Dateien am schönsten in meinen Test im Vice?

    Dem .BAS hab ich schon beigebracht, dass es vom .ASM abhängt. Wenn ich das starte, dann bekommt es auch das aktuellste Assembler-Programm, das ich dann mit If A=0 Then A=1:Load"asdasd",8,1 nachladen kann. Aber so hinterrücks schaffen es die Breakpoints des Assemblerprogramms nicht bis in den Vice.

    Andersrum sieht es besser aus: In den Properties des .ASM hab ich unter DEBUG das compilierte Basic-PRG angegeben, das dann auch wieder mit Load,8,1 das Assembler-Programm nachlädt.

    Läuft, erscheint mir aber irgendwie ein bisschen wild getrickst?
    -----------
    Komme ich in dem Basic-Programm an die Symbole des Assembler-Programms ran? In den Dependencies hab ich sie jedenfalls angehakt.
    -----------
    Das Assembler-Programm ist grad mal ganz einfach:
    *=$c000
    dec 53280
    jmp $c000
    ...gefolgt von viel mehr, aber egal.

    Der Button "Debug step" bleibt immer 2mal auf dem DEC 53280 stehen.
    Ich vermute, vor und nach der Speicheränderung?
    Wäre schön, wenn man dann in den Registern auch die effektive Adresse des Befehls und den Inhalt der Speicherstelle sehen könnte.

    Dann ist mir noch aufgefallen, dass hin und wieder, gefühlt bei jedem 100. Klick auf den Debugstep, die Disassembly anspringt und behauptet, dass nun an $00d0 ein JAM ausgeführt würde. Wird es gar nicht.
    Vollmond war gestern!
  • Interessante Konstellation :)

    Da muss ich mal rumprobieren, evtl. auch was erweitern. In welcher Form generierst du die Dateien? Als Einzel-PRG, oder baust du ein Disk-Image?

    Edit: Bisher wurden Symbole in BASIC-Dateien nicht wirklich unterstützt. Ich habe das mal eingebaut und eine Version unter georg-rottensteiner.de/webmisc/C64StudioRelease.zip abgelegt. Das funktioniert jetzt so:

    * Assembler- und BASIC-File in eine Solution/Projekt
    * Assembly und Symbole als Dependency im BASIC-File markieren
    * BASIC-File als "Active File" markieren (damit beim Debuggen auch schön das BASIC-File startet)

    Dann kannst du auch im Assembly Run-To machen, Breakpoints setzen, etc. Die Labels werden damit auch an VICE übergeben.


    Das Verhalten beim Debuggen ist fest an VICE gebunden (im Moment mache ich da ja nur Remote-Steuerung), d.h. wenn der Debug-Step da zweimal steht, ist das einmal für den Breakpoint, und dann einmal für den Step selbst.

    Das Fehlerbild im letzten Satz klingt so, als würde ich mich beim Auswerten der Monitor-Antwort vertun und eine falsche Adresse bestimmen. Da muss ich mal prüfen. Das ist die Krätze mit einem Interface, das ganz klar nicht für automatisierte Benutzung ausgelegt ist.

    Dieser Beitrag wurde bereits 2 mal editiert, zuletzt von Endurion ()

  • Endurion schrieb:

    Interessante Konstellation
    Wie testest Du denn erste Routinen? Mir fiel es immer leichter, schnell mal einen Test in Basic zu schreiben, wo ich auch was mit Sinus und For-Next-Schleifen machen kann oder gar die ganze Rechnung nochmal in einer anderen Sprache nachstellen kann.

    Endurion schrieb:

    Da muss ich mal rumprobieren, evtl. auch was erweitern. In welcher Form generierst du die Dateien? Als Einzel-PRG, oder baust du ein Disk-Image?
    Einzelprogramme tun's erst mal noch eine Weile. Das mit den Disketten ist doch schon wieder so kompliziert... :)

    Endurion schrieb:

    Edit: Bisher wurden Symbole in BASIC-Dateien nicht wirklich unterstützt. Ich habe das mal eingebaut und eine Version unter georg-rottensteiner.de/webmisc/C64StudioRelease.zip abgelegt. Das funktioniert jetzt so:

    * Assembler- und BASIC-File in eine Solution/Projekt
    * Assembly und Symbole als Dependency im BASIC-File markieren
    * BASIC-File als "Active File" markieren (damit beim Debuggen auch schön das BASIC-File startet)

    Dann kannst du auch im Assembly Run-To machen, Breakpoints setzen, etc. Die Labels werden damit auch an VICE übergeben.
    Ach so, "Symbole" sind in dem Zusammenhang alle Labelnamen, die an Vice gehen sollen. Dann meinte ich was anderes.
    Im Basic-Editor gibt es ja {}, z.B: für {CTRL-3} und ähnliches, was dann noch schnell beim Compilieren übersetzt wird. {ba_Farbram} oder ähnliches, um Label aus dem Assembler ins Basic einzusetzen wäre schön.

    Endurion schrieb:

    Das Verhalten beim Debuggen ist fest an VICE gebunden (im Moment mache ich da ja nur Remote-Steuerung), d.h. wenn der Debug-Step da zweimal steht, ist das einmal für den Breakpoint, und dann einmal für den Step selbst.
    OK.

    Endurion schrieb:

    Das Fehlerbild im letzten Satz klingt so, als würde ich mich beim Auswerten der Monitor-Antwort vertun und eine falsche Adresse bestimmen. Da muss ich mal prüfen. Das ist die Krätze mit einem Interface, das ganz klar nicht für automatisierte Benutzung ausgelegt ist.
    Erklärt, warum ein Schritt ne Sekunde dauert :D
    Vollmond war gestern!
  • @domspitze:

    Die Autovervollständigung ist insofern !zone-Abhängig, dass nur lokale Labels aus eben dieser Zone verfügbar sind. Du kannst die lokalen Labels einer anderen !zone aber immer über <zonename>.<lokaler name> greifen.

    Was nicht drin ist: Dynamisches Anpassen der Zonen mit automatischem Anpassen der Label-Positionen. D.h. der Stand des letzten Compile wird gemerkt. Wenn du jetzt eine ganze Kette an Code schreibst, verrutschen ja die Zonen. Das weiß der Vervollständiger aber nicht, d.h. da können dann Abweichungen drin sein.
    Geistert schon seit Jahrem im Kopf herum, wie ich das schön geregelt kriege, ohne dass jeder Tastendruck heftigste Verzögerungen auslöst.

    @hoogo: Interessante Idee, in welcher Form sollten die Symbole eingesetzt werden? Einfach als Dezimalzahl?
    Die Sekunden-Pause nervt mich auch höllisch. Ich könnte natürlich bei VICE mitspielen und die Schnittstelle erweitern. Oder mir den Code von VICE schnappen und direkt anbinden. Beides heftiger Aufwand :)

    @Squidward: Oh ja, RegEx macht's möglich. Ich schau mal, ob ich da was dran machen kann.
  • Endurion schrieb:

    @hoogo: Interessante Idee, in welcher Form sollten die Symbole eingesetzt werden? Einfach als Dezimalzahl?
    Ja. Im Moment lege ich die Label an einfach zu merkende Stellen (4096) und schieb Sie nach dem Test wieder an den richtigen Platz. Mit der Labeladresse direkt in Basic würde sich der Test ja selber anpassen und mit dem Programm "mitwachsen".
    Vollmond war gestern!
  • Ist auf webmisc eingebaut. Control-Code-Mappings gehen vor. Erst wenn die alle nicht passen, wird ein Label mit dem Namen gesucht. Der Zahlenwert wird direkt eingesetzt, d.h. am sinnvollsten in einen String einbauen.

    Sieht dann so aus:

    Quellcode

    1. 10IFA=0THENA=1:LOAD"ASM.PRG",8,1
    2. 20SYS16384
    3. 30?"HALLO WELT!"
    4. 40?"LABEL HAT DEN WERT {ANOTHERLABEL}"

    Quellcode

    1. * = 16384
    2. inc $d020
    3. ldx #0
    4. lda #1
    5. ANOTHERLABEL
    6. sta $0400,x
    7. inx
    8. bne ANOTHERLABEL
    9. rts
  • Gleiche Konfiguration wie oben:
    -Wäre schön, wenn im basic auch {$c000} eingegeben werden könnte. {} sieht für mich wie ein Escape für alles mögliche aus.
    -Hab grad gemerkt, dass man im Basic ja gar keinen _ eingeben kann, und Groß/Klein ist auch nicht so einfach. {Labelname} wird also nur mit passend benannten Labeln gehen.
    -Wenn ich dem .bas in den Dependencies ein Häkchen bei den Symbols des .asm gesetzt habe, dann kann man nach Änderungen am Basic-Programm kein Built mehr machen. Statuszeile sagt "Built failed"; und es gibt auch keinen Ping oder neue Datei.

    Meine Exe ist die vom 22.1.
    Vollmond war gestern!
  • Aua, wenn es nach Build Failed klemmt, dann gab es möglicherweise irgendwo eine Exception. Steht im "Output" etwas Derartiges?

    Unterstrich/Groß/Klein ist auch noch ein Problem, das beisst sich mit dem Eingabe-Mapping. Ich überlege, ob ich da so etwas ähnliches wie den String-Eingabe-Modus mache (d.h. wenn man { tippt, wechselt der Editor in den Label-Modus und man kann normale Zeichen eingeben, bis } oder Escape oder Return gedrückt wird)