Beiträge von markusC64 im Thema „Zoomfloppy funktion überprüfen“

    .) Bei dem Versuch GEOS zu deinstallieren, bootet dieses zuletzt noch von der Sicherungsdiskette, wenn ich dann das System abschalte und wieder neu bootet, hängt das Laufwerk wieder in einer Endlosschleife (ratter, ratter, ratter...)

    Hm, Ferndiagnosen ohne Daten sind schwierig. Und meine Glaskugel will ach nicht so recht.

    Aber es klingt danach, als ob nibwrite die Gaps so verkürzt haben könnte, dass ein Schreibzugriff auf einen Sektor (keine Ahnung welchen) den Header des dahinterliegenden Sektors in Miteidenschaft zieht.
    Es könnte helfen, nach jedem Schritt ein g64 anzufertigen, wo man dann genauer nachschauen kann, was los ist. Aber als Schnelldiagnose eben der "52.Master Copy" nach jedem Schritt (ich empfehle letzteres und die g64-Erstellung nur dann, wenn die Schnelldiagnose ergibt, dass man auch Fehler finden wird).

    Ah ja. Das Problem, was ich vermute, würde aber nur das Schreiben betreffen. Ein g64 ist ja durch Lesen von der Disk entstanden.

    Aber dennoch: Es ist immer gut, ein Tool zu kennen, welches schnell einen Lesbarkeitstest macht (inkl. Prüfsumme etc.)

    PS: Eine sehr schnell drehende Floppy müsste eigentlich dafür sorgen, dass die syncs kürzer erscheinen, da die ja nur durch Zeitmessung messbar sind in der Floppy und nicht tatsächlich am Prozessor als gelesene Bytes erscheinen.

    Ich habe das mit meinem C128 und 64'er Modus schon öfter benutzt. Starten mit RUN, Laden ab Basic-Anfang.

    Nachtrag: Lädt man es nicht von der Floppy (z. B. vom SD2IEC), so hilft ein "POKE 186,8" - wobei 8 die Gerätenummer der 1541/1571 ist.

    Nachtrag 2: Nochmal probiert - da ich inzwischen den C128 (nicht die 1571) mit JiffyDOS bzw. S-JiffyDos versehen habe. Geht noch immer.

    Nachtrag 3: Die Funktion heisst "Verify Disk", die uns reicht.

    Hm, bei g64 Images sagt die größe nur bedingt was aus. Hast Du schon mal mit "52.Master Copy" die Disk auf Lesefehler getestet? Das Programm braucht dazu nur wenige Sekunden (ich glaube so um die 20 Sekunden).
    Gerne auch zweimal durchlaufen lassen, manchmal bildet es sich einen Lesefehler ein, weil es einfach zu schnell ist (die "Scan"-Funktion auf Lesefehler reicht).

    Das mache ich demnächst mal, melde mich dann ...

    Hatte nicht "DerSchatten" im O.T. das Poblem und muss sein fehlerhaft geschriebenes so prüfen?


    Das stimmt so nicht ;-)Wenn man es genau betrachtet, sind es fast die wenigsten ....

    Unter "Geos 64 und Geos 128 jungfräulich" ist nur GEOS 128 f. GeoRAM (Posting 272) und GEOS 128 Original (M&T) (Posting 283) von mir.
    Die anderen habe ich nur geprüft (wenn vorhanden NIBs und G64 geschrieben und am C128 und VICE getestet. Veröffentlicht habe ich dann die G64s, wie ich sie bekommen habe.

    Unter "originale Geos Applikationen jungfräulich" sind es: GeoPublish, geoCalc 64, geoCalc 128, geoChart, geoFile 64 und GeoFile 128.
    Der Rest wie oben ...

    Ups, naja, ändert am Ergebnis aber wenig. Die Drehzahl ist schon hoch und somit nicht unwahrscheinlich höher als das Laufwerk, von dem die Disk geschrieben worden ist (kann auch das Mastering-Laufwerk gewesen sein).

    Nur mal aus Neugierde: Macht diese Routine einen Unterschied wenn seriell oder parallel übertragen wird?
    [...]

    Mir ist vorhin aufgefallen, dass im Quellcode von nibread und nibwrite der Hile-Bildschirm nicht aktualisiert wurde .... (habe ansonsten keine Ahnung von der Programmiersprache ...). Weiter oben sehe ich aber bei der Abfrage der Optionen etwas ganz anderes.

    Nein, macht kein Unterschied. Die ist so allgemein, dass ich hoffe, die im nibconv aufrufen zu können. Das würde eine Analyse der Probleme wesentlich erleichtern... Wenn ich mich recht erinnere, bekommt die Routine die Ist-Größe des Tracks, die Sollgröße und ein Zeiger auf den Trackinhalt. Und dann soll die den auf die Sollgröße bringen (durch Verkürzen oder Verlängern),

    Ja, die Hilfe ist leider outdated. Schon beim original nibtools.

    nur zum Vergleich:

    meine 1571 dreht mit 300.24 - 300.26 rpm

    Wenn ich mich nicht verrechnet habe (habe nur überschlagen), so macht das 30 Byte pro Track Unterschied. Das würde es erklären, die gesagt, der Trackkürzungsalgorithmus in nibwrite ist scheinbar nicht sonderlich gut (genauere Analyse fehlt noch, aber ich konnte bei mir beobachten, dass am Trackende immer Daten fehlen!).
    Daher auch der Hinweis mit den Test auf Lesefehler per "52.Master Copy" - wenn es pro Track ziemlich genau ein Sektor wäre, hätten wir exakt das gleiche Problem; diesmal aber nur mit ZoomFloppy ohne KryoFlux.

    Nachtrag: Die Geos-Disketten, von Denen wir die g64 haben, sind zum größten Teil ja mit Deiner 1571 geschrieben und gelesen (Du hast ja das Verfahren erklärt). Daher ist der Vergleich mit Deiner 1571 sehr aussagekräftig.

    Derzeit ist die neuste veröffentliche Version diese hier: Bitte melde dich an, um diesen Link zu sehen.

    Ich hoffe, dass ich bald rausfinde, wie ich das komplette Paket übersetzen kann, um so auch den beschriebenen Problem näherkommen zu können. Dann gibt es auch eine neue Version.

    Eins fällt mir auf: Deine Floppy dreht ein bisschen schnell (300,54 rpm). Wenn die jetzt die Daten, die mit einer normal schnell drehenden Floppy erzeugt wurden, schreiben soll, kann es Probleme geben.

    Hast Du "52.Master Copy" aus dem 64'er SH 92? Damit könntest Du mal ein Test auf Lesefehler mit einer geschriebenen Geos-Disk machen.

    Beim Experimentieren mit ZoomFloppy und Kryoflux bin ich nämlich darauf gestoßen, dass der Algorithmus in nibwrite, um die Tracklänge zu kürzen, wohl manchmal die Disk zerschießt.

    Um den Fehler einzugrenzen, könntest Du "nibconv+" nehmen. Einmal die Disk nach d64 konvertieren und zurück. Dadurch wird ein g64 mit wesentlich kürzeren Tracklängen erzeugt - und nibwrite macht beim Verlängern der Tracks keine solchen Probleme.