Beiträge von Korodny

    Vielleicht könnte man ja mal bei TD1334 anfragen? Sein Bitte melde dich an, um diesen Link zu sehen. ist noch keinen Monat alt, der Code deshalb noch weitestgehend frisch im Kopf und vielleicht hat er Ideen, wie man den auch für "ASCII-kompatibel" anpassen kann?

    Oh danke, der ist komplett an mir vorbei gegangen. PA-Basic ist mir auch neu, lauter aufregende Sachen ;) Der Editor ist gerade nach drei Zeilen Text abgeschmiert, muss ich mir mal noch genauer ansehen.

    Und mit 3 Zeilen bin ich auf dem C64 fast noch sparsam. Guck dir mal die beliebten (wohl meistgenutzten) C64-Textverarbeitungen StarTexter Und Vizawrite an:

    Genau mit denen habe ich jahrelang gearbeitet - da stammt meine Abneigung gegen zu viele UI-Zeilen ja her ;) *Heutige* Abneigung muss man korrekterweise sagen, damals kannte man ja nichts besseres.

    Aber so arbeitet doch niemand: Erst Commodore-taste drücken, lesen und dann die zweite Taste.

    Macintosh-Umsteiger, die sich keine Shortcuts merken können, könnten dann so arbeiten. Der Rest von uns macht einfach weiter Control-F ohne hinzugucken, um den nötigen Punkt aufzurufen.

    Da würde nichts "eingeblendet" werden.

    Noch mal, zum Mitschreiben: Ich widerspreche dir nicht. Wenn du es nicht "Einblenden" nennen willst, nenne es "Überschreiben" oder "Magic Bar". Mein Punkt ist lediglich, das ein nur bei Bedarf sichtbares Menü keinen Mehraufwand macht.

    Ich nicht so oft. Aber vielleicht jemand, der dort lebt und sich für mein ß kein bisschen interessiert. Du scheinst davon auszugehen, dass nur Deutsche, Schweizer und Franzosen den Editor (mit gleichem Encoding) verwenden. Mich erinnert das an die Lokalisierungen z.B. des C128, der auch immer nur die nötigsten Zeichen der jeweiligen Sprachversion enthielt.

    Nein, das hast du völlig falsch verstanden. Bei Nutzung von UTF-8/Unicode ist jedem Zeichen im Text ein fester, "weltweit" einzigartiger Code zugeordnet. Die Einschränkung ist lediglich, ob wir das jeweilige Zeichen auch korrekt darstellen können/wollen. Jemand der keine Umlaute braucht, oder kyrillische Zeichen, hat dann eben einen anderen Ausschnitt aus dem Unicode-Spektrum als darstellbar konfiguriert.

    Bei Nutzung einer 8-Bit Codepage wie ISO, tritt dagegen u.U. genau das von dir beschriebene Problem auf: Ein und derselbe Zeichencode bedeutet vielleicht bei mir etwas völlig anderes als bei einem Slawen, Türken oder Russen. Und Windows schert sich sowieso einen Dreck um ISO-8859, das geht von CP-1252 aus, da darfst du schon mal jedes verwendete Euro-Zeichen nachbessern.

    Ich würde gerne darauf verzichten, erst das Menü einblenden zu müssen. Wenn ich es immer sehe, muss ich mir nicht merken, mit welchem Shortcut ich die jeweiligen Punkte aktivieren kann. Ich muss mir aber noch genauer angucken, wie die alten DOS-Textverarbeitungen genau damit umgegangen sind.

    DOS ist m.E. kein guter Vergleich, weil dort doppelt so viel Text auf den Schirm passt. 1000 Zeichen sind schon verdammt wenig, jedes weitere Zeichen schmerzt da in meinen Augen.

    Da ein Shortcut (bei einer Textverarbeitung) ja immer eine Kombination aus Qualifier und Buchstabentaste wäre, kann man ja alternativ das Menü auch einblenden, sobald die Qualifier-Taste gedrückt wird.

    (Hier geht es darum, den Bildschirminhalt zu retten) Ich frage mich halt, ob ich nicht alles Nötige in den 3 Zeilen lösen könnte. Bis auf den Dateidialog, bei dem ich vielleicht auf die fertige Fullscreen-Lösung von Petrus zurückgreifen würde.

    Ich hatte dir nicht widersprochen: man braucht irgendeinen Mechanismus, um (Menü und) Dialoge einblenden zu können. Wie der im Detail aussieht ist egal - mir ging es nur darum, dass "Einblenden" (des Menüs) an sich keine noch kein Zusatzaufwand wäre.

    Dann würde ich gleich Nägel mit Köpfen machen und auch das in ISO 8859 nicht vorhandene große SZ mit reinnehmen. Wären dann 8.

    LOL, ich wusste noch nicht mal, dass es ein großes SZ gibt, danke.

    Dein Ansatz ist recht national/regional, während ISO 8859-15 kompatibel zu einer relativ großen Bevölkerung/Sprachenvielfalt wäre.

    Nein, mein Ansatz ermöglicht *echte* Lokalisierung. Ob Kroaten überhaupt 8859-1(5) benutzen, weiß ich gar nicht - das ist schließlich "Western Europe" während es für "Eastern Europe" und "Southern Europe" eigene Code-Pages gibt.

    Aber wenn dieses Zeichen für ein 2-Byte-Zeichen steht (und die Wahrscheinlichkeit ist wohl nicht klein, wenn es unbekannt ist), muss ich doch diesen 2-Byte-Code im Text mit herumschleppen, oder?

    Nein. Der (oder die) Platzhalter sind natürlich einfache Bytes, die über eine separate Tabelle wieder (beim Speichern) dem ursprünglichen TF-8 Code zugeordnet werden können.

    Aber noch mal: Du überschätzt m.E. das Problem der "exotischen" Zeichen ganz erheblich. Ich nutze unter Linux nur UTF-8, muss aber oft Texte wieder als ISO speichern (für den Amiga/das Aminet) - Gedankenstrich oder ein Single-/Double-Quote außerhalb von ASCII kommen mir da ständig unter, aber das wäre ja abgefangen. "Bilić" war ein blöd gewähltes Beispiel, der ginge ja dank vorhandener französischer Sonderzeichen sowieso. Probleme würde eher so etwas wie Bitte melde dich an, um diesen Link zu sehen. machen, wie oft begegnest du solchen Zeichen?

    Für mich und meinen Entwurf bleibt nach wie vor die Frage offen, ob ich das 8. Bit (über ASCII hinaus) eher für Sonderzeichen (Sprachen und auch UI) oder Invers-Zeichen opfern möchte.

    Ich halte das für eine Frage, die der Programmierer und die Nutzer entscheiden, nicht der Designer. Natürlich würde jeder gerne (mich eingeschlossen) lieber einen Zeichenvorrat von 256 Zeichen nutzen. Die Frage ist, wie sich das auf die Geschwindigkeit beim Scrollen/Blättern auswirkt und wie viel Zusatzaufwand es für den Programmierer wird - Zeichen, die nicht dargestellt werden, machen Positionsberechnungen u.ä. deutlich komplizierter und langwieriger.

    Nehmen wir an, wir hätten einen Texteditor der 40 Zeichen pro Zeile einfarbig anzeigt, zwei Bildschirmzeilen gehen für Status o.ä. drauf. Der komplette Prozess zum Scrollen/Blättern sieht dann so aus:

    • Oberste sichtbare Zeile*40 → das ist unsere STARTPOSITION im Text
    • Ausgehend von STARTPOSITION 920 Zeichen in den Bildschirmpuffer kopieren

    Das war's. Keine Eventualitäten, die berücksichtigt werden müssen, das Farb-RAM wird nie angefasst, keine komplizierten Berechnungen oder Überprüfungen wo die nächste Zeile anfängt usw. usf.

    Jetzt versuch einfach mal, ähnlichen Pseudo-Code für einen Editor mit Farbcodes im Text zu schreiben.

    Wenn wir jetzt mal davon ausgehen, dass du deine invertierten Zeichen behalten möchtest, dann wären wir bei nur 32 Zeichen mehr als ASCII. Und wenn mir die vorgefertigte Auswahl nicht gefällt, ändere ich sie und werde so zu allen anderen inkompatibel und sehe immer wieder Platzhalter. Finde ich nicht so prickelnd.

    Ich schreibe täglich (oft längere) Texte - und nein, nicht nur hier im Forum ;) Was ich zusätzlich zu ASCII brauche, wären:

    • Umlaute (7 Zeichen)
    • einfache/doppelte Anführungszeichen in mehreren Sprachen, Auslassungspunkte, Gedankenstrich (10-12 Zeichen)
    • Euro, Pfund

    in die dann noch freien rund 10 Zeichen würde ich evtl. einen Bullet Point packen wollen, ein Paragraphenzeichen sowie französische Zeichen. Das alles passt gut in 128 Zeichen, ISO 8859-15 deckt davon aber einiges nicht ab (15, 16 Zeichen oder so? Müsste ich im Detail nachschauen). Slawische oder Skandinavische Namen - das was ISO noch kann, im Vergleich zu meiner imaginären Codepage - muss ich nie anzeigen oder gar eingeben können. Und selbst wenn: dass ich den Namen von Bitte melde dich an, um diesen Link zu sehen. theoretisch richtig schreiben könnte hilft mir ja nicht viel wenn ich gar nicht weiß, wie ich das Zeichen erzeuge. Dann schreib ich halt Bilic.

    Im Übrigen wärst du nie zu etwas "inkompatibel" - du siehst halt auf dem Schirm einen Platzhalter, wenn du deine Codepage nicht anpasst, gespeichert wird wieder der ursprüngliche Unicode. Das stößt natürlich an Grenzen - wir können ja nicht beliebig viele unbekannte Unicodes irgendwo zwischenspeichern - aber ich glaube du überschätzt den im Alltag notwendigen Zeichenvorrat deutlich.

    Wie macht der C64 das? Unicode-Zeichen können mit bis zu 4 Byte kodiert sein. Soll der Konverter wirklich im Textverarbeitungsprogramm integriert sein (und Speicher wegnehmen) oder soll ich wieder extern konvertieren, wo wir dann nicht weiter wären als heutzutage.

    UTF-8 ist nach Häufigkeit des Auftretens sortiert. Alles was in irgendwelchen ISO-Codepages vorkommt - behaupte ich jetzt mal, sind 2000 Zeichen glaube ich - wird in zwei Bytes kodiert. Vier Bytes sind dann schon sehr exotisches Zeug. Bei 32 Zeichen sollte man mit 100 Bytes Platzbedarf für eine Konvertierungstabelle schon sehr weit kommen.

    Aber ich verstehe nicht ganz, wie deine Lösung arbeitet, wenn mir ein französischer Freund einen Text mit vielen Akzentzeichen und Gedankenstrichen und seiner persönlichen Sonderzeichen-Auswahl von einem C64 zum anderen per Diskette zukommen lässt, wie dann mein Editor mit meiner persönlichen Sonderzeichen-Auswahl (natürlich nur mit den deutschen Umlauten) den dann sauber darstellt.

    ASCII hat 96 Zeichen. Je nachdem ob der C64-Editor 128 oder 256 verschiedene Zeichen für die Textdarstellung verwenden kann, bleiben also 32 oder (bis zu) 160 Zeichen frei, die für weitere Zeichen genutzt werden können. Die sind im Auslieferungszustand belegt - bei einer deutschen Ausgabe bspw. mit Umlauten, typographisch wichtigen Zeichen, französischen, spanischen und nordischen Sonderzeichen. Das ergibt die Menge der aktuell unterstützten Zeichen. Beim Laden/Speichern wird dann zwischen Unicode und der internen Codepage konvertiert.

    Eine andere Ausgabe (bspw. für eine slawische Sprache) würden dann von Haus aus eventuell andere Zeichen unterstützen. Darüber hinaus kann der Nutzer die unterstützen Zeichen auch mittels externem Editor ändern. Vielleicht braucht jemand keine Sonderzeichen für fünf verschiedene Sprachen, oder keine typographisch korrekten Anführungszeichen - will aber lieber noch ein paar Rahmensymbole, damit er seine Tabellen verschönern kann? Dann ändert er das Aussehen einiger Zeichen, den zugehörigen Unicode und evtl. die Tastenkombination, mit der sie erzeugt werden und startet die Textverarbeitung neu. Solche maßgeschneiderten "Codepages" kann es beliebig viele geben, es ist halt immer nur eine davon aktiv.

    Trifft der Editor beim Laden auf ein von der aktuellen Codepage nicht unterstütztes Zeichen, wird ein Platzhalter eingefügt und der Nutzer informiert.

    Auf jeden Fall muss man bei meinem Vorschlag nichts vom Inhalt buffern, weil irgendwas überlagert werden würde.

    Musst du auch bei einem nachträglich eingeblendeten Menü nicht, du kannst ja immer noch Status-Informationen durch eine Menüzeile ersetzen. Einen solchen Mechanismus musst du sowieso einbauen, wegen diverser Dialoge (Suchen/Ersetzen, Sicherheitsabfragen...)

    Hier im Forum wurden schon Bitmaps schneller gescrollt, als man sie lesen kann, da mache ich mir beim Color-RAM jetzt keine allzu großen Sorgen. Klar, geht es ohne schneller – aber niemand hier will einen Arcade-Titel à la Dropzone mit schnellem Scrolling realisieren.

    "schneller als man lesen kann" wird der dir bei der Arbeit mit Texten ganz schnell auf die Nerven gehen, weil viel zu langsam. Ich hatte mir farbliche Hervorhebungen auch schon vor Jahrzehnten auf dem C64 erträumt - weil das so nahe an WYSIWYG wäre, wie ich es brauche und Gliederungen (Überschriften) bzw. Hervorhebungen sehr schön sichtbar macht. Ich halte es schlicht für nicht praktikabel.

    Das mag dein Ziel sein – aber meines wäre, möglichst hohe Kompatibilität zum Rest der Welt hinzubekommen. Dafür gibt es Standards und die würde ich halt einfach verwenden, statt da wieder eigene Wege zu gehen.

    ich schlage vor, einen benutzerdefinierbaren Ausschnitt von Unicode mittels UTF-8-Kodierung zu unterstützen. Das ist ein erheblich bedeutsamerer Standard als ISO-8859: >99% aller Texte im Netz sind UTF-8 kodiert, <1% ISO.

    Wenn du Umlaute unterstützen willst, musst du eh einen eigenen Zeichensatz definieren. Dann kannst du auch gleich die ASCII- bzw. ANSI-Codierung verwenden.

    Schon klar, das war nicht der Punkt. Der Ansatz - den m.E. die meisten Editoren auf dem C64 verwenden - ist, die Daten so im Speicher abzulegen, dass man sie direkt in den Bildschirmspeicher kopieren kann, ohne das Farb-RAM anfassen zu müssen - das verdoppelt die Geschwindigkeit und reduziert den Speicherbedarf, macht aber farbliche Hervorhebungen im Text unmöglich.

    Wir haben oben eine Menüleiste und die Untermenüs erscheinen in der Zeile darunter (solange diese nicht für Menüdarstellung benötigt wird, nimmt sie allgemeine Infos z. B. Textlänge/position, freier Speicher usw. auf).

    Eine ständig eingeblendete Menü-Leiste braucht es, wenn man durch Anklicken direkt zu einem Menü-Eintrag springen möchte - sprich bei Mausbedienung. Bei Tastaturbedienung muss ich das Menü sowieso durch eine Tastenkombination aktivieren und dann erst den gewünschten Punkt wählen. Dann kann ich das Menü auch so lange ausgeblendet lassen, bis ich es brauche - und spare eine Bildschirmzeile.

    Hervorhebungen fänden mit Farbe statt, Invertierungen würden nicht benötigt, auch für den (Strich-) Cursor und die Scroll-Anzeige nicht (beides mit Sprites realisiert). Bedienung per Cursor/Hiliting und Keyboard-Shortcuts.

    Obwohl der Gedanke naheliegt, bei geringem Zeichenvorrat Hervorhebungen (Blockmarkierungen, Kursiv, Fett o.ä.) in Farbe zu machen, kenne ich keine Textverarbeitung, die das macht. Startexter markiert zumindest Blöcke farbig, aber das auch nur Zeilenweise. Die meisten Textverarbeitungen dürften den Text intern als Screencodes speichern um das Scrolling zu beschleunigen. Bei einer Textverarbeitung will ich maximal schnelles Scrolling - Farb-RAM stört da nur.

    ISO-8859 hat 192 Zeichen, keine 256. davon noch mal 64 rauszustreichen sollte kein Problem sein. Ziel ist es ja nicht, volle Unterstützung für ISO zu garantieren, sondern dem Nutzer einen Zeichenvorrat an die Hand zu geben, mit dem er klarkommt oder den er auf seine Bedürfnisse zuschneiden kann. ISO ist sowieso ein Kompromiss, weil diverse typographisch bedeutende Zeichen fehlen (richtige Anführungszeichen, Gedankenstrich, Auslassungspunkte) - also lieber UTF nehmen und den Nutzer 128 Zeichen auswählen lassen.

    GUIs kann man auch mit nichts weiter als reversen Alphanumerischen Zeichen + SPACE bauen, "flat" ist ja schließlich in.

    Jammet :

    Hast du dir Jasword denn mal angesehen? 80-Zeichen-Modus und ASCII laden, das sollte deinen Anforderungen doch ziemlich nahe kommrn.

    Ob man die Übersetzungstabelle für ASCII/ISO auch automatisch beim Start laden kann,weiß ich nicht, das müsste man sich hskt mal anschauen.

    Mike:

    Keine Ahnung, wieso du meinst da jetzt mitmischen zu müssen? Jammet war irrtümlich der Meinung, vi65 würde ASCII erzeugen - da DaBrowse das halbwegs lesbar darstellt. Das haben wir ganz ohne deine "Hilfe" geklärt ;)

    Oh, Bitte melde dich an, um diesen Link zu sehen. fällt mir gerade noch ein - das konnte auch ISO-8859 (als ASCII+128 weitere Codes) laden/speichern. Ich glaube dazu musste man eine Umwandlungstabelle laden, dann wurden Texte beim Laden/speichern konvertiert.

    Sorry. Ich bin eben etwas ahnungslos. Auch Ahnungslose können vi benützen ;3.

    Hehe - dann kann er ja nicht so schlimm sein ;)

    ich möchte ASCII Texte auf dem 64er nicht nur lesen sondern auch bearbeiten

    Dann ist der ANSI-Editor deine einzige Wahl, soweit ich weiß. Es sei denn, vorher/nachher konvertieren käme in Frage - dann kannst du (dank Gnylf) auch andere Editoren verwenden, theoretisch auch einige Textverarbeitungen. Aber das ist halt schon arg umständlich.

    Hab's gerade mal ausprobiert: DaBrowser zeigt tatsächlich ASCII an, ausprobiert mit einem unter Linux erstellten Text. Allerdings funktioniert auch PETSCII halbwegs: die Kleinbuchstaben werden naturgemäß als Großbuchstaben angezeigt, die Großbuchstaben werden einfach so konvertiert dass sie auch als Großbuchstaben erscheinen.

    Das würde erklären, wieso Jammet einen Text mit vi65 erstellen und mit DaBrowse anschauen konnte. Die Frage ob er denn jetzt ASCII oder PETSCII will, ist damit aber immer noch ungeklärt.

    Wer ist "man"?

    Diejenigen von uns, die eine Verwirrung wie hier im Thread vermeiden möchten.

    Dir ist schon klar, daß das längst geklärt ist?

    Nein, ist es nicht. Jammet spricht davon, dass er einen Text mit vi65 erstellt und "mit dem ASCII Viewer" angeschaut hätte. Das kann nicht sein, da vi65 nur PETSCII macht. Irgendwo wird hier also der Begriff ASCII falsch verwendet - wo, das können wir nur mit Jammets Hilfe klären.

    Wie bereits gesagt, der schreibt von Haus aus lesbare Dateien ohne Steuerungszeichnen gleich ganz am Anfang und es läßt sich mit dem ASCII viewer anschauen. Solange ich PETSCII nicht in das Dokument einfüge wird das so bleiben

    Ah, das erklärt die Verständigungsschwierigkeiten. "PETSCII" hat erst mal Nichts mit Sonder- oder Steuerzeichen zu tun - sondern damit, welche Zahlenwerte welchen Buchstaben zugeordnet sind:

    • ASCII: "A" = 65, "a" = 97
    • PETSCII: "A" = 97, "a" = 65

    Jetzt klarer?

    vi65 benutzt PETSCII - damit kannst du keinen Text bearbeiten, der auf einer anderen Plattform erstellt wurde. Es sei denn du kannst damit leben, dass alle Groß- und Kleinbuchstaben vertauscht sind. Außerdem gibt es eventuell Probleme weil Texte auf anderen Plattformen keine Startadresse haben, während ein C64-Programm bei einer "PRG"-Datei die ersten zwei Zeichen normalerweise als Startadresse interpretiert.

    Wenn du tatsächlich ASCII-Texte berarbeiten willst, ist der von Larry empfohlene ANSI-Editor deine einzige Option. Oder hin- und herkonvertieren vor/nach dem Bearbeiten.

    Ich gehe davon aus, dass der DaBrowser - den du mehrfach erwähnt hast - auch nur PETSCII macht. Deswegen habe ich immer noch Zweifel dass du wirklich ASCII meinst. Kannst du mal ein paar Beispiele für Dateien angeben, die dir über den Weg gelaufen sind? Wo waren die her, wie sind die auf die SD-Karte gekommen, hast du die auf einem D64 gefunden usw.? Oder mal eine Datei an einen Beitrag anhängen, dann haben wir Klarheit.

    Ich frage mich die ganze Zeit wie man so lange Zeit an keinem einfachen Textaustausch zwischen 64er und z.B. Dos oder wasauchimmer interessiert war. Ich hätte mir immer wieder Texte anschauen wollen wenn ich darauf angewiesen wäre, gerade besonders in den frühen 90ern. Also auch auf DOS Computern, copy und paste ohne Reue und manueller Prüfung.

    Damals waren serielle Verbindungen (Modem oder Nullmodem) oder Laufwerke, die DOS-Disketten lesen/schreiben konnten, die gängige Technik zum Übertragen von Dateien. Sowohl Terminalprogramme als auch Disk-Tools wie Big Blue Reader oder Little Red Reader konnten solche Konvertierungen auf Wunsch erledigen. Auch sonst gab's reichlich Konverter, bspw. in der 64'er, oder Bitte melde dich an, um diesen Link zu sehen. von King Fisher/Triad.