Daten in DATA-Zeilen ändern?

Was genau hast du denn vor? Wieviel Bytes werden denn für die Daten benötigt? Spielt Geschwindigkeit bei deinem
Programmvorhaben eine Rolle?

Hallo, Telespielator,

Das ist im Grunde kein Problem, wenn man logisch vorgeht.

Die Adressen der Data-Einträge sind als Stings gespeichert.
Daher ist es logisch die Stringparameter auszulesen, Stringadresse und Länge.
Damit kann man dann die Datazeilen ändern.

Schönen Gruß.

Hier das Unterprogramm String-Copy.
Damit kann kann man einen String c$ an eine Adresse a kopieren.

Die Stringadresse kann man mit dima,c$:a=peek(34+(c$<""))+peek(35+(c$<""))*256: berechnen.

30 :rem---string-copy(c$,a)
31 :poke782,peek(35+(c$<"")):poke781,peek(34+(c$<"")):poke780,len(c$)
32 :poke54,a/256:poke53,a-peek(54)*256:sys46728:return

Schönen Gruß.

Also: selbstmodifizierenden Basic-Code zu schreiben sist alles andere als trivial (Vorsicht, hierzu hat Beetlejuice bestimmt eine Meinung. Den echten Namen nenne ich besser nicht). EDIT zu spät, er ist schon da....

Beim auslesen von DATAs mittels Read bleibt der Lesezeiger jeweils auf dem letzten eingelesenen Wert stehen. Bei vorsichtiger Programmierung kannst Du später genau an dieser Stelle weiter auslesen.

Benötigst Du aber die Möglichkeit, bestimmte DATA-Zeilen später erneut auszulesen oder an genau definierten Stellen DATAs auszulesen, würde sich ggfs. eine Basicerweiterumg anbieten, die Befehle beherrscht wie RESTORE n, wobei n die Zeile angibt, auf die der DATA Lesezeiger weisen soll.

Aufgrund Deiner kurzen Beschreibung ist es recht schwammig, was Du genau erreichen willst. Es ist aber wahrscheinlich, dass Du mit dem DATA/READ-Konzept hier den falschen Ansatz verfolgst für den Zweck, den Du erreichen willst. Als intelektuelles Denkspiel ist es aber interessant, darüber nachzudenken.

Wenn man die Data´s in ein Feld eingelesen hat, z.B.
mit
dima$(90):fori=1to90:reada$(i):next:

hat man die Stringpointer auf die Data-Elemente und kann dann auch darauf zugreifen.

Data-Zeilen-Änderung ist natürlich Selbstmodifikation, das ist natürlich klar.

Ansonsten kann man mit Super-7 die Zeilenadresse feststellen und damit dann die Zeiger auf die Data-Elemente berechnen.

Schönen Gruß.

Zitat von Telespielator

zu Beginn eines Programms Daten aus den DATA-Zeilen in ein Array zu laden und dieses dann für den Programmablauf zu benutzen. Allerdings möchte ich ungern mit einem zu großen Array arbeiten, weil das ja auch Speicher frisst. Aber dann müsste man die nicht gebrauchten Bereiche jeweils mit den aktuellen Änderungen in die DATA-Zeilen zurückschreiben, um sie bei Bedarf erneut einzulesen.

Falls es bei den Daten um Strings geht, gilt: Das "Laden in ein Array" verbraucht keinen zusätzlichen Speicher, denn die Pointer im Array werden direkt auf die DATA-Zeilen verbogen. Erst bei Änderungen werden die Strings neu im Speicher angelegt.
Ansonsten stimme ich meinen Vorrednern zu: Beschreib Dein Vorhaben mal genauer, dann kann man evtl. mehr sagen.

Telespielator:

Pro Sting hast du 3 Byte Speicherverbrauch, das sind bei 100 Strings 300 Byte.
Also das ist nicht so viel Speicher, als das es gewöhnlich nicht verschmerzbar wäre.

Schönen Gruß.

Zitat von Telespielator

Ich grüble gerade darüber nach, ob es mit vertretbarem Aufwand möglich sein könnte, Daten in DATA-Zeilen zu ändern.
Die Idee dabei ist, zu Beginn eines Programms Daten aus den DATA-Zeilen in ein Array zu laden und dieses dann für den Programmablauf zu benutzen. Allerdings möchte ich ungern mit einem zu großen Array arbeiten, weil das ja auch Speicher frisst. Aber dann müsste man die nicht gebrauchten Bereiche jeweils mit den aktuellen Änderungen in die DATA-Zeilen zurückschreiben, um sie bei Bedarf erneut einzulesen. Wer kann mir dazu was erzählen?

Sind diese Daten denn überhaupt Strings, wie oben vermutet wurde? Es wäre wirklich interessant zu wissen, welcher Art diese Daten sind und um welchen Datentyp es sich bei dem Array handelt (Float, Integer, String). Wenn es numerische Werte sind, die das Array "frisst", dann kann vielleicht ein Wechsel von Float- auf Integer-Arrays (z.B. A() -> A%() ) die entscheidende Einsparung bringen, die vielleicht das DATA-Zeilengeschubse erst gar nicht notwendig macht.

Brauchst du die DATA-Darstellung, weil du den Zustand der Daten so mit dem Programm jederzeit abspeichern können möchtest?

Wenn nicht, wäre ich eher geneigt, z.B. für Array (numerisches) den Speicherort zu ermitteln und den Adressbereich insgesamt in einen freien (ab $C000) oder reservierten Bereich (vom BASIC-RAM-Top abzwacken) mit dem BASIC-Blockcopy zu kopieren und von dort wieder zu restaurieren. Für diese Dinge gibt es die entsprechenden Routinen per SYS aufrufbar (einfach 3x Beetlejuice rufen ... ).

Die DATA-Aufbewahrung kostet auch auch üblicherweise Raum im BASIC-Speicher. Da ist es nicht immer gesagt, dass es dort weniger braucht, als in Array-Elementen gespeichert.
Aber es ist schwer das zu erörtern, wenn nicht klar ist, was du genau machen möchtest, wie die Randbedingungen sind. Da wären wir wieder bei Posting #2.

Zitat von Telespielator

Die Idee dabei ist, zu Beginn eines Programms Daten aus den DATA-Zeilen in ein Array zu laden und dieses dann für den Programmablauf zu benutzen.

Ersetze "DATA-Zeilen" durch "Datei" - dann kannst Du auch eine geänderte Fassung deiner Daten (unter anderem Dateinamen) wegschreiben, und die an Stelle der ursprünglichen Daten-(SEQ-)Datei nutzen. Zu Beginn schreibst Du einmal die Daten aus den originalen DATA-Zeilen in die SEQ-Datei rein.

Braucht nur eine gescheite Eingaberoutine, damit das ganze nicht auf Kommata und anderen Zeichen ausrutscht. GET# geht natürlich auch, ist aber langsam.

(Obwohl: alles was sich in DATA-Zeilen unterbringen läßt, *müßte* sich eigentlich auch von INPUT# wieder einlesen lassen. In DATA-Zeilen muß man ja Daten mit "," und ":" in Anführungszeichen setzen sofern sie Teil eines Datums sind ... führende und abschließende Anführungszeichen werden aus dem gleichen Grund bei String-READs großzügig ignoriert - nichts anderes als was eben auch bei INPUT# passiert ...)

Zitat von Mike

(Obwohl: alles was sich in DATA-Zeilen unterbringen läßt, *müßte* sich eigentlich auch von INPUT# wieder einlesen lassen. In DATA-Zeilen muß man ja Daten mit "," und ":" in Anführungszeichen setzen sofern sie Teil eines Datums sind ... führende und abschließende Anführungszeichen werden aus dem gleichen Grund bei String-READs großzügig ignoriert - nichts anderes als was eben auch bei INPUT# passiert ...)

Man muss die Anführungszeichen glaub ich dann auch explizit im Datenstrom haben, also etwa rausschreiben mit PRINT#1,CHR$(34);VAL$;CHR$(34)

Ich würde die Daten ja auch in eine separate Datei speichern, aber mit programmiertem Direktmodus und einem recycelten DATA-Zeilen-Generator sollte das fast genauso gut klappen. Nachteil: Auf die Daten muß mit PEEK und POKE zugegriffen werden, weil die Eingabe einer Zeile die Variablen löscht. Also entweder das Array nach 49152 ff. poken oder direkt auf das BASIC-Array verzichten.

Hehehe, Tele alter Scherzkeks!
zum Thema Adventure in Basic empfehle ich Dir das (ich glaub) 64'er Sonderheft 5/85. Da ist ein schicker Kurs für sowas drin.
Aber um zum Thema zurückzukommen: Für sowas eignet sich das mit dem Datazeilen generieren nicht.

Bei einem String benötigt man theoretisch auch nur einen String und keine Data-Zeile:

Also a$=" ..... "

Darauf kann man mit der String-Adress-Formel genauso zugreifen.

Schönen Gruß.

Zitat von Telespielator

ich meine, es ist nicht so gut, wenn Arrays so riesig sind, oder?

Warum?

Bei großen String-Arrays hat man in der Tat das Problem, dass dann die Garbage Collection ewig lange dauert, aber wenn man dieses Problem hat, lädt man einen entsprechenden GC-Patch und gut. Es bringt nichts, stattdessen $Dinge komplizierter als nötig zu machen.

Kommt ja auch drauf an wie gross die Spielwelt, Texte, Wortschatz werden soll.Schau dir mal den Kurs aus der 64'er an, den ich weiter
oben erwähnt hab. Also die Idee Datazeilen während des Ablaufs zu erstellen würde ich mir in diesem Fall aus dem Kopf schlagen.
Zumal wenn du das im programmierten Direktmodus machen würdest alle Variablen gelöscht würden. Mit Poke wirds dann auch nicht
besser. Je nach größe würde ich die Daten halt in eine Datei auslagern und vom Programm aus nachladen. Texte kannste du z.B.
auch gut in ne relative Datei packen. Siehe dazu auch den Adventure Kurs ich glaub 64'er SH 6/86.

Zitat von Telespielator

Naja, die Idee war halt, die Ausgangsdaten der Strings und Variablen in den Arrays am Anfang aus den Data-Zeilen einzulesen, aber ich meine, es ist nicht so gut, wenn Arrays so riesig sind, oder?

Ganz grob gesehen funktioniert Basic ja tatsächlich so, Programm + "RAM" für Variablen.

Zahlenvariablen belegen ein bisschen Platz, sobald man sie das erste mal verwendet, ein paar Bytes am Stück für den Namen und die Zahle selber. Die Länge bleibt immer gleich, und die Position der Variablen im Speicher bleibt auch immer gleich.
Strings können ihre Länge ändern und sind deshalb zweigeteilt: Wie bei Zahlen ein fester Teil mit dem Namen und einem Zeiger, dazu ein variabler Teil, der am Ende des RAMs Speicher frisst.

Soweit passt Deine Idee also gut, Speicher sparen zu wollen.
Allerdings hat Basic schon eine Verbesserung eingebaut: Bei Befehlen wie A$="Hallo" oder Read A$ ist der String schon perfekt im Programmspeicher enthalten. Der Zeiger in der Variablen zeigt dann ins Programm, der eigentliche Inhalt des String frisst dann keinen Speicher. So gesehen braucht das komplette String-Array auch nur billige 3 Bytes je String, Teuer wird es erst, wenn Du den String veränderst, dann muss Platz im RAM genommen werden.

Für das RAM-Sparen durch Speichern in Data-Zeilen kann ich mir verschiedene biffige Lösungen vorstellen, je nachdem, was Dein Programm im Detail machen soll.
-Beliebige einzelne Zeichen verändern? Dann das komplette Array lesen, von BIF ein 2. Integer-Array mit den Zeigern füllen lassen und dann einzelne Ascii-Werte Poken. Würde mich nicht mal wundern, wenn das schneller als per String-Operationen ginge.
-Oder größere Änderungen querbeet, die sich ganz gut mit String-Ops darstellen lassen? Dann erstmal ganz normal einen String bearbeiten und von BIF an eine Array-Position zurückschreiben lassen.
-Oder brauchst Du gar nicht alles auf einmal, sonder Screen für Screen würde reichen? Könnte die einzelnen Änderungen dann einfacher und Schneller machen.
-Ein "Restore {Zeilennummer}" dürfte dann hilfreich sein, wird BIF Dir raussuchen können. Damit könntest Du dann einen Screen ab einer bestimmten Datazeile laden. Schreiben dann auf einem der genannten Wege.
-Oder doch einen ganzen Screen im Block zurückschreiben lassen? Wird sich mit dem Restore und einem 2. Array machen lassen.

Falls Dein Programm aber so groß wird, dass Du Dir Sorgen um Speicherplatz machen musst, dann wären Assembler-Hilfen gut. Ein Binärfile ans Programm gehängt oder Nachgeladen spart viel Overhead in Data-Zeilen und kann auch noch bequem 12KB oder mehr Extra-Speicher schaffen, und diverse Sorgen zum Adressieren der richtigen Strings würden auch wegfallen