Hallo Besucher, der Thread wurde 479k mal aufgerufen und enthält 4057 Antworten

letzter Beitrag von smithloo am

C64 Studio - Entwicklungsumgebung

    Zitat von Endurion

    Ja, es gibt den Reiter "Breakpoints". Da kannst du Breakpoints anlegen, die auf bestimmte Ereignisse reagieren. Im Auswahlfeld entweder eines der Labels oder die direkte Adresse eingeben, Execute/Load/Store entsprechend setzen und auf Add klicken.


    Du kannst auch per Rechtsklick auf ein Label einen Data-Breakpoint anlegen, da hast du auch die Optionen mit Execute/Load/Store.

    Hallo Endurion,


    beim C64 funktioniert es so wie du es beschrieben hast.

    Beim VC-20 werden die Break-Points nicht gesetzt..


    VG

    Ah, das prüfe ich mal. Ich war davon ausgegangen, dass sich die Emulatoren da nicht unterscheiden.

    Wenn ich drüber nachdenke, dürfte das daran liegen, dass ich für den VC20 keinen Kernal-Einstiegspunkt gesetzt habe. Der wird in der Regel als erster Default-Breakpoint genommen, damit man nicht bei den ganzen RAM-Checks etc. schon den Breakpoint anspringt.


    Kennt zufällig jemand der Anwesenden den entsprechenden Einstiegspunkt für den VC20, beim C64 habe ich 0xE178 genommen?

    Mein Studio bleibt jetzt immer im Building ... hängen, egal ob ich compiliere, builde, debugge, ... und muss hart über den Taskmanager abgeschossen werden.


    Einzige Besonderheit zu sonst, nach dem Update auf die letzte Version hatte der Windows Defender beim ersten Start gefragt, ob ich das Programm wirklich ausführen möchte.





    Bisheriger Lösungssuche: Ich habe unter "%appdata%\GR Games\C64Studio\1.0.0.0" die settings.dat gelöscht und alles neu durchkonfiguriert. Ohne Erfolg.


    Nachtrag: Generell hängt sich das Programm auf wenn ich es versuche zu schliessen. Also auch wenn man es öffnet und sofort wieder versucht es zu schliessen.

    Es gab gestern ein Windows10-Update. Könnte es daran liegen?

    Autsch, das ist ein neues Fehlerbild. Hast du denn etwas im Output-Fenster stehen, wenn der Build hängenbleibt?


    Die Fehlermeldung mit dem Smartscreen ist auch etwas, an dem ich nicht viel machen kann. Da wird wohl irgendwo gelistet, ob eine Datei oft heruntergeladen oder als verdächtig gemeldet wird. Wenn die Version neu ist, kennt die niemand, und der normale Benutzer wird mit dieser Fehlermeldung "gewarnt".

    Könnte ich umgehen, in dem ich einen Haufen Geld in ein Applikationszertifikat einwerfe (einige hundert Euro). Ausser, dass dann irgendjemand Geld hat, der es nicht verdient, ändert sich aber an der Sicherheit nichts.

    Neue Version 6.3 liegt bereit, gerade rechtzeitig für Weihnachten. Mal schauen, was ich da wieder alles vehunzt habe :)


    Fix: Shortcut keys in charset and graphic editor only apply on focused editor

    Fix: Debugging start address properly used now

    Add: Ultimax cartridge support plus special debug behaviour for cart startup racing condition

    Add: !hex pseudo op to line up with ACME

    Add: Secondary key bindings

    Fix: Crash on find all with no open file or selected project

    Add: Mediatool support for graphic screen and binary files

    Fix: Bitmap export color clashes

    Fix: Bug in zone detection (stored zone was used instead of local one)

    Add: Binary editor gets upsize (8 to 16 bit)

    Add: Display and toggle button for string entry mode

    Fix: Hotkey for debug step out was not working

    Fix: Token scan for BASIC V2

    Fix: Predefines from build chains now really work

    Add: BASIC casing button shows current setting

    Add: Support for Laser BASIC

    Add: Display offset for binary display to help align memory views

    Add: Remove all watches

    Add: Solution Explorer: highlight one node per project, not one globally

    Add: Mark build as dirty if build events are modified

    Fix: Unwanted userappdata path usage

    Add: File Manager rename file via F2

    Fix: BASIC tokens with two byte opcodes

    Fix: Exception with invalid regular expression in Find/Replace


    Link wie gehabt: http://www.georg-rottensteiner.de/files/C64StudioRelease.zip

    Hallo Endurion


    Im Zusammenhang mit dem BASIC Weihnachten-Heft bin ich auf einen möglichen Bug im Zusammenhang mit der PETSCII-Zeichen-Generierung im C64 Studio gestossen. Und zwar sollten meines Erachtens PETSCII-Zeichen zwischen 96-127 mit den Werten 192-223 im BASIC-Code hinterlegt werden. Die Zeichen mit den Werten 96-127 sehen zwar identisch aus, man kann diese aber so nicht über eine C64-Tastatur eingeben.


    Das Problem ergibt sich aber eigentlich erst dann, wenn man versucht aus dem .PRG ein BASIC-Listing zu generieren. PetCat und andere Listing-Erzeuger-Tools übersetzen solche Zeichen dann z.B. als {$61} statt als {A}.


    Du kannst dies relativ einfach überprüfen, indem du folgende BASIC-Zeile im Vice eingibst und dann im Monitor schaust, welcher Wert abgelegt wurde (das A-Zeichen entspricht dem Pik-Symbol)


    10 print"A"

    Code
    1. (C:$e5d4) m 0801
    2. >C:0801 0a 08 0a 00 99 22 c1 22 ....."."

    Wie du beim Zeichen zwischen den Gänsefüsschen siehst, steht hier der Wert 193/$C1 und nicht, wie man erwarten würde, der Wert 97/$61. Das bedeutet, was du im Anhang vom "Commodore 64 Programmer's Reference Guide" siehst, ist "not what you get" ;).


    Auf dieses Detail bin ich auch erst gestossen, als ich für meine "PETSCII Codes in Listings"-Übersichts-Tabelle die CHR$-Zeichen ein wenig genauer unter die Lupe genommen habe: https://www.c64-wiki.com/wiki/PETSCII_Codes_in_Listings


    Auf dieser Wiki-Seite habe ich deshalb die doppelten "Nicht verwenden"-Zeichen rot markiert und verweise auf das Alternativ-Zeichen, welches man so auch eingeben kann.

    wizball6502 Wenn ich das richtig verstanden habe, beträfe das also auch mein Konsumwahn-Spiel, wenn es nicht schon mit dem C64-Studio gespeichert worden wäre. Als Abtipp-Listing, für das es ja ursprünglich vorgesehen war, hätte es also nicht funktioniert. Denn die Codes der jeweils dritten Korridor-Zeile dienen zur Kollisionserkennung (Geld=119, Leiche=120, Paket>120; s. Abfrage ab Zeile 50).


    Hätte es ein Abtipp-Listing werden sollen, dann hätte ich diese Codes also mit Hilfe von CHR$() printen müssen, richtig?

    Zitat von atomcode

    wizball6502 Wenn ich das richtig verstanden habe, beträfe das also auch mein Konsumwahn-Spiel, wenn es nicht schon mit dem C64-Studio gespeichert worden wäre. Als Abtipp-Listing, für das es ja ursprünglich vorgesehen war, hätte es also nicht funktioniert. Denn die Codes der jeweils dritten Korridor-Zeile dienen zur Kollisionserkennung (Geld=119, Leiche=120, Paket>120; s. Abfrage ab Zeile 50).


    Hätte es ein Abtipp-Listing werden sollen, dann hätte ich diese Codes also mit Hilfe von CHR$() printen müssen, richtig?

    Also auf den PEEK hat das keinen Einfluss. Beide CHR$()-Werte (da wo es doppelte Zeichen gibt) erzeugen dasselbe Zeichen auf dem Bildschirm.


    Das Problem bezieht sich mehr auf das Generieren des Listings mittels PetCat. Die folgende Zeile...



    … übersetzt PetCat mit dem Wert {$71} statt einem grossen Q, weil das C64 Studio dieses Zeichen als $71 statt $D1 gespeichert hat.



    Edit: Ich habe dein Programm Konsummwahn.prg mit dem PetCat übersetzt. Und ja, da gibt es diverse Übersetzungsprobleme:


    Zitat von wizball6502

    Also auf den PEEK hat das keinen Einfluss. Beide CHR$()-Werte (da wo es doppelte Zeichen gibt) erzeugen dasselbe Zeichen auf dem Bildschirm.

    :emojiSmiley-106: Alles klar.


    Zitat von wizball6502

    Ich habe dein Programm Konsummwahn.prg mit dem PetCat übersetzt. Und ja, da gibt es diverse Übersetzungsprobleme:

    Ja, das wäre fatal. Sogar das hin geprintete Maschinenprogramm in Zeile 81 würde dadurch zerstört (fürs Abtippen, meine ich).


    Wäre noch interessant zu wissen, wie es beim CBM-Prg-Studio ist. Ist zwar hier offtopic, aber überschneidet sich. Kann ich ja auch mal selbst ausprobieren, anstatt zu fragen. ;)

    Zitat von atomcode

    Wäre noch interessant zu wissen, wie es beim CBM-Prg-Studio ist. Ist zwar hier offtopic, aber überschneidet sich. Kann ich ja auch mal selbst ausprobieren, anstatt zu fragen. ;)

    Beim CBM prg Studio werden im erzeugten PRG-File die korrekten Byte-Werte erzeugt (bei einem grossen Q somit der Wert $D1). Netterweise erkennt das CBM prg Studio beim Import eines PRG BASIC Files auch "falsche" Werte und würde im Beispiel vom Wert $71 im Listing dann ebenfalls ein grosses Q daraus machen. Beim Generieren des PRG-Files wird dann aus dem "Q" wieder ein $D1. Als schnellen Workaround könnte man also ein PRG File mit Hilfe von CBM prg Studio sogar fixen. Aber das sollte kein Grund sein, auf das CBM prg Studio zu wechseln. Von Arthur Jordison habe ich schon länger nichts mehr vernommen, was leider kein gutes Zeichen für die Weiterentwicklung vom CBM prg Studio ist. Da bin ich doch sehr beruhigt, dass wir mit dem C64 Studio bzw. mit Endurion eine top Alternative haben. :D:thumbup:

    Hab den Bug auch schon gefixt, ist ja echt doof, dass ich das so lange übersehen habe :( Interessant, dass es aber trotzdem funktioniert, nur die Check-Summen halt nicht passen ;)


    Hab deshalb vorsichthalber direkt beide Download-Links mit der korrigierten Version ersetzt. Danke für's Melden!

    Zitat von Endurion

    Hi aitsch,


    Hmm, bei mir klappt es, sowohl mit Breakpoint als auch mit Run-To-Cursor.


    Hast du im Projekt eine Einsprung-Debug-Adresse angegeben? (Debug Start Address) - Mit einer ist es nicht so ganz klar, versuch es mal ohne einem Wert da drin.

    Komisch, bei mir nicht.


    In einem älterem Release greift der Breakpoint in der 6.3. nicht.


    Ich werde es nochmal auf einem anderen Rechner probieren...

    Nur mal so am Rande: gibt es einen speziellen Grund dafür, daß z.B. der Steuercode "unten" (0x11) als 3-Byte-Sequenz 0xee 0xba 0x91 gespeichert wird? Das führt dazu, daß MOSpeed ein "unten" (0x11) als "oben" (0x91) interpretiert und diverse andere Steuerzeichen werden so auch falsch interpretiert. Leider hat C64Studio auch eine andere Macro-Darstellung als MOSPeed (z.B. "17DOWN" statt "down*17"). Glücklicherweise konnte ich EgonOlsen71 dazu bewegen, die Macro-Darstellung des C64Studios auch zu unterstützen, aber bis gerade eben konnte man schon alleine dadurch keine Programme mit Steuercodes aus C64Studio mit MOSpeed übersetzen.

    Fürs Protokoll: man muß im C64Studio im Macro-Modus speichern und für MOSpeed die Option "/tolower=true" verwenden.

    Code
    1. [...]\MoSpeed\mospeed.cmd "$(Filename)" /tolower=true

    Nebenbei bemerkt wäre es toll, wenn MOSpeed direkter unterstützt würde z.B. zumindest ein Pfad unter Tools usw.

    Es wäre auch wünschenswert, wenn es ein Maco "$(FilenameWithoutPath)" oder so gäbe, damit man beim Einbinden des kompilierten Files in ein Disk-Image keine festen Namen verwenden müßte.

    Und wenn wir schon dabei sind: warum gibt es im Basic-Editor kein Kontextmenü? Zumindest sowas wie Copy/Paste wäre schon ganz nett, wenn man zu faul ist, die Tastatur zu benutzen.

    Uiui, gleich eine ganze Packung Bugs/Features.


    Der Grund für das Abspeichern mit 0xee91 ist der PETSCII-True-Type-Font, der für das reverse Q das als Wert hat. Das 0xba kann ich mir gerade nicht erklären.


    Unterschiedliche Macro-Darstellung ist blöd, ich hatte aber auch irgendetwas als Vorlage dafür. Evtl. baue ich das als Option ein.


    Ich schreibe meine TODO-Liste und packe folgende Punkte dazu:

    * Abspeichern von .BAS-Dateien mit "richtigem" PETSCII-Wert (falls das nicht mit irgend etwas anderem kollidiert)

    * alternative BASIC-Macro-Darstellung (xxx * Anzahl)

    * Macro Filename ohne Pfad

    * Kontext-Menü im BASIC-Editor



    Im Code nachgesehen, es gibt schon zwei Macros für reine Dateinamen, die werden nur im Hilfe-Dialog nicht aufgelistet:

    BuildTargetFile und BuildTargetFileWithoutExtension