peiselulli hat recht, schau dir die Bit-Belegung im Wiki an: https://www.c64-wiki.de/wiki/Zeropage
Beiträge von TD1334
-
-
load "speedscript 3.2",8
poke 3357,15
save "name",8
run
conch0 hat schon recht mit der Stelle. $0d1d regelt nicht nur $d020 sondern wird auch nach $d021 geschrieben.
-
Man muss niemanden ganz GENAU kennen, man bewertet das, was der andere einen wissen lassen möchte. Ich kann WebFritzi da ganz gut verstehen. Aber egal .. wollte auch mal wieder etwas schreiben
Dann tu mir doch den Gefallen und lies, was ich geschrieben habe. Das ist keine Schwarzmalerei oder Pessimismus, sondern bestenfalls ein Aufruf, sich nicht nur von dem "Habenwollen"-Gefühl treiben zu lassen. Es ist ja nun leider Fakt, dass Peri Frantic, wenn man es genau nimmt, nicht einmal ein Produkt HAT.
Dein Grundtenor ist nur Negativ, das ist das was mir bei dir in Erinnerung geblieben ist und, das wiederholt sich hier immer wieder. Du hast uns mitgeteilt, das es Risiken gibt, super, das ist ok. Aber dieses dauernde wiederholen in zig verschiedenen Nuancen. Das ist das Bild das mir in Erinnerung bleibt in diesem Thread.
Dabei spielt es dann keine Rolle das deine Kernaussage mit dem Risiko durchaus berechtigt ist.
-
Ich kann da mit dir mitfühlen .. ich habe auch diverse Anläufe gehabt bis ich mit VS Code + VS64 etwas zustande gebracht hatte.
-
Wenn alle so wären wie du (und alle anderen Schwarzmaler), würde niemand was kaufen, und das Projekt wäre gescheitert.
Aber du nennst hier das richtige Wort: Vertrauen. Das Gegenteil davon ist Misstrauen, und genau das beherrscht offenbar die Schwarzmaler-Fraktion. Mal so ein Tipp: Ich gehe viel leichter durch's Leben mit etwas Vertrauen als an jeder Ecke das Böse zu sehen.
Oh, scheisse ... da kennt mich aber jemand GANZ genau - und gibt mir zudem glücklicherweise DEN vielleicht entscheidenden Tipp, der mein Leben (was ich bis jetzt gerade eigentlich gar nicht als so schlimm empfunden hatte) in einen stetigen Quell der Freude verwandelt.
Man muss niemanden ganz GENAU kennen, man bewertet das, was der andere einen wissen lassen möchte. Ich kann WebFritzi da ganz gut verstehen. Aber egal .. wollte auch mal wieder etwas schreiben
-
-
Alles anzeigenIch habe festgestellt dass ich die VSCode Extension schon installiert habe.
Allerdings kann ich nicht auf die neueste Version updaten.
Habe die Sourcen von GitHub lokal geklont. Muss ich das selbst builden? Und wo muss man dann die Extension reinkopieren und wie?
Ausserdem habe ich ein ähnliches Problem mit ACME, habe v0.97 aus 2020 gefunden und die Sourcen aus SourceForge kopiert, aber unter Windows geht das Builden ja nicht so einfach, muss zuerst mich schlau machen.
Gibt es denn keine neuere Version seit 2020?
Du kannst die neueste Version hier herunterladen:
Diese Datei kannst du dann manuell unter VSCode installieren.
Drücke dazu CTRL+SHIFT+P oder F1, dann sollte oben eine Eingabe erscheinen.
Dort gibst du nun Extensions: Install from VSIX... ein, auswählen und dann startet der Dateidialog. "vs64-2.6.0.vsix" auswählen und installieren lassen. Eventuell ist ein Restart nötig. Dann hast du aber die neueste Version. Hat zu mindestens bei mir so geklappt.
-
-
-
PS: Warum komme ich mir eigentlich wie ein Straßenmusiker vor, der seinen Hut auf den Bürgersteig stellt und hofft, dass wenigstens eine Münze klimpert? 🎩🎶
Du musst erst leiden um dann bis ganz an die Spitze zu kommen
Willst du mehr Aufmerksamkeit, mache einen eigenen Thread dafür auf, dann schauen sich das auch wieder Leute an die sich sonst nicht für COMAL + SID interessieren. Sonst taucht nur der Thread hier in den Top20 auf und wenn den keiner abonniert hatte ist die Chance doch klein das er reinschaut, weil den Thread gibt es ja schon eine Weile.
Aber Hut ab vor dem umsetzen der Lieder ... das ist etwas an das ich mich nicht wagen würde ... !
-
Verflixt. Schon die neueste...
Yep. Bin gerade dran einen Sourcecode von mir aus dem C64Studio in das acme Format zu bringen aber das ist eine sysiphus Arbeit ...
VS64 bietet da nichts dafür an oder?
Kannst auch ACME auf der Kommandozeile mal laufen lassen. Dann siehst du gleich, ob die Fehler von ACME kommen oder von IDE-spezifika
hatte ich grad vor ein paar monaten gehabt die situation.Ja, den Gedanken hatte ich auch schon. Muss aber warten .. bin noch auf der Arbeit und nachher habe ich eventuell noch etwas Sport (Fussball) vor ... mal sehen .. aber danke für den Tipp.
-
Verflixt. Schon die neueste...
Yep. Bin gerade dran einen Sourcecode von mir aus dem C64Studio in das acme Format zu bringen aber das ist eine sysiphus Arbeit ...
VS64 bietet da nichts dafür an oder?
-
Welche Version von vs64 läuft bei dir?
-
Meine Art, wie ich den Debugger und VICE nutze, und vs64 generell: Code ändern, speichern (vs64 kompiliert/assembliert automatisch ein neues .prg) - dann einfach die Debug-Session "restarten" (über Toolbar oder Ctrl+Shift+F5). Da bleibt VICE offen und vs64 mit dem VICE monitor verbunden, führt einen Reset aus und lädt das neue .prg in den Speicher (RAM-inject), alle Breakpoints werden aus den Debug-Infos aktualisiert (und mit VICE synchronisiert). Das ist eigentlich die gesamte Idee hinter vs64, dieser Zyklus sollte extrem schnell und einfach sein....
Das habe ich eben mal ausprobiert und es gefällt mir sehr gut. So entfällt das schliessen und neu starten von VICE. Einfach Code ändern, CTRL+SHIFT+F5 und Vice wir neu initialisiert.
Mir ist gerade eben aufgefallen, das irgendwas mit den Breakpoints nicht richtig funktioniert.
Wenn ich während dem Debuggen BP entferne oder neu setze werden diese ignoriert.
Ich habe dann Vice (3.8 GTK) geschlossen, alle BP gelöscht und dann mit Ctrl+F5 neu gestartet, Vice geht auf und er stoppen an dem alten BP?!?!
In Zeile 32 war ganz am Anfang mal ein BP. Aber wieso stoppt Vice/VS64 wenn ich a) mit CTRL+F5 starte und b) wenn gar kein BP mehr gesetzt ist?`
-
Heute habe ich eine Besonderheit für Euch. Ein neues COMAL-Musikstück. Aber ich sage nicht, was es ist.
Wenn ihr es errated, dann verrate ich euch, welches die beste (BASIC-ähnliche) Programmiersprache auf dem C64 ist.
-
Endurion hat es ja auch richtig gemacht: Da stehen die Werte sogar davor, und zwar die, die sich auf den jeweiligen Befehl in derselben Zeile beziehen, also bei einem JMP 3 TZ. Überall und jedes Mal am Ende der nächsten Zeile zu schauen, was der Befehl am Anfang der vorherigen Zeile bewirkt hat, da wird man ja bekloppt, und es fördert nur die Chance, sich damit zu verhauen.
Ich verstehe deine Sichtweise, aber auch im C64Studio ist es beim debuggen so, das ich beim Step auf dem LDA im Reiter Registers nur den aktuellen Wert sehe. Erst wenn ich den LDA mit F11 ausführen lasse ändert sich der Inhalt. Die Taktzyklen stehen ja nur in der Codeübersicht, aber bei einem Bxx steht da bei mir immer 2+2. Ja was denn nun, hat der nun 2, 3 oder doch 4 Takte benötigt.
Wenn ich dich oben richtig verstanden habe, ist dein Grafikauschnitt eine History-Liste. In so einer Liste kann ich deinem Ansatz komplett nachvollziehen, da hätte ich das auch dann gerne wie du. Beim live debuggen ist es mir andersrum dann lieber
-
Was an der Darstellung der CPU-Register in der History absolut nervt, ist, dass hinter jedem Befehl die Werte von vor dem Befehl angezeigt werden. Wenn also z.B. der Akku eine 5 enthält und dann da steht LDA #$07, dann wird dahinter als Akkuinhalt noch die 5 angezeigt, obwohl er nach dem Befehl doch eine 7 enthält.
Da muss man immer umdenken und aufpassen, wenn z.B. nach einer Operation der Akkuinhalt nicht sofort offensichtlich ist.Was für mich aber logisch klingt, denn die Anzeige gibt dir Aufschluss darüber was zu einem bestimmten Zeitpunkt für Werte vorlagen.
Wenn ich mich mit einem modernen Debugger durch steppe habe ich an dem LDA Step ja auch noch den alten Wert im Register und erst wenn dieser Step vollzogen wurde steht der neue Wert im Register.
-
Vielen Dank für den Codereview, is mir gar nicht aufgefallen, erklärt aber auch warum der C64 Debugger die Krätsche gemacht hat^^
Aber 3*$FA + X=$FA ergibt doch 4*$FA was genau 1000 Zeichen sind, wo ist mein Denkfehler? Es müssten 999 Zeichen sein, weil ein Zeichen schon bei $400 ist, richtig?
Deine Schleife durchläuft ja immer die Zustände 01-fa was 250 Zeichen sind. Das mal 4 sind 1000, soweit korrekt.
Da du das alles von $0400 startest fängst du praktisch bei $0401 und hörst bei 4*$fa = $3e8 auf was dann $07e8 wäre und damit das erste Byte nach dem SCREEN. Deshalb machst du ja noch den sta $0400 am Ende.
Wie Mike schon geschrieben hat funktioniert es so besser
ZitatAlles anzeigenlda #$30
ldx #$fa
loop:
sta $03ff + 0*$fa,x ; [x=01-fa]
sta $03ff + 1*$fa,x ; [x=01-fa]
sta $03ff + 2*$fa,x ; [x=01-fa]
sta $03ff + 3*$fa,x ; [x=01-fa]
dex
bne loop
Du musst das aus der Sicht der Adresse + X-Register sehen
-
Ich bin mir nicht sicher, aber Stephan Scheuer hat mMn schon Zeit investiert in einen PetSpeed-Decompiler.
-
Hau doch mal ganz an den Anfang ein
Das wartet auf einen Tastendruck.
Vielleicht ist deine Maschine zu schnell und wie Endurion schon im anderen Thread schrieb wird erst ein Breakpoint Zugriff viel zu spät ermöglicht.
Mit dem warten auf dem Tastendruck vor dem Breakpoint könntest du wenigstens dieses Verhalten testen.
Ansonsten finde ich das debuggen im C64Studio am bequemsten, da man alles an Informationen in Echtzeit zur Verfügung hat.
