Posts by Endurion

Ah, ich wär's gewesen, ist aber i.O. so.

Armalyte, aber so bunt ist das gar nicht?

Pfff, dann schon lieber Mega65. Der hat nämlich noch eine Zukunft

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)

Danke! Dann ist das erste wohl ein Hinweis, dass mein Auto-Update von durch Änderungen verschobene Zeileninfos irgendwo eine Lücke hat, gerade wenn es um Undo/Redo geht. Werde ich nochmal inspizieren.

Ah, bei den Dateien waren das je einzeln für sich stehende Code-Dateien?

Hmmm, das ist ja wie du sagst, kein echtes BASIC. Da wäre bestenfalls eine Code-Vervollständigung drin?

Alles andere macht dann ja der XC=BASIC-Compiler. Letzteres ist über einen Custom-Build-Step möglich.

Ah, danke! Punkt #1 dürfte ich korrigiert haben. Du hast irgendwie eine Konstellation zusammen bekommen, wo C64Studio meint, dass dein Code mehr Zeilen besitzt als tatsächlich vorliegen. Hast du viel Macros und/oder !for-Schleifen benutzt?

Das mit der duplizierten Datei dürfte den eigentlich aus dem Tritt bringen. Nach meinem Verständnis hast du eine Datei kopiert, und die zusätzlich zur originalen Datei in die Solution reingehängt. Davon alleine passiert ja noch nichts, die Datei muss ja auch im Code eingebunden werden.

Hast du das !source-Statement mit dem alten Dateinamen geändert?

Waren die beiden Dateien in unterschiedlichen Verzeichnissen?

Als Tip: Du kannst auch im Solution Explorer eine Datei auswählen, Copy/Paste, und du hast eine Kopie der Datei.

Ja, in dem Fall ist es klar.

Aber der Assembler geht strikt von oben nach unten. Wenn da jetzt Opcodes vorkommen, die 2 oder 3 Bytes lang sind, je nach dem eingesetzten Label, dann verändert sich die Länge des Assemblats. Und dann ist es nicht mehr eindeutig, welchen Wert Labels danach bekommen.

Klar, könnte man auch machen, dass der Assembler dann Varianten durchprobiert. Das ist aber echt nicht ohne. Dazu noch ein Branch, der exakt an der Grenze ist, und es wird haarig

Zuweisungen zu * müssen immer im ersten Lauf auflösbar sein. Sonst würde man sich in eine Kette von immer wiederholenden Neu-Assemblierungen verstricken.

Das muss auch in 6.8 funktioniert haben, das wäre ein absolutes No Go, wenn das fehlschlagen würde.

TD1334 : Für den Suchdialog gibt es zwei Key-Bindings, da habe ich mich an Visual Studio orientiert. Das normale "Find" sucht per Default im aktuellen Dokument, das "Find in Project" sucht per Default in der ganzen Solution. Das ist in meiner Vorlage mit Ctrl-F und Ctrl-Shift-F belegt.

There's a second register that tells the VIC4 how many bytes are in a line.

;number of bytes per text screen line lo

.CHARSTEP_LO = $d058

;number of bytes per text screen line hi

.CHARSTEP_HI = $d059

So POKE $d058,80 should do the trick.

BTW, you can use $ directly for hex numbers, as in POKE $d031,224

This worked for me (entered manually):

POKE $d031,0

POKE $d058,40

Einer hat kein Gehäuse, das hab ich bekommen!

Ah ja, gute Punkte. Stimmt, die mehr-als-zwei-Buchstaben-Varianten hatte ich im Hinterkopf, aber ist irgendwo dann runtergefallen

Aber danke schon mal für's Testen und die Vorschlagsliste.

Die einzelnen Orte der Variable habe ich tatsächlich im Hintergrund, ich überlege, wie ich das sinnvoll in der Ansicht unterbringe. Ich denke, ich mache die Variablen aufklappbar, wenn es mehr als eine Stelle gibt; darunter dann die einzelnen Vorkommen.

Hab da mal was gebastelt für die Variablen-Anzeige. Ein erster Wurf liegt auf https://www.georg-rottensteine…misc/C64StudioRelease.zip.

Ist das in etwa, was dir vorschwebt?

atomcode: Ich gucke mir das gerade an im BASIC-Parser. Scheint einfacher zu gehen, als gedacht.

Aber: Variablen-Definitionen gibt es ja nicht, d.h. auf welche Zeile soll die Outline verweisen? Das erste Vorkommen?

Golden Axe?

Das ist echt seltsam. Da muss es irgendwo intern gerappelt haben. Spätestens ein neuer Build sollte das beheben.

Gibt es irgendwelche Fehlermeldungen im Output-Fenster?

Ja, das kenne ich. Leider hat Windows Forms die dumme Eigenschaft, die User-Data-Settings in einem Unterordner mit der Versionsnummer zu verwenden. D.h. jedesmal, wenn die Version hochgeht, sind die Settings futsch. Deshalb hat das Ding in der Versions-Info 1.0.0.0 drin stehen, und die 6.9 nur nach außen hin.

Der Wunsch kam schon mehrfach, habe ich aber immer nach hinten geschoben (sorry).

Du meinst wie in der Outline mit den Labels?

Die WIP-Versionen haben alle die 6.9 als Version, weil ich ein fauler Sack bin.

Hast du vom webmisc-Link geladen, oder das offizielle Release? Beim webmisc ist öfter mal was kaputt, gerade in diesem Zyklus, weil ich die Charset- und Sprite-Editoren ziemlich umgebaut habe.

Jetzt geht's aber los hier!

Zufälligerweise gibt es sowas. Mit einer Raute zu Beginn der Zeile. Kann aber dummerweise sein, dass da gerade im aktuellen Release ein Bug drin ist. Die Korrektur ist auf dem webmisc-Link schon drin, aber da sind auch eine ganze Packung andere Erweiterungen mit dabei.

So sieht das aus:

10V=53248

20POKEV+21,1

#Titelbild

50PRINT"{CLR}";