Darstellung von String-Zeichen im Basic Listing

64erGrufti · 7. Juni 2023

Zitat von EgonOlsen71

Bei PI? Das ROM macht das so: Ist das Zeichen PI? Dann mach $5E daraus. Dieser Fall wird auch dort explizit behandelt (bei $E7D6)...

Dann nimm $DD. Das gleiche in Grün. Angezeigt wird $5D. Diese Abweichungen sind ja nicht nur bei dem einen Zeichen.

Zitat von EgonOlsen71

Edit: Kannst du nicht einfach die Tabelle hinterlegen?

So hatte ich sogar dann angefangen. Aber als Du geschrieben hast, dass die Berechnung so einfach sei, wollte ich das natürlich mit Berechnung machen. Ist ja viel eleganter. Und wenn der C64 keine Übersetzungstabelle hat, dann müsste das ja dort auch einen Algorithmus geben. Den könnte man dann ja übernehmen, wenn man ihn kennen würde.

EgonOlsen71 · 7. Juni 2023

Naja, mein Mapping war ja nur für den speziellen Fall der Steuercodes von $80 bis $9f. Für andere Bereiche ist das anders. Was mir aber nicht wirklich klar ist: Was genau willst du wo auf was mappen?

Du hast ein BASIC-PRG? Und du machst das auf einem PC (nehme ich wegen des Zeichensatzes an)? Und dazu benutzt du einen TTF, dessen (Unicode-)Codepoints irgendwie die Commodore-Zeichen darstellen?

Dann brauchst du doch "nur" eine Übersetzungstabelle von PETSCII zu diesen Codepoints unter Berücksichtigung der Tatsache, dass manche Zeichen eben Steuercodes sind und beim LIST anders gemappt werden als beim direkten Eintippen. Ich sehe nicht, wie dich da die Funktionsweise des ROMs weiterbringen kann. Das mappt ja von PETSCII zu Bildschirmcodes und gibt die aus. Die haben doch aber mit deinem Zeichensatz nichts zu tun?

Nebenbei: Ich finde eine Mapping-Tabelle nicht so tragisch. Ist immerhin flexibel, d.h. ein anderer Zeichensatz mit ggf. anderem Mapping braucht nur eine neue Tabelle. Ist doch eigentlich ganz schlau...

EgonOlsen71 · 7. Juni 2023

Ich kann den von dir verlinkten Font leider nicht laden, mein Netzwerk blockiert den Zugriff auf diese Seite (https hin oder her). Ich habe mal einen anderen namens PetMe64.ttf hergenommen und schnell was in Java zusammengehauen, um zu testen, wie da die Zeichenverteilung ist. Turns out: Irgendwie! Passt so halb, aber nicht so richtig.

Aber letztendlich scheint ein Mapping nicht schwer. Bei den Steuerzeichen musste ich gar nichts machen, die passten einfach (bis auf RVS ON). Bei geshifteten Buchstaben musste ich -96 machen, damit es passt. Dann habe ich aufgehört. Also wenn ich richtig verstanden habe was du machst, dann habe ich das Gefühl, du musst das individuell auf deinen Ausgabefont mappen. Und was das ROM da macht oder nicht macht, sollte wurscht sein.

Sah so aus:

64erGrufti · 7. Juni 2023

Zitat von EgonOlsen71

Dann brauchst du doch "nur" eine Übersetzungstabelle von PETSCII zu diesen Codepoints unter Berücksichtigung der Tatsache, dass manche Zeichen eben Steuercodes sind und beim LIST anders gemappt werden als beim direkten Eintippen. Ich sehe nicht, wie dich da die Funktionsweise des ROMs weiterbringen kann. Das mappt ja von PETSCII zu Bildschirmcodes und gibt die aus. Die haben doch aber mit deinem Zeichensatz nichts zu tun?

Nein, ganz so einfach ist es nicht. In der Font sind ja auch die beiden Zeichensätze für Groß-/Kleinschreibung drin. Mag sein, dass es andere Fonts gibt, die das anders machen. Der Link den ich gepostet hatte, war die Ansicht mit den Infos zu den Codes. Die Font selbst kannst Du hier runter laden. Vielleicht wird die Seite ja nicht geblockt. Die Vorschau wird vermutlich geblockt, weil Javascript von anderen Seiten geladen wird. Das musst Du zulassen.

1570 · 7. Juni 2023

Ein PRG-nach-HTML-Printer mit dem Style-Font ist in Crank the PRINT schon integriert:

https://github.com/c1570/Crank…a4e7e4/cranktheprint#L177

PETSCII-nach-Screencode passiert dort in Zeile 239.

Das Ergebnis davon sieht dann zum Beispiel so aus:

https://c1570.github.io/GoldQuest6/gq6_de.html

EgonOlsen71 · 7. Juni 2023

Zitat von 64erGrufti

Die Vorschau wird vermutlich geblockt, weil Javascript von anderen Seiten geladen wird. Das musst Du zulassen.

Ich habe kein Problem mit Javascript, aber die blöde Firewall mag die Seite style64.org nicht, weil sie "Malware" enthält. Ist vermutlich ein false positive, aber ist halt so...

Zitat

Nein, ganz so einfach ist es nicht. In der Font sind ja auch die beiden Zeichensätze für Groß-/Kleinschreibung drin.

Dürfte ja nur ein allgemeiner Offset sein, wenn der Fontersteller das vernünftig gemacht hat.

EgonOlsen71 · 7. Juni 2023

Zitat von 64erGrufti

Nein, ganz so einfach ist es nicht. In der Font sind ja auch die beiden Zeichensätze für Groß-/Kleinschreibung drin.

Eben mit 1570 s Code (nach Java portiert) ausprobiert, funktioniert astrein mit dem Font (hatte den schon auf der Platte...).

Großschrift:

Code

private char translate(char c) {
int sc = c!=255?(new int[]{0x80, 0x20, 0x00, 0x40, 0xC0, 0x60, 0x40, 0x60}[c >> 5] + (c & 0x1f)):94;
return (char) (0xee00|sc);
}

Kleinschrift:

Code

private char translate(char c) {
int sc = c!=255?(new int[]{0x80, 0x20, 0x00, 0x40, 0xC0, 0x60, 0x40, 0x60}[c >> 5] + (c & 0x1f)):94;
return (char) (0xef00|sc);
}

...da ist nur der Offset anders, 0xEF00 statt 0xEE00. In welcher Sprache machst du das denn?

64erGrufti · 7. Juni 2023

Das scheint zu passen. Ist aber auch etwas aufwändiger, als die ganze Zeit angegeben.

EgonOlsen71 · 7. Juni 2023

Zitat von 64erGrufti

Das scheint zu passen. Ist aber auch etwas aufwändiger, als die ganze Zeit angegeben.

Naja, weil am Anfang auch nicht klar war, was du überhaupt machen willst. Zumindest ich ging davon aus, dass du irgendwas mit "PETSCII -> Screen Codes" machen wolltest. Aber eigentlich wolltest du "PETSCII -> Unicode für einen bestimmten Zeichensatz" machen und das war mir überhaupt nicht klar. Daher die völlig unnötigen Schlenker in Richtung ROM und Co. Und so aufwändig ist das auch wieder nicht, es ist nur schlecht zu lesen. Eine Alternative wären lauter IFs mit der entsprechenden Bereichsprüfung. Das wäre viel länger und nicht so cool aber evtl. besser verständlich.

goloMAK · 7. Juni 2023

Zitat von 64erGrufti

10 print"{Commodore+4}"
Dann erscheint im Basic-Listing das Dreieck (PETSCII $7F). An der Speicherstelle steht aber in Wirklichkeit eine $9F. Nach welcher Übersetzungstabelle wird das dargestellt?

Der Commodore +4 war meines Wissens eine Nullnummer. Da kann also etwas nicht stimmen.

64erGrufti · 7. Juni 2023

Zitat von goloMAK

Der Commodore +4 war meines Wissens eine Nullnummer. Da kann also etwas nicht stimmen.

Das haben wir ja schon lange geklärt.

Jedenfalls haben die Tests gezeigt, dass die Anzeige in Vice mit der meines Programms sowohl in Groß- wie auch Kleinschreibung überein stimmt. Sogar besser als mit dem Programm, was zu Schriftart gehört

Also, danke an 1570 für die Formel. Die hätte ich so nie hin bekommen, ist aber genial gelöst. Mit solchen "Kompaktformeln" habe ich immer Probleme. Im Endeffekt macht sie genau das, was ich aus der Tabelle von Hand gemacht habe, wo ich die 256 Bytes blockweise händisch in eine Übersetzungstabelle geholt habe.

Edit: Jetzt habe ich aber nochmal ne andere Frage. Wie setze ich den Beitrag auf gelöst? Ich finde da gar nichts.

64erGrufti · 7. Juni 2023

OK, jetzt hat zwar irgendjemand den Beitrag auf "erledigt" gesetzt, aber ich fände es trotzdem für die Zukunft interessant, wie man das selbst macht. Oder kann das nur ein Moderator?

1570 · 7. Juni 2023

Die Umwandlungsroutine ist übrigens auch nur aus dem 6502-ASM von hier screencodes vs. PetASCII übernommen.

64erGrufti · 8. Juni 2023

Zitat von 1570

Die Umwandlungsroutine ist übrigens auch nur aus dem 6502-ASM von hier screencodes vs. PetASCII übernommen.

Wenn man in Assembler so fit ist, geht das. Deine Version ist verständlicher für mich.