Wird ja immer spannender.
Hello, Guest the thread was viewed4.2k times and contains 53 replies
last post from 64erGrufti at the
Darstellung von String-Zeichen im Basic Listing
- 64erGrufti
- Thread is marked as Resolved.
-
-
Wird ja immer spannender.
Eine große Tüte Popcorn ist meist günstiger als zwei kleine, nur mal so als Tipp
-
Aber warum?
Weil ich mit Peek aus der Speicherstelle auslese. Und da bekomme ich ja genau das zurück, was in der Speicherstelle steht (im Beispiel $9F, oder dez. 159). Ich weiß ehrlich gesagt nicht, was Peek mit dem angezeigten Zeichen 223 zu tun hat. Das bekomme ich doch mit Peek gar nicht zu sehen.
-
Vielleicht ist es noch nicht so rausgekommen:
BASIC speichert die Zeichen in Strings in PETSCII. Die werden beim Ausführen von PRINT in die tatsächlichen Zeichencodes (=Bildschirmcodes) umgewandelt, bzw. die Steuerzeichen (Farbe, Cursor, etc.) gesondert behandelt, d.h. ausgeführt.
Warum zum Geier das auch gemacht wurde, man hat auf jeden Fall nicht den gleichen Wert.
Die Kontrollzeichen wären sonst ja nicht verwendbar, und man könnte nicht alle 256 Zeichen aus dem Zeichensatz benutzen.
-
BASIC speichert die Zeichen in Strings in PETSCII. Die werden beim Ausführen von PRINT in die tatsächlichen Zeichencodes (=Bildschirmcodes) umgewandelt, bzw. die Steuerzeichen (Farbe, Cursor, etc.) gesondert behandelt, d.h. ausgeführt.
Ja, und dann kommt beim LIST-Befehl die dritte Zeichentabelle zum tragen (wie von wizball6502 zusammen getragen). Warum man da noch eine dritte Tabelle ins Leben gerufen hat ist natürlich die Frage. Und vor allem, nach welchem Schema das übersetzt wird? Ich gehe ja mal davon aus, dass das nicht durch eine einfache Tabelle gemacht wird. Die würde ja viel zu viel Speicher fressen. Aber zumindest habe ich mal eine Tabelle nach der ich nun arbeiten kann.
-
Es gibt keine einzige Zeichentabelle im ROM. Ist auch nicht notwendig.
-
Die Ausgabe der Steuerzeichen beim List erfolgt durch explizites Setzen von Bit 6 und 7 (nur nötig, weil das vorher gelöscht wurde) im jeweiligen Zeichen (in $e82e bzw. $e697). Das wird für alle Zeichen im Bereich von $80-$9f gemacht.
Du kannst das manipulieren, z.B. so:
Danach wird statt Bit 6 Bit 5 für die Ausgabe gesetzt und es erscheinen andere Zeichen.
-
Es gibt keine einzige Zeichentabelle im ROM. Ist auch nicht notwendig.
Das ist ja schon meine Vermutung. Die Frage war halt nur, nach welchem Algorithmus.
Die Ausgabe der Steuerzeichen beim List erfolgt durch explizites Setzen von Bit 6 und 7
Das passt aber im Beispiel nicht so ganz:
Das angezeigte Zeichen existiert ja 2x in der PETSCII-Tabelle. Aber bei $7F sind 3 Bits geändert, bei $DF ist es 1 Bit. Wobei da noch das Reverse fehlt. Ich weiß jetzt nicht, wie das zustande kommt.
-
Das angezeigte Zeichen existiert ja 2x in der PETSCII-Tabelle. Aber bei $7F sind 3 Bits geändert, bei $DF ist es 1 Bit. Wobei da noch das Reverse fehlt. Ich weiß jetzt nicht, wie das zustande kommt.
Ja stimmt, das Zeichen wird mit RVSON ausgegeben.
-
Also genauer: Wir reden an der Stelle nicht mehr vom PETSCII-Code, sondern vom Bildschirmcode. Der ist $DF/223 und das ist dann das Zeichen, was du siehst...also quasi das inverse Zeichen zu CHR$(223). Diese Umwandlung muss irgendwo vorher stattfinden, dass habe ich jetzt nicht angeschaut.
Aber: Wozu brauchst du das eigentlich genau? Nur so aus Interesse...?
-
Es gibt keine einzige Zeichentabelle im ROM.
Aber (vier) Zeichen-Zuordnungstabellen, die vier Adressen stehen $eb79 und folgen gleich darauf (ab $eb81). Hiermit wird den Tasten ein eindeutiger Code mitgegeben, aus dem dann die weiteren Kodierungen zugeordnet werden (PETSCII, Bildschirmcode).
Arndt
Edit: Mit diesem TSB-Programm kann man sich alle Zeichen, die man von der Tastatur aus erreichen kann, anzeigen lassen.
-
Also genauer: Wir reden an der Stelle nicht mehr vom PETSCII-Code, sondern vom Bildschirmcode. Der ist $DF/223 und das ist dann das Zeichen, was du siehst...also quasi das inverse Zeichen zu CHR$(223). Diese Umwandlung muss irgendwo vorher stattfinden, dass habe ich jetzt nicht angeschaut.
Nicht ganz. Der Bildschirmcode ist teilweise scheinbar auch wieder ein anderer (zumindest wenn ich mir die vorherige Tabelle und Bildschirmcodes so ansehe)
Aber: Wozu brauchst du das eigentlich genau? Nur so aus Interesse...?
Ich schreibe gerade einen Viewer für Basic-Programme. Und die sollen ja korrekt dargestellt werden.
-
Nicht ganz. Der Bildschirmcode ist teilweise scheinbar auch wieder ein anderer (zumindest wenn ich mir die vorherige Tabelle und Bildschirmcodes so ansehe)
Jetzt hast du mich auch verwirrt...
Also, nochmal geschaut: Im Speicher steht 159/$9F, der ASCII-Code für das Steuerzeichen CYAN. Der wird mit $40 geORt, weil er zwischen $80 und $9F liegt und das wird dann (als Bildschirmcode 223/$DF) direkt in den (Bildschirm)-Speicher geschrieben. Das ist eigentlich der ganze Zauber.
-
Vielleicht kommt hier noch etwas Verwirrung dazu, weil einige PETSCII-Codes wiederholt werden, und auf das gleiche Bildschirm-Zeichen mappen. Man kann im BASIC, wenn man es nicht normal eingibt, PETSCII-Werte einsetzen, die man normalerweise nicht reinkriegt.
-
Es gibt keine einzige Zeichentabelle im ROM.
Aber (vier) Zeichen-Zuordnungstabellen, die vier Adressen stehen $eb79 und folgen gleich darauf (ab $eb81). Hiermit wird den Tasten ein eindeutiger Code mitgegeben, aus dem dann die weiteren Kodierungen zugeordnet werden (PETSCII, Bildschirmcode).
Das sind aber Keyboard-Tabelle. Die Umwandlung von Basic/String-Codes in Bildschimrcodes wird doch berechnet.
-
Ja, aber keine kompletten Zeichentabellen. Das meinte ich.
Schon klar. Man sollte aber bei solchen Aussagen immer die User im Auge haben, die nicht tiefer ins Thema eingestiegen sind. Könnte ja zu Verwirrung führen, deshalb meine Ergänzung.
Ich hab meinen Post #31 noch mit einem Edit ergänzt, vielleicht kann 64erGrufti damit was anfangen.
Arndt
-
Also, nochmal geschaut: Im Speicher steht 159/$9F, der ASCII-Code für das Steuerzeichen CYAN. Der wird mit $40 geORt, weil er zwischen $80 und $9F liegt und das wird dann (als Bildschirmcode 223/$DF) direkt in den (Bildschirm)-Speicher geschrieben. Das ist eigentlich der ganze Zauber.
Jaa, jetzt sind wir ganz woanders. Du hast vorhin geschrieben
Die Ausgabe der Steuerzeichen beim List erfolgt durch explizites Setzen von Bit 6 und 7 (nur nötig, weil das vorher gelöscht wurde)
$40 ist aber NUR Bit6. Dann passt es. Bit7 ist bei meinem Beispielzeichen eh gesetzt, wurde also vorher nicht gelöscht.
-
$40 ist aber NUR Bit6. Dann passt es. Bit7 ist bei meinem Beispielzeichen eh gesetzt, wurde also vorher nicht gelöscht.
In der Kernal-Routine wird es das...und dann wieder gesetzt. Kann man aber ignorieren, weil ist halt egal...
-
Anderes Beispiel: Ich habe $DE in der Datei. Das ist ein Pi in Basic.
Schaue ich in der Tabelle von wizball6502 nach, so komme ich auf $5E als Zeichen zum anzeigen. Das passt mit der Schriftart auch. Aber rechnerisch komme ich nicht drauf. Jedes Mal wenn ich denke, ich habe was gefunden, passt es woanders nicht. Die Tabelle stellt das alles korrekt auch passend zur Schriftart dar. Aber wie lautet die Rechenvorschrift dahinter?
Bei PI? Das ROM macht das so: Ist das Zeichen PI? Dann mach $5E daraus. Dieser Fall wird auch dort explizit behandelt (bei $E7D6)...
Edit: Kannst du nicht einfach die Tabelle hinterlegen?
