Simons’ Basic/TSB: Farben, Zeichensätze, Sprites & Co.

Es gibt 4.424 Antworten in diesem Thema, welches 407.113 mal aufgerufen wurde. Der letzte Beitrag (19. November 2025 um 16:35) ist von GoDot.

  • Wenn ein Programm dermaßen lang ist, dass jedes Byte weniger Code dem Ganzen zugute kommt. Das ist z.B. in North Sea Oil der Fall. Nach dem Start hab ich noch rund 3000 Bytes frei. Ziemlich wenig. Nach D! sind es über 4000. Schon besser... ^^

    D! ist doch ziemlich lasch. Der einzige Befehl, der richtig was bringt, ist NEW. :D

  • Der einzige Befehl, der richtig was bringt, ist NEW. :D

    Dann macht aber das Spielen keinen richtigen Spaß mehr... :|

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • GoDot du hast mal ein Beispiel gezeigt, wo der gesamte Variablenbereich in die REU kopiert wurde, dann eine Prozedur mit ihren eigenen Variablen gearbeitet hat, und am Ende der Prozedur der alte Variableninhalt wieder hergestellt wurde.

    Aber ich finde das nicht.

    Könntest du das zu den TSB-Tipps auf der Webseite dazugeben?

    Danke!

    EDIT: habs gefunden, hatte vor zwei wochen schon danach gefragt :biggrin:

    wäre trotzdem einen eintrag bei den tipps wert :smile:

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • wäre trotzdem einen eintrag bei den tipps wert

    Muss aber überlegen, ob das wirklich die Lösung darstellt, denn du kannst (im Sinne einer Funktion) keine Rückgabewerte produzieren. Das mindert meiner Meinung nach den Wert dieser Aktion. Ich wollte da tatsächlich nur ausprobieren, ob einem laufenden Programm einfach so seine Variablen weggenommen werden können. Gut, ja, das geht :wink:

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Ich find das toll wenn andere Programmteile geladen werden sollen. Im Ganzen, nicht mit Merge.

    Blitz macht das auch so dass der Variablenbereich erhalten bleibt. Einfacher kann man das nicht nachahmen :smile:

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Ich find das toll wenn andere Programmteile geladen werden sollen. Im Ganzen, nicht mit Merge.

    Blitz macht das auch so dass der Variablenbereich erhalten bleibt. Einfacher kann man das nicht nachahmen :smile:

    So, ich experimentiere hier nun mit LOAD und dem Speichern und Wiederherstellen der Variablenwerte.

    Das hin- und herspringen zwischen den Programmen funktioniert. Auch die Variablenwerte stimmen.

    Natürlich muss jedes geLOADete Programm so funktionieren, dass es nach LOAD in den richtigen Zustand zurückkehrt (zB der richtige Spieler muss im richtigen Submenü sein, etc )

    Nun ist es so, dass ich nach der Rückkehr ins ursprüngliche Programm relativ rasch einen overflow error kriege. Und zwar genau dann, wenn eine Proc aufgerufen werden soll.

    Meine Annahme ist, dass der Call-Stack der Prozeduren bei LOAD nicht zurückgesetzt wird. Indem beim "Neustart" wieder die proc mit der gameloop, etc. aufgerufen werden, kommt man einfach zu tief.

    Wie kann man denn diesen Stack löschen?


    Anmerkung:

    Vielleicht muss ich aber ohnehin auf MERGE ausweichen, weil ja doch viele Utility-Methoden (zB dem Aufbau von Menüs, etc) wahrscheinlich für alle geladenen Programme benötigt werden...

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Meine Annahme ist, dass der Call-Stack der Prozeduren bei LOAD nicht zurückgesetzt wird. Indem beim "Neustart" wieder die proc mit der gameloop, etc. aufgerufen werden, kommt man einfach zu tief.

    Wie kann man denn diesen Stack löschen?

    Das funktioniert genauso wie Bitte melde dich an, um diesen Link zu sehen. beschrieben. Ich hatte damals überlegt, ob ich den EXEC-Stack hier auch mit aufnehmen soll, hatte dann aber gedacht, dass ich besser nicht zu viel Info dort unterbringe. Es soll ja nicht abschrecken. Der Stackpointer für EXEC steht an Adresse $C62C und muss für jede Ebene weniger um 2 erniedrigt werden, ganz so wie auf der Trickseite für REPEAT beschrieben.

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Der Stackpointer für EXEC steht an Adresse $C62C und muss für jede Ebene weniger um 2 erniedrigt werden, ganz so wie auf der Trickseite für REPEAT beschrieben.

    Danke

    Dh dort kann ich auch auslesen, wo man gerade steht.
    Und beim LOAD manuell zurücksetzen.
    Werd ich ausprobieren

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • So: ihr Besserwisser. Alle seid ihr Besserwisser. Alle. :biggrin:

    Hab jetzt mit dem Laden einer anderen Programmdatei experimentiert, während die Variablen bestehen bleiben.

    Wenn man direkt im Programmcode LOAD"XY",use,0 verwendet, bleiben die Variablen bestehen. Das ist ziemlich cool.

    Auch ohne sie in die REU zu retten und dann wiederherzustellen.

    Auch das Hauptprogramm wieder laden funktioniert mit dem selben Mechanismus.

    ABER: wenn man mit D! arbeitet, muss man das Programm dann mit RUN nochmal starten und dann sind die Variablen futsch :biggrin:

    Jetzt könnte man doch wieder die REU verwenden.

    Oder alles das in einen LOADER vorlagern, was mit D! derzeit gelöscht wird.

    Ich bin immer sehr stolz darauf, Probleme zu provozieren, aus denen andere Lernen können :smile:

    D! is nicht schlecht. Für komplexere Fälle kanns halt ohne einfacher sein.

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • So: ihr Besserwisser. Alle seid ihr Besserwisser. Alle. :biggrin:

    Nein, das ist nicht wahr. Du hast unrecht. Ich weiß es besser! :D

    Wenn man direkt im Programmcode LOAD"XY",use,0 verwendet, bleiben die Variablen bestehen. Das ist ziemlich cool.

    Das wußte ich noch nicht. Das ist ziemlich cool (wenn es keine Risiken und Nebenwirkungen hat).

    Oder alles das in einen LOADER vorlagern, was mit D! derzeit gelöscht wird.

    Damit wären wir dann wieder bei Post #Bitte melde dich an, um diesen Link zu sehen..

  • Wenn man direkt im Programmcode LOAD"XY",use,0 verwendet, bleiben die Variablen bestehen.

    Aber nur, wenn das nachgeladene Programm kürzer bis gleich lang ist. Ist es länger, werden entsprechend viele Variablen unbrauchbar bis unauffindbar. Bei D! wird intern ein CLR durchgeführt, daher sind alle weg.

    Übrigens, TSB lädt (wenn man keine andere Angabe macht) immer wie mit ",8,1" (also dahin, was im File steht).

    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Damit wären wir dann wieder bei Post #Bitte melde dich an, um diesen Link zu sehen..

    ich verweigere die Aussage :biggrin:

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Aber nur, wenn das nachgeladene Programm kürzer bis gleich lang ist. Ist es länger, werden entsprechend viele Variablen unbrauchbar bis unauffindbar.

    Ja, richtig.

    Und das ist eigentlich ja ohnehin das normale Verhalten, weswegen man auch beim Nachladen von Binaries immer ein IF A=0 then A=1:LOAD bla machen muss. Da bleiben ja auch die Variablen erhalten. :smile:

    Andere Frage:

    wenn ich ein anderes Programm so lade, was passiert mit den Sprungdaten aus CHECK?

    Verwirft ein LOAD diese, dh ich sollte das erneut ausführen?
    Oder bleiben die im Speicher und tun halt nix, weil die Sprungziele für das neue Programm nicht mehr gelten?

    Falls das so ist: gelten die dann wieder, wenn ich zum alten Programm zurückkehre?

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Aber nur, wenn das nachgeladene Programm kürzer bis gleich lang ist. Ist es länger, werden entsprechend viele Variablen unbrauchbar bis unauffindbar.

    Ja, richtig.

    Und das ist eigentlich ja ohnehin das normale Verhalten, weswegen man auch beim Nachladen von Binaries immer ein IF A=0 then A=1:LOAD bla machen muss. Da bleiben ja auch die Variablen erhalten. :smile:

    Das mit dem IF A=0 THEN A=1... muss man machen, damit es nicht zur einer Endlosschleife beim Laden kommt. Was GoDot hier jedoch erklären wollte ist, dass die Variablen teilweise unbrauchbar werden, wenn das nachgeladene Programm größer ist als das ladende Programm.

  • Andere Frage:

    wenn ich ein anderes Programm so lade, was passiert mit den Sprungdaten aus CHECK?

    Verwirft ein LOAD diese, dh ich sollte das erneut ausführen?
    Oder bleiben die im Speicher und tun halt nix, weil die Sprungziele für das neue Programm nicht mehr gelten?

    Falls das so ist: gelten die dann wieder, wenn ich zum alten Programm zurückkehre?

    Sprungziel ist Sprungziel. Das sind also absolute Adressen. Die bleiben zwar bei D! erhalten, zeigen aber bei einem geänderten Programm nicht mehr auf die „richtige“ Stelle. TSB vergleicht ja weiterhin die Prozedurnamen, kann aber an der alten Stelle im neuen Programm nichts finden. Kurz gesagt: CHECK ist erforderlich! Wenn aber am Ende das gleiche Programm im Speicher ist wie ursprünglich, ist kein Eingriff nötig. TSB würde allerdings neue Prozeduren in der Liste von sich aus ergänzen (wenn zwischendurch andere Verhältnisse herrschten).


    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Sprungziel ist Sprungziel. Das sind also absolute Adressen. Die bleiben zwar bei D! erhalten, zeigen aber bei einem geänderten Programm nicht mehr auf die „richtige“ Stelle. TSB vergleicht ja weiterhin die Prozedurnamen, kann aber an der alten Stelle im neuen Programm nichts finden. Kurz gesagt: CHECK ist erforderlich! Wenn aber am Ende das gleiche Programm im Speicher ist wie ursprünglich, ist kein Eingriff nötig. TSB würde allerdings neue Prozeduren in der Liste von sich aus ergänzen (wenn zwischendurch andere Verhältnisse herrschten).

    Dh beim Wechsel des Programmes CHECK aufrufen ist empfehlenswert.

    Das vorige Löschen einer alten Sprungtabelle ist nicht nötig, oder?

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com
  • Dh beim Wechsel des Programmes CHECK aufrufen ist empfehlenswert.

    Das vorige Löschen einer alten Sprungtabelle ist nicht nötig, oder?

    Nein, bei CHECK wird immer neu aufgebaut.


    Arndt

    GoDot C64 Image Processing
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Aber nur, wenn das nachgeladene Programm kürzer bis gleich lang ist. Ist es länger, werden entsprechend viele Variablen unbrauchbar bis unauffindbar.

    Ja, richtig.

    Und das ist eigentlich ja ohnehin das normale Verhalten, weswegen man auch beim Nachladen von Binaries immer ein IF A=0 then A=1:LOAD bla machen muss. Da bleiben ja auch die Variablen erhalten. :smile:

    Das mit dem IF A=0 THEN A=1... muss man machen, damit es nicht zur einer Endlosschleife beim Laden kommt. Was GoDot hier jedoch erklären wollte ist, dass die Variablen teilweise unbrauchbar werden, wenn das nachgeladene Programm größer ist als das ladende Programm.

    Ja, richtig.

    Und ich wollte das Thema für mich mental damit abschließen, dass das alles die eh bekannten Mechanismen sind, wenn man ein Basic Programm von einem anderen nachlädt.

    Sowohl die Gefahr des Überschreibens, als auch die Tatsache, dass Variablenwerte erhalten bleiben.

    Die Endlosschleife kann man ja nur deshalb verhindern, weil Variablenwerte erhalten bleiben.

    Und das hätt ich eigentlich schon längst gewusst.

    Keine Ahnung, warum mich das nun so freut :biggrin:

    YouTube Kanäle über Basic, den C128 und den VDC-Chip
    Bitte melde dich an, um diesen Link zu sehen. --- Bitte melde dich an, um diesen Link zu sehen.
    Commodore 8-Bit Projekte
    auf Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen. zu Commodore 8-bit Hardware
    auf printables.com