Hallo Besucher, der Thread wurde 8,8k mal aufgerufen und enthält 50 Antworten

letzter Beitrag von wweicht am

ASCII (mit Umlauten) nach GeoWrite - Konverter gesucht

  • Im Native-Mode funktioniert es ja nicht.
    Aber mit D81 (MP3, GEOS glaub auch), DNP (Wheels) geht es

    Auch wenn es eigentlich nicht in das Thema hier gehört :D


    Die Bezeichnung Native-Mode könnte zu Mißverständnis führen. Hier ist der direkte Zugriff auf die SD-Karte (also nicht in D64, D71, D81, DNP (CMD-Native-Mode)) gemeint. Nur damit das klar ist ... :bgdev


    D64, D71, D81 funktionieren in Geos, Wheels und MegaPatch. DNP derzeit nur in Wheels. Das wird aber irgendwann auch irgendwie in MegaPatch funktionieren. Wie genau wird man sehen. Ist eine Funktion die ich haben will, ist also "nur" eine Frage der Zeit. Aber es wird definitiv noch dauern ..... (dieses Jahr definitiv nicht mehr)




    Hab mal eine Frage betreffen Textkonvertierung und zwar in die andere Richtung.
    Also GeoWrite -> Win/Mac, am liebsten zu OpenOffice.


    Hab schon ein paar Konvertierungstabellen von GeoDos probiert leider war das Ergebnis nicht wirklich brauchbar.
    OpenOffice bietet selber auch noch x-Konvertierungstabellen.

    OpenOffice ist eigentlich toter als tot ;-) . Ich nutze hier schon seit Jahren LibreOffice.


    Ohne es jetzt probiert zu haben, in GeoDOS beim Kopieren GeoWrite > DOS die entsprechende Tabelle 437 oder 850 wählen. In OpenOffice beim Import (Achtung! Bezeichnungen stammen aus LibreOffice!) müßte eigentlich eine dieser 3 funktionieren:


    Western Europe (DOS/OS2--850/International)
    Western Europe (DOS/OS2--437/US)
    Western Europe (ISO-8859-1)



    Wenn Du mehr willst (Geowrite mit Schriftstilen, Fonts und Bildern, GeoPaint auch in Farbe) ist diese Konvertierung so (GeoDOS - OpenOffice) nicht möglich. Da empfehle ich das Windows-Programm "D64-Lister". Es kann die genannten Formate nicht nur anzeigen, es konvertiert sie auch in PC-Formate. Geowrite-Dokumente werden RTF und GeoPaint-Dokumnete BMP. Aber Achtung ;-) , die Konvertierung ist genauer, als sie in GeoWrite oder GeoPaint am C64/C128 sichtbar sind.



    Beispiele: PhotoScraps in Geowrite werden, wenn sie farbig sind auch in Farbe konvertiert, Tabulatoren die in GeoWrite einfach durch Löschen des Tabulators oben entfernt werden, sind im eigentlichen Text noch vorhanden und werden auch konvertiert. Für die Entfernung solcher unsichtbaren Fehler in GeoWrite-Dokumenten hat mal jemand ein Programm geschrieben. Es heißt "GeoMiser" und ist irgendwo in der GUC-Geothek. Da kann ein Geowrite-Dokument schonmal 1-2 kB kleiner werden....


    Der Original-Hintergrund in GeoPaint-Dokumenten ist grau. Auch wenn das in GeoPaint oder beim Ausdruck damit nicht sichtbar ist. D64-Lister konvertiert das natürlich auch in grau.


    Aber keine Panik, D64-Lister hat verschiedene Einstellungen um sowas entsprechend bei der Konvertierung an- oder abzustellen.


    D64-Lister ist also auch eine Werkzeug, um Fehler in den Dokumenten sichtbar zu machen.




    Das einzige negative, dass man über D64-Lister meiner Meinung nach sagen kann, es kann ausschlich D64 öffnen. Aber bei dem was das Programm kann, fällt das nicht ins Gewicht.


    Gruß
    Werner


    PS: Der Link zu D64-Lister: http://www.hardworks.de/d64lister/index.php

  • OpenOffice ist eigentlich toter als tot . Ich nutze hier schon seit Jahren LibreOffice.

    Ist doch eigentlich das Selbe, das Einte ist blau, das Andere grün :D



    Besten Dank, werd ich bei Gelegenheit probieren.


    Gruss C=Mac.

  • Schade, hat bei mir (Windows 10 - Texteditor, Ansi Format) nicht geklappt.

    Habe gerade nicht die Zeit, das an meinem Windows 10 (32Bit) nachzuvollzioehen. Habe aber mal kurz geschaut. Bei mir gibt es auch noch "WordPad". Da kann man bei "Speichern unter" auch "Textdokument - MS-DOS-Format (*.txt)" auswählen. Das müßte dann eigentlich passen.
    Ansonsten im Office-Paket schauen (siehe die Nachricht an "C=Mac" hier im Thema). Ich kenne nur LibreOffice, andere Offices kenne ich nicht ;-) .


    Ich gehe mal davon aus, dass Unicode hier das Problem ist ....


    Gruß
    Werner

  • Wer hätte sich denn seinerzeit mit der Umsetzung beschäftigen sollen? Die offizielle Entwicklung von Geos für 8-Bit-Systeme wurde 1989 mit der Veröffentlichung der Version 2.0 abgeschlossen.Die Version 2.5 stammt ja von Markt & Technik und hat mit der eigentlichen Entwicklung nichts zu tun.
    Ab 1989/1990 konzentrierte sich Berkeley Softworks auf die PC-Version GeoWorks. Damit war das 8-Bit Thema bei denen durch. Du musst das also im korrekten zeitlichen Kontext sehen.
    1985 bis 1988 hat niemand die Notwendigkeit gesehen, Iso oder gar Unicode (gab's ja offiziell erst ab 1991) irgendwelche Beachtung zu schenken.

    Soweit ich mich erinnere, hat der Geos User Club noch so einiges zu der Zeit an Geos mitgewirkt.

  • Soweit ich mich erinnere, hat der Geos User Club noch so einiges zu der Zeit an Geos mitgewirkt.

    Nein, da täuscht Du Dich.


    Der Geos User Club hat nichts mit dem eigentlichen Geos-System zu tun. Das ist auch bei Geos 64 V2.5 bis auf eine Kleinigkeit 1:1 das originale Geos V2.0, wie es irgendwann Ende der 1980er erschienen ist. Das einzige was sich von Seiten Markt&Technik da noch getan hat, war der Austausch von Geomerge mit der Version, die nicht mehr installiert werden mußte. Dies erfolgte auf Geos V2.0 (auch Geos 128) und Geos 64 V2.5 und wohl auch nur hier im deutschsprachigen Raum.
    Ich habe mich auch damals schon gefragt, warum sie nicht mehr verändert haben. Sie hätten z.B. das bessere Konfigurieren V2.1 (RAM1581, RAM bis 2 MB Größe) in Geos 64 V2.5 integrieren können.....


    Der Geos User Club hat lediglich einige seiner vorher schon einzeln verfügbaren kommerziellen Applikationen als Zugabe für Geos 64 V2.5 zur Verfügung gestellt (Topdesk, Silbentrenner, und ein paar andere "Kleinigkeiten"). Ansonsten war der GUC Supporter, Händler für M&T-Produkte (Geos) und Anbieter zusätzlicher Hard- und Software für Geos von dritten.


    Gruß
    Werner

  • Soweit ich mich erinnere, hat der Geos User Club noch so einiges zu der Zeit an Geos mitgewirkt.

    Das hat mit der originalen Entwicklung seitens Berkeley Softworks gar nichts zu tun. Ob irgendjemand noch irgendwelche Tools für Geos entwickelte, nachdem der Hersteller das Produkt zur Seite legte, ist doch dabei gar nicht interessant. Mir ging es ausschließlich darum, nochmal klar darzulegen, von wem, in welcher Zeit und für welche (damalige) Erwartungshaltung Geos entwickelt wurde.


    Es wird aber neuerdings in diesen Diskussionen des öfteren davon gesprochen (und kritisiert), dass Geos nicht konsequent für neuere Speichermedien und heutige Anforderungen optimiert wurde.
    Was viele anscheinend dabei übersehen: Es kostet unglaublich viel Mühe, sich in ein solch komplexes System einzuarbeiten, dessen Entwicklung vor fast dreißig Jahren von seinem damaligen Entwicklerteam abgeschlossen wurde. Man kann nicht mal eben so alle Kriterien, die damals durchaus dem Geist der Zeit entsprangen, über Bord werfen und die Struktur der Kernelroutinen "kurz mal" auf neue Medien anpassen. Und auch entsprechende Anwendungen, ein neues Handling der Oberfläche und ein neues Design lassen sich nicht über Nacht entwickeln.

  • Ich werde mir wohl doch einen eigenen Konverter basteln.

    Nicht unbedingt nötig ;-) .


    Was kommt denn überhaupt in Geowrite bei Dir an? Sind es nur die Umlaute, die falsch sind oder was anderes?


    Die Übersetzungstabellen sind in der Datei "GD_Convert" von geoDOS. Ich habe da auch schonmal was geändert, kann aber beim besten Willen nicht mehr sagen wie genau. Habe mir davon wohl keine Notizen gemacht :-( .


    So um 2004/2005 habe ich mit Linux rumprobiert und dabei festgestellt, dass die Linux-Tabellen in geoDOS die Umlaute auch nicht richtig konvertiert haben (müßte damals SUSE-Linux gewesen sein). Also mal eben "schnell" die Tabellen für Linux mit einem Diskmonitor geändert.....


    Kann jetzt nicht sagen, ob das in der Wolke zu finden ist. Es liegt auf jeden Fall auf meiner Homepage ( http://wweicht.homepage.t-online.de/ ) als ZIP. Das ist aber PKZIP V2.0-Format (geoZIP). Neuere Versionen von 7z zum Beispiel können das nicht mehr entpacken. Unter Win 10 geht es noch mit dem Win-internen ZIP. Hänge das geänderte "GD_Convert" mal neu gepackt als 7z hier mit an.


    Gruß
    Werner


    Nachtrag: Gehe mal davon aus, dass meine Änderung von damals heutzzutage auch nicht mehr passen. Keine Ahnung ob das Unicode war .....

  • Hallo Stuckalf,


    irgendetwas ist faul im Staate Dänemark ..... ;-)



    Bin noch nicht dazu gekommen, geoDOS auf Windows 10 auszuprobieren. Aber ich habe mal den Output von "Editor" von WindowsXP (32 Bit) und dem "Editor" von Windows 10 (32 Bit) verglichen. Der ist bezüglich der Umlaute identisch. Bei mir stehen da für ä ö ü ß Ä Ö Ü bei beiden Windows die Hex-Werte e4 f6 fc df c4 d6 dc. Warum geht das bei mir und bei Dir nicht?
    Einziger Unterschied, der mir bewußt ist: Bei meinem geoDOS ist die von mir damals geänderte GD-Convert vorhanden. Sollte das den Ausschlag geben? Oder machst Du irgendwas anders? Meiner Meinung nach müßte das auch in Windows 10 funktionieren. Oder hast Du 64Bit Windows und das macht den Unterschied?


    Ansonsten kann das Problem eigentlich nur noch wo anders liegen.....


    Gruß
    Werner


    PS: Kannst Du mir mal das mit DirMaster erzeugte Image mit einem nicht funktionierenden Text zuschicken. Dann kann ich das mal hier probieren....
    Aber heute ist erstmal Schluß, mache ich die nächsten Tage, sobald ich dazu komme.

  • Kannst Du mir mal das mit DirMaster erzeugte Image mit einem nicht funktionierenden Text zuschicken.

    Mache ich gleich mal fertig.
    Windows 64 sollte keinen anderen Code für eine ASCII/Ansi-Textdatei liefern.
    Ich denke eher, dass es mit den geänderten Tabellen zu tun hat.


    Bei meinem Ergebnis sind auch nicht nur die Umlaute falsch, die ganze Groß-Kleinschreibung ist nicht in Ordnung. Soweit ich das noch weiß, war es beim PETSCII umgekehrt zum ASCII.
    Allerdings ging ich bislang nach Informationen von Internetquellen davon aus, dass Geos sich in der Groß-Kleinschreibung an ASCII orientiert.


    Hier mal die Datei (*.d81) - erstellt mit dem DirMaster 3.1.1 (Import einer Textdatei direkt in das D81-Image)
    Umlaute.rar


    Folgendes sollte als Text in der Datei "Umlaute.seq" vorhanden sein:
    äöüÄÖÜß
    1234567890
    abcdefghijklmnopqrstuvwxyz
    ABCDEFGHIJKLMNOPQRSTUVWXYZ
    !"§$%&/()=+*#',;.:-_<>

  • Das ließ mir nun doch keine Ruhe ;-). (werde wohl morgen auf Arbeit etwas müde sein ;-) )


    Ich kenne noch nicht die Ursache, aber in Deinem D81 gibt es ein paar Probleme.


    1. Geos kommt schwer durcheinander, wenn in 2 Laufwerken Disketten mit gleichem Namen liegen. Dein D81 hat gar keinen Diskettennamen (nur $A0) und keine ID. Keine Ahnung, was für Auswirkungen das hat.


    2. Das auf Disk vorhandene File ist verändert. In der 1. Zeile steht irgendwelcher Müll. Die 2. Zeile enthält die Zahlen, die 3. Großbuchstaben, die 4. Kleinbuchstaben und die 5. die Satzzeichen usw.


    Es stimmen also nur die 2. und 5. Zeile.


    Ich kann Dir leider nicht sagen, wie DirMaster das handhabt oder ob da irgendwelchen Voreinstellungen nicht optimal sind. Aber so kann das nicht funktionieren.


    Das txt-File aus dem Editor von Windows muß einfach so 1:1 in das D81 kopiert werden. Dateiname oder Filetype ist unwichtig. Mußt Du mal schauen, ob sich bei DirMaster sowas machen läßt. Unter 64Bit-Windows läuft ja z.B. StarCommander nicht, den ich hier verwende.
    Das ist der Grund, warum ich so lange es irgendwie geht bei 32bit-Windows bleibe. Der DirMaster ist von V2.1 - V3.1.1 zumindest für Geos nicht brauchbar! Wenn es mal ein Programm gibt, dass unter Windows den Geos-Support funktionierend bietet, den ich brauche, dann konnt ein Umstieg auf 64Bit in Betracht.... ;-)


    Gruß
    Werner

  • Danke für die Nachtschicht, Werner!


    Ich denke, ich habe den Grund für die "fehlerhafte" Konvertierung gefunden: DirMaster konvertiert *.txt-Dateien beim Import in ein Diskimage automatisch von ASCII nach PETSCII.
    Das hatte ich mir schon fast gedacht, da die Groß- und Kleinbuchstaben komplett vertauscht sind.


    ich werde also wohl ein anderes Programm suchen müssen, um die Textdateien in ein entsprechendes Diskimage einzufügen.
    Da ich jeweils Windows 10 64 bit auf den Laptops habe, scheidet der Star Commander ja leider aus.


    Oder eben doch einen eigenen Konverter basteln. Mal schauen.

  • Oder eben doch einen eigenen Konverter basteln. Mal schauen.

    Vielleicht eine total blöde Idee aber was passiert eigentlich, wenn man alle Tools außen vor lässt und einfach den Text in Windows per Strg-C in die Zwischenablage packt und in VICE/GeoWrite per Strg-V einfügt? Wird daraus auch automatisch PETSCII?

  • Ob Vice das unterstützt, kann ich nicht sagen. Wenn, dann denke ich nicht, dass da etwas konvertiert würde.


    Aber Geos unterstützt das nicht, daran scheitert es schon grundlegend. Datenaustausch unter Geos lief seinerzeit nur über Scap-Dateien.
    Das machte damals Sinn, da bei 64 K abzüglich Kernel, Treibern und Grafikspeicher jedes Byte für die Programme gebraucht wurde.
    Auf dem C64 war die Lösung mit den Geos-Scrap-Dateien meines Wissens das erste Mal, dass ein Hersteller einen Datenaustausch mittels einer Zwischenablage eingebaut hatte.

  • Ob Vice das unterstützt, kann ich nicht sagen.

    VICE schreibt den Inhalt der Zwischenablage in den Tastaturpuffer des C64, wenn man Strg-V drückt (zumindest bei mir auf dem Mac). Wenn GEOS also nicht komplett andere Keyboardabfragen macht, als das C64-Standardsystem, dann sollte zumindest etwas auf dem Bildschirm erscheinen. Was, das bliebe halt auszuprobieren. So habe ich schon den einen oder anderen Text (z.B. kleine Listings aus dem Netz) zum C64 übertragen.

  • Ich habe es gerade mit VICE 3.0 und GEOS 2.1e (.crt) getestet. Leider verwendet GEOS wohl andere Tastaturabfragen. Beim Pasten erscheint nichts, sobald ich aber GEOS verlasse, steht im C64-Basic, was ich zuvor gepastet habe. "Dank" Unicode-Zwischenablage erscheint dort jeder Umlaut als 2 Fragezeichen. Schade, war aber meines Erachtens einen Versuch wert.