Der C64 meldet sich ja beim Einschalten mit 38911 Basic Bytes Free.
Da in einen Block 254 Bytes passen, wäre rein rechnerisch bei ca. 153 Blöcken schluss.
Es ist jedoch zu beachten, dass auch noch die Variablen etc. Speicherplatz verbrauchen, sodass der für das Programm nutzbare Speicher geringer ausfällt.
Mit 140 Blöcken bist du wahrscheinlich schon hart an der Grenze. Ich hatte schon bei kleineren Programmen ?OUT OF MEMORY ERROR, wenn diese viele Variablen oder gar Arrays benutzt haben. Ich denke mal viel Platz wirst du für dein Programm nicht mehr haben. Wenn es ein Spiel mit mehreren Leveln ist, solltest du überlegen die Levels nicht direkt im Programm abzulegen, sondern in Dateien auszulagern und jeweils das aktuelle Level nachzuladen (dabei immer das letzte im Arbeitsspeicher überschreiben, um keine Speicherplatzprobleme zu bekommen).
Soweit ich mich erinnern kann, kann eine Diskette 144 Dateien haben, da man nur 664 Blöcke zur Verfügung hat, können das natürlich nur sehr kleine Dateien sein.
In Blöcken weiß ich jetzt aucvh nicht genau. Aber eben so viele Blöcke, bis die Speichergrenze (für nromale Basickonfiguration) $9FFF erreicht ist. 
Wenn du ein AR Modul oder ähnliches hast, welches die Lade und Endadresse des Prg. Hexadezimal beim 'reinladen anzeigt, kannst ja ungefähr abschätzen wieviel noch Platz ist.
-
Ach, dass mit den Variablenspeicher, vom zeitgleichen Vorposter erwähnt, hinten im Speicher dran, habe ich jetzt nicht bedacht. Könnte also etwas weniger als bis $9FFF reichen. Je nach Var. Nutzung etc. im Programm.
kommt darauf an, wie man die Blöcke erzeugt, auch im BASIC kannst du bis in den hohen Speicherbereich unter die ROMs laden, z.B. Grafik wie Zeichensätze usw. usw. Also eigentlich eher 256 imho =P
http://www.c64-wiki.de/index.p…NAL#Disketten-Operationen
Aber sonst erstmal in den Taschenrechner tippen ($A000-$0800)/$10
144 Einträge pro 1541-Disk / .D64 stimmt.
Du willst das hier lesen und verstehen:
http://www.c64-wiki.de/index.p…icherbelegung_%28BASIC%29
Hallo zusammen,
ich bastel gerade mal wieder an meinem Basicprogramm.
Nun hab ich auf der Disk berits 140 Blöcke für das Hauptprogramm zusammengebastelt.
Wieviele passen den in den Basicspeicher vom C64.
Die Methode PRINT FRE(0) bringt nur einen Absturz = keine Rückmeldung!
[..]
Zu welchem Zeitpunkt aufgerufen. Gleich nach dem Laden?
Viel Platz ist ja nicht mehr da, dass eine etwaige Garbage-Collection allzu lange brauchen würde. Ein bisschen über 830 Strings in einem Array wäre da noch Platz. Eine Collection würde dazu dann ca. 1 Minute 8 Sekunden brauchen... da könnte man schon den Eindruck eines Absturzes bekommen, zumal ein RUN/STOP nichts bewirkt
Hm?! Mit dem Aktion Replay MK6 gefreezte Programme haben teilweise über 200 Blöcke. Wie passen die denn in den Speicher?
So ein "Freeze" ist im Prinzip ein Abbild des Speichers von Anfang bis Ende (vermutlich nicht komplett, aber so in etwa kommt das hin). Die Kollegen sprechen hier aber von _Basic_-Programmen. Also den 38911 Bytes, die Basic einem lässt.
Achso. Alles klar.
der ROM loader kann einfach nicht unter den I/O Bereich ab $d000 laden. So einfach ist das.
Also bis $cfff geht. Meist ja (muss aber nicht!) ab $800, also die eigentlich bekannten 51200 Bytes ($cfff-$0800) bzw ca 202 Blocks.
Das hat mit den 64KB RAM selbst nichts zu tun. Die waeren ja auch fast 260 Blocks gross.
Die 38911 Bytes sind der BASIC Speicher der 'Ab Werk' zur Verfuegung steht. Auch das ist nicht in Stein gemeisselt.
Dabei ist die obere Grenze dann $9fff (ab $a000 liegt ja das BASIC). Nimmt man $0800 als untere kommt man auf genau die 38911 Bytes.
64kB RAM heißt theoretisch, daß auch 64kB mit Daten gefüllt werden können.
Praktisch gibt es aber Einschränkungen durch die Speicheraufteilung.
die Zeropage. 0-1023
den Bildschirm: 1024-2047
das Basic-Programm-RAM: 2048-40959
den ROM-Bereich: ab 40960
das obere RAM: ab 49152
Für Basic es wohl das geeignetste das Basic-RAM für Programme und die ROM-Bereiche für Grafik, Sprites, und Zeichensätze zu verwenden.
Kleinere Programme bis 4k kann man allerdings auch ins obere RAM laden und ausführen.
Der Thread ROM-RAM zeigt, wie man den Bildschirm ins obere RAM verlegt und zusätzlich 1kB Basic-RAM Speicher dazugewinnen kann.
Schönen Gruß.
Aus der Sicht des Basic-Programmierers ist das so.
Schönen Gruß.
Nö.
Warum können die Basic Programme beim Plus/4 60kb groß sein?
@Suppenwürfel:
Wie ich gehört habe, werden die Programme beim Plus4 auch unters ROM gelegt.
@Ben:
Für den Basic Programmierer ist die Zero-Page die 0te Bildschirmseite, die man übrigens auch einschalten kann.
Für den Assembler-Programmierer der 0te Speicher-Block.
Schönen Gruß.
der ROM loader kann einfach nicht unter den I/O Bereich ab $d000 laden.
Ja, gerade gestern auch im Wiki aktualisiert wegen ähnlicher Problematik im Nachbar-Fred
http://www.c64-wiki.de/index.p…NAL#Disketten-Operationen
Warum können die Basic Programme beim Plus/4 60kb groß sein?
Weil der Basic-Interpreter dort so verändert wurde, dass beim Holen von Basic-Daten das ROM kurz abgeschaltet wird. Beim 128er ist das genauso. Der Zugriff erfolgt über eine kurze Routine, die beim Rechnerstart vom ROM ins RAM kopiert wird (aus dem ROM heraus ist das Abschalten des ROMs ja logischerweise eine schlechte Idee).
Für den Basic Programmierer ist die Zero-Page die 0te Bildschirmseite
Warum nicht das 0te Sprite, der 0te Zeichensatz, die 0te Grafikbitmap oder gleich die 0te VIC-Bank?
Disclaimer: Das war eine rhetorische Frage, denn von Dir kommt eh keine brauchbare Antwort.
Der Begriff "Zero Page" ist für den 6502-Prozessor definiert als die ersten 256 Byte des Adressraums (und nichts sonst). Und zwar deshalb, weil in dieser Speicherseite das High-Byte der Adresse eben den Wert Null hat.
Der einzige Grund, dass ich mir die Mühe des Widersprechens überhaupt noch mache, ist dieser: Diese Rubrik könnten auch Leute lesen, die es noch nicht besser wissen, und die sollten erfahren, dass BIF nicht für "den Basic Programmierer" an sich spricht.
Das ist mir im Wiki letzt auch schon aufgestossen:
QuoteErweiterte Zeropage
Dieser Bereich unmittelbar nach der Zeropage beginnend mit Page 1 erstreckt sich bis inklusive Page 3 und wird einfacherweise auch erweiterte Zeropage (engl. extended zeropage) genannt. Dieser Begriff ist aber technisch nicht genau spezifiziert
Wobei ich meine, dass "wir" damals auch alles "was da vorne liegt" pauschal Zeropage genannt haben.
Mit den Begriffen "Page 1 bis 3" kann vermutlich auch keiner was anfangen. "Page 01, 02, 03" wäre da vielleicht sinnvoller.
Das ist mir im Wiki letzt auch schon aufgestossen:
Wobei ich meine, dass "wir" damals auch alles "was da vorne liegt" pauschal Zeropage genannt haben.
Mit den Begriffen "Page 1 bis 3" kann vermutlich auch keiner was anfangen. "Page 01, 02, 03" wäre da vielleicht sinnvoller.
Ich muss gestehen, ich hab mich mit dem Ausdruck "erweiterte Zeropage" auch nie anfreunden können (hatte es vor 2009 auch noch nie gehört oder gelesen) und hab dezente Änderungen im Wiki versucht unterzubringen, die es nicht arg falsch aussehen lassen. Einem Assembler-Programmierer gibt es nur die eine Zero-Page. Alles andere macht keinen Sinn oder bedient nur Vorstellungen von etwas, was es in Wirklichkeit nicht gibt oder schlicht nur verwirrt.
Ich wollt nicht gleich einen Wiki-Aufstand anzetteln. Aber mit etwas mehr Rückhalt und aufgrund fehlender zitierbarer Quellen (die Quelle wo der Begriff vorkommt, kann wohl nicht wirklich Gewicht haben - schätz ich mal, weiß es aber nicht -) würde den Ausdruck "erweitere Zeropage" sofort vernichten. 
