Hallo Besucher, der Thread wurde 4,7k mal aufgerufen und enthält 35 Antworten

letzter Beitrag von wweicht am

Zoomfloppy funktion überprüfen

  • Gibt es eine Möglichkeit wie ich die Verbindung zwischen Zoomfloppy zum PC auf 100% Funktion überprüfen kann?


    Mir ist es zb. nicht möglich bestimmte GEOS-Disketten (zb. GEOWRITE) so auf Disk zu kopieren das ich sich am C128D fehlerfrei benutzen kann.
    Wenn ich ein funktionierendes IMAGE auf die Disk kopiere, wird grundsätzlich kein Fehler angezeigt (zumindest keinen den ich als Fehler interpretieren könnte)


    Wenn ich die Disk dann in den C128D einlege und ein Validieren drüber laufen lasse, friert GEOS beim Überprüfen der Datei GEOPAINT ein. Obwohl die IMAGES selbst in Ordnung sein sollten.
    Jetzt wollte ich mal mit der Fehlersuche bei der Zoomfloppy beginnen.


    Eine Installation von GEOWRITE ist ebenfalls nicht möglich, da ständig irgendwelche Fehler angezeigt werden.


    Das ganze hängt an einem WinXP Rechner mit 1571 Floppy und eingebauten JiffyDOS.

  • Hallo,

    Das ganze hängt an einem WinXP Rechner mit 1571 Floppy und eingebauten JiffyDOS.

    Ist das 32-bit oder 64-Bit WinXP?


    kurzes rundes Seriell sowie Flachband Parallel.

    Bitte ziehe mal das Parallelkabel (im ausgeschaltetem Zustand ;-) ) vom Zoomfloppy ab und versuche das Lesen und Schreiben auf/von Diskette nur mit Seriell-Kabel. Laut Deinem Log oben wird nur das benutzt (SRQ-Mode). Ändert das irgendwas?


    Wie genau mit welchen Parametern rufst Du nibread/nibwrite auf?


    Mögliche weitere Fehlerquelle ist die USB-Verbindung zwischen PC und Zoomfloppy. Diese Kontrollieren oder mal anderes USB-Kabel benutzen.


    Fakt ist: Deine Images haben Diskettenfehler (z.B. das nib und das G64, die Du mir letztens per Mail geschickt hast: test.nib und test.g64). Irgendwas scheint da die Übertragung zu stören.



    Hier bei mir werkelt das Zoomfloppy unter WinXP 32 bit mit einem normalen CBM-Seriell Kabel und kurzem USB-Kabel problemlos mit einer 1571 die auch JiffyDOS eingebaut hat ....



    Wenn das nicht hilft, müssen wir tiefer einsteigen ...



    Gruß
    Werner


    PS: Es geht hier vor allem um die G64-Images für Geos aus GEOS 64 und 128 V2.0 GE jungfräulich , die von mir zusammengestellt wurden und teilweise damals von "DerSchatten" erstellt wurden. Ich meine, die waren damals noch OK ...

  • Funktionieren die Images im VICE? Kannst du da ohne Probleme GEOS und dann GEOWRITE starten?

    Ich habe damals und sonst immer mal wieder alle von mir zur Verfügung gestellten G64s, die es hier zum Download angeboten habe in VICE probiert. Geht problemlos. Seit ich das ZoomFloppy selber habe (seit Mitte 2015), habe ich alle auch auf echte Disketten kopiert und auf meinem C128DB laufen sie dann auch ohne Probleme...


    Gruß
    Werner

  • Hallo,

    Hinter Track 1 bis 38 steht im OP überall 0%. Weiss jemand, was das bedeutet?

    Ich leider nicht. Diese Anzeige kommt auch erst bei neueren nibtools-Versionen und habe ich hier bei mir auch schon beobachtet. Aber da die Disketten hier bei mir nach dem Kopieren sowohl unter WinVice als auch am echten C128DB funktionieren, gehe ich mal davon aus, dass das so sein muss ;-) .


    Gruß
    Werner

  • 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.

  • Hallo,

    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.

    nur zum Vergleich:


    meine 1571 dreht mit 300.24 - 300.26 rpm



    Um den Fehler einzugrenzen, könntest Du "nibconv+" nehmen.

    hast Du mal einen Download-Link parat für nibconv+ (fertiges Programm) ? Danke.


    Gruß
    Werner

  • Derzeit ist die neuste veröffentliche Version diese hier: nibconv: Fehlerkorrekturen


    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.

  • 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.

  • Ich wollte jetzt mal eine andere ZoomFloppy und 1571 versuchen.
    Nur dürfte die Firmware der ZoomFloppy noch einen alten Stand haben.


    nibwrite meckert zumindest:

    Successfully loaded G64 file
    xum1541 firmware version too low (6 < 7)
    please update your xum1541 firmware
    Is your X-cable properly configured?


    Kann mir jemand sagen wo man die aktuelle Firmware bekommt?

  • 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

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



    Die Geos-Disketten, von Denen wir die g64 haben, sind zum größten Teil ja mit Deiner 1571 geschrieben und gelesen

    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 ...



    der Trackkürzungsalgorithmus in nibwrite ist scheinbar nicht sonderlich gut

    Nur mal aus Neugierde: Macht diese Routine einen Unterschied wenn seriell oder parallel übertragen wird?
    Das wäre möglicherweise eine Erklärung dafür, warum bei "DerSchatten" plötzlich die Probleme aufgetreten sind. Irgendwann wurde in nibread/nibwrite die Voreinstellung für den zu benutzenden Modus (SRQ oder Parallel) geändert. Die ist in neueren Versionen SRQ und war früher Parallel .


    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.


    Gruß
    Werner

  • Kann mir jemand sagen wo man die aktuelle Firmware bekommt?

    in dem Paket von hier:


    http://root.org/~nate/c64/xum1541/index.html


    ist die aktuelle Firmware das File mit der Endung . hex und eine bat. Datei (firmware-update.bat) enthalten. Die bat-Datei muss eventuell noch auf Deine Verhältnisse angepasst werden ....



    Gruß
    Werner


    PS:

    Wie genau mit welchen Parametern rufst Du nibread/nibwrite auf?

    Wenn Du mir mal diese schon gestellte Frage beantwortest ;-) , kommen wir eventuell weiter ...
    Ich glaube momentan nicht, dass das ein Problem der Zoomfloppy ist.

  • Die Geos-Disketten, von Denen wir die g64 haben, sind zum größten Teil ja mit Deiner 1571 geschrieben und gelesen

    Nachtrag:
    In den Postings 134 und 154 unter "Geos 64 und Geos 128 jungfräulich" sind G64s enthalten die "DerSchatten" damals für mich erstellt hat. Bei Geos 64 alle 3, bei Geos 128 das, welches Geowrite 128 enthält.


    Gruß
    Werner

  • OK, Firmware-Update ist drauf.
    ZoomFloppy funktioniert.


    Zurückspielen des geo1281b.g64 IMAGES auf die andere 1571 sieht nun wie folgt aus:



    Wie soll ich nun was testen?

  • 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.

  • Bevot ich es vergesse: Das mit der Trackkürzung betrifft das Schreiben. Lesen müsste davon unberührt sein.
    Natürlich: Wenn Müll geschrieben worden ist, kann man anschließend natürlich nur Müll lesen :)

  • Ich habe die Disk jetzt mal im GEOS128 (MP3128) mit validate überprüft.
    Hängt sich wieder bei der Datei GEOPAINT auf. Also GEOS friert ein.


    Das wars dann wohl auch nicht.


    Habe nochmal die Disk beschrieben und wieder gelesen.
    Ergebnis ist folgendes:


    Dateigröße zuvor: 333.744 danach: 309.954