Hallo Besucher, der Thread wurde 2,6k mal aufgerufen und enthält 9 Antworten

letzter Beitrag von GenerationCBM am

PETSCII in BASIC Listings - Neue Übersichtstabelle im C64-Wiki

    Liebe Forum64-Freunde


    Nach meinem ersten C64-Wiki-Beitrag zu dem nützlichen Checksummen-Tool "F64Summer" ( https://www.c64-wiki.com/wiki/F64Summer ) hat mich die Wiki-Lust gepackt. Ich habe nun noch einen weiteren Eintrag im C64-Wiki vorgenommen Auch dieses Mal ging es mir um den leichteren Umgang mit BASIC Listings.


    Bei der neuesten C64-Wiki Seite geht es um die Klartext-Bezeichnungen von PETSCII-Zeichen, wie sie in BASIC-Listings zu finden sind. Da es keinen einheitlichen Standard gibt und die "Tokenizer"-Tools ihren eigenen Spielraum für PETSCII-Interpretationen festgelegt haben, kann die Übersicht dem einen oder anderen helfen, herauszufinden, welches Zeichen den gemeint ist (z.B. wenn im BASIC Listing nur {148} steht).


    Hier der Link dazu: https://www.c64-wiki.com/wiki/PETSCII_Codes_in_Listings


    Ich wäre dankbar, wenn ihr da bei Gelegenheit mal drüberschauen könnt, für den Fall, dass da noch Fehler dabei sind. Die deutsche Version folgt dann, sobald die englische Seite in trockenen Tüchern ist. Auch wäre nett, wenn mir jemand mit deutschem Tastatur-Layout sagen könnte, welche Tasten-Shortcuts (für die VICE-Spalte) standardgemäss zum Einsatz kommen - z.B. beim Zeichen CHR$(192) bzw. (CHR$(223).


    Das TOK64 hätte ich auch noch gerne dazugenommen, leider konnte ich kein lauffähiges TOK64.EXE finden, dass auf einem Windows10 64-Bit rechner läuft. Und selbst ein Binary zu kompilieren war mir zu aufwendig. Auch kann das sein, dass der Umfang der unterstützten PETSCII-Zeichen beim TOK64 eher auf der sparsameren Seite liegt?


    Ich zumindest finde die BasText-Grundlage die beste Implementierung bisher. Bin aber dankbar für jedwelche Anregunen oder Argumente, die mich anderweitig überzeugen können. :saint:

    Zitat von JeeK

    Reicht für TOK64 nicht die Doku TOK64.TXT? Oder ist das unvollständig?

    Vielen Dank für das Feedback. Das ist ein Anfang, aber ich hätte gerne Bestätigung, ob sich dies dann auch so manifestiert in der aktuellen Version. Auch möchte ich gerne überprüfen, wie das Tool mit den anderen Zeichen umgeht, die nicht in dieser Liste sind. Wenn also jemand liebenswürdigerweise eine 64-Bit Version des TOK64 Tools (https://github.com/thezerobit/tok64) kompilieren und mir zukommen lassen könnte? Das würde mir sehr helfen. :emojiSmiley-106::emojiSmiley-08:


    Zitat von JeeK

    Sollte man bei der Spalte für Tasteneingaben nicht die Tastendarstellung nutzen (Deutsch {{Taste|...}} und Englisch {{Key|...}})?

    Du meinst die Darstellung im Wiki? Ja, das würde Sinn machen, vorausgesetzt, es drückt die Zeilen nicht zu weit auseinander. Ich probiere das aber gerne mal aus.

    Zitat von GenerationCBM

    Probier mal die hier

    Danke für die Bemühungen. Wenn ich das in meinem Windows 10 starte, dann erhalte ich eine blaue Meldung "This app can't run on your PC - To find a versino for your PC, check with the software publisher". Geht auch nicht, wenn ich auf dem Icon den Kompatiblitätsmodus aktiviere. ;(

    Zitat von wizball6502
    Zitat von JeeK

    Reicht für TOK64 nicht die Doku TOK64.TXT? Oder ist das unvollständig?

    Vielen Dank für das Feedback. Das ist ein Anfang, aber ich hätte gerne Bestätigung, ob sich dies dann auch so manifestiert in der aktuellen Version. Auch möchte ich gerne überprüfen, wie das Tool mit den anderen Zeichen umgeht, die nicht in dieser Liste sind. Wenn also jemand liebenswürdigerweise eine 64-Bit Version des TOK64 Tools (https://github.com/thezerobit/tok64) kompilieren und mir zukommen lassen könnte? Das würde mir sehr helfen. :emojiSmiley-106::emojiSmiley-08:


    Ich für Windows keine Entwicklungsumgebung. Da mögen bitte andere hier im Forum aushelfen (sind ja offenbar schon dabei hier Abhilfe zu schaffen).

    Für mich ist Linux interessant und war jemand schon so nett, eine Anpassung vorzustellen:

    https://github.com/0cjs/tok64 - ist zwar noch ein Pullrequest, der vom Originalautor noch nicht aufgenommen wurde, aber das kommt hoffentlich noch

    (wir warten schon 2 Wochen ... :/)

    Ich kann also nur ein Linux-Compilat anbieten. Oder, wenn es ein Test-PRG gibt, gerne dazu das Listing anfertigen und zur Verfügung stellen.

    Zitat von wizball6502

    Wenn ich das in meinem Windows 10 starte, dann erhalte ich eine blaue Meldung "This app can't run on your PC - To find a versino for your PC, check with the software publisher". Geht auch nicht, wenn ich auf dem Icon den Kompatiblitätsmodus aktiviere.

    Versteh isch nit. Auf Win7 64bit funktioniert die. Probier mal diese hier, die ist nicht mit UPX gepackt. Vielleicht lag's ja daran:

    Ich habe TOK64 inzwischen einem wissenschaftlichen :search: PRG-2-ASCII Übersetzungstest unterzogen. Zum Testen habe ich ein BASIC-Programm erstellt, dass sämtliche CHR$-Werte von 1-255 in 32 Print-Statements mit je 8 Zeichen enthält:


    petscii_test.prg


    Dieses PRG habe ich dann mittels Anweisung "TOK64.exe /TOTXT petscii_test.prg" in ein Text-Listing konvertieren lassen. Das Tool hat als Folge eine "petscii_test.txt"-Datei produziert. Bei Sichtung des Outputs bin ich auf ein paar Probleme mit dessen Interpretation der CHR$-Werte gestossen.


    Zum Vergleich - der folgende Output ist vom CMB prg Studio (interpretiert die CHR$-Werte von allen von mir bisher getesteten Tools am besten, aber auch dort ist nicht alles perfekt):

    Und hier der Output vom TOK64 (V1.4):

    Ab Zeile 21 (Zeichen 160) werden beim TOK64 die wesentlichen ge-CBM-den bzw. ge-Shifteten Zeichen nur als Zahlen dargestellt. Das ist zum Erstellen eines lesefreundlichen Listings leider nicht hilfreich. Der Entwickler vom TOK64 hat sich vermutlich zu sehr auf das Handbuch gestützt und nicht gemerkt, dass die Grafikzeichen, die man mit Shift oder CBM-Taste eingibt, die Werte 192-223 erhalten und nicht - wie man gemäss Handbuch erwarten würde - die Werte 96-127. Dieser Irrtum ist dann problematisch, wenn man z.B. einen Tastendruck eines geshifteten 'A's mit GETA$:IF ASC(A$)=97 THEN DO SOMETHING abfragen möchte. Statt 97 müsste da eben 193 stehen.


    Nochmals zur Veranschaulichung des TOK64 Problems...


    Das folgende Listing, eingegeben im VICE und gespeichert als PRG file sieht - durch den TOK64 gelassen- ...



    ...dann so aus:

    Code
    1. 1 print"{193}{194}{195}{196}{197}{198}{199}{200}"
    2. 2 print"{201}{202}{203}{204}{205}{206}{207}{208}"
    3. 3 print"{209}{210}{211}{212}{213}{214}{215}{216}"
    4. 4 print"{217}{218}"

    Leider kann ich für TOK64 damit keine Verwendungs-Empfehlung abgeben, zumindest nicht in der hier vorliegenden Version 1.4.


    Was die Verwechslungsgefahr bei den mehrfach vorkommenden Zeichen angeht: Ich denke, ich werde die doppelten Zeichen, die man eher nicht verwenden sollte, im C64-Wiki Eintrag rot markieren, damit man nicht in die vom Handbuch gestellte Falle tappt. :gluck

    Zum Einen ist Tok64 inzwischen relativ antik (die aktuellste prä-Github-Version ist von 1996). Natürlich hat auch alte Software ihren Sinn und Zweck, und kann mitunter auch Sachen die moderne Äquivalente noch nicht oder nicht mehr können, aber man würde sicherlich eher zu einem anderen Tokenizer/Detokenizer greifen wenn man keine ausgewachsenere Programmiersuite einsetzt. Schon allein petcat aus dem Vice-Paket ist erwachsener und mächtiger, gibt auch noch ein paar andere.


    Zum Anderen sind (De)Tokenizer chronisch inkonsistent zueinander was die Verwendung von Uppercase vs. Lowercase im Ausgangsmaterial angeht. Da hilft manchmal nur trial & error.