Danke. Sowas ist Suport der Extraklasse.
Hallo Besucher, der Thread wurde 480k mal aufgerufen und enthält 4057 Antworten
letzter Beitrag von smithloo am
C64 Studio - Entwicklungsumgebung
- Endurion
- Erledigt
-
-
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...... -
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.
-
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?
-
Das Semikolon markiert alles, was danach kommt, als Kommentar. Dass man das dann tatsächlich noch einklappen kann, ist ein, äh.. *Ausreden-Liste-Durchblätter*, ah! Ein Feature!
Nee, ist natürlich ein Bug. Regex macht es möglich
-
-
ich möchte sehen wie sich die .o-Dateigrößen seit dem letzten release geändert haben
-
Es gibt bei C64Studio keine .o-Dateien?
Meinst du nach dem Assemblieren zusätzlich zur erstellten Datei eine Ausgabe um wie viele Bytes sich die Größe der erstellten Datei geändert hat?
-
Wunsch: Fehler "Relative jump too far" könnte angeben, wie viel man zu weit springen will. Dann kann man sich überlegen, wo sich umsortieren lohnt.
-
Ist gebongt!
-
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.
-
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 http://www.georg-rottensteiner…misc/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.
-
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.
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...
Edit: Bisher wurden Symbole in BASIC-Dateien nicht wirklich unterstützt. Ich habe das mal eingebaut und eine Version unter http://www.georg-rottensteiner…misc/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.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.
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
-
Mal eine Frage wegen der Autovervollständigung: ist die !zone abhängig? Habe das Problem, dass er nicht im gesamten Quelltext diese Funktion anbietet.
-
!text "hallo;test"
Markiert er dann auch alles nach dem Semikolon als Remark?
-
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 AufwandSquidward: Oh ja, RegEx macht's möglich. Ich schau mal, ob ich da was dran machen kann.
-
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".
-
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:
-
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.
-
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)