Hallo Besucher, der Thread wurde 5,3k mal aufgerufen und enthält 42 Antworten

letzter Beitrag von wweicht am

Problem mit GEOS 2.5 (Deutsch) und ras4C64net Druckertreiber

    Zitat von wweicht

    Achso: originale Geos-Bootdisketten (G64) kann man nicht einfach als D64 speichern. Dann ist der Kopierschutz weg und die Dinger booten nicht.

    Im Allgemeinen stimmt das. Ein SD2IEC emuliert jedoch den Kopierschutz von Geos bei Geos Startdisketten auch bei Verwendung eines D64. :-) Mit einem SD2IEC kann man also einfach von den original Disketten ein D64 Image ziehen und gut.


    Zumindest für Geos 2.0 / 2.5. Für Geos 1.x hat das keiner so recht überprüft...

    Zitat von markusC64
    Zitat von wweicht

    Achso: originale Geos-Bootdisketten (G64) kann man nicht einfach als D64 speichern. Dann ist der Kopierschutz weg und die Dinger booten nicht.

    Im Allgemeinen stimmt das. Ein SD2IEC emuliert jedoch den Kopierschutz von Geos bei Geos Startdisketten auch bei Verwendung eines D64. :-) Mit einem SD2IEC kann man also einfach von den original Disketten ein D64 Image ziehen und gut.


    Zumindest für Geos 2.0 / 2.5. Für Geos 1.x hat das keiner so recht überprüft...

    Wie geht das denn im Detail von Statten? Ich habe hier einen C64, ein SD2IEC Laufwerk und eine 1541 - da braucht es doch eine Software um da von Diskette nac SD2IEC auszulesen, oder?

    Ausprobiert habe ich noch nicht, das D64 am C64 zu erstellen. Per PC auf die SD-Karte kopieren ist ja eine taugliche Alternative.


    Aber "dracopy" https://csdb.dk/release/?id=165305&show=notes sollte das hinbekommen.


    [Externes Medium: https://www.youtube.com/watch?v=khyATbkEYDI]
    zeigt das mit einer älteren Version von DraCopy. DiskCopy ist mittlerweile die Taste "K".

    Zitat von lodger

    Meine original Disketten von MSPI kann ich mit dem Zoom Floppy nicht auslesen,

    Das hatten wir doch schon, ZoomFloppy und nibtools ;-) .


    Zitat von markusC64

    Mit einem SD2IEC kann man also einfach von den original Disketten ein D64 Image ziehen und gut.

    Ja, die D64 aus dem ZIP auf der Wolke (Geos2.5 installiert) sind aber keine Originale. Die sind irgendwie bearbeitet.


    Wenn ich meine originalen Geos-Disketten (je installiert Geos 64 und Geos128) als D64 speichere, dann kann das SD2IEC die booten, in VICE machen sie aber das, was sie am echten C64/128 auch tun würden: Reset während des Bootens.


    Die D64 aus der Wolke booten sowohl vom SD2IEC als auch in VICE. Ergo: irgendwie manipuliert, NICHT ORIGINAL.


    Zitat von lodger

    Wie geht das denn im Detail von Statten?

    Mal von Deinem Beispiel aus gesehen:


    Deine installierten Geos-System-Disketten (siehe Posting #1) mit nibread als nib-File einlesen, für VICE mit nibconv nach G64 wandeln. Ich habe es jetzt nicht probiert, aber nibconv sollte das eingelesene auch als D64 speichern können. Ansonsten in VICE mit "Diskkopier" (sollte auf den originalen Geos-Disks drauf sein) die G64 (Quelle) kopieren auf ein D64 (Ziel).

    Aber nochmals: diese Disketten (D64) funktionieren nur auf SD2IEC!

    Zitat von lodger

    mit dem Zoom Floppy nicht auslesen, ich vermute wg. eines Kopierschutzes.

    Für das SD2IEC die Disk einfach als D64 speichern (d64copy von opencbm).


    Gruß

    Werner


    Uups, vergessen:


    Anbei ein D64, das die Programme geoTelnet, geoCBMTerm und RAS4C64NET (den hier besprochenen "Druckertreiber") enthält. Zu allen 3 Programmen ist auch je eine Anleitung dabei.


    Der Hinweis, das es sich bei den Images aus der Wolke um bearbeitete Varianten handelt, war sehr hilfreich und bestätigt eine meiner Vermutungen.


    d64copy hatte mir mehrfach beim Lesen der 1. Seite der Systemdiskette mittels ZoomFloppy auf Spur 2 einen Leserfehler gemeldet. Andere Disketten liessen sich aber problemlos einlesen. Daher schloss ich entweder auf einen Kopierschutz oder eine defekte Diskette.


    Ich habe jetzt einen erneuten Versuch gestartet, diesmal nutze ich meine alte MMC64 und das d64read Plugin. Hier gab es bislang keinen Lesefehler. Ich werde berichten...


    P.S.: danke für das image, hatte ich mir aber auch schon zusammengestellt ;)

    Zitat von lodger

    das es sich bei den Images aus der Wolke um bearbeitete Varianten handelt,

    Irgendwie bearbeitet sind die fast alle. Bei Geos64 2.5 installiert ist es aber irgendwie besonders bearbeitet ...


    Die uninstallierten Geos-Sachen sind aber (bis auf wenige Ausnahmen, wer hat schon völlig uninstallierte Sachen von damals rumliegen) soweit möglich im originalen Zustand. Der Inhalt entspricht dem Original und die Disketten wurden soweit möglich deinstalliert. Die Deinstaller wurden ja damals von der 64er bzw. 64er-Geos-Sonderheften veröffentlicht und werden bei den von mir erstellten Sachen auf der F64-Wolke auf der jeweiligen Extra-Diskette mitgeliefert.

    Einige Sachen hat markusC64 auch "per Hand" deinstalliert und so den originalen Zustand wieder hergestellt.


    Zitat von lodger

    danke für das image, hatte ich mir aber auch schon zusammengestellt

    Das D64-Image stammt so (hab der Disk nur einem Namen gegeben) von Bo Zimmermann aus dem github-Zimodem-Repo von hier:

    https://github.com/bozimmerman/Zimodem/tree/master/cbm8bit


    Gruß

    Werner

    Kurzes Update: das mit der MMC64 hat natürlich auch nicht geklappt. Aber: ich habe jetzt nochmal ein frisches D81 Image sowohl für ein "Markt & Technik GEOS 2.0" als auch die 2.5 Version aus dem genannten "F64 Wolke" Paket mittels VICE und der unter Geos 2.5 bootfähig auf SD2IEC/D81 über Geomakeboot gegebenen Anleitung erstellt.


    Ausgangsbasis waren jeweils die in den ZIP Files vorliegenden G64 Images von den Originaldisketten, welche ja auch tatsächlich mit aktivem Kopierschutz daher kommen und entsprechend beim ersten Bootvorgang den Wechsel zwischen System- und Sicherungssystemdiskette erfordern (lang, lang ist's her). Danach habe ich das im Thread beschriebene GeoMakeBoot Prozedere angewandt und nun habe ich endlich zwei "frische", deutschsprachige GEOS Versionen auf zwei D81 Images. An dieser Stelle vielen Dank an alle, die mir hier den nötigen Input geliefert haben.


    EDIT:

    Eine Frage habe ich noch zu den nibtools: muss ich unter Linux die Windows Version mittels WINE nutzen, oder gibt es irgendwo auch eine native Linux Version von den nibtools?

    Hab's gefunden -> https://github.com/OpenCBM/nibtools

    leider *nein* ... :wand

    Zitat von lodger

    d64copy hatte mir mehrfach beim Lesen der 1. Seite der Systemdiskette mittels ZoomFloppy auf Spur 2 einen Leserfehler gemeldet.

    Hast Du das Ganze auch mal mit Deiner Sicherheitssystem-Disk probiert? Das D64 brauchen wir ja erstmal nur, um Dein System mit SD2IEC zum laufen zu bekommen. Und wenn System nicht will, Sicherungssystem ist bis auf den Disknamen identisch. Vielleicht klappte es ja damit.


    So ganz nebenbei: Wenn Deine Diskette "Appliaktionen" noch funktioniert, könnte man mit der das System auf Deine Seriennummer einrichten. Die Disk als G64 einlesen. Bei Abfrage beim ersten Booten der System-G64 angeben, daß man schon Applikationen hat und dann "APPLIKATIONEN" benutzen. Das System bekommt dann die Seriennummer Deiner Diskette.


    Zitat von lodger

    nun habe ich endlich zwei "frische", deutschsprachige GEOS Versionen auf zwei D81 Images.

    Hast Du bei der Prozedur auch an die Programme gedacht, die auch installiert werden müssen (einmal von originaler Disk (G64) starten)?


    Bei Geos 2.0 sind das Geowrite und geoMerge

    Bei Geos 2.5 sind das Geowrite, Topdesk und Silbentrenner (letzters glaubt mir keiner, aber es ist so!). geoMerge braucht hier keine Installation mehr.


    Die Programme müssen einmal vom G64 gestartet werden und dürfen erst danach kopiert werden. Auf Deinem ersten D81 startete ja TOPDESK nicht wegen Seriennummer. Könnte daran liegen.....


    Übrigens, auf der F64-Wolke liegen unter Handbücher & Bedienungsanleitungen\GEOS-DE-EN\ die entsprechenden PDFs. Könnte ganz hilfreich sein, zumindest für die zusätzlichen Programme von Geos 2.5 ...


    Zitat von wweicht

    Ändern die neue Bootdisks irgendetwas bezüglich ras4C64net?

    Zitat von lodger

    leider *nein* ... :wand

    Mist :-( .


    Da bin ich mit meinem Latein auch so ziemlich am Ende. Von Druckertreibern und der WiFi-Geschichte habe ich keine Ahnung und auch keine Hardware zum experimentieren.

    Im Quelltext fällt mir nichts weiter auf. Da ist nur dieser Test auf Wheels (bei RASPKiSS: ), der aber nicht weiter stören sollte bei Geos (wird übersprungen).


    Falls sich hier jemand das mal anschauen will/kann, anbei ein D64 mit dem kompletten Quelltext in Geowrite-Dokumenten (für geoProgramme/Concept). Das fertige Programm gibt es ein paar Beiträge weiter vorne.


    Wenn garnichts hilft, vielleicht mal Bo Zimmerman kontaktieren. Eventuell müßte man ihm dann eine deutsche Boot-Disk mit dem Treiber zur Verfügung stellen ....


    Schönen Rest-Sonntag noch.


    Gruß

    Werner

    Hab ich gerade mal gemacht -> https://github.com/bozimmerman/ras4c64net/issues/1

    Wobei das G64 "Original" ihm ggf. auch helfen könnte... :-)


    Naja, kannst ja erstmal seien Antwort abwarten - oder das nochmal editieren und das G64 auch als Option angeben.

    Zitat von markusC64

    Wobei das G64 "Original" ihm ggf. auch helfen könnte... :-)


    Naja, kannst ja erstmal seien Antwort abwarten - oder das nochmal editieren und das G64 auch als Option angeben.

    Hab ich entsprechend angepasst.

    Zitat von markusC64

    Wobei das G64 "Original" ihm ggf. auch helfen könnte...

    Wartet doch erstmal ab, ob und was er dazu sagt.......


    Man könnte auch ein D64 (GeoMakeBoot) schicken ;-) . Braucht nicht so viel Platz ;-) .


    Aber da fällt mir was auf: Kann mal jemand den Treiber nach Timing-Problemen checken? War da nicht was mit Unterschieden zwischen NTSC und PAL???

    Nicht daß ich davon wirklich Ahnung hätte ;-) .


    Wenn mir einer sagt, was man da diesbezüglich im Quelltext ändern sollte (müßte) oder es macht und einen neuen Quelltext liefert, das assemblieren könnte ich übernehmen.


    Gruß

    Werner

    Ich habe noch ein wenig getestet: an GeoWrite scheint es wahrscheinlich nicht zu liegen, denn wenn ich ein Dokument Erstelle oder Lade und dann - ohne zu es drucken - GeoWrite wieder beende, tritt der Fehler nicht auf.

    Zitat von wweicht

    Aber da fällt mir was auf: Kann mal jemand den Treiber nach Timing-Problemen checken? War da nicht was mit Unterschieden zwischen NTSC und PAL???

    Nicht daß ich davon wirklich Ahnung hätte ;-) .

    Ich auch nicht - jedoch habe ich im Treiebr eine PAL / NTSC Erkennung gesehen. Ob die es tut, ist eine andere Frage. Ich denke aber, die tut es, weil anonsten wahrscheinlich das Wifi-Modem die Seite missverstanden hätte, was offenbar nicht der Fall ist.

    Zitat von lodger

    Hab mir als "Workaround" jetzt ein englisches GEOS 2.0 (von CBMfiles.com) mit den Fonts aus der deutschen Version erstellt

    Weiß nicht, ob das so gut ist ;-) .

    Was kann der Druckertreiber denn alles drucken? Mir fällt da z.B. geoCalc ein, wo zwischen deutscher (9,99) oder amerikanischer (9.99) Schreibweise unterschieden wird. Also aufpassen...


    Zitat von markusC64

    weil anonsten wahrscheinlich das Wifi-Modem die Seite missverstanden hätte, was offenbar nicht der Fall ist.

    Der eigentliche Druckvorgang scheint ja zu funktionieren. Aber was ist am Ende des Druckens oder nach dem Drucken. Da passiert irgendwas, was ohne den Treiber nicht passiert und Geos zum Absturz bringt ....


    Gruß

    Werner

    Der Treiber rendert die Dokumente als SUN Microsystems RAS Rasterimage. Ich denke, entscheidend bei so Sachen wie Währungen etc. ist, das die jeweilige Programmversion (z.B. geoCalc) in deutscher Sprache vorliegt. Ist aber nur eine Vermutung. geoWrite und Umlaute klappt jedenfalls prima!

    Zitat von lodger

    ist, das die jeweilige Programmversion (z.B. geoCalc) in deutscher Sprache vorliegt.

    Ja, aber dann müßte geprüft werden, ob die deutschen PRG-Versionen auch mit US Geos laufen. Das kann sein, muß aber nicht. Es gibt da eine Speicherstelle im Geos-Kernal, die angibt ob ein US- oder DE-System vorliegt. Wenn die abgefragt wird ....


    Bei Geowrite ist es nur eine Font-Sache. Obwohl: BSW (und zusätzlich BSW128 bei Geos 128) sind normalerweise im Kernal und haben bei US-Geos keine Umlaute (stattdessen eckige und geschweifte Klammern) ...


    Gruß

    Werner