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.
Posts by 64erGrufti
-
-
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?
-
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.
-
Das scheint zu passen. Ist aber auch etwas aufwändiger, als die ganze Zeit angegeben.
-
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.
-
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.
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.
-
Also irgendwie krieg ich langsam nen Knoten im Hirn. Ich bekomme keine einfache Rechenvorschrift hin.
Ich lese die Bytes aus der Datei. Dann habe ich diese Schriftart, mit der ich das darstellen will.
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?
-
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.
-
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.
-
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.
-
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.
-
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.
-
Ich möchte noch etwas zur Diskussion beitragen:
https://www.c64-wiki.com/wiki/PETSCII_Codes_in_Listings
Die Seite hatte ich mal zusammengestellt, als ich ähnliche Fragen hatte.
In der ersten Spalte ist der Bildschirmcode, in der zweiten, was auf dem Bildschirm sichtbar ist und in der dritten der CHR$ code. Alles auf einen Blick. Interessante Erkenntnis war für mich noch, dass die CHR$ Codes 224-254 nicht benutzt werden sollten, da es zu Misstverständnissen kommen kann (z.B. bei GET A$).Sprich: Du kannst das Dreieck mit CHR$ nicht erzeugen. Es dient dort als Steuercode für die Farbe Cyan.
Nicht schlecht die Tabelle. Allerdings verstehe ich die Beschriftungen nicht so ganz und weiß nicht, ob der Treffer nur Zufall ist.
Wie in meinem Beispiel gezeigt, wird $9F als das Dreieck im Basic-Listing dargestellt. Laut Deiner Tabelle wäre das $DF als Peek-Code und $9F als ASC-Code. Das stimmt ja soweit überein, aber das, was in der Speicherstelle ja wirklich drin steht, ist ja das $9F. Ich würde aber als das, was in der Speicherstelle drin steht, als PEEK-Code von der Bezeichnung her verstehen. Zumindest scheint es (außer mit $00) in diese Richtung zu passen.
-
Nein, ist es nicht:
Das ist ja nur die inverse Variante. Aber trotzdem entspricht es nicht dem eigentlichen PETSCII-Code für den Wert im Speicher.
Wie immer haben wir doch alles da:
Umwandlung Bildschirmcodes in Ascii
ASCII-Codes in Bildschirmcodes umrechnen (und umgekehrt)?Leider ist es das nicht. Die Bildschiemcodes siend wieder anders. Wenn man mal $9F in den Bildschirmspeicher schreibt, kommt wieder ein anderes Zeichen raus.
-
Display More
Genau das ist es. Das dargestellte Dreieck ist aber PETSCII $7F. Aber laut welcher Übersetzungstabelle geschieht das?
Edit: Bei der $97 ist das genau das gleiche. Das in Basic dargestellte Kreissymbol ist $77
-
Und so steht das auch im Speicher. Irgendwie hast du da dich da vielleicht einfach vertippt?
Nein, wie Mac Bacon schon schrieb, das habe ich im Vice probiert und wird am C64 nicht Commodore, sondern Control sein. Jedenfalls das Zeichen für Cyan.
-
und ich nehme an, dass Du VICE benutzt
Ja stimmt, hatte ich jetzt zum probieren benutzt.
Wenn Du einfach PRINT ASC("{Steuerzeichen}") eingibst, bekommt Du den korrekten Code ausgegeben.
Da bekomme ich auch nur 159 angezeigt, was auch wieder nur $9F ist. Meine Frage ist aber, wie komme ich auf das Zeichen, was am Bildschirm im Endeffekt angezeigt wird? Nach welcher Übersetzungstabelle läuft das?
-
Ich hoffe dass ich hier in dem Bereich halbwegs richtig mit dem Thema bin.
Ich kriege die Brücke von Hex zur Darstellung im Basic-Listing nicht hin. Wenn ich z.B. ein Basic Programm mit Sonderzeichen schreibe:
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?
-
Wenn ich mir das Video aus Post #11 anhöre und das, was mein 6581 raus bringt, so sind da schon Welten dazwischen.
Gut, ob der Ton aus dem Video wirklich von einem 6581 stammt, auf diese Aussage muss man natürlich vertrauen. Aber man hört auf jeden Fall den Unterschied extrem deutlich.
Ab wann man einen Chip als "defekt" bezeichnet ist auch Betrachtungssache. Es kommt immer auf den Qualitätsanspruch eines Herstellers an, was er nach der Produktion verschrottet und was er verkauft. Da ist jeder Hersteller anders.
Ich habe gerade letzte Woche von Märklin-Gleisen gehört, die Märklin nicht mehr verkaufen wollte, weil die Weichmacher-Mischung nicht ihren Ansprüchen genügte. Die Gleise wurden dann günstig abgegeben und sind auf dem Flohmarkt gelandet. Sind diese nun defekt oder nicht? Für Märklin ja, für den Flohmarkthändler wohl nicht. Diese haben dann übrigens mit der Zeit Probleme gemacht. Es war also nicht so, dass sie der Qualität der von Märklin verkauften entsprachen. Grundlegend funktionierten sie aber erstmal.
Wenn ein Chip gar nichts raus bring, dann sind sich wohl alle einig, dass dieser als "defekt" zu bezeichnen ist. Aber irgendwann kommt man in einen Bereich, wo es einfach Ansichtssache ist. Der ein oder andere hätte die Chips mit "kaputtem" Sound wohl verschrottet, Commodore hatte wohl nicht einen so großen Qualitätsanspruch. Ausschuss gibt es durch Toleranzen in jeder Produktion. Es liegt jetzt nur am Hersteller zu entscheiden, wo der Ausschuss anfängt.
-
Leider ist mir noch kein Panasonic in die Finger gekommen. Vielleicht habe ich ja irgendwann mal Glück.
