Schon mal 10 rem L probiert?
Das ist auch lustig, darauf kommt man von selber, wenn man halt weiter macht nach dem G ![]()
Es gibt 54 Antworten in diesem Thema, welches 8.639 mal aufgerufen wurde. Der letzte Beitrag (
Schon mal 10 rem L probiert?
Das ist auch lustig, darauf kommt man von selber, wenn man halt weiter macht nach dem G ![]()
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
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. ![]()
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.
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. ![]()
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.
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.
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. ![]()