TSB Info

Es gibt 2.419 Antworten in diesem Thema, welches 329.475 mal aufgerufen wurde. Der letzte Beitrag (19. November 2025 um 22:55) ist von GoDot.

  • Goodwell kann beruhigt weitermachen und ClausS mit seinem Projekt loslegen (wird er euch selber erklären)! ^^

    Hoho, schon viele haben es verkündet, mit TSB Großes zu schaffen… aber am Ende blieb meist nur Rauch aus der Pfeife. Mal sehen, ob diesmal mehr als heiße Luft kommt! :bgdev

  • 1. Zu dem von GoDot angesprochenen Projekt.

    Ich möchte kein Programm mit TSB erstellen, sondern ich plane TSB in mein Projekt "Bitte melde dich an, um diesen Link zu sehen." mit aufzunehmen.

    2.

    Mal sehen, ob ich HSG und SMON austauschbar hinkriege (wenn SMON startet, kann es ja nachsehen, ob HSG bereits aktiv ist, und es beim Beenden wieder nachladen und erneut aktivieren).

    In SMON erfolgt ja der "Rücksprung" nicht zu TSB, sondern zum Basic Warmstart nach $a474.
    Das würde bedeuten, das man diesen Sprung Umleiten müsste, um HSG wieder nachzuladen.

    Zuerst sollte aber auch überprüft werden, ob HSG vorher überhaupt aktiv war.

    Dazu bräuchte man wiederum ein Flag, welches beim Starten von HSG gesetzt werden muss, und welches man dann beim Beenden von SMON auslesen könnte.

    Gibt es denn noch eine Speicherstelle, welche als Flag genutzt werden kann?

    Alles in Allem ein recht grosser Speicherbedarf, welcher so in der verwendeten SMON-Version mMn nicht vorhanden ist.

    Oder wäre es nicht einfacher, dafür zu sorgen, dass der Vector in $0308/$0309 bevor SMON gestartet wird, auf den "Normalzustand" gesetzt wird?
    Soweit ich das beurteilen kann, wären die dafür benötigten Bytes ja "noch frei"

    Meine Frage an dich, soll ich TSBneo in der jetzigen Fassung in mein Modul mit aufnehmen, oder möchtest du erst noch über eine Lösung für den Fehler nachdenken, welcher TSB abstürzen lässt?

    LG

    Claus

    "Wer einen Fehler begangen hat und ihn nicht korrigiert, begeht einen weiteren Fehler."

    (aus den Lehren des Konfuzius)

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.

  • Zuerst sollte aber auch überprüft werden, ob HSG vorher überhaupt aktiv war.

    Dazu bräuchte man wiederum ein Flag, welches beim Starten von HSG gesetzt werden muss, und welches man dann beim Beenden von SMON auslesen könnte.

    Gibt es denn noch eine Speicherstelle, welche als Flag genutzt werden kann?

    Das Flag ist bereits vorhanden: Der Befehlsvektor von GRAPHICS ist umgelenkt, wenn es aktiv ist! Das kann als Flag dienen.

    Oder wäre es nicht einfacher, dafür zu sorgen, dass der Vector in $0308/$0309 bevor SMON gestartet wird, auf den "Normalzustand" gesetzt wird?

    SMON verändert nur den BRK-Vektor $0316/$0317. Der wird auch beibehalten, wenn SMON beendet wird, und zwar als *Feature*, damit du eigene Programme besser debuggen kannst (statt es mit RTS zu beenden, BRK setzen). Diese Änderung sollte also, solange SMON im Speicher ist, erhalten bleiben.

    Meine Frage an dich, soll ich TSBneo in der jetzigen Fassung in mein Modul mit aufnehmen, oder möchtest du erst noch über eine Lösung für den Fehler nachdenken, welcher TSB abstürzen lässt?

    Absturzfehler? Wo denn? Oder meinst du das Verhalten von HSG, nachdem SMON drübergebügelt wurde? Ich würde mal sagen - im jetzigen Zustand von TSB - ist das eine Fahrlässigkeit des Users. Aber ich denke, ich kann einen Nachlader für HSG im SMON einbauen. Platz ist in SMON noch vorhanden (ist ja etwas optimiert worden).

    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.

  • Das Flag ist bereits vorhanden: Der Befehlsvektor von GRAPHICS ist umgelenkt, wenn es aktiv ist! Das kann als Flag dienen.

    Stimmt gar nicht, du hast recht! Ich probier mal was…


    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.

  • Absturzfehler? Wo denn? Oder meinst du das Verhalten von HSG, nachdem SMON drübergebügelt wurde? Ich würde mal sagen - im jetzigen Zustand von TSB - ist das eine Fahrlässigkeit des Users. Aber ich denke, ich kann einen Nachlader für HSG im SMON einbauen. Platz ist in SMON noch vorhanden (ist ja etwas optimiert worden).

    Arndt

    Also ich starte HSG, dann fällt mir ein, das ich etwas mit SMON im Speicher nachschauen wollte.
    Also starte ich SMON, vergesse dabei aber HSG mit dem Befehl COLD zu beenden.

    Nachdem ich dann wieder den SMON verlassen habe, funktioniert kein Befehl mehr in TSB.:gruebel

    Stimmt, ist ja meine Fahrlässigkeit, wie kann ich aber auch nur.:platsch:
    Ich bin aber auch ein Schelm, habe ich SMON gestartet, ohne vorher HSG zu killen.:nuss:

    Also ich bin der Meinung, das sollte nicht passieren.:prof:

    LG

    Claus

    "Wer einen Fehler begangen hat und ihn nicht korrigiert, begeht einen weiteren Fehler."

    (aus den Lehren des Konfuzius)

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.

  • Also ich bin der Meinung, das sollte nicht passieren.

    Verstehe! :wink:

    Ist jetzt geregelt. Neue Version von Disk und CRT in Vorbereitung. Geändert werden "tsb.hsg", "tsb.mon" und "smon" (der Launcher für SMON). Du solltest aber wissen, dass jeder Neustart von HSG mit einem CLR verbunden ist. D.h., ein Basic-Programm müsste nach dem SMON (und zurück zu HSG) neu gestartet werden. Ich hab deine Idee mit dem Flag verwirklicht (Speicherstelle $c648 heißt jetzt "identify").

    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.

  • Das mit dem Neustart von HSG ein CLR gemacht wird, liegt sicherlich am Aufbau von HSG, und sollte auch dort in der Dokumentation als Hinweis platziert werden. (falls noch nicht vorhanden)

    Aber der "Absturz" des TSB hat ja andere Gründe.

    HSG 'verbiegt' nun mal den Vector in $0308/$0309, und SMON weiss halt nichts davon.
    Wenn SMON einfach den Vector bei jedem Start 'gerade' richtet, sollte es auch schon ausreichen.

    Claus

    "Wer einen Fehler begangen hat und ihn nicht korrigiert, begeht einen weiteren Fehler."

    (aus den Lehren des Konfuzius)

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.

  • Wenn SMON einfach den Vector bei jedem Start 'gerade' richtet, sollte es auch schon ausreichen.

    Ich hab's jetzt so gemacht: In der CRT-Version ist es egal, was im Interpretervektor steht, denn nach Verlassen von SMON ist dann halt der HSG-Vektor immer noch an (ansonsten der TSB-Vektor) und in der Disk-Version sorgt der SMON-Launcher ("smon") für den richtigen Vektor. Funktioniert wunderbar!

    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.

  • Daher also:

    Update der Dateien "TSB.HSG" (v1.04), "TSB.MON" (v1.05), "smon" und der beiden CRTs!

    Das Update bewirkt, dass ein Aufruf des Monitors (SMON) nach Verwenden der Erweiterung "High Speed Graphics" (HSG) nicht mehr zu einem Shutdown führt ("nichts geht mehr"). Stattdessen wird HSG beim Verlassen von SMON (mit "x") automatisch neu geladen und aktiviert. Da die Initialisierung von HSG mit einem CLR endet, sind danach eventuelle Variablenwerte aus einem vor dem Aufruf von SMON durchgeführten Programmlauf verworfen und das PRG muss neu gestartet werden.

    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,

    sollte das Flag in $C648 nicht auch geloescht werden, wenn man HSG mit COLD beendet?

    "Wer einen Fehler begangen hat und ihn nicht korrigiert, begeht einen weiteren Fehler."

    (aus den Lehren des Konfuzius)

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.

  • sollte das Flag in $C648 nicht auch geloescht werden, wenn man HSG mit COLD beendet?

    Es wird mit Null initialisiert, wenn man SMON verlässt. Das sollte reichen, denke ich. HSG hat keinen Abschlussbefehl, bei dem man das tun könnte und in COLD ist kein Platz mehr (höchstens, wenn ich die Initialisierung des SID weglasse).

    Arndt

    Edit: Ach, du meinst, weil sich dann unbeabsichtigt HSG einschleichen würde? Hm... soll ich den SID unaufgeräumt lassen?

    Edit2: Dann - übergangsweise, bis zum nächsten Release - dies hier: POKE $807B,$8d: D!POKE $807C,$C648.

    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.

    3 Mal editiert, zuletzt von GoDot (10. September 2025 um 15:48)

  • Ich kenne mich mit TSBneo wirklich nicht aus, Ich dachte der Befehl COLD sei Bestandteil von HSG.
    Ich hatte dies im Handbuch auf Seite 82 dazu gelesen:

    Zitat

    HSG wird im Speicher ab $7400 abgelegt und von TSB automatisch eingebunden. Es wird mit dem Befehl COLD wieder abgeschaltet.

    Auch wenn SMON das Flag löscht, wird es beim Starten von HSG ja wieder gesetzt.
    Das Flag wird aber so wie es aussieht nicht wieder gelöscht.

    Claus

    "Wer einen Fehler begangen hat und ihn nicht korrigiert, begeht einen weiteren Fehler."

    (aus den Lehren des Konfuzius)

    Mein GitHub: Bitte melde dich an, um diesen Link zu sehen.

  • Das Flag wird aber so wie es aussieht nicht wieder gelöscht.

    Der vorläufige POKE in meinem letzten Post erledigt das (innerhalb von COLD). Im nächsten TSB-Release ist das dann drin.

    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 hab immer bedauert, dass der Befehl Bitte melde dich an, um diesen Link zu sehen. nicht in der Lage ist, Verzögerungen von weniger als einer Sekunde zu liefern. Einen Workaround hatte ich mir schon ausgedacht (Bitte melde dich an, um diesen Link zu sehen., weiter unten, unterhalb des dicken Trennstrichs). Die ist aber, weil sie im Wesentlichen auf Basic beruht, ziemlich ungenau, besonders bei ganz kurzen Wartezeiten.

    Jetzt hab ich einen Weg gefunden, auf Zehntelsekunden genau zu verzögern, Bitte melde dich an, um diesen Link zu sehen. beschrieben. Man braucht nur zwei POKEs und ein bisschen IF... :smile:

    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.

  • Bevor das in Vergessenheit gerät:

    Der Port von "North Sea Oil" von Simons' Basic auf TSB!

    Bitte melde dich an, um diesen Anhang zu sehen.

    (Dieser Text wird länger, sorry! Beim Lesen: "NSO" steht für das SB-Original, "NSOneo" für den Port, "SB" ist kurz für Simons' Basic.)


    Was waren die Herausforderungen bei diesem Projekt?

    1. Die zusätzlichen Maschinenroutinen bei NSO

    NSO ist ein Programm, das ausschließlich mit der Modulversion von SB läuft. Es verwendet fünf Maschinenprogrammroutinen für spezielle Zwecke. Diese Routinen liegen fast alle an Speicherpositionen, die TSB zum Absturz bringen würden (im Bereich von $a100 bis $a91e, $c7a0 bis $c7e9 und $02a7 bis $02ff, letzterer ist der Spriteblock 11). Außerdem wird von $c800 bis $c9ff ein Puffer eröffnet. Bis auf den Spritebereich wird dadurch TSB-Code überschrieben.

    2. Die exzessive Zahl von Dateizugriffen bei NSO

    NSO besteht aus 89 Dateien. Jede Änderung auf dem Bildschirm ist mit einem Diskzugriff verbunden. Das Floppylaufwerk ist praktisch daueraktiv. Das wirkt sich äußerst negativ auf die Ablaufgeschwindigkeit des Programms aus.

    3. NSO arbeitet im Hires-Bitmap-Modus, beachtet aber dessen Farbrestriktionen nicht

    Das Programm verursacht bereits auf dem ersten Bildschirm nach dem Booten, noch ohne irgendwas gemacht zu haben, deutlich sichtbare Color Clashes. Diese verschwinden während des ganzen Spiels nicht, es werden im Gegenteil immer mehr.

    Bitte melde dich an, um diesen Anhang zu sehen.

    4. NSOs Programmierung ist fehlerbehaftet bis hin zu Absturz- und Aufhängfehlern, einige Algorithmen liefern zusätzlich falsche Ergebnisse

    Diese Fehler kommen immer erst nach und nach ans Tageslicht. Ein Berechnungsfehler wurde erst durch KI-Einsatz eingekreist und behoben.

    5. Die Programmierung von NSO insgesamt ist nicht auf Geschwindigkeit optimiert

    In NSO führen jede Menge GOTOs in den vorderen Bereich des Programms zum Ausbremsen des Ablaufs (bei GOTO nach vorne sucht der Interpreter vom Programmstart aus). Auch sehr lange PROC-Namen verzögern den Ablauf.

    6. NSO ist nicht speicherfreundlich angelegt

    Mit 101 Blocks Code-Länge (rund 25 KB) bleibt nicht viel Platz für Variablen, vor allem die Stringverarbeitung macht über kurz oder lang Probleme (Garbage Collection). Die Verteilung des NSO-Codes auf viele Einzelzeilen muss auch nicht sein.

    Lösungen:

    Zu 1.:

    Unter TSB sind die aufgeführten Speicherbereiche mit Code belegt. Die einzige Möglichkeit, NSO unter TSB lauffähig zu machen, ist, diese Teile - bevor sie überschrieben werden - in Sicherheit zu bringen. Das ist nur möglich, wenn eine Speichererweiterung verwendet wird, möglichst eine schnelle, deren Arbeit den Programmablauf nicht weiter verzögert, sprich: eine REU. Beim Booten von NSOneo wird das alles erledigt. TSB arbeitet dann trotz Code-Überschreibung reibungslos.

    Zu 2.:

    Für jede Anzeige auf dem Bildschirm findet ein Dateizugriff statt. Hier eine Übersicht über alle "Icons", die verwendet werden (linkes Bild):

    Bitte melde dich an, um diesen Anhang zu sehen. Bitte melde dich an, um diesen Anhang zu sehen.

    Alle diese Icons wurden in eine einzige Datei eingetragen, und zwar in einer Form, die eine schnelle Darstellung auf dem Bildschirm erlaubt (rechtes Bild). Auch diese Datei landet in der REU, und statt der vielen Disk-Zugriffe werden die Icons nun aus der REU geholt, was eine ganz und gar ungeheure Geschwindigkeitssteigerung darstellt.

    Zu 3.:

    Neben der Vermeidung von Color Clashes ist auch überhaupt eine angenehmere Darstellung des Spielbretts das Ziel gewesen. Die Trennlinien der Spielfelder sind z.B. zu hell und die in den vier Ecken sichtbaren Himmelsrichtungen auf den ersten Blick unverständlich. Das wurde so gelöst (statt weiß: hellgrau):

    Bitte melde dich an, um diesen Anhang zu sehen.

    Zu 4.:

    Die Programmierfehler haben wir hoffentlich alle lokalisiert und ausgemerzt. (Ich danke Goodwell für seine wichtige Unterstützung!)

    Zu 5.:

    Ganz viele GOTOs wurden in EXECs oder CALLs umgewandelt, da TSB solche Aufrufe erheblich viel schneller abarbeitet als GOTOs. Die Namen von PROCs haben wir aber im Original belassen (was man noch ändern könnte). Leider konnten wir keine geschwindigkeitsoptimierte Version des Mischens der "Ereigniskarten" finden. Hier werden Einträge in Fließkomma-Arrays vertauscht, was natürlich seine Zeit dauert. Wären hier Strings zu tauschen gewesen, hätte TSB seine Fähigkeiten besser ausspielen können (es gibt einen Stringtauschbefehl, der ohne Stringmüll und blitzschnell arbeitet).

    Zu 6.:

    Zuerst wurde NSO eingekürzt auf etwa 80 Blocks. Durch die REU-Einbindung (und eine Reihe weiterer erforderlicher Änderungen) war NSOneo am Ende aber auch wieder 99 Blocks groß. Die Garbage Collection kommt im Spiel (allerdings erst nach längerer Spieldauer) weiterhin vor. Das liegt vor allem daran, dass zum Aufbau der Menüs sehr viel Stringmanipulation betrieben wird.

    Insgesamt gesehen wurden die Ablaufzeiten zum Teil *drastisch* verbessert (die Anzeige der Ergebnisse einer Spielrunde erfolgt in NSO nach der letzten Spielereingabe erst nach sage und schreibe 53 Sekunden! Fast eine Minute! NSOneo drückt das auf *sieben Sekunden*! Die Staffelübergabe von einem Spieler zum nächsten dauert in NSO 17 Sekunden (in NSOneo 3 Sekunden) und das Reagieren auf eine Anweisung braucht in NSO 34 Sekunden (unter TSB 5 Sekunden). Das ist immer noch spürbar, hat aber nichts mehr (!) mit dem Original zu tun.

    Also, es ging mir bei dem Port weniger darum, ein Spiel zu kopieren, als vielmehr darum, die Probleme, die mit dieser Portierung verbunden sind, zu lösen. Und da bin ich eigentlich sehr zufrieden.

    Freundlicherweise hat Forum64-User t0m3000 ein neues Bootlogo für NSO entworfen (siehe am Anfang dieses Beitrags), so dass beim Spielen von Anfang an klar ist, dass sich hier was geändert hat.

    Download von NSOneo v1.7 von Bitte melde dich an, um diesen Link zu sehen.. Viel Spaß!

    Arndt

    Edit: Fast hätte ich vergessen, Tobias zu erwähnen! Er hat die Abschlussbildschirme neu gemacht. Die Originale waren einfach gescannte Hires-Bildschirme mit einer Beschriftung, die keine Rücksicht auf Farbkacheln nahm!

    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.

    Einmal editiert, zuletzt von GoDot (2. Oktober 2025 um 11:10)

  • Vielleicht stehe ich auf dem Schlauch :)

    Aber unter diesem Link steht mir nur die alte (langsame) Version zur Verfügung.

    Aber es kann auch sein, dass der Fehler vor der Tastatur sitzt ;)

  • t0m3000 : Wenn du beim Starten dein Logo siehst, ist es die neue Version. Wenn du die langsam findest, weißt du, wie langsam die alte war! :D

    Arndt


    Edit: Tobias , danke für den Doku-Link, den hab ich vergessen.

    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.

  • t0m3000 : Wenn du beim Starten dein Logo siehst, ist es die neue Version. Wenn du die langsam findest, weißt du, wie langsam die alte war! :D

    Arndt


    Edit: Tobias , danke für den Doku-Link, den hab ich vergessen.

    Bei der Version im Downloadbereich kommt noch das alte Logo.

    Bitte melde dich an, um diesen Anhang zu sehen.