GEOS 2.0 gekauft - es fehlen GEOWRITE 2.1 und GEOPAINT

Zitat von 64erGrufti

Im Endeffekt ist es keine originale Xoom, weil hier nicht verfügbar.

Na ja, die XoomFloppy ist ja nicht original (im Sinne, dass sie nicht offiziell unterstützt wird). Das offizielle XUM1541-Geräte ist die ZoomFloppy.

Deshalb meine Nachfrage. Ich kann aus dem Stegreif nicht einmal sagen, wo genau die Unterschiede sind und welche FW auf die XoomFloppy muss.

Zitat von 64erGrufti

Die zweite, die ich noch nicht probiert habe, ist eine mit Teensy-Board.

Die dürfte noch schlechter unterstützt sein. Ich kenne niemanden, der eine XUM1541 mit Teensy besitzt, daher ist die FW zwar kompiliert, aber komplett ungetestet und unsupported!

Zitat von 64erGrufti

Ich werde es mal ausprobieren. Normalerweise müsste man doch mit Hash-Vergleich des NIB ausprobieren können, ob alles richtig auf der Diskette angekommen ist, oder ist da noch was veränderliches drin?

Leider nicht. Anders als z.B. die .D64, bei denen nach einem definierten Muster die Daten abgelegt werden (pro Track beginnt man bei Sektor 0) ist das bei .G64 und .NIB nicht der Fall. D.h., bei zweimaligem Auslesen werden die .NIB oder .G64 in den seltensten Fällen identisch sein.

Zitat von 64erGrufti

Also habe ich meine Geos-Diskette mit der Option "-t" drauf kopiert - und es läuft

Hm.... Verlangt GEOS eine "pingelige" "synchronisierte" Anordnung der Sektoren auf den Spuren?

Zitat von markusC64

Ansonsten habe ich in die leer.zip reingeschaut. Das ist merkwürdig:

... snipp...

Ich habe mir dein g64conv auch mal runtergeladen, das ist deutlich komfortabler, als es im Hex-Editor zu machen (wie ich normalerweise). Allerdings kommt es nicht mit .NIB Dateien zurecht, oder übersehe ich was? Ich habe es erst mit nibconv in g64 umgewandelt.

Diese Stellen bei leer.zip sind mir auch aufgefallen, sehr eigenartig.

64erGrufti : Falls du noch Spaß beim Debuggen hast, könntest du mal bitte folgendes machen:

1. Sag mir, was für eine 1541 du genau hast (1541, 1541-II, 1541C, ...)?
2. Kannst du mit cbmformat eine neue Diskette formatieren
3. Genau diese Diskette dann mit nibread auslesen und mir schicken
4. Kannst du mit cbmforng eine neue Diskette formatieren
5. Genau diese Diskette dann mit nibread auslesen und mir ebenfalls schicken

Mir kommt das Muster der Fehler bekannt vor von der Entwicklung von cbmformat und cbmforng, daher will ich abchecken, ob es das sein könnte.

Zitat von strik

Hm.... Verlangt GEOS eine "pingelige" "synchronisierte" Anordnung der Sektoren auf den Spuren?

Eigentlich nicht, aber wer weiß, ob es andere Effekte beim Schreiben gab?

Zitat von strik

Ich habe mir dein g64conv auch mal runtergeladen, das ist deutlich komfortabler, als es im Hex-Editor zu machen (wie ich normalerweise). Allerdings kommt es nicht mit .NIB Dateien zurecht, oder übersehe ich was? Ich habe es erst mit nibconv in g64 umgewandelt.

Nee, .nib kann es nicht - weil .nib mehr als eine Rotation beinhaltet, macht das auch nur bedingt Sinn. Wobei es sein kann, dass ich es im Nachfolger (wenn der mal fertig wird...) reinnehme.

.nb2 kann g64conv allerdings nach .txt umwandeln - und zwar ausschließlich nach .txt. Und dann darf der ahme Benutzer das richtige daraus heraussuchen, nb2 hat ja jeden Track in mehreren Rotationen und mehreren Geschwindigkeiten.

Der Nachfolger wird übrigens ein portables binäres Powershell Modul sein, der unverändert als Binary unter Windows, Linux and Mac OS läuft. Und gelegentliche Permanceprobleme von g64conv beseitigen.

Zitat von strik

Die dürfte noch schlechter unterstützt sein. Ich kenne niemanden, der eine XUM1541 mit Teensy besitzt, daher ist die FW zwar kompiliert, aber komplett ungetestet und unsupported!

Bei mir gab es keinen merklichen Unterschied zwischen der Teensy-Version und der ProMicro. Zumindest die Lesefehler treten mit "-t" bei beiden nicht mehr auf und Geos läuft.

Zitat von strik

Sag mir, was für eine 1541 du genau hast (1541, 1541-II, 1541C, ...)?

Das ist ne 1541-II

Zitat von strik

Kannst du mit cbmformat eine neue Diskette formatieren
Genau diese Diskette dann mit nibread auslesen und mir schicken
Kannst du mit cbmforng eine neue Diskette formatieren
Genau diese Diskette dann mit nibread auslesen und mir ebenfalls schicken

Muss ich heute Abend zuhause machen.

Zitat von markusC64

g64conv kann g64 in Textdateien konvertieren. Und die kann man dann bearbeiten und daraus wieder eine g64 machen.

Ich habe mir das Tool nun mal zumindest g64->txt angeschaut. Klasse Tool! Ich weiß gar nicht, warum die die kompilierte exe auf Github nicht gesehen hatte.

Vielleicht noch eine Idee der Erweiterung: Man könnte hinter dem Hexdump noch die Werte als decodiertes ASCII (besser geht es auf dem PC wohl nicht) darstellen, wie bei einem Hexeditor. Das macht den Inhalt manchmal besser sichtbar, wenn man etwas bestimmtes sucht.

Zitat von 64erGrufti

warum die die kompilierte exe auf Github nicht gesehen hatte.

Hat auch sein Gutes - die Release ist leider etwas veraltet, die neue Release im werden. Neue EXE habe ich inzwischen manuell erstellt, bevor ich davon eine Release mache, will ich die jedoch noch testen.

Wie auch immer, die maschinell erstellte ZIP-Version tut es ja, so dass keine Eile besteht.

Und unter Github Actions suchen die wenigsten eine EXE, auch wenn dort für jeden, der im Github eingeloggt ist, bei mir ein ZIP mit der EXE zu finden ist.

Zitat von strik

Kannst du mit cbmformat eine neue Diskette formatieren
Genau diese Diskette dann mit nibread auslesen und mir schicken
Kannst du mit cbmforng eine neue Diskette formatieren
Genau diese Diskette dann mit nibread auslesen und mir ebenfalls schicken

Im Anhang sind die Testdateien. Allerdings weiß ich nicht, was hier anders als vor 2 Wochen läuft. CBMFORNG hatte mir vor 2 Wochen nach dem Formatieren gar nichts gezeigt und das Formatieren funktionierte auch. Jetzt rattert das Laufwerk rum.

Aber irgendwie ist heute Abend scheinbar sowieso der Wurm drin. Mitten im auslesen hatte sich plötzlich der eine XUM1541 verabschiedet und wollte gar nicht mehr laufen. Dann habe ich mit dem anderen weiter gearbeitet. Jetzt stecke ich ihn dran, da geht er wieder.

Aber dazu noch eine weitere Frage. Gibt es irgendwie die Möglichkeit, Opencbm mit allen Plugins zu installieren? Die Tools haben doch auch extra Parameter dafür, also müsste das doch irgendwie auch gehen. Ich habe ja noch ein XU1541. Das konnte ich aber jetzt erst nach Deinstallation von Opencbm und Neuinstallation nutzen, da ich es nicht schaffe, beide Plugins verfügbar zu haben.

Edit: OK, das habe ich hin bekommen. Man muss das zweite Plugin nachträglich von Hand installieren. Der Fehler bei cbmforng bleibt allerdings. Mit XU1541 geht es sogar gar nicht mehr. Da kommt immer "error reading debug logging data!".

Edit2: Doch, stimmt, das war doch schon vorher so. Mit Parameter "-s" kommt dann diese Ausgabe (nicht über die Hieroglyphen wundern, die sind wirklich so):

Zitat von 64erGrufti

ber dazu noch eine weitere Frage. Gibt es irgendwie die Möglichkeit, Opencbm mit allen Plugins zu installieren? Die Tools haben doch auch extra Parameter dafür, also müsste das doch irgendwie auch gehen. Ich habe ja noch ein XU1541. Das konnte ich aber jetzt erst nach Deinstallation von Opencbm und Neuinstallation nutzen, da ich es nicht schaffe, beide Plugins verfügbar zu haben.

Edit: OK, das habe ich hin bekommen. Man muss das zweite Plugin nachträglich von Hand installieren.

Was heißt "per Hand"?

Das install.cmd - Script ermöglicht die Auswahl der Plugins, die installiert werden sollen.

Beispiel:

installiert sowohl das XUM1541- als auch das XU1541-Plugin.

Wenn es die Erst-Installation von OpenCBM ist, dann wird das erste genannte Plugin zum Default.

Man kann das auch in zwei getrennte Aufrufe trennen:

Der Befehl "install" geht normalerweise auch, weil bei fehlendem Plugin-Namen das Install-Skript davon ausgeht, dass das xum1541 installiert werden soll. Das dürfte heutzutage eine gute Heuristik sein.

Ein Deinstallieren entfernt immer alle installierten Plugins.

Ich habe mir die NIB-Dateien angeschaut, mit g64conv. Ich kann die Auffälligkeiten nicht erkennen - also kann es nicht daran liegen, woran ich gedacht hatte.

Dann bin ich etwas ratlos, wieso nibwrite offenbar etwas falsches schreibt. Da kann dann wahrscheinlich nur Pete was zu sagen.

r.cade, you are Pete, right? Can you tell us why nibwrite has Problems with GEOS disks if the option "-t" is not used?

Zitat von strik

installiert sowohl das XUM1541- als auch das XU1541-Plugin.

OK, das geht aus der Doku leider nicht hervor. Ich dachte, man kann immer nur eines angeben. Ich habe es dann mit instcbm nachinstalliert.

Zitat von strik

Ein Deinstallieren entfernt immer alle installierten Plugins.

Auch das war mir nicht klar. Ich dachte, dann wird das Installationsprotokoll mit dem neuen Plugin überschrieben., wobei mein Nachinstallieren da auch "Reste" überlassen würde.

Zitat von strik

Dann bin ich etwas ratlos, wieso nibwrite offenbar etwas falsches schreibt.

Ich nehme man an, dass markusC64 Recht hat und die Daten zu schnell zur Floppy kommen? "-t" verzögert die Übertragung ja, womit es dann funktioniert. Ich bin mir eben nur nicht sicher, ob das immer funktioniert. Da ja vermutlich, wie von markusC64 vermutet, der Sektor nicht in einem geschrieben werden kann, nehme ich an, dass es in dem ein oder anderen Fall doch zu Problemen könnte. Bei Geos scheint es wohl zufällig zu klappen. Deswegen war ja meine Frage nach einer Prüfmöglichkeit, ob alles genau so angekommen ist, wie erhofft. Aber wie ich ja inzwischen gelernt habe, kann man mit solch einfachen Mitteln keine tatsächliche 1:1-Kope erzeugen, weshalb wohl auch mit einer 1571 in dem ein oder anderen Fall ein Kopierschutz mal nicht funktionieren könnte.

markusC64 Übrigens hätte ich noch eine Idee für eine Erweiterung von g64conv. Man kann sich die Sektorbytes ja schön in 16er Gruppen anordnen lassen. Das i-Tüpfelchen wäre jetzt noch, wenn man die Adresse dabei stehen hätte.

Zitat von 64erGrufti

OK, das geht aus der Doku leider nicht hervor.

Das Problem ist: Alle Leute beschweren sich, dass die Doku zu komplex ist. Also habe ich solche Dinge nicht erwähnt, weil wahrscheinlich 99% der Leute es nicht brauchen werden.

Zitat von 64erGrufti

die Daten zu schnell zur Floppy kommen?

Na ja, sie dürften nicht wirklich zu schnell kommen, weil es ja ein (eingeschränktes) Handshake gibt.
Sonst müssten da dauernd Probleme sein - und die sehe ich nicht.

Zitat von strik

Dann bin ich etwas ratlos, wieso nibwrite offenbar etwas falsches schreibt. Da kann dann wahrscheinlich nur Pete was zu sagen.

Was ist hier das Grundproblem ... bitte nochmal genau beschreiben bitte?

Ich beherrsche die nibtools von Pete zu 100% und habe schon mehr als > 1.000 Konvertierungen in jede Richtungen mit allen Parametern gemacht. Immer hat allles funktionert. Auch mit dem g64conv ... da bin ich übrigens auch sehr gut mit bewandert ... muss ich ja.

Biite ganz genau das Problem hier beschreiben ... dann kann ich es auch präzise beantworten. Danke!

Zitat von Parser

Biite ganz genau das Problem hier beschreiben ... dann kann ich es auch präzise beantworten. Danke!

Wenn ich mit nibwrite eine Diskette "normal" beschreibe, kommen teilweise ungültige Bitfolgen auf der Diskette an (nicht GCR-konform) und die Diskette enthält Fehler oder wird teilweise völlig unlesbar. Schreibe ich mit dem Parameter "-t", kommen solche Fehler nicht zustande und die Kopie scheint zu funktionieren (zumindest Geos erkennt den Kopierschutz einwandfrei, keine Lesefehler).

Zitat von 64erGrufti

Zitat von Parser

Biite ganz genau das Problem hier beschreiben ... dann kann ich es auch präzise beantworten. Danke!

Wenn ich mit nibwrite eine Diskette "normal" beschreibe, kommen teilweise ungültige Bitfolgen auf der Diskette an (nicht GCR-konform) und die Diskette enthält Fehler oder wird teilweise völlig unlesbar. Schreibe ich mit dem Parameter "-t", kommen solche Fehler nicht zustande und die Kopie scheint zu funktionieren (zumindest Geos erkennt den Kopierschutz einwandfrei, keine Lesefehler).

OK. Dann fangen wir mal ganz von vorne an. Den Parameter -t habe ich bisher noch nie verwendet, da nie erforderlich gewesen, weil alles funktionierte. Den Parameter -t braucht man nicht.

1. Man benötigt als Erstes eine sehr gute 1541 mit einer Umdrehungsgeschwindigkeit von möglichst nahe an 300.00 RPM. Bei mir 299.94 RPM.

2. Wenn man eine Originaldiskette bzw. eine originale GEOS-Diskette mit nibread einliest, sollte man genau beobachten, wie die angezeigten Tracks eingelesen werden. Dazu gibt es ja dann auch das .log File. Man kann beim Einlesevorgang fast immer schon genau sehen, wie es um die Magnetisierung & Qualität der Diskette bestellt ist.

3. Nehmen wir nun an, man hat ein optimales .nib eingelesen. Dann wird man das .nib mit nibconv korrekt nach .g64 konvertieren wollen.

4. Es gibt gewisse Inkompatibilitäten zwischen den verschiedenen nibtools Versionen. Das sollte man wissen. Angefangen von den alten mnib-Versionen bis hin zu den nibtools-DOS-Versionen und dann den nibtools-Windows-Versionen. Ich nutze hauptsächlich die nibtools Version R613 vom 06.07.2015 als letzte DOS-Version am echten DOS-Rechner mit XEP-1541 (also seriell & parallel Verbindung gleichzeitig) und diese in der DOSBox sowie unter Windows die Version R694.

5. Eine optimale, unbeeinflusste Konvertierung erreicht man mit:

nibconv -f0 -r file.nib file.g64

6. Wenn man während des Konvertierungsvorgangs sieht, dass das .g64 als Output nicht richtig rauskommt, kann man die RPM verringen, z. B.:

nibconv -f0 -r -C298 file.nib file.g64

nibconv -f0 -r -C294 file.nib file.g64

In selten erforderlichen Fällen:

nibconv -f0 -r -C292 file.nib file.g64

7. Für GEOS-Originaldisketten gibt es ein spezielles nibconv (siehe angehängtes Bild).

8. Das eingelesene .nib von der GEOS-Originaldiskette kann man nach .d64 konvertieren:

nibconv file.nib file.d64

oder

nibconv -$ file.g64 file.d64

Anmerkung zum undokumentierten Parameter -$:

-$ sync-align all data before further processing

9. Parameter -7:

Damit wird bei der Umwandlung .d64 nach .g64 (in anderen Situationen ist der Parameter nutzlos) in den Header- und Tailgaps die Bytes des Geos-Kopierschutzes eingetragen.

10. nibconv -$ file.g64 file.d64 geht immer mit der Version R694 und manchmal bei der Version R613 nicht (Directory not found oder viele Sektorenfehler werden konvertiert).

11. Man kann das g64conv verwenden um ein file.d64 zu erzeugen. Das kann man dann ggf. auch wieder mit den nibconv nach .g64 konvertierten usw. und so fort. Je nach Notwendigkeit und Belieben.

12. Zurückschreiben mit nibwrite:

nibwrite file.nib

nibwrite file.g64

nibwrite file.d64

Immer auf die Bildschirmanzeige und die zurückgeschriebenen Tracks achten, ob das passt und stimmig ist (vergleiche .log File). Wenn nicht, dann stimmt dort etwas nicht. Spezielle nibwrite Parameter bedarf es hier nicht. Es ist auf Versionsgleichheit zu achten. Die anderen nibtools Parameter benötigt man nur in anderen Spezialfällen.

Fazit: Der Einlesevorgang zum .nib ist das Entscheidende. Ca. 10 % der .nbz/.nib aus dem C64 PP wurden beispielsweise korrekt eingelesen, aber falsch nach .g64 konvertiert, so dass diese nicht lauffähig sind.

13. Mit g64conv nach file.g64 zu file.txt kann man einzelne Tracks & Sektoren herausschneiden und Copy & Paste je nach Wunsch.

Zitat von Parser

Man benötigt als Erstes eine sehr gute 1541 mit einer Umdrehungsgeschwindigkeit von möglichst nahe an 300.00 RPM. Bei mir 299.94 RPM.

Die passt bei mir auf allen Tracks sehr gut. Irgendwo hier im Thread gibts auch das Log dazu.

Zitat von Parser

Wenn man eine Originaldiskette bzw. eine originale GEOS-Diskette mit nibread einliest, sollte man genau beobachten, wie die angezeigten Tracks eingelesen werden. Dazu gibt es ja dann auch das .log File. Man kann beim Einlesevorgang fast immer schon genau sehen, wie es um die Magnetisierung & Qualität der Diskette bestellt ist.

Und wie sehe ich das? Klar, da kommen ne Menge Meldungen. Aber was sagen die mir? Sind meine Logs OK?

Generell, Deiner Antwort nach vermute ich, wir haben uns missverstanden. Das Einlesen der Disketten funktioniert problemlos. Probleme gibt es beim Schreiben der Disketten (siehe Post 265ff), auch mit einer D64-Datei. Die geschriebene Diskette ist dann manchmal nicht mal mehr mehr lesbar, hat aber auf jeden Fall defekte Tracks. Nur noch eine Formatierung geht. markusC64 schrieb etwas davon, dass die Bits beim Schreiben wohl durcheinander gekommen sind. Ich weiß jetzt nicht genau wo, aber wenn die Diskette vom Laufwerk gar nicht mehr gelesen wird, vermute ich mal, dass es der Track-Header war und deswegen das Laufwerk den Track gar nicht mehr findet. Ich habe einen kompletten nagelneuen Diskettenpack vor- und Rückseite probiert. Also 20 Diskettenseiten. Zusätzlich noch einige von anderen Diskettenpacks. Bei allen das gleiche Problem. Von daher gehe ich weniger von einem Problem mit der Diskette selbst aus.

Ich nutze Opencbm 0.4.99.104 X64 und Nibtools 0.6.4-x64. Mit Parameter "-t" schreibt er langsamer und dann treten die Probleme nicht auf. Was also macht "-t" anders/besser, was dazu führt, dass es dann geht?

Zitat von 64erGrufti

Nibtools 0.6.4-x64

Man, man, man, ...

Da wird hier seitenweise diskutiert und herumgedockert und dann kommt wohl erst die entscheidene Info des Fragenden. Hast Du mal das Datum der benutzten nibtools-Programme angeschaut? Die sind von 2009. Da gab es das originale ZoomFloppy noch nicht mal. Mich wundert das nicht, daß damit ein ZoomFloppy-Nachbau nicht (richtig) funktioniert ....

Gehe nach https://c64preservation.com/files/nibtools/ und lade dort die 2 Archive (eins ist 32 bit, das andere 64 bit) herunter (NICHT in den Ordner "old" gehen, da liegen alte Versionen). Dann versuche mal zunächst die 64bit Version und wenn die nicht läuft, dann probiere mal die 32 bit Version....

Werner

Zitat von wweicht

Da wird hier seitenweise diskutiert und herumgedockert und dann kommt wohl erst die entscheidene Info des Fragenden. Hast Du mal das Datum der benutzten nibtools-Programme angeschaut?

Sorry, war mein Fehler. Die Version habe ich zwar auch auf der Festplatte, aber die, die ich benutzt habe ist die nibtools-msvc-opencbm5-amd64-r694

Parser

Zitat von 64erGrufti

Und wie sehe ich das? Klar, da kommen ne Menge Meldungen. Aber was sagen die mir?

Vielleicht ist die Frage unter gegangen.

Zitat von 64erGrufti

Parser

Zitat von 64erGrufti

Und wie sehe ich das? Klar, da kommen ne Menge Meldungen. Aber was sagen die mir?

Vielleicht ist die Frage unter gegangen.

Ach so ... ja ... ich sehe das ... ist halt Erfahrungssache. Dazu müsste man sich mal auf einem Retro-Treffen zusammensetzen und dann kann ich dir das alles genau erklären. Würde sonst hier den Rahmen völlig sprengen und am Ende keiner mehr etwas verstehen, worüber ich schreibe. Außerdem habe ich dafür auch zu wenig freie Zeit.

Kleiner Tipp von mir: Am besten mal so viele GEOS Originaldisketten wie möglich einlesen ... so 40 - 50 Stück. Dann wirst du es auch sehen ... nach und nach.

Zitat von Parser

Am besten mal so viele GEOS Originaldisketten wie möglich einlesen ... so 40 - 50 Stück.

Na prima, wer hat denn so viele?

Ich dachte, es gäbe da eine einfache Regel oder Erklärung, was die Ausgaben bedeuten. Vielleicht macht ja mal irgendwann jemand einen Vortrag darüber