Speicheroptimiertes READ-DATA

Es gibt 54 Antworten in diesem Thema, welches 8.640 mal aufgerufen wurde. Der letzte Beitrag (11. Januar 2022 um 21:54) ist von goloMAK.

  • Leider habe ich es nicht geschafft deinen Codeschnipsel VICE zu übertragen.

    Falls Du versucht haben solltest, die Copy-und-Paste-Funktion von VICE einzusetzen: die ist seit jeher für alles ungeeignet, was Steuerzeichen enthält. Auch die meisten Zeichen die mit der CBM-Taste eingegeben werden, "kommen" nicht richtig mit.

    Ich verwende hier eine eigene Methode um (Steuer-)Zeichen von PETSCII zu quoten, die aber ohne Probleme nachvollziehbar sein sollte. Die geschweifen Klammern kommen selber in PETSCII nicht vor, alles innerhalb ist gequotet. Heißt: Eingabe von Hand im Hauptfenster von VICE ist hier angesagt.

    Bei dem Beispiel macht es keinen Sinn eine *.prg-Datei mitzuliefern. Die Zeile muß man im Direktmodus eingeben. Macht man mit einer Zeilennummer ein Programm daraus, zerstört man beim Einladen genau das, was mit der OLD-Routine eigentlich hätte gerettet werden sollen.

    Ich habe deswegen dieses Beispiel gewählt, weil es kurz ist und trotzdem schon zeigt worum es geht.

    Deshalb verstehe ich wahrscheinlich nicht die ganze Idee. Soll man, ganz auf READ&DATA verzichten und stattdessen die Werte mit PRINT auf dem BS ausgeben um sie anschließend an die gewünschte Speicherstelle zu poken???!!!

    Ja, das hast Du schon richtig verstanden. :)

    Wenn "ja" müssen doch aber die Werte für den Print-Befehl aufbereitet werden und ich hätte das gleiche Problem wie jetzt. Wie codiere ich Werte zwischen 0-255?

    Mit PRINT kannst Du alle Werte von 0..255 im Bildschirmcode erzeugen! Normale Zeichen von 0..127 gehen im {RVS OFF}-Modus, inverse Zeichen gehen im Bildschirmcode von 128..255 und brauchen ein vorangestelltes {RVS ON}. Bei mehreren inversen Zeichen direkt hintereinander reicht ein {RVS ON} davor aus, gleiches gilt für mehrere normale Zeichen direkt hintereinder. {RVS ON} und {RVS OFF} kommen also nur beim Wechsel zwischen den Wertebereichen 0..127 und 128..255 zum Einsatz und darum braucht man im Regelfall weniger als zwei Zeichen (1 Steuerzeichen + 1 druckbares Zeichen) pro Byte.

    Und wo ist dann der Vorteil zu READ&DATA ...?

    Du brauchst keine spezielle Dekodierroutine. Übertragen des Bildschirminhalts reicht.

  • Mit der Methode kann man maximal vier Stufen in jede Richtung gehen. Die Ziffer "0" (==> -5) geht nicht, da die IF-Abfrage bei der Ziffer einen positiven Wert erwartet, die Ziffer "0" scheidet hier aus, da durch VAL(B$) sowohl Buchstaben als auch die Ziffer "0" den Wert 0 zurückgeben.

    Dadurch dass Du natürlich mehrere Ziffern für die Segmentsprünge kaskadieren kannst, kannst du (mit etwas Overhead) auch größere Stufen springen:

    Die Werte 3, 217,5 würden kodiert so aussehen: C99Q11E

    Ja, da ist deine Routine mit 32 Byte langen Segmenten und der absoluten Segmentangabe gegebenenfalls von Vorteil...

    Gruß

    Thomas

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • Mit der Methode kann man maximal vier Stufen in jede Richtung gehen. Die Ziffer "0" (==> -5) geht nicht, da die IF-Abfrage bei der Ziffer einen positiven Wert erwartet, die Ziffer "0" scheidet hier aus, da durch VAL(B$) sowohl Buchstaben als auch die Ziffer "0" den Wert 0 zurückgeben.

    Dadurch dass Du natürlich mehrere Ziffern für die Segmentsprünge kaskadieren kannst, kannst du (mit etwas Overhead) auch größere Stufen springen:

    Die Werte 3, 217,5 würden kodiert so aussehen: C99Q11E

    Ja, da ist deine Routine mit 32 Byte langen Segmenten und der absoluten Segmentangabe gegebenenfalls von Vorteil...

    Hm. Zumindest solltest du dann wohl die "5" einbinden, die im Moment, wenn ich es richtig sehe, ungenutzt bleibt. Die IF-Abfrage könnte man natürlich auch noch so erweitern, dass explizit auf "0" geprüft wird. Dann hast du immerhin eine Bewegungsfreiheit von +/- 5 Segmenten = +/- 125 Bytes, was aber halt auch für viele Fälle zu wenig ist.

    In dem Beispiel sieht man, dass die Darstellung dann sogar länger werden kann als in Hexadezimal.

    Was ich mir noch überlegt habe: Wenn man die Segmentbreite auf PETSCII 64 - 90 (= 27 Bytes) einstellt, dann hat man nicht mehr das Problem der "schwer übertragbaren Zeichen" wie Pfund und Pfeil nach oben. Wenn man den Segmentpointer jetzt absolut einstellt (0 bis 9), dann hat man auch alle 256 Bytes abgedeckt. Das letzte Segment wird dann halt nicht voll genutzt.

    Nachteil wäre, dass dann Texte nicht mehr in lesbarer Form erhalten bleiben.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Hm. Zumindest solltest du dann wohl die "5" einbinden, die im Moment, wenn ich es richtig sehe, ungenutzt bleibt. Die IF-Abfrage könnte man natürlich auch noch so erweitern, dass explizit auf "0" geprüft wird. Dann hast du immerhin eine Bewegungsfreiheit von +/- 5 Segmenten = +/- 125 Bytes, was aber halt auch für viele Fälle zu wenig ist.

    Naja, das endet dann ja wieder in einer längeren Dekodierroutine. Und ich wollte in meinem Screenshot den Speicherverbrauch so klein wie möglich halten.

    Ja, +/- 5 Segmente reicht auch nicht. Deswegen finde ich deinen Ansatz mit 8 absoluten Segmenten mit je 32 Bytes schon ganz gut (oder 10 Bereiche mit 27 Bytes, auf jeden Fall mit absoluter Segmentwahl...)

    Meine Projekte:
    Bitte melde dich an, um diesen Link zu sehen.
    Bitte melde dich an, um diesen Link zu sehen.

  • War wohl gestern ein bisschen spät. Die Leitung wurde immer länger. Ich habe erst heute verstanden wie eure Programme funktionieren.

    goloMAK Die "Idee" die ich gestern hatte läuft auf deine Lösung hinaus. Allerdings wollte ich die Ziffern 0-9 nutzen.

    0 = 0

    1-8 = Segmente 1-8 (oder wie dein 0-7)

    9 = 255

    Allerdings habe ich es heute nicht geschafft das ganze als Programm zu schreiben.

    Die Technik mit der du neue Codezeilen generierst finde ich richtig cool.:thumbup:

    Mike

    Deine Variante könnte für mein aktuelles Projekt die geeignetste sein. Sie ließ sich nicht ins VICE übertragen, weil ich nicht die Tastenkombination für RVS ON / RVS OFF finden konnte.

    Irgendwie konnte ich den erzeugten String aber nicht in einen PRINT-Befehl verpacken um es später ins Programm zu integrieren.

    Mein Ehrgeiz ist, alles in Basic zu realisieren allerdings schreit das ganze regelrecht nach einem kleinen Assembler-Loader:whistling:

    Meine VC20 Projekte:

    🕹 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. 🕹 Bitte melde dich an, um diesen Link zu sehen.

  • Ebster 9. Januar 2022 um 01:11

    Hat den Titel des Themas von „speicheroptimiertes READ-DATA“ zu „Speicheroptimiertes READ-DATA“ geändert.
  • goloMAK Die "Idee" die ich gestern hatte läuft auf deine Lösung hinaus. Allerdings wollte ich die Ziffern 0-9 nutzen.

    0 = 0

    1-8 = Segmente 1-8 (oder wie dein 0-7)

    9 = 255

    "0=0"? *grübel*

    D.h. du willst für den Wert 0 ein eigenes Zeichen reservieren?

    Die Technik mit der du neue Codezeilen generierst finde ich richtig cool.:thumbup:

    Danke! Allerdings war auch ein cooler Bug drin, nämlich die letzte Zeile wurde nicht mehr übernommen. Deswegen habe ich noch eine neue Version erstellt, die außerdem etwas übersichtlicher ist.

    Anyway, als Abschluss meiner Forschungsarbeiten lade ich hier noch drei Programme hoch:

    1.) Den altbekannten SMON. Damit habe ich meine Programme ausprobiert. Belegt den Speicherbereich 49152-53242 ($c000-$cffa).

    2.) "DATACRAM V2" erzeugt die DATA-Zeilen aus einem beliebigen Speicherbereich.

    3.) "SMON LOADER" ist der BASIC-Loader für das Beispiel SMON. Ist getestet und funktioniert.

    P.S. Der Basic-Loader umfasst jetzt 9397 Bytes. Wer sich sportlich angesprochen fühlt, kann ja versuchen, einen noch kürzeren Loader zu basteln. :)

  • Anyway, als Abschluss meiner Forschungsarbeiten lade ich hier noch drei Programme hoch:

    1.) Den altbekannten SMON. Damit habe ich meine Programme ausprobiert. Belegt den Speicherbereich 49152-53242 ($c000-$cffa).

    2.) "DATACRAM V2" erzeugt die DATA-Zeilen aus einem beliebigen Speicherbereich.

    3.) "SMON LOADER" ist der BASIC-Loader für das Beispiel SMON. Ist getestet und funktioniert.

    P.S. Der Basic-Loader umfasst jetzt 9397 Bytes. Wer sich sportlich angesprochen fühlt, kann ja versuchen, einen noch kürzeren Loader zu basteln. :)

    Selbst wenn man anstatt 32 Zeichen 128 Zeichen (Bildschirmcode, dann mit nur 2 Segmenten) verwendet, gibt es beim SMON 1856 Segmentwechsel. Nutzt man ein Zeichen ("0", "1" oder "RVS ON" "RVS OFF") für einen Segmentwechsel, benötigt man also 5947 Zeichen für den SMON. Codiert man (wie bspw. bei BASE64) konstant 3 Bytes in 4 Zeichen benötigt man 5456 Zeichen (8.2 Prozent weniger).

    Anbei ein Bitte melde dich an, um diesen Anhang zu sehen. in 6240 Bytes. Je 4 Zeichen codieren 3Bytes. Das erste Zeichen codiert drei mal zwei hochwertige Bits der folgenden 3 Bytes. Die anderen 3 Zeichen codieren jeweils die niederen 6 bits. Es werden Zeichen der PETSCII-Codes 35-98 verwendet. Das Programm läuft allerdings ca. 4 Minuten und 15 Sekunden und abtippen müssen möchte ich das nicht.

  • Je 4 Zeichen codieren 3Bytes. Das erste Zeichen codiert drei mal zwei hochwertige Bits der folgenden 3 Bytes. Die anderen 3 Zeichen codieren jeweils die niederen 6 bits. Es werden Zeichen der PETSCII-Codes 35-98 verwendet.

    Interessant, das kannte ich tatsächlich noch nicht.

    Frage: Was macht man, wenn zum Schluss z.B. 2 Bytes übrigbleiben?

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • Müsste nach DATA nicht ein Gänsefüßchen stehen ? Und hinter "Z" auch ?

    Muss nicht, nur wenn man Steuerzeichen angeben möchte. Hingegen machen etwaige BASIC-Token auch ohne Gänsefüßchen keine Probleme. DATA interpretiert alles als "String" bis zum nächsten ":" oder ",".

  • Muss nicht, nur wenn man Steuerzeichen angeben möchte. Hingegen machen etwaige BASIC-Token auch ohne Gänsefüßchen keine Probleme. DATA interpretiert alles als "String" bis zum nächsten ":" oder ",".

    Na ja... mir ist aber heute Folgendes aufgefallen:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • DATA setzt im BASIC-Interpreter das Bit 6 von $0f. Ich dachte immer, das wäre ein Quote-Flag, aber es ist eher ein DATA-Flag. Es verhindert nur die Tokenisierung von Text. Das eigentliche Quote-Flag ist $08, wenn dort der Wert $22 gespeichert ist, dann wird alles 1:1 durchgeleitet. Hinter DATA werden hingegen alle Werte ab $80 ignoriert. Und hinter REM werden sie sogar tokenisiert, was ich auch nicht wusste. Dolle Wurst.

    Aber nein, überrascht bin ich selbstredend nicht! :)

    Sample:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Bitte melde dich an, um diesen Link zu sehen. - Ratespiel • Bitte melde dich an, um diesen Link zu sehen. - BASIC-Erweiterung • Bitte melde dich an, um diesen Link zu sehen. - Sprite-Editor • Bitte melde dich an, um diesen Link zu sehen. - Zeichensatz-Editor Bitte melde dich an, um diesen Link zu sehen. - 2048 Blöcke

  • DATA setzt im BASIC-Interpreter das Bit 6 von $0f. Ich dachte immer, das wäre ein Quote-Flag, aber es ist eher ein DATA-Flag. Es verhindert nur die Tokenisierung von Text. Das eigentliche Quote-Flag ist $08, wenn dort der Wert $22 gespeichert ist, dann wird alles 1:1 durchgeleitet. Hinter DATA werden hingegen alle Werte ab $80 ignoriert. Und hinter REM werden sie sogar tokenisiert, was ich auch nicht wusste. Dolle Wurst.

    Es wird noch viel lustiger! Probier mal das aus (Achtung, die Großbuchstaben wirklich mit Shift eingeben!):

    10 rem ABCDEFG

    Und dann mach mal LIST und lass Dich überraschen :D

    Früher waren 64k unglaublich viel, heute reicht es nicht mal mehr für "Hello, world!".

  • Diese Interpreter-Routinen stammen vermutlich alle noch vom PET und da war nun mal exakt 8K Platz für den gesamten Interpreter. ;)

    Da hat man sich wegen der Ungereimtheiten sicherlich keine Gedanken gemacht.

  • Es wird noch viel lustiger! Probier mal das aus (Achtung, die Großbuchstaben wirklich mit Shift eingeben!):

    10 rem ABCDEFG

    Und dann mach mal LIST und lass Dich überraschen :D

    Schon mal 10 rem L probiert?