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.
Absturz BASIC-Programm - verstehe nicht warum
-
jomodore -
6. Oktober 2015 um 17:19 -
Erledigt
Es gibt 32 Antworten in diesem Thema, welches 7.053 mal aufgerufen wurde. Der letzte Beitrag (
-
-
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?
-
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.").
-
Also rein theoretisch sollte es
:for p=0 to -1 step-1: heißen .Schönen Gruß.
-
Und Feldindexe sollten nicht negativ werden.
Schönen Gruß.
-
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.
-
Ich wollte gerade das Zitat reparieren, das ich versaubeutelt habe - warum zum Geier ist in diesem Thread die Editierfunktion abgeschaltet?!
-
Und wann kommt NEXT P?
-
@ 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.
-
Edit:
Also statt "R" mal "AR" nehmen oder "X".
Macht keinen Sinn aber bei mir hat es geholfen. -
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:
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
. 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.

jomodore
-