Beiträge von Retrofan

    Simple aktive Kühler sind kühlen besser.

    Was mich bei denen beschäftigt: Genau da, wo die Kühlung am Wichtigsten wäre (in der Mitte), sitzt der Motor des Lüfters und deckt die Stelle ab. Kühlrippen sehe ich bei diesen am Ehesten an den Ecken. Ist das nicht sehr ineffektiv?

    Wo greift man am Besten Strom ab (und wie viel Volt wären das)? Lüfter finde ich zumeist mit 5 oder 12 V.

    Höhere Kühlkörper passen unter Umständen nicht in den 475.

    Ich hatte ja erst daran gedacht, einen niedrigen Kühlkörper zu verwenden und darauf einen Lüfter zu setzen (falls es diesen Aufwand bräuchte) aber dafür wird die Höhe evtl. nicht reichen, oder? Weißt du zufälligerweise, wie hoch es bis zum Abschirmblech ist? Sonst versuche ich das mal mit Knetgummi herauszufinden.

    Auf der Doreco-Party hat mir stynx gezeigt, wie man mit einer kleinen Bitte melde dich an, um diesen Link zu sehen. den Performa (LC) 475 von 25 auf 33 und sogar 40 Mhz übertakten kann. Ich habe die Software installiert und sie läuft einwandfrei (Mit Marathon, Doom und Speedometer getestet). Bei 33 MHz erreicht man ca. 30% mehr Gesamt-Performance, was schon ganz schön ist – für null Kosten oder Bastelei.

    Mein 32 MB-RAM-Riegel (72 Pin PS/2) läuft mit 60ns (laut eigener Beschriftung), sollte also schnell genug sein, vielleicht sogar für mehr als 33 MHz?

    Da ich die 33 MHz nur kurz (und die 40 MHz noch gar nicht) getestet habe, möchte ich nun für eine Dauerlösung die CPU kühlen. Reicht da ein Kühlkörper oder besser gleich mit einem Lüfter (50 mm?) ergänzen? Was braucht man da – 5 oder 12V?

    Wärmeleit-Kleber hätte ich da – soll/kann ich den verwenden, um den Kühlkörper zu fixieren?

    Funktioniert das Hochtakten auch, wenn ich in den 475 einen vollwertigen 68040 (mit FPU, z.B. aus einem Quadra) einbaue? Oder bekommt der Probleme, weil die FPU ja (laut Internet-Quellen) intern mit doppeltem Takt arbeitet? Müsste man den stärker kühlen?

    ----

    Und nach einem Absturz (Spieletest) fährt der Mac gerade nicht mehr richtig hoch. Meine Mac System 7-Erfahrungen sind doch über die Zeit etwas eingerostet und ich komme gerade nicht weiter. Rechner bootet durch und lädt seine Erweiterungen aber just, wenn er den Desktop laden will, friert der Rechner ein. Mac OS-Lade-Fenster verschwindet, Leere Menüleiste, grauer Hintergrund, Mauszeiger eingefroren. Finder defekt? Desktop-DB korrupt?

    Edit: Schon besser – von einem externen Laufwerk kann ich starten, einige Tastendrücke beim Start sind mir wieder eingefallen, Erste Hilfe "repariert" gerade das Startlaufwerk. Mal gucken ....

    Ich habe das Board nach offensichtlichen Fehlern abgesucht aber noch nichts gefunden. Ich stelle diese Fehlersuche erstmal hintenan. Der Mac hat auch noch ein Netzteil-Problem (ich will gucken, ob eines vom IIcx passt) und ich muss eine NuBus-Grafikkarte für den Quadra suchen. Für beides muss ich in mein etwas entfernt liegendes Lager. Danke schonmal für die Hilfe – und ich melde mich, wenn es neues zu berichten gibt.

    Nun ja, eine weitere Diskussion scheint mir müßig – außer Korodny fängt doch noch an, irgendwas in der Art zu coden (da würde ich mich dann aber nicht weiter einmischen, da wir wohl eh nicht "zusammenkämen"). P1X3L.NET ist hier raus, wir sind gedanklich schon wieder bei anderen (WIP-) Projekten. Ein schönes WE.

    Ich hatte Markdown-Dateien mehrfach ausgeschlossen. Da liegt der Fall komplett anders. Mir ging es um reine Textdateien.

    Was sind denn Markdown-Texte anderes als "reine Textdateien"? In welchem Format speicherst du die ab? Also, ich verwende da .txt, keine Ahnung, was du so machst. ;)

    Und warum sollte man Markdown nicht am C64 mit einem geeigneten Editor bearbeiten wollen? Gerade das ginge mit einem eingeschränkten 40-Zeichen-Editor ohne Auszeichnungsmöglichkeiten doch ganz wunderbar, bzw. wäre DIE Lösung, einem auf dem C64 geschriebenem Text schon Auszeichnungen mitzugeben.

    Von mir wurde hier (meistens von dir) mehrfach verlangt, Beispiele zu suchen, zu zeigen und zu verlinken usw., was ich immer brav tat. Im Märchen bekommt der Protagonist nach den bestandenen Aufgaben immer die Prinzessin oder ein halbes Königreich, hier halt gar nichts, nicht mal einen C64-Editor. :cry

    Es ging ja ausdrücklich um Texte, die von Dritten stammen

    Ich weiß gar nicht mehr, wann und warum irgendwann dahin abgebogen wurde, denn das war nicht das ursprüngliche Ansinnen. Jammet suchte nach einem Editor, mit dem er auf dem C64 echte ASCII- (nicht PETSCII-) Texte schreiben/editieren kann (zumindest kam das nach einigem Hin und Her dabei heraus). Gab's nicht aber ich fand die Idee ganz cool – wegen Datenaustausch mit dem PC/Mac. Niemand am Anfang wünschte einen Text-Viewer, der kompatibel zur imaginären Internet-TXT-Bibliothek sein sollte (egal wie die formatiert ist). Es ging um das eigene Schreiben von Text, dank ASCII (und in Erweiterung ISO8859 oder UTF-8) kompatibel zwischen C64 und PC. Warum ist das Anforderungsprofil so weit abgedriftet?

    Also, ICH kann meine Texte an Gegebenheiten anpassen. ICH brauche keine 80-Zeichendarstellung, meine TXT-Dateien würden auf dem C64 sauber umbrochen werden (ja, die Zeilen sind kurz aber daran hätte man sich gewöhnen können). Ich hätte die UTF-8-Kompatibilität spannend gefunden, auch die Lösungen, um auf dem C64 z.B. Umlaute zu tippen usw.

    Die Anforderung, Alle ASCII-Texte der Welt (und vor allem die mit fester 80-Zeichen-Formatierung) möglichst gut importieren/darstellen zu müssen, hat das Projekt für mich uninteressant gemacht, vor allem weil das bei ALeX der Einfachheit halber geheißen hätte, NUR diese Art von Texten (mit kurzen, festen "Zeilen"/Absätzen) bearbeiten zu können. Sowas brauche ich nicht, dann lasse ich es lieber sein.

    Und das habe ich gestern Abend auch so mit ALeX besprochen und die Sache gecancelt. Glücklicherweise haben wir auch so genügend anderes (gemeinsames) zu tun, wir fallen also in kein tiefes Loch. ;)

    Der Wunsch nach Umlauten kam nicht von mir selbst. Kompatiblität damit beim anzeigen wäre sicher schön, aber wie ich diese am C64 selbst schreiben wollen würde, keine Ahnung.

    Ich habe ja ganz allgemein von "man" gesprochen. Von mir wäre es auf jeden Fall ein Wunsch gewesen. Bei dem erweiterten Encoding geht es ja erstmal um die Übernahme und auch Darstellung – wie man die Eingabe löst, kann ganz unterschiedlich (und vielleicht sogar auswählbar) sein. Ich würde für Deutschland als erstes eine DIN-Belegung unterstützen, wie sie im C128 (auch im C64-Modus) ;) oder bei Nutzung eines Emulators (oft) vorhanden ist. Und man kann natürlich auch die Eingabe-Lösungen von Linux, Windows und Mac versuchen nachzubilden.

    ----

    Der Witz ist ja, dass mein Wunsch nach "beliebig" langen Absätzen ALeX' Ansatz ins Straucheln brachte. Gerade Korodnys künstliche Begrenzung auf 80 Zeichen bis zum nächsten Linebreak hätte AleX das Leben/Coden wohl deutlich leichter gemacht. Aber das wäre halt kein Editor, den ICH benutzen wollen würde. Und was soll ich einen Editor forcieren, den ich selbst gar nicht gebrauchen könnte.

    Ich "warte" jetzt einfach darauf, dass es vielleicht doch irgendwann einen echten 80-Zeichen-Texteditor (im Bitmap-Mode) für den C64 gibt – hoffentlich mit (teilweiser) UTF-8-Unterstützung.

    Das Netz ist nun mal voll mit 80 Zeichen-Beschreibungen von "alter" Software und genau das ist doch ein Bereich, der auch für C64-Fans noch interessant ist. ;)

    Nur sollte der Editor nie ein Textbrowser fürs Internet werden. Ich war anfangs davon ausgegangen, dass Texte verarbeitet werden sollen, die der Autor selber abwechselnd am C64 und PC tippt (zumindest war das mein Grundgedanke). Und warum sollten diese Texte einen festen 80-Zeichen-Umbruch haben, wenn der Autor doch weiß, dass der C64 dafür nur mäßig geeignet wäre.

    Daher verstand ich die Richtung nicht ganz, die die Diskussion nahm.

    Und wenn ich was davon auf dem PC weiterverwenden will, dann schicke ich das einmal durch einen Konverter und gut ist.

    Wie mehrfach gesagt – dass war nicht das Gewünschte, weil man die Texte gerne kollaborativ/parallel auf C64 und PC bearbeiten wollte. Halt hin und her, mehrfach, immer wieder. Nicht nur einmal und gut ist's.

    Und man wollte Umlaute, Akzentzeichen, Sonderzeichen (z.B. verschiedene Anführungszeichen) und Formatierungen (über Markdown). Bei einer PETSCII-Konvertierung bliebe davon nur wenig übrig.

    Gleichzeitig halte ich es aber für übertrieben, zu fordern, dass so ein Editor mit jedem ASCII-Readme aus dem Internet kompatibel sein muss. Mir würde es reichen, wenn MEINE Texte vernünftig und verlustfrei zu bearbeiten wären.

    Außerdem verstehe ich nicht, dass überhaupt, wenn gerade diese externen Texte einem wichtig sind, gleichzeitig so ein Fokus auf UTF-8 und Sonderzeichen gelegt wurde. 99,9% dieser Readmes sind auf englisch und enthalten gar keine Zeichen über ASCII hinaus.

    Ändert aber nichts an der Tatsache, dass dieses "Format" bei Textdateien in der Praxis komplett irrelevant ist.

    Wie gesagt, umgekehrt wird mE ein Schuh daraus. Aber wir werden wohl nicht herausfinden, welche unserer Bubbles die größere ist. ;)

    Ich weiß aber trotzdem nicht, was das Problem sein soll. Ja, natürlich sehen Dokumente, die für feste 80 Zeichen erstellt wurden, auf nur 40 Zeichen manchmal blöde aus. Unlesbar werden sie dadurch aber nicht. Muss man halt wissen, ob man die trotzdem auf dem C64 bearbeiten wollen würde.

    Aber wie gesagt, die Gegenwehr macht es mir sehr leicht, mein Angebot, ALeX zu überzeugen, so etwas mit mir zusammen zu entwickeln, zurückzuziehen. Ein kleiner Stein fällt mir damit vom Herzen. Ich treffe ihn heute Abend ohnehin und kann ihm sagen, dass er vom Haken ist. :thumbsup:

    Kann jemand auf solche TEXT-Dateien verlinken, die im Netz herumschwirren?

    Sowas?:

    Bitte melde dich an, um diesen Link zu sehen.

    Okay, und wie bearbeitest du das jetzt weiter? Ich sehe hier (Geany unter Linux) 22 Zeilen, von denen die Hälfte zwischen 400 und 600 Zeichen hat - von denen ich lediglich etwas über 100 pro Zeile sehen kann.

    In allen Editoren, die ich habe und auch dem macOS Datei-Viewer Quicklook (per Space-Taste zu erreichen) sehe ich den Text vollständig. Er ist so breit, wie ich das Fenster ziehe.

    Bitte melde dich an, um diesen Anhang zu sehen.

    Okay, und wie bearbeitest du das jetzt weiter?

    Ganz normal, wie jeden (Plain-) Text. Ich verwende ja Plaintext, damit ich gerade keinen unnötigen Kram, keine Formatierung (auch nicht auf feste 80 CPL) drin habe.

    Das erste, was jeder Texteditor-Nutzer machen muss, ist diesen Text auf rund 80 Zeichen hart zu formatieren, ansonsten kann er ihn nicht sinnvoll bearbeiten.

    Eben nicht. Vielleicht tut das ein Programmierer, das will ich nicht ausschließen. Aber alle anderen verwenden natürlich Softwrap, damit die Zeilen ins Fenster (oder auf eine eingestellte Breite) passen.

    Deswegen habe ich auch noch nie ein Text- (kein Markdown-) Dokument in diesem Format bekommen.

    Ich habe gerade nochmal hier geguckt:

    Bitte melde dich an, um diesen Link zu sehen.

    Die Beschreibungstext für GitHub werden mit Markdown formatiert aber da steht nichts von 80-Zeichen-Zeilen – und dieser Beschreibungstext selbst hat auch keine solchen Zeilentrenner drin (fände ich auch überraschend). 80 CPL hat für Markdown keinerlei Relevanz und habe ich auch noch nie so verwendet/gesehen. Wer künstlich Linebreaks alle 80 Zeichen reinhauen will, kann das sicherlich tun – geht aber genau so gut auch ohne.

    Oder zumindest befremdlich / unüblich.

    Also, wie gesagt, in der Medienbranche ist das der übliche Weg, denn niemand kann sagen, wie breit ein Text später erscheinen soll. Man hält sich immer alle Optionen offen. Wenn ich unformatierten Plaintext bekomme (oder selbst erstelle) ist der IMMER so aufgebaut. Ansonsten, wie gesagt, muss ich die Linebreaks erst entfernen, weil sonst untauglich für die Weiterverarbeitung.

    Guck dir jede x-beliebige Wiki-Seite an, da findest du auch keine festen Linebreaks nach 80 Zeichen. Sowas will einfach niemand haben.

    Wahlweise sind die Blasen, in denen sich hier bewegt wird, inkompatibel.

    Das kann wohl sein: Medienbranche vs. Coder.

    Dass z.B. Readme-Texte für den Amiga (sowas waren ja die ersten "zufälligen" Texte) solche festen Linebreaks auf 80 Zeichen drin haben, wundert mich nicht, der hatte halt noch feste 80 CPL-Darstellung. Aber in Zeiten von dynamischen Layouts (Stichwort Smartphones) darf man einfach keine festen Zeilenlängen mehr verwenden. Das Gerät, der Browser, das Editorfenster, das Layout entscheidet, wie breit die Zeilen werden.

    ----

    Aber OK, wenn ihr euch das Leben künstlich schwer machen wollt, haut halt überall sinnlos Linebreaks rein. Und ja, vielleicht wäre ein C64-Texteditor mit nur 40 CPL nicht das richtige für euch. Ich könnte ihn zwar immer noch gut gebrauchen – aber ganz ehrlich, mit mir allein ist die Zielgruppe dann doch wohl zu klein. Da ALeX auch nicht so ganz begeistert war, sowas zu programmieren und ich eh lieber einen 80-zeichen-Editor (im Bitmap-Mode) hätte, erkläre ich das (glücklicherweise kaum gestartete) Projekt (aufgrund zu geringer Nachfrage) damit für gestorben.

    Damit kann ich mich dann auch wieder anderen Projekten zuwenden, bei denen stärker auf ein Release hingefiebert wird.

    Erstell' mir doch mal eine solche von dir herbeifantasierte Datei: reines UTF-8, ISO-8859 oder ASCII; mehrere Absätze; Linefeeds nur an Absatzenden. Und beschreibe, wie du sie erstellt hast.

    Die Beschreibung kann ich dir sogar vorab geben. Ich kopiere den Text einer beliebigen von mir hier verlinkten Webseite und füge ihn in meinem Editor ein und speichere ihn als TXT. So mache ich das täglich. Aber damit du mir das glaubst, mache ich das gerade einmal für dich und hänge ihn nachträglich hier an.

    Edit: Hier der Text: (wie meistens bei mir, außer jemand wünscht etwas anderes, mit UTF-8-Encoding und Unix-Linebreaks (LF))

    Es gibt nun mal zig Texte u.a. im Programmierbereich (v.a. solche READMEs) im Netz

    Ja, genau in dieser Nische, in 0,000000000001% aller Webseiten, kommen solche Texte vor. Und wer sich nur dort herumtreibt, findet natürlich solche Texte. Aber das ist eben nicht die Welt, nicht das "Normal", sondern "Nerd-Kram".

    Aber nehmen wir aktuellen Nerd-Kram: Ist GitHub nerdig genug? Hier ein link:

    Bitte melde dich an, um diesen Link zu sehen.

    Die Projektbeschreibung könnte man problemlos auf einem C64 mit kompatiblem Encoding editieren, keine überflüssigen Linebreaks enthalten.

    du arbeitest nicht oft mit Textdateien von Dritten, oder?

    Im Gegenteil, sogar sehr oft.

    Alles, was du von extern bekommst, wird exakt so formatiert sein

    Nein, höchstens einer von hundert Texten ist so formatiert. Und falls es doch mal passiert, nehme ich natürlich als erstes alle überflüssigen Zeilenschaltungen heraus, damit ich die Zeilenlänge selbst definieren kann. In den seltensten Fällen komme ich nämlich auf 80 Zeichen beim Output. Kein Buch hat 80 Zeichen, kein Magazin-Artikel, kein Katalog, keine Tageszeitung und auch keine Website.

    Du kannst ja auch einfach gucken, was du gerade vor dir hast: Hier im Forum gibt es keine Zeilenschaltungen bei 80 Zeichen (und bei den anderen 99,9% von Webseiten auch nicht), sondern erst, wenn jemand einen Absatz mit Return erzeugt. Und genauso arbeitet man in InDesign, Word, Simple Text, BBEdit oder jedem anderen textverarbeitendem Programm der heutigen Zeit.

    Kann sein, dass Coder anders arbeiten als der Rest der Welt.

    Ich beginne zu verstehen, dass du von irgendwelchen Fantasie-Texten ausgehst. bei denen Linefeeds nur an Absatzenden vorkommen, aber die gibt es halt in der Praxis nicht.

    Und ich denke genau das Gegenteil. ;)

    Ich gebe dir auch mal drei zufällige Webseiten (offene Tabs von mir):

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Bitte melde dich an, um diesen Link zu sehen.

    Wenn du die darin enthaltenen Texte kopierst und in einen Editor einfügst, wirst du feststellen, dass die Umbrüche nicht dort sind, wo sie im Original-Layout waren. Und genau so ist es auch bei nahezu jedem Text, den ich im Word-Format oder als Plaintext bekomme. Aber so arbeitet die Welt schon seit Jahrzehnten, hat nur wohl noch nicht jeder mitbekommen. ;)


    Edit: Upps, die neue Forums-Software macht ja aus simplen Links einen riesigen Aufriss mit Bild und allem. Sorry dafür.

    Es wird viel eingerückt. 8 Leerzeichen meistens.

    Nun ja, es gäbe notfalls die Lösung, dass beim Einlesen der Texte auf wiederholende Spaces hin geprüft und durch ein echtes Tab (spart ohnehin RAM) ersetzt wird. Dieses kann dann einstellbar viele Spalten (z.B. 3 oder 4) verbrauchen. Beim Speichern wird dann wieder zurückkonvertiert. Bei Korodnys Lösung muss ja ohnehin kräftig beim Laden und Speichern konvertiert werden, um die 2-Byte-Zeichen für den C64 verdaulich zu machen.

    Aber wie gesagt, man kann bei den Texten, die man dem C64 zumuten möchte, ja auch einfach gucken, womit er klarkommt. Keine Lösung auf diesem eingeschränkten Gerät wird je wirklich universell sein.

    Dann schau dir mal das an:

    Hat da jemand kilometerlange Einrückungen aus Spaces verwendet oder wie kommt das zustande? Sicherlich kann ich auch beim besten C64-Editor der Welt immer Texte aus dem Internet finden, die er nicht 1:1 darstellen/bearbeiten kann. Wir reden hier von einer über 40 Jahre alten Kiste mit nur geringer Büro-Tauglichkeit. Ich möchte mich viel lieber auf die Texte konzentrieren DIE er bearbeiten könnte.

    dann kann man 40 Zeichen Breite von C64 im Prinzip knicken.

    Nun ja, ich bin ja eigentlich nie der Verfechter der 40-Zeichen-Lösung gewesen. Ich bin Team "80-Zeichen im Bitmap-Mode". Ich habe nur versucht, auszuloten, ob man nicht notfalls auch was im 40-Char-Mode machen kann. Jetzt bin ich fast der einzige, der das noch verfolgt und habe das Gefühl, ich müsste das irgendwie verteidigen. Je stärker ich sehe, dass da was ginge, desto weniger (so mein Eindruck) tut es mein Umfeld hier. ;)

    Und wenn man schon extra einen ASCII-Editor bauen will, damit man problemlos Texte lesbar mit der Außenwelt austauschen kann

    Ich sehe den Anwendungsfall aber wirklich nicht darin, wahllos alle verfügbaren Internet-Texte auf den C64 zu laden. Allein bei der Länge vieler Texte bekommt er zwangsläufig Probleme. Ich denke schon, dass die paar Leute, die den C64 in einer gemischten Umgebung mit PCs oder Macs für Texteingabe nutzen wollen, um die C64-Beschränkungen bescheid wissen und ihre Aufgaben, die sie dem C64 übertragen, an dessen Fähigkeiten anpassen werden.

    Deswegen gleich wieder die Flinte ins Korn zu werfen und mit PETSCII und Konvertern und Verlusten arbeiten zu wollen, sehe ich nicht als wirkliche Alternative an.

    Allerdings geht auch langsam mein Enthusiasmus zurück, mit ALeX zusammen nach einer Lösung zu streben, da hier doch deutlich mehr Probleme gesehen werden, als ich erwartet hätte. Wir können unsere knappe Zeit auch gerne in ein Spiel oder die Software für das C64PicoCart stecken – das macht ohnehin mehr Spaß.

    Mal zur Illustration ein paar Beispiele die mir zufällig gerade untergekommen sind

    Erst einmal würde ich jeden, der mir solche Texte zwecks Weiterverarbeitung geben würde, mit der Puderquaste quer durch den Raum prügeln. ;) Wenn ich den Text auf irgendwas, was nicht zufälligerweise 80 CPL benötigt, darstellen möchte, darf ich per Suchen/Ersetzen erstmal alle überflüssigen Linefeeds entfernen. Aber sei's drum.

    Das letzte Mal, dass ich manuell Zeilenschaltungen an irgendeinem vermuteten Zeilenende ohne tieferen Sinn hinzugefügt habe, war auf einer mechanischen Schreibmaschine (da die keinen automatischen Wortumbruch kennt).

    Aber OK, "jeder" soll ja mit so einem Editor auf dem C64 arbeiten können, auch die, die meinen, Zeilen müssten gottgegeben immer 80 Zeichen lang sein. ;)

    Ich habe den ersten Text mal auf 40 Zeichen umbrochen, indem ich mein Editor-Fenster soweit zusammengeschoben habe. Folgendes kam dabei heraus:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Ich sehe da kein Problem, das auf dem C64 zu bearbeiten und wieder zurück zu sichern. Ich würde vielleicht Zeilenschaltungen mit einem Zeichen optional sichtbar machen, um automatischen (Soft-) Umbruch von Linefeeds zu unterscheiden. Das könnte dann so ähnlich aussehen:

    Bitte melde dich an, um diesen Anhang zu sehen.

    Wie gesagt, ich finde Markdown toll aber ich verstehe nicht, wofür du das genau an dieser Stelle (beim Zeilenumbruch) überhaupt benötigst. Kein Markdown-Tag sagt irgendwas zu Zeilenlängen oder Linefeeds.

    Die Frage ist doch, wieso willst du das in Echtzeit machen?

    Wer sagt denn sowas?

    Auch was Speicherverschiebungen von nachkommendem Text angeht, würde ich versuchen, das in "Denkpausen" durchzuführen. Angenommen, jemand fügt in der ersten Zeile eines längeren Absatzes ein Wort aus 5 Buchstaben ein und deswegen würde schon nach Eingabe von 3 Zeichen das letzte Wort der Zeile in die nächste rutschen (was Neuberechnungen zur Folge hätte und die weitere Eingabe verzögern würde), dann würde ich dieses "springende" Wort erstmal einfach "aus dem Bildschirm" schieben und erst bei der nächsten Eingabe-Pause (oder mit einem Kommando) den Umbruch wirklich durchführen.

    Bei einem Texteditor kommt dann - im Gegensatz zu einem Textanzeiger - dann ja noch die Möglichkeit von Modifikationen dazu: Der Nutzer setzt irgendwo mitten drin ein neues Absatzende, oder er ergänzt ein zwei Worte, oder er kürzt irgendwo - in allen Fällen musst du den ursprünglichen Text neu formatieren.

    Das ist doch genau das, wovon ich vor einigen Postings sprach und fragte, ob das ein Problem werden könnte. Wobei sich das mE durch jeden eingefügten Zeilenumbruch entschärft. Im Normalfall fängt ein Absatzende viele Änderungen ab. Erst wenn hier Zeilen-relevante Verschiebungen auftreten, führt es zu größeren Speicher-Änderungen.

    Ich hätte prinzipiell von "Softwrap" Abstand genommen: Langsamer und verkompliziert den Code.

    Letztlich kann Softwrap und Linefeed ähnlich behandelt werden, man muss nur darauf achten, dass unterschiedliche Codes dafür verwendet werden, um erstere beim Sichern entsorgen zu können. Ich kann mir immer noch nicht vorstellen, was das große Problem damit sein soll.

    (Und wenn die 40-Zeichen-Darstellung so große Problem bereitet, dann wäre ich doch dafür, gleich auf 80 Zeichen (und Bitmap-Mode) zu gehen. ;) Ich bin auf 40 Zeichen eingeschwenkt, weil ich dachte, das sei die deutlich einfachere Lösung.)

    Ich finde das Lineup grundsätzlich toll.

    Aber bei Cosmic Hero 2 hat mich etwas enttäuscht, dass das anfängliche Intro mit dem Raumschiff nicht zum eigentlichen Spiel wird/gehört. Ich hoffte beim Namen und der Animation auf etwas wie Defender oder Salamander.

    Bei "Schränker 4" (und auch Wee Ninja) musste ich denken: Hätte der Coder doch einen Grafiker zur Seite gehabt (sorry, falls das der Fall war) – dann hätte man da noch deutlich mehr herausholen können.

    Trotzdem: Coole Games!

    Bei Markdown kann ich das wie gesagt umgehen: Der Editor prüft beim Laden, was die längste Zeile ist: wenn sie größer 40 Zeichen ist, formatiert er auf 40 Zeichen und merkt sich, dass er vor dem Speichern wieder auf 80 Zeichen formatieren muss.

    Ich verstehe nicht, wofür du an dieser Stelle Markdown benötigst. Im Text sind doch die Linebreaks enthalten und werden beim Speichern unverändert zurückgesichert. Wenn vor dem Import im Text nach 80 Zeichen ein Linebreak kommt oder bei einem anderen Text nach 2000 Zeichen, was muss sich der Editor dabei merken? Der 40-Zeichen-Softwrap beim C64 ändert mE doch nichts am "Code". Oder was verstehe ich hier nicht richtig?