Wofür sollte ich in BASIC die Umwandlung von PETSCII nach Screen-Code brauchen
Es geht eigentlich um die Umwandlung von Screen-Code nach PETSCII.
Es gibt 74 Antworten in diesem Thema, welches 8.051 mal aufgerufen wurde. Der letzte Beitrag (
Wofür sollte ich in BASIC die Umwandlung von PETSCII nach Screen-Code brauchen
Es geht eigentlich um die Umwandlung von Screen-Code nach PETSCII.
Das Thread-Thema hab ich allerdings trotzdem noch nicht wirklich verstanden.
Ich versuche es mal so zu erklären, worum es Omega geht:
Es werden Zeichen mittels POKE und entsprechendem Bildschirmcode auf dem Bildschirm angezeigt. Hier im Beispiel mal links oben in der Ecke.
Bitte melde dich an, um diesen Anhang zu sehen.
Jetzt soll das Programm diese Codes vom Bildschirm auslesen (z.B. bei 1024 für das "A" die 1) und daraus selbsständig den passenden PETSCII-Code für einen String basteln. Also für die 1 aus dem Beispiel dann die 65, was man z.B. mit PRINT CHR$(65) ausgeben könnte oder als Ganzes dann eben den Inhalt des linken oberen Bildschirmecks als zwei Strings speichern, die man dann mit PRINT einfach ausgeben kann.
Bonus-Aufgabe: Ein reverses Anführungszeichen!
Also ich habe das jetzt so gelöst wie in dem Code in PostBitte melde dich an, um diesen Link zu sehen.. Lediglich bei dem inversen Anführungszeichen musste ich ein wenig tricksen,
wie Endurion ja schon angedeutet hat (da habe ich dann einfach das nachfolgende RVS ON weggelassen, damit es nicht als inverses R ausgegeben wird).
Und stichprobenartige Tests legen den Schluss nahe, dass es so funktioniert. Toll!
Ich habe mir jedenfalls gestern den ganzen Abend lang auf die Schulter geklopft und mir anerkennend (im Spiegel) zugenickt.
Danke an alle. Jetzt kann ich endlich an meinem Spiele-Superhit weiterarbeiten. Wenn er fertig ist, wird er natürlich hier im Forum veröffentlicht.
Das dauert aber noch eine Weile. Ganz schön mühsam so ein Spiel zu programmieren.
Noch eine persönliche Anekdote in diesem Zusammenhang. Was mich damals zur Erstellung der C64-Wiki-Seite "Bitte melde dich an, um diesen Link zu sehen." bewogen hat - und vor allem dem roten Hinweis "Duplicate - use CHR$(...) instead" - war u.a. folgender eigene Use-Case...
Ich habe früher den Programmer's Reference Guide als Reference genutzt und habe mich gewundert, warum z.B. eine Abfrage von Shift-Q (ausgefüllter Kreis) bei GETA$:A=ASC(A$):IFA=113THEN... nicht funktionierte.
Bitte melde dich an, um diesen Anhang zu sehen.
Dabei wäre 209 der relevante CHR$ Code, auf den es ankommt, wie der folgende Test beweist:
Bitte melde dich an, um diesen Anhang zu sehen.
Das Handbuch bildet da also nicht sauber das Kernal-Verhalten ab und unterschlägt, dass man sich nicht auf die "ASCII AND CHR$ CODES"-Tabelle verlassen kann.
Das 10-Liner-BASIC-Programm "Print is the new Poke" (2019) von will hatte die Aufgabe, Screen-Code in PETSCII-Code zu konvertieren, auch schon gelöst - und war vermutlich nicht das erste. Es ist ein Tool, das von beliebigem Code im Speicher ein PRINT-Statement erzeugt, um in einem BASIC-Programm Maschinencode oder andere Daten deutlich schneller und platzsparender an den gewünschten Ort zu bringen als es eine FOR-Schleife mit DATA-Zeilen tut. Eine Dokumentation ist auch dabei. Bitte melde dich an, um diesen Link zu sehen.
PETSCII ist eigentlich ASCII. Aber in einer Version aus den 60er Jahren.
Überall wurde das durch eine Version aus den 70ern abgelöst und dort dann natürlich immer noch ASCII genannt.PETSCII ist eine Wortschöpfung. Offiziell richtig ist schon auch am Commodore der Begriff ASCII. Aber halt irreführend
Ich muss nochmal widersprechen. ASCII und PETSCII sind nicht identisch. Leg doch einfach mal eine ASCII und eine PETSCII Tabelle nebeneinander.
Da fällt schon mal auf, dass die Codes für Groß- und Kleinbuchstaben vertauscht sind.
Wenn man zum Beispiel Daten vom C64 über die serielle Schnittstelle an einen Rechner überträgt, der mit ASCII arbeitet (zum Beispiel ein PC), dann muss man konvertieren.
ASCII wurde 1968 standardisiert. Das ist einen Norm und nicht einfach irgendein Begriff. Und selbstverständlich hat sich diese Norm nicht einfach mal so geändert.
In dieser Tabelle wird empfohlen, genau den Bereich nicht zu verwenden, der eigentlich von ASCII verwendet wird:
Bitte melde dich an, um diesen Link zu sehen.
Stattdessen soll man Codes in einem Bereich ab 192 verwenden, die es bei ASCII gar nicht gibt. Das ist ein 7-Bit-Code. ![]()
detlef : Petscii ist Ascii-1963
Das Ascii das wir kennen ist Ascii-1967
Hier Bitte melde dich an, um diesen Link zu sehen. unter Specifications
Ich hatte mich da nicht klar genug ausgedrückt ![]()
Ich muss nochmal widersprechen. ASCII und PETSCII sind nicht identisch.
Ich denke wir sollten das vor Gericht klären. ![]()
Petscii ist Ascii-1963
Aber auch ASCII-1963 hat nur 7 Bit und definiert die ganzen Commodore-spezifischen Grafikzeichen nicht?
Aber auch ASCII-1963 hat nur 7 Bit und definiert die ganzen Commodore-spezifischen Grafikzeichen nicht?
Laut Wikipedia ist es als „8-bit extended early ASCII„ klassifiziert und basiert auf Ascii-1963.
Das ist aber jetzt copy/paste Wissen
Die Zuordnung ist leider nur in eine Richtung eindeutig. ...
D.h. für einige Zeichen gibt es potentiell zwei mögliche PETSCII-Werte. Frohlock!
Ok, dann bin ich der Meinung, daß man wegen der vielen Spezialfälle "screencode2petscii()" mehr oder weniger von Hand schreiben muß:
#!/usr/bin/python
# coding: utf-8
# Table 1: https://sta.c64.org/cbm64pettoscr.html
# Table 2: https://www.c64-wiki.com/wiki/PETSCII_Codes_in_Listings
def petscii2screencode(p):
if p > 255 or p <0:
return -1
if p == 255:
return 94
a = (31, 63, 95, 127, 159, 191, 223, 254)
b = (128, 0, -64, -32, 64, -64, -128, -128)
i = 0
while p > a[i]:
i += 1
return p + b[i]
def screencode2petscii(s):
if s > 255 or s <0:
return -2
if s <= 31:
return s + 64
if s >= 32 and s <= 63:
return s
if s >= 64 and s <= 95:
return s + 32
# From table 2:
if s >= 96 and s <= 127:
return s + 96
if s >= 128 and s <= 159:
return s - 128
# From table 2:
if s == 160:
return 32
# From table 2:
if s >= 161 and s <= 191:
return s - 64
# Conflict between table 1 and 2. Using table 2:
if s >= 192 and s <= 223:
return s - 128
# From table 2:
if s >= 224 and s <= 254:
return s - 64
if s == 255:
return 94
a = "hallo welt"
print("char\tascii\tc64-screencode\tpetscii\tchrpetscii")
for i in a:
s = petscii2screencode(ord(i))
p = screencode2petscii(s)
b = (i, ord(i), s, p, chr(p))
c = []
for i in b:
c.append(str(i))
print("\t".join(c))
Alles anzeigen
Das Handbuch bildet da also nicht sauber das Kernal-Verhalten ab und unterschlägt, dass man sich nicht auf die "ASCII AND CHR$ CODES"-Tabelle verlassen kann.
Öhm ... da steht auf Seite 381 noch irgendwas von "CODES XXX-XXX SAME AS XXX-XXX" - also da wird mitnichten was unterschlagen!
Unglücklich ist allenfalls, daß in der Tabelle nicht vorzugsweise die Code-Nummern hervorgehoben sind, die entstehen wenn der KERNAL die Zeichen vom Bildschirm scannt und für CHRIN zur Verfügung stellt (mit {PI} = 255, etc.).
Dann holt man sich eben mit ASC(...) die "richtige" Code-Nummer und gut ist.
Bonus-Aufgabe: Ein reverses Anführungszeichen!
CHR$(18)CHR$(34)CHR$(20)CHR$(34)CHR$(146) ![]()
Weiss denn jemand, was der Grund sein könnte, warum das Kernal bei einem asc("Q") 209 und nicht 113 zurückgibt, so wie es in der Tabelle vorgegeben ist? Unnötig verwirrend oder technisch clever?
Weiss denn jemand, was der Grund sein könnte [...] ?
Die ge-SHIFT-eten Buchstaben haben alle das oberste Bit gesetzt. Damit bringt man die Abkürzungen von BASIC-Schlüsselworten zum Funktionieren: der Tokenizer erkennt über das gesetzte oberste Bit in der Eingabe vorzeitig ein gültiges Schlüsselwort - der dazu relevante Code steht im BASIC-ROM von $A5B8 bis $A5C3.