Posts by Korodny

    Übrigens: Keine Ahnung wo der "mplayer muss man aus dem Terminal starten"-Mythos herkommt. Ich nutze mpv (Mplayer-Fork) und hab den noch nie aus dem Terminal gestartet...

    Müssen tut man nicht

    Nimm bitte in Zukunft Rücksicht auf die anwesenden Windows-Nutzer, einige von denen haben Kreislauf- und Verständnisprobleme. Es erschwert die Unterhaltung unnötig, wenn ein Teil der Anwesenden laut brüllt ICH-HABS-JA-SCHON-IMMER-GESAGT-SCHEISS-LINUX-ALLES-KONSOLE!!! während Hagtrix schon wieder künstlich beatmet werden muss.

    aber es ist recht bequem beim Aufruf gleich die abzuspielende Datei mit anzugeben.

    Rechtsklick auf eine Video-Datei, "Öffnen mit...", evtl. Haken bei "standardmäßig für Dateien dieses Typs benutzen", "Ok".

    Mein Modul war rot, mit roten Tastern und ohne Aufdruck/Aufkleber - also nicht wie im Foto von Parser. Von den "richtigen" Handbüchern auf seinen Fotos war bei mir nur das mit dem schwarzen Cover dabei, sowie zwei lose "Beipackzettel" für die Erweiterungsdisketten.


    Scheint also, als wären Handbuch-Cover und Einschaltmeldung wirklich die einzigen Unterscheidungsmerkmale.

    Ja, Displayskalierung scheint dann wirklich vom WindowManager abzuhängen.

    In dem Punkt liegt der Fehler bei dir: Wenn der Anspruch lautet "ich will nichts mehr basteln müssen", ist XFCE die falsche Wahl, dann nimmst du einen der großen Desktops wie Gnome.

    Was mir bei Linux jetzt noch missfallen hat, ist das manche Programme ja fast 2GB an Libs brauchen um zu laufen. Also das eine brauch GTK das andere Qt KDE Plasma haste nicht gesehen usw. und jedes Toolkit hat wieder so teilweise sein eigenes Aussehen.

    Das stört mich auch, lässt sich aber in der Mehrzahl der Fälle umgehen in dem du einfach Programme einsetzt, die zu deiner Desktop Umgebung bzw. dem dort genutzten UI-Toolkit passen. Es gibt nur sehr wenig (Qt-) Software, für die kein brauchbares GTk-Equivalent existiert (den umgekehrten Fall kann ich mangels Erfahrung nicht beurteilen).

    Ich weiß nicht, früher war ich da experimentier freudiger. Ich bin irgendwie total windowsverwöhnt, erst recht seit der 10er Version. Die hat mir von Anfang an super gefallen und ich habe Win7 keiner Träne nachgeweint.


    Wenn ich mir jetzt selbst mein Geschreibsel durch lese ist meine Entscheidung gegen Linux irgendwie schon gefallen.

    Die war schon gefallen, bevor du Linux angefasst hast ;) Wenn du mit Windows 10 glücklich bist, ist Linux nichts für dich. Es ist anders . und hat damit von Anfang an keine Chance, da auf deiner Seite ja kein Leidensdruck herrscht.

    AR5 und AR6 nutzen die gleiche Hardware. Als Unterscheidungsmerkmale fallen zwei Sachen ein:

    • das Cover des Handbuchs: bei meinem AR6 steht hier neben "ACTION REPLAY" in ziemlich exotischem Font ganz klein "VI", wobei das "V" mehr wie ein Checkmark aussieht.
    • der Startbildschirm, wo man per F-Tasten "Configure Memory", "Normal Reset" usw. wählen kann: beim AR6 hat der einen weißen Hintergrund, bei früheren Versionen einen blauen

    Die Grenze bei 250 macht auch nur bedingt Sinn, die 1581 kann 288. Fragt mal GoDot und nach dem GoDot-1581-DiskImage... das ist voll ;)


    Von daher fände ich z.B. 512 Einträge gut...

    Naja, wo man die Grenze zieht bis man auf einen Fall-Back-Modus wechselt, ist ja dann Geschmacksfrage. Mein Fallback wäre sowieso lediglich ein simpler Dialog mit Texteingabefeld, Knöpfen für "Laden/Abbrechen" und der Möglichkeit, das Directory ein mal traditionell über einen leeren Bildschirm scrollen zu lassen.


    Aber warum denn 512 Einträge? Bei 18-20 sichtbaren Dir-Einträgen im Dialogfenster sind das bald 30 Seiten voller Dateien. Wie viele solcher Verzeichnisse hast du denn auf CBM-Laufwerken? Ich hab selbst auf meinem Desktop in HOME nur zwei Verzeichnisse in der Größenordnung - und das sind Backups größerer statische HtML-Projekte.

    Ich würde eher so auf rund 250 gehen. [...] Apropos SD2IEC: Ich meine, das reicht optional den Date/Time-Stamp vom FAT-Verzeichnis durch

    Das sind (ausgehend von @darkvision's 24 Bytes) 6 Kilobyte. Dazu kommt der Bildschirm-Cache, bei farbigem Hires sind das 9 KB. Dann wäre fast ein Viertel des Hauptspeichers Cache...

    Entweder gestaltet man den Zeichensatz von vornherein so, daß die Zeichen dann an anderer Stelle liegen, oder die Zeichen des Dateinamens werden in einer Stringroutine "petscii_dateinamen_konvertieren" übersetzt. Ist programmtechnisch kein großes Problem. Letzteres würde ich bevorzugen, damit sich bei Sortierungsaktionen die sortierte Reihenfolge ähnlich verhält wie bei den ISO-8859 Namen.

    Ja sicher, so könnte man das lösen - das ist das, was ich mit "dritte Lösung" (zusätzlich zu normalem PETSCII und proportionalem ISO) meinte. Wäre mir halt zu viel Aufwand, nur um Proportionalschrift anzeigen zu können.


    Weitere Vorteile hat der Einsatz des (neuen) System-Zeichensatzes in dieser Situation ja nicht. Eher Nachteile, weil er mich bei der Wahl der zur Verfügung stehenden Zeichen einschränkt - nur die PETSCII-Zeichen, die auch in ISO vorkommen, können angezeigt/genutzt werden.

    Es kommt immer darauf an, mit welchem Datenträger man arbeitet. Würde es z. B. darum gehen, weitere Inhalte eines Roms darzustellen, könnte man durchaus das Inhaltsverzeichnis modern unter Verwendung von ISO-8859 gestalten.

    Mal abgesehen vom EasyFlash oder Tape-Lösungen sind C64-Laufwerke intelligente Laufwerke, auf deren Zeichensatz-Encoding ich keinerlei Einfluss habe. Macht es wirklich Sinn, in dem einen Sonderfall plötzlich neue Regeln für Dateinamen zu definieren ("Hier gehen Umlaute!")?

    Vorher hattest Du angemerkt, daß bei einem Dateirequester, der PETSCII-Zeichen anzeigen soll, zusätzlich 2 kb verbraucht werden für einen Commodore-Zeichensatz. Der Witz dabei ist, daß diese 2 kb gar nicht so sehr ins Gewicht fallen, weil so ein Dateirequester mit ganz anderen Speicherproblemen zu kämpfen hat. Das Requesterprogramm an sich dürfte schon 1 kb oder mehr verschlingen, aber noch viel mehr die Speicherung der Dateinamen des Verzeichnisses. Angenommen die Dateinamen dürften 16 Bytes lang sein, und ein Verzeichnis hat maximal 256 Einträge, so kommt man schon auf 4 kb nur für die Liste der Dateinamen. Mit anderen Worten: Bei der Organisation des OS führt kein Weg daran vorbei, eine Art Speichermanagement einzurichten, welches im Bedarfsfall dafür sorgt, daß ausreichend Speicher für eine eingeschobene Aktion wie einem Dateirequester vorhanden ist.

    Hilfe, schalt mal einen Gang runter - In einem Satz von "Speicher-Dialog" über "Segmentierung" zu "modernes Speicher-Management" :D


    Wie viele Dir-Einträge ich unterstützen will bzw. muss, lege ich vorher fest - 144 würde Sinn machen, so viel kann eine 1541 und auch meine CMD-HD konnte nicht mehr, IIRC. D.h. ich weiß auch vorher, wie viel Cache ich brauche. Cache brauche ich sowieso auch bei anderen Gelegenheiten (Bildschirminhalte zwischenspeichern) oder manchen Anwendungen (Undo-Speicher o.ä.) - also definiere ich ein oder zwei Bereiche fester Größe als Cache und definiere ein paar Rahmenbedingungen für die Nutzung durch Anwendungsentwickler.


    Der Speichern-Dialog selbst verbraucht übrigens nur unwesentlich Platz. Er ist eine Kombination aus den Modulen "Verzeichnis laden", "Dialogfenster", "Listview" und "Knopfreihe" - alles Elemente, die das System bereits zur Verfügung stellt und die ständig im Speicher stehen müssen.

    Das bedeutet zumindest, daß das OS in einer Art segmentierter Form vorliegen muß und nur immer bestimmte Teile geladen werden. Das könnte aber auch bedeuten, daß native Applikationen für dieses OS auf irgendeine Art segmentiert sein müssen.

    Angenommen für den Requester werden 10 kb benötigt, wovon die meisten temporäre Daten sind und lediglich 1 kb aus Code besteht. Dann könnte man den Programmteil in den Bereich $c000..$cfff laden, sofern man diesen Bereich für Programmsegmente reserviert hat. Den großen Anteil der temporären Daten müßte man dann auf eine Art Stapel anlegen, d. h. Position und Lage sind nicht vorherbestimmt. Das vereinfacht die Anwendung des Segments aus einem Programm heraus. Nichtsdestoweniger kann es dazu führen, daß der Stapel überläuft und in den Code- oder Datenbereich der Applikation reinragt. Nun kann nach Beendigung des Requesters der Codeteil der Applikation durch erneutes Laden wiederhergestellt werden. Für das gezielte Laden von Einzelteilen muß die Applikation jedoch ebenfalls irgendwie segmentiert vorliegen. Oder das OS erkennt den Speicherbedarf und rettet den Speicher in ein externes Ram, wovon es anschließend wiederhergestellt wird.

    Verstehe ich nicht. Es gibt X Kilobyte allgemeinen Daten-Cache, und Y Kilobyte Screen-Cache (vermutlich ein mal kompletter Bildschirminhalt). Den Screen-Cache nutzt nur das OS, wenn es Dialogfenster oder Menüs anzeigt. Der Daten-Cache wird abwechselnd vom OS oder der Anwendung genutzt, aber nie gleichzeitig: Der Anwendungsprogrammierer weiß, dass der Cache gelöscht werden könnte, wenn er irgendeine (oder einige bestimmte) OS-Routinen aufruft.


    Wozu brauche ich den da Speichermanagement für den Daten-Cache? Das OS haut das Ding mit einem Directory voll, weil ich gerade einen Speichern-Dialog geöffnet habe, danach nutzt ihn die Anwendung als Undo-Speicher ("Änderungen beibehalten? J/N"), dann nutzt der Anwender ihn um das Accessory "Minesweeper" parallel zu meiner laufenden Anwendung auszuführen. Mit ein paar Einschränkungen ("Keine Laden/Speichern-Dialoge in Accessories") komme ich doch da prima ohne Speicher-Management aus?


    Wenn ich das OS oder Anwendungen in einzelne Module aufteilen würde, dann definitiv nur so dass ich einen fixen Bereich definiere und dorthin Module lade. D.h. die am meisten genutzten Module liegen immer im RAM, zusammen mit einer Routine die weiteren Kram nach $MODUL_START lädt und ausführt, wenn er gebraucht wird. Ich denke das war auch das, was Retrofan im Sinn hatte mit seiner EasyFlash-Unterstützung.


    KISS-Prinzip.

    Auf jeden Fall ergeben sich folgende Forderungen an eine Entwicklung:

    1.) Es muß festgestellt werden, wer hauptsächlich für das Speichermanagement verantwortlich ist: Applikation oder OS.

    2.) Es muß festgestellt werden, wie der Speicherbedarf und die Speicherbelegung kommuniziert wird. (Welcher Speicher wurde überschrieben? Welcher Programmteil ist betroffen?)

    3.) Ein Nachladen von Programmcode setzt zwingend voraus, daß entweder a) die Applikation in kleinen Segmenten auf einem Datenträger vorliegt, von wo aus sie relativ schnell restauriert werden kann. b) das OS im günstigen Fall auf einem Steckmodul-ROM vorliegt, von dem aus schnell Programmteile wie der Requester geladen werden können, c) als beste Lösung (weil transparent für die Applikation) das OS den Speicherinhalt von sich aus in ein externes Ram rettet und wiederherstellt.

    Welche Fälle fallen dir denn ein, wo OS oder Anwendung den eigenen Speicherbedarf nicht fix vorhersagen können? Nur dann muss ich doch überhaupt solche Klimmzüge wie Speichermanagement machen?


    Ich hätte jetzt gesagt eine Anwendung kriegt X Kilobyte freien Speicher, was sie damit macht ist ihre Sache. Eine eventuelle Segmentierung kann man ja mit entsprechenden OS-Routinen unterstützen, aber eine Notwendigkeit für Speicher-Management sehe ich einfach nicht.

    Im PETSCII gibt es keine Umlaute, und PETSCII ist ein Zeichensatz und kein Font.

    PETSCII ist Commodores Zeichensatz, sowie ATASCII dem Zeichensatz von Atari 8-bit-Mascinen war.

    Jetzt schmeißt du aber Begriffe durcheinander ;) "Zeichensatz" ist schlicht deutsch für Font. "PETSCII" ist streng genommen kein Zeichensatz, sondern eine Codepage. Der Zeichensatz legt dann fest, wie die in der PETSCII-Codepage definierten Zeichen aussehen: vergleiche PET, VIC 20 und C64 - alles PETSCII, aber komplett unterschiedliche Zeichensätze.


    Aber die Begriffe verwendet sowieso niemand korrekt, sich darüber jetzt zu streiten ist glaube ich ziemlich sinnlos.

    Für die Mehrzahl der Verzeichnisse von großen Massenspeichern (auf SD-Karte) möchte ich platzsparende Proportionalfonts einsetzen – wenn man hingegen auf D64-Images trifft, dann würde ich gerne auf die typische C64-monospaced-PETSCII-Ansicht umstellen, da manche Künstler sich ja in in den Directories optisch austoben wollen.

    "Platzsparend" sind deine Proportionalfonts in dem Fall nicht, weil der Dialog ja breit genug sein muss um auch fixed-width-PETSCII anzeigen zu können. Bei einer Limitierung auf 16 Zeichen für den Dateinamen finde ich die klassische Darstellung sogar hilfreich, weil ich beim Speichern oder Umbenennen immer genau weiß wie viel Platz ich noch habe.


    Außerdem würde mit deinem Proportionalfont ja alle Dateinamen, die nicht direkt zu deinem OS gehören, mit vertauschten Klein- und Großbuchstaben angezeigt werden - für Datei-Management "eher" hinderlich. Also müsstest du neben PETSCII und ISO noch einen dritten Anwendungsfall handhaben, nämlich proportional-PETSCII.


    Und Zeichencodes >128 aus ISO o.ä. für Dateinamen zu verwenden ist IMHO (a) sinnlos, da die Zeichen nur als Hieroglyphen auf dem eigentlichen Datenträger landen werden und so für den Datenaustausch oder die Nutzung außerhalb deines OS komplett nutzlos sind und (b) gefährlich, weil du nicht sicher vorhersagen kannst ob jede Laufwerksemulation solche Zeichen-Codes identisch in die UCS-Codierung übersetzt, die FAT32 verwendet.

    Ich würde das dynamisch anlegen. Der Hauptzeichensatz des Systems sollte ISO 8859 (oder CP1252) sein. PETSCII würde man doch nur benötigen, wenn man auf echte Disketten (1541) bzw. D64/D81-Images treffen würde.

    Nein, IMHO benötigst du PETSCII für alle Datei-Operationen. 8-Bit-Zeichen an diverse Software-Emulationen eines IEC-/CBM-DOS-Geräts zu schicken, die dann im Backend (vermutlich) FAT32 einsetzen - was weder 8859 noch 1252 zur Kodierung nutzt - ist ein ziemlich großer Fallstrick.


    Ganz abgesehen davon ist auch optisch und ergonomisch IMHO ein No-Go wenn Verzeichnisinhalte mit komplett unterschiedlichen Zeichensätzen dargestellt werden, je nachdem welchen Datenträger man sich gerade ansieht.

    Genau dann, wenn das z.B. in einem File-Requester passiert, kann man einen PETSCII-Zeichensatz laden. Und zwar sogar notfalls über den vorhandenen System-Zeichensatz drüber-bügeln

    Wegen Acht fehlenden Bytes?

    dürfte ein generelles Speichern als UTF-8 keinen nennenswerten Vorteil bieten und sollte optional bleiben.

    Natürlich hat niemand die Absicht, "generell als UTF-8 zu speichern". Es ging um das Lesen (und Wiederabspeichern) von Texten, die bereits als UTF-8 vorliegen. Nichts weiter.

    Tut mir leid, aber ich empfinde das als Haarspalterei. Windows-1252 umfaßt ISO-8859 und ist bis auf kleine Ausnahmen dazu kompatibel. Ja, das Eurozeichen kam später hinzu, denn damals[tm] zu Amigazeiten gab es noch keinen Euro. Aber deswegen zu sagen, daß die in ISO-8859 enthaltene Codierung für westeuropäische Zeichen in Texteditoren nicht als Standard benutzt würde, geht an der Sache vorbei.

    Windows-1252 enthält eine ganze Reihe zusätzliche Zeichen, die für Autoren - im Unterschied zu Programmierern - von Bedeutung sind und deswegen auch genutzt werden: Gedankenstrich, Auslassungszeichen, (deutsche) öffnende und schließende Anführungszeichen. Da es im hier diskutierten Beispiel um Texte (s. "Markdown Editor") nicht um Code ging, ist deswegen der Unterschied zwischen 1252 und 8859-15 zumindest bei der Konvertierung nach ISO-8859 von Belang. In der Gegenrichtung ist das tatsächlich zu vernachlässigen.

    Wenn ein Texteditor ernsthaft nur UTF-8 unterstützt, kannst Du ihn am besten gleich wegschmeißen.

    Wo hast du nur dieses ganze Zeugs her? Niemand hat das gesagt?

    Richtig. Für die Anzeige eines 1541-Verzeichnisses wäre ein PETSCII-Zeichensatz sinnvoll. Aber warum soll man dafür keine zwei Zeichensätze im Speicher halten?

    Weil das schon wieder 2 KB Speicher sind? PETSCII müsste ja ständig verfügbar sein, nicht wie von dir impliziert nur im Desktop: ein Dateidialog - wie auch immer der aussieht - ist ja Teil des OS, nicht Teil des Desktops.


    Ich hab's mir gerade bei Wikipedia noch mal angesehen: Neben 96 ASCII-Zeichen und 96x ISO-8859 würde man noch 64 PETSCII-Grafikzeichen benötigen - das würde also exakt in einen Zeichsatz passen. Allerdings unterscheiden sich ASCII und PETSCII auf den ersten Blick dann immer noch auf acht Positionen (Unterstrich statt Linkspfeil u.ä.), für diese acht Zeichen fehlt der Platz.


    Ich würde zur Lösung des Problems wahrscheinlich zwei C64-spezifische Untermengen von ISO machen und dann mit PETSCII koppeln. "Westeuropa", "Osteuropa" oder so. Je nachdem welche Sprache der Benutzer einstellt, wird dann der entsprechende Zeichensatz samt zugehöriger Codepage genutzt. Ein "ë" oder "Ý" wird auf dem C64 sowieso kaum jemand eingeben oder sehen wollen/müssen.

    Ich bitte um Verzeihung, aber ich habe diese ganze Diskussion nicht verstanden.

    Es ging einfach um einen imaginären Texteditor, der möglichst unkomplizierten Austausch mit modernen Systemen ermöglicht.


    Meine Definition von "möglichst unkompliziert" beinhaltet schlicht, dass sich der Nutzer beim Laden/Speichern keinen Kopf um das Encoding machen muss, sondern einfach speichert. Daraus hat sich diese Diskussion entwickelt.

    1.) Selbstverständlich können die gebräuchlichen Texteditoren unter Windows ISO-8859

    2.) ISO-8859 ist schon seit Jahrzehnten der Standard bei der Textcodierung.

    Windows hat noch nie ISO-8859 unterstützt, es würde mich wundern wenn Texteditoren das dort als Standard nutzen würden. Windows CP-1252 ist in sehr großen Teilen mit ISO-8859 identisch, bietet aber eben mehr Zeichen als der ISO-Standard, und das Euro-Zeichen liegt woanders.

    4.) Für rein westeuropäische Texte ist ISO-8859 die seit Jahrzehnten einfachste und platzsparendste Codierung, und es gibt überhaupt keinen Grund, davon abzuweichen. Wozu sollte man für deutsche Umlaute zwei Bytes benötigen, wenn es auch mit nur einem geht? Das macht keinen Sinn.

    Die Idee ist ja auch nicht, dass "wir" davon abweichen, sondern das andere Systeme das tun (und bspw. UTF-8 als Standard-Encoding benutzen) - und wenn wir möglichst unkompliziert Daten mit diesen Systemen austauschen wollen, müssen wir eben UTF-8 unterstützen - beim Laden/Speichern von Texten in einem Texteditor. Niemand will UTF-8 auf dem C64 als Standard-Encoding nutzen.

    Dieser Thread versucht nun auszuloten, wie man das leere Papier am besten bemalen kann, so daß Geschwindigkeit und Benutzerfreundlichkeit akzeptabel sind. Dazu gehört die Verwendung von ISO-8859 als Zeichencodierung, da sie platzsparend ist und alle wesentlichen im Rahmen eines C64-OS zu erwartenden Zeichen abdeckt.

    Es waren sich m.E. mal alle einig, dass "Datei-Management" im weitesten Sinn eine der Hauptaufgaben eines noch zu entwickelnden OS sein würde. Das setzt m.E. zwingend die Möglichkeit voraus, auch PETSCII anzeigen zu können - völlig unabhängig vom gewählten Darstellungsmodus. Wenn du also nicht zwei Zeichensätze im Speicher halten willst, wirst du um ein bisschen Codepage-Gehacke nicht herumkommen.

    Ich wüsste nicht, warum ich auf dem C64 Unicode lesen können wollte. Davon ab ist ISO 8859-1 und Unicode im 8-Bit-Bereich (also 00 bis FF) deckungsgleich, wie wir ja gemeinsam herausgefunden haben.

    Nochmal: Es ist völlig unerheblich, ob irgendein Unicode-Block mit ISO-8859 deckungsgleich ist, da Unicode - im Gegensatz zu ISO - nur eine (gigantische) Codepage ist, aber kein Encoding. Das (meist)verwendete Encoding für Unicode ist UTF-8, und das ist nicht kompatibel zu ISO, zumindest nicht jenseits von ASCII.

    Die Möglichkeit, Texte unterschiedlicher Encodings in einem Editor lesen und schreiben zu können (würdest du defaultmäßig auch UTF-8 speichern wollen, obwohl das auf dem C64 Platzverschwendung wäre?), sagt natürlich nichts darüber aus, wie das OS selbst seine Zeichen kodiert. Da bin ich natürlich weiterhin bei einem 8-Bit-Standard-Encoding, wie ISO 8859-15 (oder notfalls meinetwegen Windows 1252) – warum sollte man da was Neues erfinden.

    Hm - was man als Standardformat verwenden würde, ist eine gute Frage. UTF-8 sicher nicht, weil die Texte ja auch lokal angezeigt werden sollen (Online-Hilfe, Programmdokumentation...), dann müsste man die Konvertiererei an diversen Stellen machen. Aber ISO-8859 oder CP-1252, das müsste man mal noch durchdenken Stolperstein ist in dieser Richtung (ISO→1252) glaube ich nur das Euro-Zeichen, also eventuell in dem Fall nachfragen...


    Das OS muss IMHO aus Kompatibilitätsgründen für sämtliche DOS-Aktivitäten auf jeden Fall Großbuchstaben-PETSCII anzeigen können. Dazu kommen einige ASCII-Zeichen, die in PETSCII fehlen (geschweifte Klammern, Tilde, Pipe) sowie die 96 Zusatzzeichen aus ISO-8859. Damit das alles in einen Zeichensatz passt wirst du sowieso tricksen müssen, ich gehe davon aus dass 3,4 oder fünf Zeichen weggestrichen werden müssen. Wie man das am besten auf die jeweiligen Text-Encodings mappt bzw. welches Encoding am wenigsten Klimmzüge (sprich: Zeichenersetzungen bei der String-Ausgabe) benötigt, müsste man mal ausprobieren. Reines ISO-8859 wird sich nicht 1:1 umsetzen lassen.

    Da ist zu erkennen, dass Notepad zumindest unterschiedliche Encodings (Menüpunkt: Encoding) unterstützt (und das Encoding auch am unteren Textrand anzeigt). Was sich in der Aufzählung hinter "more ..." verbirgt, kann ich leider nicht sagen.

    Er macht wohl 'ANSI' (CP-1252) und UTF-8.

    Das wusste ich vorher. Wie gesagt, ich weiß grundsätzlich, wie Encoding mit einem oder mehreren Bytes funktioniert.

    Du hast behauptet, dein ISO-8859-Texteditor könnte Unicode unverändert laden ("ist damit kompatibel"), nicht ich.

    Um das nochmal genauer zu klären: Du meinst, du kannst auf dem C64 automatisch erkennen, welches 8-Bit-Encoding verwendet wird. Wie machst du das? Und du willst UTF-8-Text vom PCeinlesen und dann z.B. die Umlaute in 1-Byte-Codierung umwandeln? Richtig?

    Ja, richtig. UTF-8 im Sinne von "nur UTF-8-Zeichen, die in unserer lokalen Codepage auch vorkommen". Ist jetzt nur Brainstorming, aber ungefähr so würde das aussehen:

    • nur 7-Bit-Werte: ASCII
    • auch 8-Bit Werte, aber immer paarweise, erster Wert beginnt binär mit "11", der zweite mit "10": UTF-8 -> Konvertierung der 8-Bit-Zeichenpaare, Warnung bei nicht unterstützten Zeichen. Gibt es Ketten mit drei oder vier 8-Bit-Werten, sind das nicht unterstützte Unicode-Zeichen (rate ich mal, müsste man überprüfen)
    • auch 8-Bit Werte, aber nur im Bereich 160-255: ISO-8859-15
    • auch 8-Bit-Werte, inklusive 128-159: CP-1252 -> Konvertierung der Zeichen 128-159, Warnung bei nicht unterstützten Zeichen, die konvertiert werden müssen

    An PETSCII hatte ich bisher noch gar nicht gedacht, das müsste man sich noch überlegen ob/wie man das erkennt. Da müsste man dann natürlich einen separaten Zeichensatz verwenden.

    Ja, so mächtige Texteditoren, wie mein kleiner kostenloser, mit dem ich Plaintext bearbeite. Oder den bei macOS mitgelieferten Mini-Editor. Ich gehe daher davon aus, dass auch Windows Notepad mit ISO 8859 umgehen kann. Deine Editoren können echt nicht mit unterschiedlichen Encodings umgehen? Ausgerechnet auf Linux, das ja eher so technisch daherkommt?

    Mein Editor kann das natürlich, weil ich es (und mehr) brauche. Die Standard-Editoren der diversen Linux-Desktop-Umgebungen können das aber nicht - zumindest nicht die drei oder vier, mit denen ich bisher zu tun hatte. Mein letzter Notepad-Kontakt ist mehr als ein Jahrzehnt her, aber Microsoft hat nie ISO-8859 unterstützt - die sind direkt von CP-1252 auf UTF-8 gewechselt.


    Solche vorinstallierten Editoren sind ja eher dazu gedacht, mal eine Readme-Datei zu lesen oder ein Batch-Skript zu bearbeiten. Es reicht völlig, wenn die das lokale Encoding unterstützen. Das ausgerechnet MacOS mit einem Editor kommt, der das kann, wundert mich. Aber vielleicht ist das noch wegen des Wechsels von Classic zu OS X - ich nehme an, dass Classic auch ISO o.ä. als Encoding benutzt hat.

    Ich habe ja für dich nachgeschaut und es verlinkt. Bis zum Ende von 8 Bit (FF) ist Unicode mit Latin 1 identisch

    Seufz, ich geb's auf. Ich hab dir jetzt drei Mal erklärt, dass Unicode und UTF-8 nicht das selbe sind, inklusive einem Link auf Wikipedia.


    Ich hänge mal zwei Textdateien an, der String "Ächz..." ein mal als ISO-8859, und ein mal als UTF-8. DU wirst feststellen, dass die zweite Datei ein Byte größer ist. In Hex-Darstellung sehen die beiden Dateien so aus:

    Code
    1. christoph@Desktop:~/Temp$ xxd -b uft8.txt
    2. 00000000: 11000011 10000100 01100011 01101000 01111010 00101110 ..chz.
    3. 00000006: 00101110 00101110 00001010 ...
    4. christoph@Desktop:~/Temp$ xxd -b iso8859.txt
    5. 00000000: 11000100 01100011 01101000 01111010 00101110 00101110 .chz..
    6. 00000006: 00101110 00001010 ..


    Nö. Auch hier favorisiere ich den Weg mit den wahrscheinlich geringsten Stolpersteinen. Dein Weg würde doch bedeutet, dass ich einen Text vom PC auch schon auf ein 8-Bit-Encoding umstellen müsste – oder willst du auf dem C64 wirklich direkt einen UTF-8-Text umwandeln?

    Ich halte es für machbar ISO-8859, 1252 und eine ISO-8859 entsprechende Untermenge von UTF-8 auf dem C64 zu erkennen und beim Laden/Speichern automatisch in die/von der lokalen Kodierung zu konvertieren, genau wie auf dem PC. Damit bliebe der Textaustausch in beide Richtungen für den Nutzer komplett transparent, und er muss sich um Codepages keinen Kopf machen - es sei denn, er nutzt Zeichen, die ISO-8859 (und damit der C64) nicht kann.

    Und auf dem C64 führst du dann eine weitere Umwandlung durch, um in 7 Bit eine variable Untermenge des 8-Bit-Zeichensatzes darstellen zu können. Da habe ich dich doch richtig verstanden, oder?

    Unter Umständen, ja. Nutzt der Texteditor einen eigenen Zeichensatz (egal ob im Bitmap- oder Textmodus) nehme ich eine 8-Bit-Kodierung, ansonsten halt 7 Bit. Ist aber von der Frage unabhängig, ob ich beim Laden/Speichern konvertieren soll.

    Deswegen weiß ich immer noch nicht, was dein ganzes Konvertier-Problem in diesem Thread zu suchen hat.

    Das hatte ich bereits erklärt. Unabhängig davon, welche Darstellung dein Texteditor nutzt, wirst du mit ISO-8859 nicht sehr weit kommen, da das nur beim Amiga das Default-Encoding ist. Einfache (sprich: vorinstallierte) Linux-Texteditoren lassen in der Regel keine Auswahl des Encodings zu, meine (limitierten) Erfahrungen mit Windows sagen mir dass es dort auch so ist. Der Nutzer müsste also u.U. einen anderen, mächtigeren Texteditor installieren, um Texte austauschen zu können. Und er muss über Codepages Bescheid wissen und manuell in der richtigen Kodierung speichern bevor ein Text zum C64 geht.


    Diese Probleme lassen sich m.E. vermeiden.

    Ich weiß, wie Unicode grundsätzlich funktioniert. Ich meinte mit "basiert" bzgl. ISO/Unicode nicht "code-kompatibel" sondern "historisch daraus entstanden". [...] Edit: Aber um nochmal auf die konkrete Belegung zurück zu kommen: Die Zeichen-Belegungen 80 bis FF (also bis zum Ende von 8 Bit) sind nach kurzem Überfliegen meinerseits bei Unicode und ISO 8859-1 absolut identisch.

    In irgendeiner Unicode-Page sind sie identisch, das mag sein (hab's nicht nachgeschaut). Ein Texteditor liest und schreibt aber eben nicht Unicode, sondern UTF-8 - und bei UTF-8 sind alle nicht-ASCII-Zeichen mit zwei oder mehr Bytes kodiert. Ich hatte die entsprechende Erläuterung aus Wikipedia bereits verlinkt.

    Hier ist wieder eine Stelle, wo du mich nicht richtig verstehen WILLST – was man an der Polemik im letzten Abschnitt erkennt. Erst einmal entscheide ich gar nichts, ich mache Vorschläge. Und die basieren u.a. darauf, dass eine Zusammenarbeit des C64 mit dem PC nicht unnötig verkompliziert wird.

    Ich werde versuchen, in Zukunft weniger flapsig zu formulieren - du wirst dann immer gleich so unangenehm bissig.


    Das war eine ernst gemeinte Frage, die du irgendwie nicht richtig verstanden hast. Du hast bisher immer Lösungen favorisiert, bei denen der C64 PC-Inhalte oder -Konzepte unverändert verarbeiten oder nachahmen soll: Proxies für WWW, Chat und Netzlaufwerke, eine GUI die möglichst modern aussieht usw.


    Ausgerechnet beim Texteditor brichst du mit diesem Ansatz aber - obwohl das hier mit vergleichsweise wenig Aufwand realisierbar ist, lehnst du eine Formaterkennung und -konvertierung ab. Das soll der Nutzer auf dem Fremdsystem erledigen und den Text erst im richtigen Encoding speichern, bevor er ihn an den C64 übergibt.


    Ich erkenne da auf den ersten Blick keine Linie, deswegen mich würde interessieren wieso du das mal so und mal so handhaben willst.

    Der 2. Unicode Codeblock ist meines Erachtens ISO8859-kompatibel (Latin 1), der 1. enthält natürlich die ASCII-Zeichen.

    UTF-8, also das Unicode-Encoding was ein Texteditor verarbeitet, ist nicht ISO kompatibel. Vereinfacht ausgedrückt funktioniert UTF-8 so: Ist das höchste Bit in einem Byte nicht gesetzt, ist es ASCII - das hat ja nur 7 Bit. Ist dieses Bit gesetzt ist das das Signal für die verarbeitende Software, dass jetzt ein Unicode-Zeichen kommt. Aufgrund der Menge an Unicode Zeichen werden dann mindestens zwei - bis maximal vier, glaube ich - Bytes genutzt, um festzulegen um welches Unicode-Zeichen es sich handelt.

    Wie gesagt, das ist egal, da man bei Text-Editoren das Encoding einstellen kann, zumindest bei meinen.

    Das Encoding des "Partner"-Systems ist relativ uninteressant, damit wird der C64 höchstens bei Dateinamen konfrontiert

    Das Encoding des Fremdsystems ist das Encoding, was Texteditoren im Normalfall benutzen. Ich kann das bei meinem Editor auch ändern, das ist aber bei simplen Texteditoren eher die Ausnahme als die Regel.


    Ich verstehe nicht, wonach du entscheidest, welche modernen Technologien dein Wunsch-OS beherrschen soll und in welchen Fällen die Daten auf einem Fremd-System aufbereitet werden müssen, bevor sie der C64 zu Gesicht bekommt. Bisher war doch die Philosophie, möglichst kompatibel mit der modernen Welt zu sein - notfalls, in dem man einen Großrechner unter dem Schreibtisch versteckt und den C64 nur noch als graphisches Terminal benutzt.


    Wenn ich also für WWW, Chat und das von dir angesprochene "Netzwerklaufwerk" einen Proxy benutze, damit ich ohne irgendwelche Verrenkungen mit meinem Windows/Android/etc.-Kosmos kompatibel bleibe, wieso diesen Anspruch und den dazugehörigen Ansatz bei Textdateien gleich wieder aufgeben? Wenn ich jetzt drüber nachdenke, hätte ich eigentlich eine Antwort der Sorte "Encoding ist egal, da solche Texte ja vom Netzlaufwerk geladen werden, und der Netzlaufwrks-Proxy das automatisch nach ISO-8859 konvertiert" o.ä. erwartet.

    Jein – ich habe gesagt, dass man bei Bitmap-Darstellung Text zu 100% ISO-8859-kompatibel kodieren kann, weil man auf invertierte Zeichen verzichten kann. Und bei einem Char-Mode-UI geht das eben nicht. Punkt. Das ist nach wie vor Fakt und nicht diskutabel.

    Du hattest behauptet, ISO-8859 hätte 256 Zeichen und nahegelegt, man sei verloren wenn man die nicht alle gleichzeitig darstellen kann. Beides ist falsch, das hatte ich richtig gestellt.

    Zum einen ist Windows Codepage 1252 sehr nah dran, zum anderen können auf meinem Rechner die Editoren die meisten bekannten Encodings lesen und speichern. Unicode basiert übrigens auf ISO-8859 und ist damit kompatibel.

    Unicode ist nicht mit ISO sondern mit ASCII kompatibel, alles außerhalb der ersten 128 Zeichen (also bspw. deutsche Umlaute) wird mit zwei oder mehr Bytes kodiert.


    1252 ist zwar sehr nah an ISO - aber der Euro ist eben anders kodiert. Und Gedankenstrich, Auslassungspunkte oder Filled Bullets sind ziemlich gängig bei Texten von Windows-Nutzern, genau wie die diversen zusätzlichen Anführungszeichen.

    Wenn du die Konvertier-Problematik also weiter besprechen willst, wäre dafür einer der Text-UI-Threads der richtige Ort – denn nur da gibt es das Problem.

    Angesprochen hast du diese Thematik, mehrfach. Ich weise lediglich auf Probleme hin, die es natürlich auch bei Bitmap-Darstellung gibt. Aber wenn dir das zu viel Realität ist, können wir ja wieder den Chat-Proxy diskutieren, der Multitasking simuliert in dem er meine Chat-Sitzung speichert und für mich in Abwesenheit protokolliert ;)

    github.com/mist64/final_cartridge allerdings kann es sein, dass sich der Copyright-Vermerk (Public Domain) auf den disassemblierten Quelltext bezieht, nicht auf den Original-Code.

    Danke. Allerdings lese ich auch so, dass das Original nicht frei ist: er erwähnt ja nicht dass er die Erlaubnis hätte. Außerdem macht Michael Steil mehrere solche Projekte, und GEOS 2.0 ist ganz sicher nicht freie Software.