Danke wie immer fix.
Hallo Besucher, der Thread wurde 479k mal aufgerufen und enthält 4056 Antworten
letzter Beitrag von WebFritzi am
C64 Studio - Entwicklungsumgebung
- Endurion
- Erledigt
-
-
Ich habe extra nochmal eine neue Solution angelegt und kann es sofort reproduzieren.
-
Cool, danke
Das ist genau die NullReferenceException, die ich vorhin bereinigt habe, dann bin ich beruhigt!
-
Hallo zusammen,
wenn ich einen Zeichensatz (charset.projectfile) in den Text Screen Editor importieren möchte, quittiert das C64 Studio mit einer Fehlermeldung.
Ein paar Bilder zum besseren Verständnis findet ihr weiter unten. Kann das Problem jemand bestätigen? (Hab gestern auf das Fall Creators Update aktualisiert - nicht das es daher rührt.)
-
KiWi hat gerade angefragt, ob ich mein C64-Diag-Projekt nicht in 64Studio weiterführen kann.
Dazu eine Frage zu C64Studio. Ich verwende mit meinem Compiler in fast allen meinen Projekten lokale Labels. Das sind Labels, mit dem Präfix "_", die innerhalb von PROC/ENDPROC Gültigkeit haben.
ACME kennt dafür routine_start/routine_end. Die lokalen Labels beginnen hier mit einem Punkt.Unterstützt der C64Studio Assembler so einen Mechanismus für lokale Labels?
-
lokale Labels. Das sind Labels, mit dem Präfix "_", die innerhalb von PROC/ENDPROC Gültigkeit haben.
ACME kennt dafür routine_start/routine_end.Warum weiß ich dann nix davon? Menno, nie erzählt mir hier einer was.
...in ACME muss der Gültigkeitsbereich der lokalen Symbole immer manuell per "!zone" abgesteckt werden. Die einzige Ausnahme sind Makros, dort bekommt jeder Aufruf automatisch eine eigene Zone.
Schon seit geraumer Zeit steht die Einführung von "Cheap Locals" auf der TODO-Liste, deren Bereich würde automatisch durch die umliegenden globalen Labels abgesteckt. Die Implementation ginge sogar recht fix, das ist bisher immer nur an einer Sache gescheitert: Da ich selbst statt lokaler Labels inzwischen fast nur noch anonyme Labels benutze, ist der Leidensdruck nicht sonderlich hoch...
-
Ach, sieh an
Sowas schoss mir auch immer wieder mal durch den Kopf. Man müsste aber auf jeden Fall ein neues Startzeichen dafür aussuchen, damit existierender Code immer noch funktioniert.
-
DMHas: Ah, danke für den Hinweis. Kann ich nachstellen. Ich übersehe immer wieder, dass nicht jeder mit einem Projekt arbeitet. Wird gefixt!
Danke!
-
Die lokalen Labels gelten immer im Anschluss an ein !zone-Element.
Wie sieht das aus? Kannst du mal ein kurzes Beispiel posten?
EDIT: Ich hab's gerade gefunden. Das scheint mir aber von der Verwendung her eher eine Art Namespace-Ersatz zu sein.
Bei mir sieht das so aus:Alles anzeigenDELAY ist der Einsprungspunkt. Alles andere ist hier lokal. Da springt mir keiner mal eben mitten rein und wenn, dann sieht man das am globalen Label.
Ich verstehe gar nicht, wie ihr größere Projekte nur mit globalen Labels schreiben könnt.
Welchen Assembler hast du denn da verwendet? C64Studio unterstützt teilweise auch andere Assembler-Syntaxen (ACME zu einem sehr großen Teil, DASM und PDS zu kleineren Teilen und CBMPRGSTUDIO sowie C64ASM zu kleinen). Ggf. kann ich das auch einbauen.
Das ist ein eigener. Den hatte ich in den 80ern geschrieben, als ich noch beruflich 6502 programmiert habe und unter DOS keinen brauchbaren Crosscompiler gefunden habe.
Ich habe den dann vor ein Jahr von C nach C# portiert, damit ich meine alten Sachen wieder assemblieren kann. Außerdem hatte ich diverse Quellen (z.B. das Betriebssystem der PET Floppys, für die ich überhaupt keinen Assembler gefunden habe. Ich habe dann einfach meinen Assembler an die Syntax angepasst.Mein Problem ist, dass ich nicht so einfach auf 64Studio wechseln kann. Ich würde daher eher meinen Assembler an die ACME-Syntax anpassen, damit die Quellen kompatibel sind.
Schon seit geraumer Zeit steht die Einführung von "Cheap Locals" auf der TODO-Liste, deren Bereich würde automatisch durch die umliegenden globalen Labels abgesteckt. Die Implementation ginge sogar recht fix, das ist bisher immer nur an einer Sache gescheitert: Da ich selbst statt lokaler Labels inzwischen fast nur noch anonyme Labels benutze, ist der Leidensdruck nicht sonderlich hoch...
Ich kann mir irgendwie nicht vorstellen, wie das in der Praxis aussieht.
Anonyme Labels sind für mich keine Lösung. Ich will den Code schon noch lesen können.
-
Schon seit geraumer Zeit steht die Einführung von "Cheap Locals" auf der TODO-Liste, deren Bereich würde automatisch durch die umliegenden globalen Labels abgesteckt.
Sowas schoss mir auch immer wieder mal durch den Kopf. Man müsste aber auf jeden Fall ein neues Startzeichen dafür aussuchen, damit existierender Code immer noch funktioniert.
Üblich ist wohl '@'.
Ich verstehe gar nicht, wie ihr größere Projekte nur mit globalen Labels schreiben könnt.
Das hat doch gar keiner behauptet?
Ich kann mir irgendwie nicht vorstellen, wie das in der Praxis aussieht.
Ungefähr so:
Alles anzeigenCode
Anonyme Labels sind für mich keine Lösung. Ich will den Code schon noch lesen können.
Das kommt immer auf den Einzelfall an. Oft genug sind anonyme Labels lesbarer als "loop1/loop2/skip3" etc.
-
Für die !zone-Syntax würde das so aussehen:
Das sieht ok aus. Mit der Syntax kann ich leben.
Gibt es irgendein größeres Assembler-Projekt, das mit dem C64Studio erstellt wurde? Damit ich mal schauen kann, wie das alles in der Praxis aussieht und verwendet wird und ich sehen kann, welche Kommandos ich zuerst implementieren muss.
Ich hänge hier auch mal den aktuellen Quelltext von meinem C64-Diag-Projekt an. Dann können wir vergleichen.
-
Das Pre-Guns 'n' Ghosts wäre ein größeres Beispiel, wo der Code auch frei verfügbar ist.
Ok, das sieht von den Pseudo-Opcodes her überschaubar aus. Die geschweiften Klammern widersprechen etwas meiner Logik, aber das kriegt man hin. Die Syntax meines Assemblers ist halt old-school zeilenorientiert.
Also ich schaue mal, dass ich meinem Assembler die wichtigsten Dinge beibringe und dann baue ich C64-Diag so um, dass es mit C64Studio assembliert.Kann man den C64Studio-Assembler per Komandozeile starten oder muss man dazu ins C64Studio?Kennt der C64Studio-Assembler ein System-Label, über das man Abfragen kann, dass mit C64Studio assembliert wird?
Dann kann ich die Pseudo-Opcodes meines Assemblers per IF-Statement klammern. -
Es gibt ein Teilprojekt mit Kommandozeilen-Assembler, den ich (*nachkram*) offenbar nie ins Release-Archiv gepackt habe. Das wäre im Projekt der C64Ass.
Ich mag die geschweiften Klammern auch nicht besonders, aber Mac Bacon steht drauf
Ein System-Label habe ich bisher nicht drin. Gute Idee aber. Setze ich gleich rein. Ich habe das mal in Ermangelung an Vorgaben ASSEMBLER_C64STUDIO genannt und auf Wert 1 gesetzt.
-
Ein System-Label habe ich bisher nicht drin. Gute Idee aber. Setze ich gleich rein. Ich habe das mal in Ermangelung an Vorgaben ASSEMBLER_C64STUDIO genannt und auf Wert 1 gesetzt.
Das ist super. Ich werde dann etwas entsprechendes bei mir einbauen. Mein Assembler hat noch keinen Namen. Der heisst einfach nur Asm65.exe.
Da muss ich mir noch was Schlaues einfallen lassen.Ist es völlig frei, wo die geschweiften Klammern stehen können? Also
!ifdef TEST {
}oder
!ifdef TEST
{
}Spätestens hier wäre mein Parser aufgeschmissen:
!ifdef TEST { ... }
Das kann der nicht.
-
Die Öffne-Klammern müssen in der gleichen Zeile wie die zugehörige Anweisung sein. Also nur das erstere. Stört mich aber auch schon lange
Das Beispiel ganz zu Ende mit allem in einer Zeile kann C64Studio auch nicht. Ist ja pervers
Bei ein paar Sachen wie Makros habe ich das wahlweise mit Klammern oder einem Ende-Makro.
-
Die Öffne-Klammern müssen in der gleichen Zeile wie die zugehörige Anweisung sein. Also nur das erstere. Stört mich aber auch schon lange
Ok, das ist dann einfacher.
So gerne ich in C und C# die öffnende Klammer auf die nächste Zeile setze, meinen Parser würde das deutlich verkomplizieren, weil der - wie gesagt - zeilenweise arbeitet.
