Speicheroptimiertes READ-DATA

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

  • Schon mal 10 rem L probiert?

    Das ist auch lustig, darauf kommt man von selber, wenn man halt weiter macht nach dem G ;)

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

  • 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

    Ein ähnliches Beispiel hatte ich ja auch in meinem Sample. Wobei meine Formulierung nicht ganz treffend war: Hinter REM werden Bytes bei der Eingabe tatsächlich einfach ungeprüft übernommen und dann von LIST als Token interpretiert. Wenn sich kein passendes Token findet, wirft LIST interessanterweise einen Syntax Error.

    Also:

    10 rem HIJK

    lässt sich LISTen

    10 rem HIJKL

    wirft einen SYNTAX ERROR. Es sei denn, man hat eine BASIC-Erweiterung mit zusätzlichen Tokens, dann werden die wieder gelistet. :)

    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

  • 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?

    Eigentlich wollte ich BASE64 nutzen, aber in Basic Bits zu shiften ist kein Spaß. Daher habe ich mir diese Aufteilung überlegt.

    Ist die Anzahl der zu codierenden Bytes nicht durch drei teilbar, so spendiert BASE64 ein eigenes Zeichen ("=") um wieder auf 4 Zeichen zu kommen. Endet der letzte Viererblock mit zwei "=", dann ist nur ein Byte darin codiert, endet er mit einem "=", sind zwei Byte codiert.

    Wenn der Dekodierer weiß wieviele Bytes zu erwarten sind, kann man aber auch einfach die letzten Bytes beliebig (z.B. mit 0) zu einer Dreiergruppe auffüllen.

  • 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:

    Mit "Steuerzeichen" sind im Grunde alle Zeichen gemeint, die im Großschriftmodus nicht Standard-ASCII-Zeichen ergeben. Ein Shift+A hat z. B. den Code 193. Über die Tastatur kann man, würde ich meinen, das entsprechenden ASCII-Zeichen mit Code 97 nicht eingeben (also "A"), auch wenn als CHR$(97) darstellbar ist (das Zeichen am Bildschirm wird aber immer als Code 193 gelesen).

  • Ein ähnliches Beispiel hatte ich ja auch in meinem Sample. Wobei meine Formulierung nicht ganz treffend war: Hinter REM werden Bytes bei der Eingabe tatsächlich einfach ungeprüft übernommen und dann von LIST als Token interpretiert. Wenn sich kein passendes Token findet, wirft LIST interessanterweise einen Syntax Error.

    [..]

    Daher wählt der vorsichtige BASIC-Programmierer bei "komplexen" Kommentaren auch besser die Syntax

    10 rem "Das ist ein Kommentar mit Klein- und Grossschreibung"

    ;)

  • kein passendes Token findet, wirft LIST interessanterweise einen Syntax Error

    REM{SHIFT-L} war damals ein ganz üblicher "Listschutz", und z.B. das Final Cartridge 3 hat auch damit geworben, das zu fixen.

    Bitte melde dich an, um diesen Link zu sehen. - Bitte melde dich an, um diesen Link zu sehen.

  • Daher wählt der vorsichtige BASIC-Programmierer bei "komplexen" Kommentaren auch besser die Syntax

    10 rem "Das ist ein Kommentar mit Klein- und Grossschreibung"

    ;)

    Der vorsichtige BASIC-Programmierer verwendet gar keine Großschrift außerhalb von String-Konstanten. :D

    Für mich ist immer wichtig, dass der Programmcode sowohl im Gross/Klein- als auch im Grafik-Modus lesbar ist.

    Das kommt aber daher, dass ich eher auf dem PET programmiere und da arbeitet man häufiger im Grafik-Modus, weil man PETSCII-Grafiken im Programm verwendet.

  • Eigentlich wollte ich BASE64 nutzen, aber in Basic Bits zu shiften ist kein Spaß.

    Warum? Leftshift geht so: (a and 127)*2; Rightshift so: (a and 254)/2. Größere Schrittweiten gehen analog. Dabei werden zwar intern Flootingpoint-Zahlen benutzt, aber meines Erachtens sind die in dem Bereich, der hier gebraucht wird, exakt. Man sollte die Zweierpotenzen allerdings nicht mit ^ berechnen. Das könnte möglicherweise Rundungsfehler verursachen.

  • Eigentlich wollte ich BASE64 nutzen, aber in Basic Bits zu shiften ist kein Spaß. Daher habe ich mir diese Aufteilung überlegt.

    Welche Aufteilung? Jetzt bin ich verwirrt. Die Codierung in deinem Programm *war* doch BASE64? Ich habe mal die ersten Bytes von Hand nachgerechnet, und es hat genau gepasst.

    Ist die Anzahl der zu codierenden Bytes nicht durch drei teilbar, so spendiert BASE64 ein eigenes Zeichen ("=") um wieder auf 4 Zeichen zu kommen. Endet der letzte Viererblock mit zwei "=", dann ist nur ein Byte darin codiert, endet er mit einem "=", sind zwei Byte codiert.

    Ok, danke, da werde ich noch weiterrecherchieren. :)

    REM{SHIFT-L} war damals ein ganz üblicher "Listschutz", und z.B. das Final Cartridge 3 hat auch damit geworben, das zu fixen.

    Tatsächlich kannte ich diesen "Trick", habe aber anscheinend die Querverbindung nicht gesehen. Dass er hinter REM jetzt tatsächlich Schlüsselwörter auflistet, hat mich dann doch verblüfft.

    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

  • Mit "Steuerzeichen" sind im Grunde alle Zeichen gemeint, die im Großschriftmodus nicht Standard-ASCII-Zeichen ergeben. Ein Shift+A hat z. B. den Code 193. Über die Tastatur kann man, würde ich meinen, das entsprechenden ASCII-Zeichen mit Code 97 nicht eingeben (also "A"), auch wenn als CHR$(97) darstellbar ist (das Zeichen am Bildschirm wird aber immer als Code 193 gelesen).

    Hm. Eigentlich sind Steuerzeichen solche, die eine Aktion des Computers veranlassen, z.B. Bildschirm löschen, Cursor positionieren, Beep ausgeben usw.

    Ein

    10 rem ACHTUNG: Ab hier nicht mehr editieren!

    ... stellt eigentlich kein logisches Problem dar. Das Wahrscheinlichste ist, dass der Tokenizer noch komplizierter geworden wäre, als er ohnehin schon ist, wenn man das auch noch berücksichtigt hätte. Man darf halt nie vergessen, dass der ganze shizzle nur 8 KByte groß ist.

    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

  • Mit "Steuerzeichen" sind im Grunde alle Zeichen gemeint, die im Großschriftmodus nicht Standard-ASCII-Zeichen ergeben. Ein Shift+A hat z. B. den Code 193. Über die Tastatur kann man, würde ich meinen, das entsprechenden ASCII-Zeichen mit Code 97 nicht eingeben (also "A"), auch wenn als CHR$(97) darstellbar ist (das Zeichen am Bildschirm wird aber immer als Code 193 gelesen).

    Hm. Eigentlich sind Steuerzeichen solche, die eine Aktion des Computers veranlassen, z.B. Bildschirm löschen, Cursor positionieren, Beep ausgeben usw.

    Ein

    10 rem ACHTUNG: Ab hier nicht mehr editieren!

    ... stellt eigentlich kein logisches Problem dar. Das Wahrscheinlichste ist, dass der Tokenizer noch komplizierter geworden wäre, als er ohnehin schon ist, wenn man das auch noch berücksichtigt hätte. Man darf halt nie vergessen, dass der ganze shizzle nur 8 KByte groß ist.

    Ich hab nur salopp "Steuerzeichen" geschrieben und eben damit nicht vom Bildschirmeditor irgendwie anders interpretierten Zeichen gemeint. Bitte jetzt nicht auf die Goldwaage legen. ;)

    Aus meiner Sicht ist der Tokenizer hier minder implementiert. Könnte man auch als Bug ansehen. Das trifft speziell bei CBM-BASIC eine Rolle, wo ein Bildschirmeditor zusammen mit Möglichkeit besondere Zeichen per Tastatur zu generieren. Andere MS-BASIC-Ableger kommen da erst gar nicht in Verlegenheit (wie etwa das Extended Color BASIC auf einem Dragon oder Color Computer).

  • Warum? Leftshift geht so: (a and 127)*2; Rightshift so: (a and 254)/2. Größere Schrittweiten gehen analog. Dabei werden zwar intern Flootingpoint-Zahlen benutzt, aber meines Erachtens sind die in dem Bereich, der hier gebraucht wird, exakt. Man sollte die Zweierpotenzen allerdings nicht mit ^ berechnen. Das könnte möglicherweise Rundungsfehler verursachen.

    Eben, genau dieses Umherschieben der der 6er-Bit-Gruppen in oder aus Binärdaten ist aufwändig und langsam. Es hat ja keiner gesagt, dass man nicht wüsste wie es ginge. ;)

  • Eigentlich wollte ich BASE64 nutzen, aber in Basic Bits zu shiften ist kein Spaß. Daher habe ich mir diese Aufteilung überlegt.

    Welche Aufteilung? Jetzt bin ich verwirrt. Die Codierung in deinem Programm *war* doch BASE64? Ich habe mal die ersten Bytes von Hand nachgerechnet, und es hat genau gepasst.

    BASE64 codiert auch drei Bytes in vier (6Bit-)Zeichen, aber das erste Zeichen enthält die ersten 6 Bit des ersten Bytes. Das zweite Zeichen enthält die restlichen 2 Bits des ersten Bytes und die ersten 4 Bits des zweiten Bytes. Das dritte Zeichen enthält die letzten 4 Bits des zweiten Bytes und die ersten 2 Bits des dritten Bytes. Das letzte Zeichen enthält dann die letzten 6 Bits des dritten Bytes.

    Das war mir zuviel Bitgeschubse. In "meiner" Codierung verschiebe ich nur im ersten Zeichen um jeweils zwei Bit.

  • Warum? Leftshift geht so: (a and 127)*2; Rightshift so: (a and 254)/2. Größere Schrittweiten gehen analog. Dabei werden zwar intern Flootingpoint-Zahlen benutzt, aber meines Erachtens sind die in dem Bereich, der hier gebraucht wird, exakt. Man sollte die Zweierpotenzen allerdings nicht mit ^ berechnen. Das könnte möglicherweise Rundungsfehler verursachen.

    Eben, genau dieses Umherschieben der der 6er-Bit-Gruppen in oder aus Binärdaten ist aufwändig und langsam. Es hat ja keiner gesagt, dass man nicht wüsste wie es ginge. ;)

    Achso. Ich hatte "ist kein Spaß" so aufgefasst, dass du damit meintest, dass es schwer zu programmieren sei. Du meintest aber, dass das Ergebnis langsam ist. Klassisches Missverständnis. ^^

  • BASE64 codiert auch drei Bytes in vier (6Bit-)Zeichen, aber das erste Zeichen enthält die ersten 6 Bit des ersten Bytes. Das zweite Zeichen enthält die restlichen 2 Bits des ersten Bytes und die ersten 4 Bits des zweiten Bytes. Das dritte Zeichen enthält die letzten 4 Bits des zweiten Bytes und die ersten 2 Bits des dritten Bytes. Das letzte Zeichen enthält dann die letzten 6 Bits des dritten Bytes.

    Das war mir zuviel Bitgeschubse. In "meiner" Codierung verschiebe ich nur im ersten Zeichen um jeweils zwei Bit.

    Ah, in dem Fall hatte ich einfach "dein" Format irrtümlich mit BASE64 gleichgesetzt. Das BASE64-Format scheint mir auch erheblich komplizierter als deine Methode, ohne dass ich im Moment einen Vorteil erkennen könnte. Aber vielleicht gibt es ja einen, den ich nur nicht sehe. :/

    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