Apropos Zugänglichkeit: Kann man irgendwo ein komplettes (mehr oder weniger aktuelles) GEOS/MP3-D81 (o.ä.) herunterladen, das man so out-of-the-box auf C64 oder Emulation benutzen kann, wenn man sich dafür interessiert?
GEOS heute
- Retrofan
- Thread is marked as Resolved.
-
-
Schreiben direkt durch GEOS ist wegen des GEOS-Dateiformats schwierig.
Das ist es halt, was schnell ein Showstopper sein kann. Wenn man erst lange herumrätseln muss, wie man einen Text abwechselnd auf PC und C64 bearbeiten kann, ist die Sache eigentlich schon gelaufen. Heutzutage muss man ein Dokument schnell rein- und rausbekommen, sonst macht man das nur einmal – um es auszuprobieren. Man darf nicht vergessen – im Gegensatz zu den 80ern ist niemand mehr auf die Benutzung von GEOS angewiesen – daher sollte man es den potentiellen Verwendern besonders leicht machen.
Also das reine GEOS ist da eh aussen vor, da der DOS-Treiber nicht für das reine GEOS gemacht ist sondern für MP3. Also beziehe ich ab hier mal nur auf MP3 und dessen Nachfolger...
Aktuelle arbeite ich ja daran das System von 1999 in die Richtung weiterzuentwickeln, die mir damals vorschwebte. Der Workflow wäre dann in etwa so:
* Textdatei auf RAMLaufwerk bearbeiten, weil es schneller geht.
* Zurück zum Desktop/Dateimanager.
* 1xFenster RAMLaufwerk und 1xFenster DOS-Diskette
* Drag'n'Drop vom RAM-Laufwerk auf Diskette.
Wenn es ein Write-Dokument ist, dann wird es automatisch konvertiert. Das muss ja wegen des GEOS-Dateiformats zwingend sein. Hatte erst letztens wieder ein D64 mit GEOS-Dateien die ein Unwissender vermutlich mit FCOPY&Co kopiert und damit die GEOS-Dateien "beschädigt" hat.
Bei einer seq. Textdatei muss der Anwender schon selbst sagen ob das 1:1 kopiert werden soll (weil schon ISO) oder ob PETSCII nach ASCII konvertiert werden muss.
Write->SEQ geht momentan bei mir noch über geoDOS. Und das ist das was auf der ToDo steht: Das alles in einem System zusammenzubasteln. Aber ist Hobby, wie ich eben Lust+Zeit dazu habe.
Ein Problem ist hier, dass GEOS' Zeichenroutinen aus heutiger Sicht eher lahm sind. Punkte, Linien und Flächen kann man auch 4x so schnell füllen, wie GEOS es tut (oder tat? – hat sich daran seit damals™ etwas geändert?) und Fonts kann man schneller rendern, wenn man auf einige Wysiswyg-Features (z.B. beliebige Größen) verzichtet. Dabei können dann semantische Auszeichnung, wie bei Markdown, helfen.
Nein, das ist unverändert. Ich hab zwar hier und da mal ein paar Sachen korrigiert die andere in den hier geführten Diskussionen aufgezeigt haben, aber im Prinzip ist das Stand der 80er.
Ich bin auch kein Spezialist für Grafikprogrammierung. Die neuen Routinen müssten die Pixel aber auch bei Diagonalen Linien 1:1 setzen wie die alten, dürften vom Code her nicht größer sein, dürften keine anderen ZeroPage-Register als die bisherigen Routinen verändern.
Das Problem: Wie willst du über 200 ISO-Zeichen auf rund die Hälfte (bei GEOS) mappen?
Das geht nur durch Reduktion, ein ó wird dann halt zu einem o. Mir geht es dann eher darum das ich zumindest auch einen Text mit deutschen Umlauten korrekt nach geoWrite konvertieren kann. Damals mit PC437/PC850 hatte das bei mir noch geklappt, jetzt unter LINUX müsste ich wie gesagt eine neue Tabelle erstellen. Aktuell hab ich ein BASH-Script das die C64-Zeichen in deutsche Umlaute wandelt. Aber wie gesagt, das will ich schon für mich selbst irgendwann so vereinfachen, das ich meine geoWrite-Quelltexte einfach auf die Diskette schiebe (oder auf das VICE/VDrive-Laufwerk) und am PC die Dateien direkt ins GIT einbinden kann.
Die anderen Sonderzeichen wären mir egal. Das bearbeiten eines solchen Textes ist mit geoWrite eh nicht möglich. Da braucht es einen neuen Texteditor und neue Zeichensätze. Aber um mal schnell einen Text "lesbar" zu öffnen, da sollte es mit einer Reduktion gehen.
Das ist halt ein großes Problem. Man will heutzutage nichts mehr konvertieren, zumindest nicht, wenn es Spaß machen soll. Glücklicherweise hat sich seit dem letzten Jahrhundert einiges weiterentwickelt und man hat sich auf eine Handvoll Dateiformate, Encodings usw. geeinigt, die zu 99% verwendet werden.
Stimmt, will heute keiner mehr. Muss ich aber in der Firma machen (wenn einer kein DWG18 sondern nur DXF10 kann oder wenn einer zwar JPG versteht aber kein TIFF).
Aber ich will das ja für mich so einfach wie möglich machen und ggf. "unsichtbar" bzw. "transparent".
und Fonts kann man schneller rendern, wenn man auf einige Wysiswyg-Features (z.B. beliebige Größen) verzichtet. Dabei können dann semantische Auszeichnung, wie bei Markdown, helfen.
Ich hab ja bereits vor 20 Jahren eine Art "Hilfesystem" entwickelt, das aktuell auch in GEOS in jeder Anwendung (bei mir) per <F1>-Taste abrufbar ist. Dort nutze ich auch Steuerzeichen. Also kein WYSIWYG, aber es geht. Es gibt doch auch TEX das auch nicht WYSIWIG ist und trotzdem noch von einigen Leuten verwendet wird.
Für mich wäre das kein Problem.
Ich sehe das größere Problem eher in den TrueType bzw. Vektor-Fonts. Das dürfte die Textdarstellung ziemlich einschränken. Dann eher Pixel-Fonts die dann beim speichern als PDF durch TrueType ersetzt werden. Quasi Pixelfont als Preview, TrueType dann im PDF.
Aber das ist wie gesagt Wunschdenken... ich hab mir den geoWrite-Code mal angeschaut, da muss sich einer noch sehr intensiv damit beschäftigen um da was zu "verändern"...
Apropos Zugänglichkeit: Kann man irgendwo ein komplettes (mehr oder weniger aktuelles) GEOS/MP3-D81 (o.ä.) herunterladen, das man so out-of-the-box auf C64 oder Emulation benutzen kann, wenn man sich dafür interessiert?
Gar nicht... solange die Rechtslage so ist wie sie ist verteile ich nur SETUP-Pakete. Ich hatte aber vor kurzem in einem Parallel-Thread mal die Installation auf der RAMLink Step-by-Step erklärt. Da kam in mir selbst schon der Wunsch auf das vielleicht noch weiter auszuführen. Auch mit Bildern und ggf. noch auf ein paar Besonderheiten eingehen.
vielleicht liegt es auch etwas an fehlenden oder nicht so leicht zu findenden vorkonfigurierten und optimierten Paketen für verschiedene Hardware.
Für MP3 brauchst Du keine vorkonfigurierten Pakete für verschiedene Hardware. Wenn Du 1x eine MP3-Bootdisk erstellt hast, dann startest Du damit im Emu, am MK2 oder auch am U64. Einzige Ausnahme: Aktuell muss das Boot-Laufwerk immer der gleiche Typ sein und die gleiche Adresse haben. Das wird sich evtl. erst mit dem Nachfolger ändern... da plane ich eine automatische Erkennung noch bevor der Kernal gestartet wird und kann dann den passenden Treiber laden. Unter MP3 wird es aber beim bisherigen Stand bleiben.
-
Apropos Zugänglichkeit: Kann man irgendwo ein komplettes (mehr oder weniger aktuelles) GEOS/MP3-D81 (o.ä.) herunterladen, das man so out-of-the-box auf C64 oder Emulation benutzen kann, wenn man sich dafür interessiert?
Das 2.0r deutet auf eine GeoRAM-Version hin, also GEOS 2.x und damit Hardware-spezifisch und eben nicht "out-of-the-box" (unterstützt keine REU, SuperRAMCard oder RAMLink-DACC).
-
Das 2.0r deutet auf eine GeoRAM-Version hin, also GEOS 2.x und damit Hardware-spezifisch und eben nicht "out-of-the-box" (unterstützt keine REU, SuperRAMCard oder RAMLink-DACC).
Das ist richtig.
Aber GEOS macht auch nur mit einer Geo-RAM richtig Spass ...
Und 2MB Geor-RAM kosten 34€, insofern ...
-
Ich meine natürlich nicht das GEOS von vor 30 Jahren, sondern das aktuelle MP3 mit allem Kram. Also einfach ein Image, dass ich mir irgendwo draufziehen kann.
Wenn Du 1x eine MP3-Bootdisk erstellt hast
Die würde ich gerne einfach runterladen, statt mir eine zu erstellen.
Gar nicht... solange die Rechtslage so ist wie sie ist verteile ich nur SETUP-Pakete.
OK, dann muss ich noch warten, bis sich die Rechtslage geändert hat – gibt es denn Hoffnung darauf? Auf das Gebastel habe ich irgendwie überhaupt keine richtige Lust. Ich fand schon diesen alten GEOS-Kopierschutz einen Showstopper. Also Download und sofort starten (zumindest im Emu) – meinetwegen auch einmal auf EF für den C64 flashen aber dann will ich auch möglichst loslegen.
Display More* Textdatei auf RAMLaufwerk bearbeiten, weil es schneller geht.
* Zurück zum Desktop/Dateimanager.
* 1xFenster RAMLaufwerk und 1xFenster DOS-Diskette
* Drag'n'Drop vom RAM-Laufwerk auf Diskette.
Wenn es ein Write-Dokument ist, dann wird es automatisch konvertiert. Das muss ja wegen des GEOS-Dateiformats zwingend sein. Hatte erst letztens wieder ein D64 mit GEOS-Dateien die ein Unwissender vermutlich mit FCOPY&Co kopiert und damit die GEOS-Dateien "beschädigt" hat.Bei einer seq. Textdatei muss der Anwender schon selbst sagen ob das 1:1 kopiert werden soll (weil schon ISO) oder ob PETSCII nach ASCII konvertiert werden muss.
Das ist irgendwie auch ein Weg – aber nicht das, was ich mir so vorstelle, damit ich es nutzen würde.
Was ich nutzen würde: Ein Texteditor (egal ob eingebunden in ein alternatives OS, das von einem Modul startet oder aber Stand-Alone für den Vanilla-C64), mit dem ich direkt vom SD2IEC (kein Disk-Image) eine (optional Markdown-getaggte) PC-Textdatei (ISO-Konformes encoding) öffnen und korrekt darstellen und editieren kann. Und wenn ich Änderungen speichere, hätte ich die gerne direkt auf der SD-Karte gespeichert (weil ich sonst ja mindestens 2 x kopieren müsste). DAS wäre für mich "einfach" und da hätte ich auch Spaß dran, es mal zwischendurch zu benutzen, wenn mich der Retro-Hafer sticht.
Das geht nur durch Reduktion, ein ó wird dann halt zu einem o. Mir geht es dann eher darum das ich zumindest auch einen Text mit deutschen Umlauten korrekt nach geoWrite konvertieren kann.
Ja, aber was ist mit einem Franzosen oder Schweden? Das Problem bei dieser Art des Konvertierens ist halt, dass man den Ursprungstext zerstört – man kann es nicht bidirektional machen, weil der Konverter nicht weiß, ob eine C64-"Zoe" mal eine "Zoé" oder "Zoë" war.
Ich sehe das größere Problem eher in den TrueType bzw. Vektor-Fonts.
Da würde ich mir am wenigsten Sorgen drum machen. Jedes OS (und auch Drucker) hat seinen eigenen Fonts – und Markdown sind die vollkommen egal. Irgendwo ist hinterlegt, wie eine Überschrift (mit den verfügbaren Schriften) gerendert werden soll, fertig. Zum Drucker geht dann auch nur "Helvetica, bold, 14pt, linksbündig ..." und fertig ist die Laube.
-
Das 2.0r deutet auf eine GeoRAM-Version hin, also GEOS 2.x und damit Hardware-spezifisch und eben nicht "out-of-the-box" (unterstützt keine REU, SuperRAMCard oder RAMLink-DACC).
Das ist richtig.
Aber GEOS macht auch nur mit einer Geo-RAM richtig Spass ...
Und 2MB Geor-RAM kosten 34€, insofern ...
Es ging um eine Lösung die Out-of-the-box auf jeder Hardware läuft. Das ist bei GEOS einfach nicht der Fall. MP3 hat da eine automatische Erkennung für die Speichererweiterung, da ist es egal ob REU oder GeoRAM (oder RAMCard oder RAMLink)
Bei U64, UII+ oder TC64 ist die REU+GeoRAM ja eingebaut und beim TC64 kann man REU+geoRAM sogar gleichzeitig nutzen. Da brauch ich keine spezielle Bootdisk. Bei GEOS 2.x braucht es das sehr wohl...
Ich will MP3 jetzt hier nicht in den Himmel loben, da gibt es auch vieles was nicht geht. Aber die Hardware-Unterstützung ist bis auf das U64 doch deutlich weiter als es das bei GEOS 2.x jemals war. Selbst für die SuperCPU brauchte es da Patches. Für die RAMLink auch ein andere CONFIGURE.
Und von dem ollen Desktop2 reden wir mal gar nicht
-
OK, dann muss ich noch warten, bis sich die Rechtslage geändert hat – gibt es denn Hoffnung darauf?
Da kümmere ich mich erst gar nicht darum. MP3 ist mehr oder weniger Final... da ändere ich sowieso nichts mehr am Konzept. Und ob ich den Nachfolger überhaupt als Paket rausgebe weiß ich noch nicht. Ich mach das aktuell weil ich das für mich selbst brauche und (noch) Spaß am programmieren habe.
meinetwegen auch einmal auf EF für den C64 flashen aber dann will ich auch möglichst loslegen.
EF flashen ? Da bin ich raus... ich hab zwar ein EF3, aber wie man da MP3 von starten soll? Hab das noch nie richtig genutzt.
Ich denke das was Du von GEOS erwartest wird das aktuelle System nicht leisten können. Direktes schreiben auf eine SD-Karte geht nur mit einer Anwendung unter Umgehung der GEOS-Disk-I/O-Routinen. Dann kann man GEOS auch ganz weglassen. Wegen des GEOS-VLIR-Dateiformates wird es meiner Meinung nach auch immer DiskImages benötigen. Ausserhalb schreiben geht, aber nicht über den GEOS-Kernal, das muss die Anwendung dann erledigen.
-
Formatierungen sollten möglichst einfach und portabel möglich sein – da bietet sich vor allem Markdown an.
Aber schon mit WYSIWYG, schätze ich mal. Welche Formatierungen sollten denn möglich sein? Das ursprüngliche Markdown (https://daringfireball.net/projects/markdown/) zum Beispiel kennt keine Tabellen.
