Bytes aus Dateien schneller auslesen

Hallo Forum,

also, ich hatte gaaanz, ganz viele DATA-Zeilen in meinem BASIC-Programm. Alles Bytes. Die haben das Programm sehr groß gemacht. Also habe ich sie in ein sequentielles File ausgelagert*. Ich hatte nun irgendwo gelesen, dass das Einlesen von Daten aus einem File schneller ist als READ. Aber ich sehe keinen Unterschied. Mein Code ist wie folgt:

Die Zeile 30 ist eine Beispielzeile. Es gibt viel mehr davon.

Also: Geht das schneller?

(*) Ich hatte das vorher noch nie gemacht. Meine Infos habe ich aus einem Blog. Dass ich N statt S für numerische Werte verwenden kann, war geraten. Oder steht dort das "S" für "SEQ"? *confused*

Zitat von BIF

Benutze den Anhang für Binäre Daten, dann brauchst du nix aus Data-Zeilen oder Dateien zu laden.

Hi BIF. Verstehe ich nicht. Welchen Anhang?

Info: Ich programmiere direkt im C64 BASIC Editor. Das Ende des BASIC-RAMs habe ich auf $3F80 verschoben, da ich vier Sprites habe, die in die VIC-Bank müssen. Der "Anhang" wäre also danach (?), also ab $4000. Ich habe aber keine Ahnung, wie ich aus dem BASIC Editor heraus binäre Daten ans BASIC-Ende anhänge und zusammen mit dem Programm abspeichere. Ich habe allerdings einen ML-Monitor (Supermon64). Hilft das evtl. weiter?

Zitat von Unseen

Allerdings ist es ziemlich sinnlos, Daten in einer SEQ-Datei zu speichern und per INPUT# zu lesen, wenn sie danach direkt per POKE ins RAM geschrieben werden - den RAM-Block kann man auch direkt in einer PRG-Datei speichern und die beim Programmstart nachladen, dann wird es tatsächlich schneller.

Ok, ist klar, dass das schneller ginge. Frage ist: Wie?

Zitat von Unseen

Zitat von WebFritzi

Oder steht dort das "S" für "SEQ"?

Ja, S steht für SEQ.

Danke für die Aufklärung.

Zitat von JamiroDrache

Ich denke er meint, die Bytes direkt als Datei zu speichern und mit load ,8,1 wieder an die jeweilige Stelle zu laden.

Nein, denn er schrieb, dass ich nicht aus Dateien zu laden brauche.

Zitat von BIF

Die Programmierung des Anhangs ist relativ einfach:
Du mußt einfach das Programmende deines Basic-Programms raufsetzten.
poke46,peek(46)+4:clr:

Und schon hast du 4 Blocks = 1kB Anhang in dem du deine Daten reinkopieren kannst.

Das spart im Vergleich zu DATA-Zeilen eine Menge Speicher und Nachladen muß du auch nichts.

Schönen Gruß.

Alles klar. Danke. Da gibt es nur ein Problem. Mein BASIC-RAM ist bei $3F80 zu Ende, weil danach noch zwei Sprite-Definitionen kommen. Bevor ich 55/56 verschoben hatte, wurden die Sprites bei $3F80 von BASIC irgendwann im Verlaufe des Programms korrumpiert.

Zitat von JeeK

Um wie viel Bytes geht es denn dabei überhaupt?

Es ist ca. 1 KB. Warum die SEQ-Datei 14 Blocks verschlingt, weiß ich nicht.

Zitat von Drachen

Wäre es nicht einfach in eine andere Bank zu wechseln, damit du mehr Platz für dein Basicprogramm hast.

Biff hat da was schönes gemacht TRICKS mit ROM-RAM

Und was willst du denn für Daten einlesen, wenn es Sprites sind, würde ich die nachladen, dann sind sie gleich an der richtigen Stelle.

Ja, das wollte ich eigentlich aus Faulheit vermeiden. Aber ich sehe im Moment auch keine bessere Möglichkeit. Die Daten sind 4 Sprites, ein paar ML-Prozeduren und Daten für Tetris-Steine. Das Problem ist, dass ich dann ein paar ML-Procs anpassen muss, die $0400 verwendet haben.

Also, dann mache ich folgendes:

1. VIC-Bank auf $8000, Bildschirmspeicher auf $8800

2. BASIC-Ende auf $8000 setzen

3. Ca. 1 KB Daten direkt dahinter. Dann sind die Sprites gleich mit drin.

Wäre das so ok? Und wenn ja, wie kriege ich Punkt 3 im BASIC-Editor gebacken?

Zitat von JeeK

Zitat von WebFritzi

dass ich N statt S für numerische Werte verwenden kann, war geraten.

"N" wird ignoriert. Es gibt im Wesentlichen nur die Dateitypen U(SR), S(EQ), R(EL), P(PRG). Das hieße, dass standardmäßig ein PRG hier zur Anwendung kommt. Wenn man byte-weise oder Zeilen in eine Datei hineinschreibt, ist es im Grunde egal, ob S, U oder P verwendet wird. Als PRG kann es halt passieren, dass es "versehentlich" als Programm geladen werden könnte bzw. von LOAD/SAVE "gesehen" wird.

Du hast mich missverstanden. Ich dachte, das S steht für "String". Also habe ich N für "Numerisch" verwendet. Habe erst vorhin gemerkt, dass das Quatsch war. Es werden wohl immer Strings abgespeichert. Übrigens erfolgt die Konvertierung in Zahlen automatisch. Bei INPUT#8,A bekomme ich eine Zahl in A, obwohl ich die Zahl ja (offenbar) als String abgespeichert hatte.