Absturz BASIC-Programm - verstehe nicht warum

Es gibt 32 Antworten in diesem Thema, welches 7.052 mal aufgerufen wurde. Der letzte Beitrag (10. Oktober 2015 um 13:25) ist von jomodore.

  • Dann ist die Fehlerursache wohl nicht in dem Teil-Listing, sondern dort geht dem Basic halt nur endgültig der Speicher aus, der schon woanders verwurstet wurde.

  • 2 Dämliche Fragen: ist die Schleife "FOR P=0 TO -1" so Absicht? Wie groß sind die Arrays DIMensioniert?

    PRINT R=20. PRINT Q=1. PRINT P=0 (direkt nach dem Abbruch).

    Die Schleife scheint bereits einmal durchgelaufen zu sein (R hat noch den alten Wert 20) - hattest Du die Schleife wiederholt aufgerufen oder wird R noch wanders genutzt?

    Wissen ist das einzige Gut, das sich beim Teilen vermehrt. Also seid vorsichtig damit!

  • Der erste BCS fängt den Fall ab, dass jemand die Routine mit einem Wert aufruft, der selbst für einen komplett leeren Stack schon zu groß wäre...


    War auch so meine einzige Idee. Was ein Quatsch...

    CBM bzw. Microsoft haben vielleicht nicht ganz so aufs letzte Byte geachtet...


    Muss wohl...

    Hab' vorhin mal das BASIC-ROM in RAM kopiert und 'dran rumgedreht'. Lief da zumindest einwandfrei. War aber wohl auch Glückssache ("IRQ & Co.").

    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.

    Ex-TLI (The Level 99 Industries) & Ex-TNP (The New Patriots) & Ex-TEA (The East Agents) & ?


  • Muss wohl...

    Hab' vorhin mal das BASIC-ROM in RAM kopiert und 'dran rumgedreht'. Lief da zumindest einwandfrei. War aber wohl auch Glückssache ("IRQ & Co.").

    Vielleicht ist die große Reserve ein Überbleibsel aus dem BASIC einer älteren CBM-Maschine? Man müsste mal deren Memory Maps überprüfen, ob dort der Speicher ab $0100 noch für andere Zwecke benutzt wurde.

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • Ich wollte gerade das Zitat reparieren, das ich versaubeutelt habe - warum zum Geier ist in diesem Thread die Editierfunktion abgeschaltet?!

    Yes, I'm the guy responsible for the Bitte melde dich an, um diesen Link zu sehen. cross assembler. And some Bitte melde dich an, um diesen Link zu sehen..

  • @ jomodore

    Ich werde vorerst um Arrays unter C64 Basic einen Bogen machen. Bin noch traumatisiert von "Minesweeper".
    Was bei mir in Minesweeper geholfen hat: Benenne die Variablen um, aber achte darauf, dass sie maximal 2-buchstabig sind.
    Ich hatte dasselbe Problem und habe es durch geänderte Variablennamen behoben.

    Es war reine Verzweiflung, denn durch gesunden Menschenverstand kommt man auf sowas nicht. Es waren bei mir wie bei Dir auch keine Systemvariablennamen betroffen (wie ti oder Anfangsbuchstaben von Basicbefehlen im Variablennamen). Ich hab nur 2 Buchstaben durch 2 andere getauscht, ich weiß aber nicht mehr, ob ich ein Array umbenannt habe oder eine Variable die einen einzelnen Zahlenwert enthält. Ich glaube sogar, ich habe damals ein eindimensionales Array umbenennen müssen.

  • Das wiederum spricht dann dafür, daß die Variable R noch in einem anderen Zusammenhang als Adresse für POKE verwendet wurde und durch die FOR-Schleife überschrieben wurde. Daraufhin ging der POKE in die Zeropage und das bringt ohne Probleme den Interpreter soweit durcheinander, daß er mit *irgendeiner* Fehlermeldung aussteigt, oder abstürzt.

  • Vielleicht ist die große Reserve ein Überbleibsel aus dem BASIC einer älteren CBM-Maschine? Man müsste mal deren Memory Maps überprüfen, ob dort der Speicher ab $0100 noch für andere Zwecke benutzt wurde.


    Schuld ist scheinbar die Tape-Routine im Kernal. Da findet sich das 'Gegenstück' zu #$3E:

    Code
    FAEF   A2 3D      LDX #$3D


    Daneben wird der Stack von $0100-010F auch noch für die Fließkommazahlen-Ausgabe vom BASIC 'missbraucht' (und für NEXT auch noch irgendwie von $0110-). Somit sind ca. $20 schon reserviert. Bleiben noch ca. $1D übrig. Im Test hatte ich es manchmal, dass sich der Stack-Pointer auf einen Schlag um 22 Bytes verringerte. Da fehlt nicht mehr viel zu $1D/29.

    Hab' mal ein kleines Stück Code rangehängt, wo man schön den Stack und den Stackpointer (rechts am Rand/Sp.stelle 1303) beobachten kann. Start bei $1000/4096.

    EDIT: War natürlich selten dämlich, das Programm mitten in den Speicher zu packen :drunk: . Hab' jetzt noch eine Kassettenpuffer-Version und eine ganz hinten im RAM rangehängt. Macht mehr Sinn.

  • Hatte ein paar Tage zu tun. Deshalb keine Reaktion von mir.

    Habe mich seit gestern Nachmittag rund 6 Stunden mit dem Programm auseinander gesetzt. Das war hart. Und ich habe jetzt eben den Fehler gefunden. Es gibt weiter vorne im (langen) Programm GOSUB Anweisungen, die nicht mit einem RETURN an den viel weiter entfernten Stellen "returniert" werden. Dadurch läuft der Stack über, wenn dieser Prozess ein bestimmte Anzahl durchgelaufen ist.

    Ich ersetzt jetzt vorerst mal GOSUB durch GOTO. Mal sehen, ob das hilft.

    Danke für die vielen Einlassungen und Tipps. Ich werde weiter berichten. :thumbup:

    jomodore