C-Kurs, Abend 4 - Verbesserungsvorschläge

skoe: Lob und Anerkennung möchte ich hiermit gerne Ausprechen für deinen C/cc65 Kurs! Layout der Seite TOP! Übersichtlich, interessant und lehrreich!

Toll!

(Auch wenn ich zur Zeit selbst keine Anwendung dafür habe, so lese ich doch interessiert mit.. und lernen kann man ja immer..)

Peter

Bei dem Beitrag gerade ist mir aufgefallen: Natürlich auch von mir noch ein Lob für Dein Projekt!

Zitat von skoe

Da sind wir zum gleichen Schluss gekommen: So in etwa habe ich es gerade im Kurs geändert.

Du könntest noch den Absatz "Wenn Ihr mal etwas genauer in die PETSCII-Tabelle schaut, ..." rausnehmen. Wir hatten uns ja, glaube ich, darauf geeinigt, dass wir nicht zu nicht-portablen Hacks ermutigen wollen, oder?

Außerdem habe ich gerade noch mal in den cc65-Code geschaut: Der geht nicht von ASCII, sondern von ISO 8859-1 aus. Als Link würde ich dann auch eher [wikipedia]ISO_8859-1[/wikipedia] nehmen. Der ist auf Deutsch, werbefrei, persönlich finde ich die Tabelle schöner und er lädt zum Weiterlesen ein. Eigentlich ist es aber auch egal, da die Zeichensätze eh in den relevanten Bereichen alle identisch sind (sogar die Windows-eigenen).

In der Tabelle, welche Zeichen nun sicher sind, könnte man vielleicht auch einfach die ohne CeVi-Entsprechung ({, }, \, ~, |, die beiden Tabs und Form Feed, so weit ich sehe) rausnehmen. Dafür sollten \n und \r vielleicht noch rein. Das führt dann vielleicht zu weniger Verwirrung.

Als Alternative zum Link http://www.rt.com/man/putchar.3.html hätte ich noch http://man-wiki.net/index.php/3:putchar anzubieten. Wiederum werbefrei. Ein Hinweis auf das man-Kommando für Linux-Nutzer wäre vielleicht auch interessant.

Grüße,
heptasean

Zitat

Dafür sollten \n und \r vielleicht noch rein. Das führt dann vielleicht zu weniger Verwirrung.

die beiden sollte man evtl sogar nochmal extra erklären... ich bin mir grade garnicht sicher, aber ich glaube das cc65 für \r (CR) - zumindest bei cbm rechnern - garkeine sinnvolle übersetzung macht (die kernal routinen kennen nur CRLF). evtl müsste man da mal rumtesten, auch auf andren zielsystemen als den commodore rechnern. zusätzlich verhalten sich da wenn ich mich recht erinner die stdio und die conio routinen unterschiedlich.

Zitat von sauhund

die beiden sollte man evtl sogar nochmal extra erklären...

Oh ja, vielleicht sollte man das. ...

Zitat von sauhund

ich bin mir grade garnicht sicher, aber ich glaube das cc65 für \r (CR) - zumindest bei cbm rechnern - garkeine sinnvolle übersetzung macht

Habe in den Code geschaut. Die Standardübersetzungstabelle mappt $0A (LF) auf $0D (CR) und umgekehrt!

Zitat von sauhund

(die kernal routinen kennen nur CRLF).

Nö, wenn ich das Kernal-Listing nicht völlig falsch lese, kennen die nur $0D/CR. Von LF wissen die gar nichts.

Dann ist das Mapping vom cc65 zumindest in die Richtung richtig. Das Mapping von $0D auf $0A verstehe ich nicht ganz. Das müsste eigentlich Überprüfungen auf ein eingegebenes Return kaputt machen. ...

Zitat

Nö, wenn ich das Kernal-Listing nicht völlig falsch lese, kennen die nur $0D/CR. Von LF wissen die gar nichts.

ja..äh. was ich meinte ist: ein "return" erzeugt immer ein CRLF (also wagenrücklauf+zeilenvorschub). es gibt weder ein einzelnes CR noch ein einzelnes LF. (ich beziehe mich hier immer darauf was besagte steuerzeichen ursprünglich auf einem drucker machen)

wobei es an der stelle auch schon zwischen dos/windows und *nix unterschiede gibt, alles halb so wild \n macht das was man erwartet und wer \r benutzt sollte eh lieber genau wissen was er tut

Wenn man die cc65-ASM-Routinen vom Atari800 vergleicht und dem c64 dafür, dann biegt jedes Programm diese Routinen um für die jeweilige Ausgabe des Rechners.

Wichtig ist : 10 und 13 machen das wie es in der C-Branche vorgesehen ist. Wie ist doch scheiss egal.

Zitat

Wichtig ist : 10 und 13 machen das wie es in der C-Branche vorgesehen ist. Wie ist doch scheiss egal.

wichtig ist vor allem zu verstehen das es eben nicht 10 und 13 sondern eventuell auch 23 und 42 sein kann =P

Zitat von sauhund

ja..äh. was ich meinte ist: ein "return" erzeugt immer ein CRLF (also wagenrücklauf+zeilenvorschub). es gibt weder ein einzelnes CR noch ein einzelnes LF. (ich beziehe mich hier immer darauf was besagte steuerzeichen ursprünglich auf einem drucker machen)

wobei es an der stelle auch schon zwischen dos/windows und *nix unterschiede gibt, alles halb so wild \n macht das was man erwartet und wer \r benutzt sollte eh lieber genau wissen was er tut

Naja, wenn eine Erklärung in den Kurs (vielleicht besser später oder als Anmerkung für ganz-genau-wissen-Wollende) soll, dann bitte richtig. Ich würde das so oder so ähnlich formulieren:

Früher musste man zwei getrennte Steuerzeichen an Drucker schicken, eines (CR/$0D/13) für den Rücklauf des Wagens an den Zeilenanfang und ein zweites (LF/$0A/10) für das Vorschieben um eine Zeile. Aus diesem Grund haben Windows-Textdateien immer noch beide Zeichen am Ende jeder Zeile (CRLF). Unter Unix hingegen ist CR üblicherweise das Zeichen, welches von der Tastatur gelesen wird, wenn die "Return"-Taste gedrückt wird, während in Text-Dateien (und Strings) nur LF am Zeilenende steht (und beides bewirkt, nächste Zeile und Zeilenanfang). Im C64 (in PetSCII) wird nur das Zeichen CR verwendet, welches sowohl der von der Tastatur gelesene Code bei "Return" als auch der in Strings verwendete Code für "nächste Zeile und Zeilenanfang" ist. Der cc65 macht nun aus einem '\n' (LF), welches auf Unix-Systemen (der Heimat von C) "nächste Zeile und Zeilenanfang" bewirkt, beim Kompilieren ein CR, um das gleiche auf dem C64 zu bewirken. Aus unerfindlichen Gründen macht er aber auch aus '\r' (CR) ein LF, welches auf dem C64 keine Bedeutung hat. '\r' sollte also am Besten nicht verwendet werden.

Interessant wären tatsächlich Tests auf anderen Geräten: Wenn man überprüfen möchte, ob "Return" gedrückt wurde, müsste es eigentlich Probleme geben, da man ja normalerweise (auf Unices) mit '\r' vergleichen würde, was aber bei der Umsetzung im cc65 keinen Sinn ergibt. Dann ist es vielleicht doch plattformunabhängiger gleich mit 0x0D bzw. 13 zu vergleichen. ...

Ansonsten werde ich mich, glaube ich, mal durch die Konvertierungstabelle vom cc65 durchfressen und das aufschreiben/dokumentieren.

skoe, weil ich Deinen Kommentar gerade lese: Völlig unwichtig ist das alles nicht, aber Du hast natürlich recht, dass man die Leute nicht zu früh vergraulen sollte. Vielleicht kann man das später im Kurs als Exkurs, Anhang oder so einbauen. Da der cc65 ansonsten nicht so detailliert dokumentiert ist, hätte das schon einen Mehrwert, finde ich.

Wie gesagt: '\r' sollte vielleicht erst mal nicht vorkommen, bis sauhund und/oder ich das näher analysiert haben. In Abend 2 hast Du auch noch '\t' drin. Das dürfte, wenn ich die Konvertierung richtig lese, auch nicht machen, was es soll. (Wie soll es auch der CeVi hat keine Tabs, oder?) Ich würde sagen, raus damit.

Grüße,
heptasean

Zitat von schnucke

Wenn man die cc65-ASM-Routinen vom Atari800 vergleicht und dem c64 dafür, dann biegt jedes Programm diese Routinen um für die jeweilige Ausgabe des Rechners.

Was möchtest Du sagen?

Zitat von schnucke

Wichtig ist : 10 und 13 machen das wie es in der C-Branche vorgesehen ist. Wie ist doch scheiss egal.

Ich geh' ja mit skoe so weit mit, dass man Anfänger nicht gleich vergraulen soll, aber mit "Wie's innen drin läuft, ist mir scheißegal!" kommst Du IMHO weder in C noch auf 8-Bit-Rechnern, auf denen jeder Zyklus zählt, weit, erst recht nicht in C auf 8-Bittern. Für "wie ist doch egal" sind eigentlich eher Java und andere sehr hohe Sprachen zuständig (was sie nicht schlechter macht, nur halt für beschränkte Hardware eher ungeeignet).

Zitat

mit "Wie's innen drin läuft, ist mir scheißegal!" kommst Du IMHO weder in C noch auf 8-Bit-Rechnern, auf denen jeder Zyklus zählt, weit, erst recht nicht in C auf 8-Bittern.

in der tat, speziell C auf 8 bittern kann man eigentlich erst sinnvoll anwenden wenn man ziemlich genau weiss was "unter der haube" vor sich geht.

Zitat von skoe

Tabs "hat" man nicht, die implementiert man

Ja, OK, aber wenn dies die Kernal-Routine machen soll, braucht sie einen Code für Tab und den hat PetSCII nicht.

Zitat von skoe

Aber auch hier müsste man durchleuchten, wie '\t' konvertiert und in den verschiedenen Funktionen benutzt wird.

Konvertiert wird es nicht, sondern einfach als 0x09 durchgereicht, müsste also beim CeVi als "Entriegele Shift-C=" ankommen, es sei denn puts und/oder printf interpretieren es selbst. Muss ich ausprobieren.

Zitat von skoe

Mhhh, ich würde das nicht so allgemein sagen. Schau mal (Linux, hab gerade kein anderes Unix zur Hand). Starten und "Enter" drücken:

Code

1. ...

Alles andere würde mich auch wundern, weil die Quelle des Streams egal sein sollte. Du meintest sicher eine andere Funktion. Welche ist es, die \r zurückgibt?

Hab' mich einfach geirrt. Dann braucht man '\r' wohl nicht wirklich irgendwofür. Könnte höchstens Ärger geben, wenn man auf dem CeVi wirklich etwas schreiben möchte, was CRLF- oder LF-Zeilenenden hat - also direkte Behandlung von Windows- und Unix-Textdateien und/oder Netzwerkprotokolle, die CRLF verlangen. In diesen Fällen müsste man dann in cc65 "\n\r" für CRLF und "\r" für LF verwenden statt der üblichen "\r\n" und "\n", aber das sind esoterische Fälle.

Zitat von skoe

Insgesamt finde ich Deine Idee mit dem Exkurs ganz gut, den würde ich als extra Seite (weiterführende Info) dazulegen. Aber er muss korrekt sein. Also wenn aus der obigen Formulierung von Dir was wird, wo alle hier zustimmen können, übernehme ich sie.

Braucht ein bisschen. Wenn, dann will ich gleich die gesamte Konvertierung, wie sie im aktuellen cc65 gemacht wird, mit abdecken. Mit einer fetten Warnung, dass man sich nicht drauf verlassen kann, dass das auf ewig so bleibt.

Zitat von skoe

Ein paar andere, einschließlich mir, können auch Quelltexte lesen

Sorry, so war das natürlich nicht gemeint.

Grüße,
heptasean

aber zb mein schonmal erwähntes tetris

Dieses scheissding kommt schon fast so oft vor wie "Hello World". So etwas kann man nicht als Maßstab nehmen. Das sind doch faule Eier.
Hier geht es um das ausreizen eines c64/plus4 mit dem Fähigkeiten mit cc65.

Da kann ich die Äpfel vom c64 nicht mit den Birnen vom Plus4 vergleichen oder dem Atari800.

Hier geht es darum, den 8Bitter mit dem cc65 die Beine zu machen und wie du vorhin sagtes dem antiquarten Kernal vom c64 Rs232-fähig zu machen mit 32000baud...ho...ho...

Zitat

Hier geht es um das ausreizen eines c64/plus4 mit dem Fähigkeiten mit cc65.

nein, hier geht es darum am beispiel des cc65 erstmal rudimentäre kenntnisse in C zu vermitteln. wenn du den c64 oder plus4 (oder irgendeinen andren 8 bitter) *ausreizen* möchtest wirst du um assembler und fundierte hardware kenntnisse nicht drumherum kommen, dabei kann dir kein compiler helfen.

Zitat

Da kann ich die Äpfel vom c64 nicht mit den Birnen vom Plus4 vergleichen oder dem Atari800.

nur zu schade das du weder von äpfel noch von birnen auch nur den hauch einer ahnung hast, sonst könnte man deine aussage zumindest ansatzweise ernst nehmen.

Also, ich habe mal ein bisschen rumgetestet und mir die Konvertierungstabelle genauer angeschaut. Ich würde folgendes als Exkurs vorschlagen:

Konvertierung von Quellcode-Zeichenketten in C64-Zeichenketten

Da der C-Quelltext und der C64 unterschiedliche Zeichensätze verwenden, muss der cc65-Compiler eine Konvertierung vornehmen. In den C-Standards werden diese unterschiedlichen Zeichensätze "source character set" und "execution character set" genannt. Der cc65 verwendet ISO 8859-1 als "source character set" (welcher in den ersten 128 Zeichen mit ASCII übereinstimmt) und (zumindest beim C64 als Zielsystem) PetSCII als "execution character set". Wie diese Umwandlung genau vorzunehmen ist, wird in den Standards nicht genau festgelegt, sondern dem Compiler überlassen.

PetSCII ist eigentlich nicht ein einzelner Zeichensatz, sondern besteht aus zwei Zeichensätzen – einer für den Großbuchstaben/Grafikzeichen- und einer für den Klein-/Großbuchstaben-Modus. Wie Ihr sicherlich schon bemerkt habt, schalten vom cc65 erzeugte Programme automatisch in den zweiten Modus um, damit Groß- und Kleinbuchstaben verwendet werden können. Wenn wir nun ISO 8859-1 (bzw. ASCII) mit PetSCII (in der Klein/Groß-Variante) vergleichen, stellen wir fest, dass die Klein- und Großbuchstaben vertauscht sind. Dies ist also die erste Konvertierung, die der cc65 vornehmen muss, was er auch tut, sonst hätten unsere ersten Test-Programme auf dem C64 seltsam ausgesehen.

Die Sonderzeichen und Buchstaben in den oberen 128 Zeichen von ISO 8859-1 (und die Zeichen {, |, } und ~ aus ASCII) haben keine Entsprechungen in PetSCII und sollten daher besser nicht verwendet werden. Umgekehrt haben die grafischen Zeichen in PetSCII keine Entsprechung in ASCII oder ISO 8859-1 und können daher von C aus nicht (oder zumindest nur mit nicht-portablen und schwer nachzuvollziehenden Mitteln) angesprochen werden.

In C-Zeichenketten können verschiedene sogenannte Escape-Sequenzen verwendet werden. Eine davon, nämlich "\n" für "newline" haben wir schon ausgiebig benutzt. Die anderen (und ihre Umsetzung auf dem C64) werden wir uns nun in einem kleinen Test-Programm angucken:

Wenn dieses Programm auf dem C64 ausgeführt wird, erzeugt es die folgende Ausgabe:

In der oberen Hälfte zeigt das Programm die Hexadezimal-Codes, in die die Escape-Sequenzen umgewandelt werden, und zum Vergleich die auf dem PC üblichen Werte. In der unteren Hälfte wird dann der Effekt, den diese (Sonder-)Zeichen bei der Ausgabe haben, getestet.

Zunächst sehen wir, dass \', \" und \? ganz ohne Konvertierung genau wie erwartet funktionieren, da die Zeichen in ASCII und PetSCII auf den gleichen Positionen liegen. Diese Sequenzen brauchen wir auch gelegentlich, da wir sonst z.B. keine doppelten Anführungszeichen in Zeichenketten verwenden könnten, da sie ja gerade verwendet werden, um die Zeichenkette einzuschließen. Die Sequenz \\ für den Backslash wird ebenfalls nicht konvertiert, was auf dem C64 zu einem £ führt, da dieser keinen Backslash im Zeichensatz hat und an dieser Stelle das Pfund-Zeichen codiert.

Die Sequenzen \a (gibt normalerweise einen kurzen Ton aus oder lässt den Bildschirm aufblinken) und \t (Tabulator) werden ebenfalls nicht konvertiert. Die entsprechenden Codes in PetSCII haben aber einfach überhaupt keine Bedeutung. Hierbei fällt auf, dass Zeichen unterschiedlich behandelt werden, je nachdem, ob sie in der ausgegebenen Zeichenkette in Anführungszeichen stehen oder nicht. Dies liegt daran, dass die erzeugten Programme die Ausgaberoutinen des C64-Kernal verwenden und dieser (wie in BASIC) einen speziellen Modus innerhalb von Anführungszeichen verwendet.

Die Sequenzen \b, \f und \v werden anscheinend auf entsprechende Codes in PetSCII konvertiert. Der Backspace \b ergibt den Code für Inst/Del, welches auf dem C64 ja den erwünschten Effekt hat, das vorherige Zeichen zu löschen. Der Formfeed \f wird in den Code für Clr/Home übersetzt, welcher an den Bildschirmanfang springt. Der sogenannte vertikale Tabulator \v schließlich wird in Cursor down konvertiert. Bei \f und \v tritt wieder der Effekt ein, dass innerhalb von Anführungszeichen etwas anderes passiert als außerhalb.

Eine besondere Beachtung verdienen \n und \r. Diese haben auf dem PC (in ASCII) normalerweise die Bedeutungen LF ($0A oder dezimal 10) und CR ($0D oder dezimal 13) und haben beide etwas mit dem Zeilenende zu tun. Traditionell hatten Drucker und andere Ausgabegeräte getrennte Sonderzeichen/Befehle für den Wagenrücklauf an den Zeilenanfang (carriage return, CR) und das Vorschieben um eine Zeile (linefeed, LF). Aus diesem Grund haben Textdateien unter DOS und Windows und einige Internet-Protokolle immer noch beide Zeichen an den Zeilenenden (in der Reihenfolge CRLF). Unter Unix (der Heimat von C) wird dagegen nur LF als Zeilenende-Zeichen verwendet (und auch von der Return-Taste erzeugt). Auf dem C64 (und Apple-Computern bis zu MacOS 9) wird CR als Zeilenende-Zeichen (und Code der Return-Taste) verwendet.

Daher tauscht die Konvertierung des cc65 die Codes für \n und \r aus. Damit bleiben Programme zwischen Unix und C64 portierbar: \n bedeutet in beiden Fällen ein Zeilenende und den von der Return-Taste gelieferten Code. \r hingegen hat auf dem C64 überhaupt keinen Effekt (ähnlich wie \a und \t), während auf Unix-Systemen tatsächlich an den Anfang der gleichen Zeile gesprungen wird. Normalerweise sollte also einfach (wie in C üblich) \n verwendet werden, wenn Zeilenende oder Return gewünscht ist. (Zu Problemen kann es nur kommen, wenn man mit cc65 direkt DOS- oder Unix-Textdateien oder Internetprotokolle bearbeiten möchte. Hierbei müssen die in C sonst üblichen Sequenzen getauscht werden: CRLF wird durch \n\r (üblicherweise \r\n) und LF durch \r (üblicherweise \n) erreicht.)

Zusammenfassung:

Aus den vorherigen Betrachtungen wird deutlich, dass in cc65-Zeichenketten normalerweise nur die Buchstaben und Zeichen des ASCII-Zeichensatzes (außer {, |, } und ~) und die Escape-Sequenzen \', \", \? und \n vorkommen sollten. \b ist in Ausgaben weniger sinnvoll, aber für die Bearbeitung von Eingaben interessant.

Die anderen Zeichen und Escape-Sequenzen haben auf dem C64 entweder keine Entsprechung oder sind wegen der unterschiedlichen Behandlung in Anführungszeichen und der unterschiedlichen Interpretation auf anderen Systemen kritisch.

Zitat

Die Sequenzen \b, \f und \v

... hab ich in all den jahren in denen ich C programmiere nicht einmal benutzt :o)

(ansonsten kann man das als exkurs gut so stehen lassen, keine einwände :))

Zitat von sauhund

... hab ich in all den jahren in denen ich C programmiere nicht einmal benutzt :o)

Und ausgerechnet die werden im cc65 halbwegs vernünftig umgesetzt (modulo der komischen Sache mit den Anführungszeichen). ...

\b scheint mir tatsächlich ganz sinnvoll zu sein, für einen plattformunabhängigen Editor z.B., der auf Inst/Del auf dem CeVi so reagiert wie auf Backspace unter Unix. ...

Übrigens: Tab ist in PETSCII vorhanden, nur im C64 nicht implementiert. Schaut euch mal den C128 an.