letzter Beitrag von GenerationCBM am
@Odo: Kleiner Tipp: Für welchen Namen könnte sein Nick eine Abkürzung sein, wenn du mal auf die OpenCBM Webseite gehst? 
Da habe ich auch eine Frage an STrik: Ist das OK für Dich/Euch, wenn ich (auf Wunsch von Odo) das OpenCBM Manual der Webseite auf Deutsch übersetze und zur Verfügung stelle?
@Odo: Kleiner Tipp: Für welchen Namen könnte sein Nick eine Abkürzung sein, wenn du mal auf die OpenCBM Webseite gehst?
Da ist Ryk dran Schuld. Der hat mich gestern mit merkwürdigen Wortkonstruktionen durcheinander gebracht. 
Da habe ich auch eine Frage an STrik: Ist das OK für Dich/Euch, wenn ich (auf Wunsch von Odo) das OpenCBM Manual der Webseite auf Deutsch übersetze und zur Verfügung stelle?
strik = Spiro.
Hallo,
Uh, ich habe mich lange nicht mehr damit beschäftigt. Bin bei meinem Tool erstmal auf c1541.exe ausgewichen und wollte die OpenCBM Sachen später einbauen.
Version muß ich mal nachschauen. Kann aber etwas dauern.
Am einfachsten mit usb_echo_test.exe herauszubekommen: Lade es dir einfach von http://sourceforge.net/p/openc…/master/tree/xu1541/misc/ herunter und starte es.
In den ersten Zeilen gibt es die Versionsnummern von BIOS und Firmware aus. Indirekt ist darin auch kodiert, ob es mit avrusb oder usbtiny läuft.
Zitat
Hub. Auch hier gilt, kann noch etwas dauern bevor ich das wieder anfassen werde.
Wie gesagt (habe ich doch?), die USB-Implementierung in den Soft-USB-Stacks "avrusb" (bzw. V-USB, wie es nun heißt) und '"usbtiny" ist etwas wackelig und stresst die USB-Spezifikation schon recht stark. Da kann ein Hub dazwischen der Unterschied zwischen "geht" und "geht nicht" sein.
Zitat
Alpha?
Mal schauen.
Alle Versionen, die XU1541 und XUM1541 unterstützen, gelten als Alpha. :p
Zitat
Mail gerne.
Aber jetzt eine Frage an Dich. Bist Du der Entwickler vom OpenCBM oder wie hast Du damit zu tun?
Wie schon unten von anderen geschrieben: ja, ich bin's.
Da habe ich auch eine Frage an STrik: Ist das OK für Dich/Euch, wenn ich (auf Wunsch von Odo) das OpenCBM Manual der Webseite auf Deutsch übersetze und zur Verfügung stelle?
Absolut in Ordnung, wobei ich persönlich es eher bevorzugen würde, wenn mir jemand hilft, das Manual für die 0.5.0 fertigzustellen. Das ist nämlich der größte Showstopper, weshalb keine 0.5.0 herausbringe. Mir fehlt da schlicht und ergreifend die Zeit dazu.
Okay, das ist frisch. Sehr schön, ersten offensichtlichen Fehler schonmal vermieden.
Ähm, wir nutzen zur Zeit libusb-win32 v1.2.6.0: http://sourceforge.net/p/opencbm/code/ci/master/tree/windrv/
Auch zu finden auf meiner HP: http://www.trikaliotis.net/Download/xum1541-windrv.zip
Aber zurück am Thema - OpenCBM/USB-Abstürze dieser Art sind m.E. nicht ungewöhnlich, kommt bei mir auch dauernd vor. Das ganze scheint mir einfach etwas wenig stabil zu sein, mir fliegt's manchmal schon bei bestimmten Lesefehlern oder schwer einzulesenden Disketten um die Ohren, mit den von dir genannten Symptomen/Meldungen. Floppy an USB ist halt eine kitzelige Sache.
Manche Leute empfehlen da den Einsatz von nicht zu langen USB-Verlängerungskabeln und vor allem extra kurzen IEC-Kabeln an der Floppy. Das mag gegen USB-Asynchronizitäten helfen.
Wieso sollte das helfen? Halte ich für ein Gerücht.
Zitat von »oobdoo«
Bei der frickeligen Rein-in-Software-USB-Implementierung, die das XU1541 verwendet finde ich das jetzt nicht soooo verwunderlich. Ein XUM1541 wäre besser, das verwendet einen Microcontroller mit Hardware-Support für USB.
Ja, das ist in der Tat frickelig. Das XU1541 kann entweder auf dem USB-Bus oder auf dem IEC-Bus arbeiten, aber nicht beides. Für einen Transfer auf dem IEC-Bus muss die USB-Seite komplett gestoppt werden. Dadurch gehen Pakete verloren, was aber an sich nicht kritisch ist, weil USB mit Retries arbeitet. Es dürfen nur nicht zu viele werden.
Bei Disketten mit Lesefehlern kann es aber passieren, dass die USB-Seite zu lange nicht bearbeitet werden kann.
Es gab hier mehrere Ansätze, wie man das lösen könnte - z.B. haben die USB-Software-Implementierungen "Verzögerungen", in denen man eventuell auch Zugriff auf IEC einbetten könnte. Vielleicht müsste man dafür auch dien Takt des Atmel erhöhen, um ein paar mehr Lücken zu erhalten. Allerdings wurde das ganze recht schnell aufgegeben, weil mit dem ZoomFloppy/XUM1541 eine deutlich bessere Alternative zur Verfügung steht und das den Aufwand nicht lohnt (und mir für dieses Gefrickele schlicht die Zeit fehlt!)
Es scheint sich in den Tickets auch nix mehr gross was zu tun, ausser, dass diese in die v0.50 oder auf einer andere Kategorie/Gruppe übertragen werden:
http://sourceforge.net/p/opencbm/activity?page=0
Ich will dokumentieren, was ich für die 0.5.0 noch machen will und was ich erst später sehe. Welche Tickets würdest du denn lieber früher gelöst sehen?
Schöne Kommentare sind dann z.B.: "Closing, because after so much time, it is unlikely we will fix this issue."
Das ist etwas kurz geschrieben. Gemeint ist: Nach so langer Zeit ohne Reaktion vom Ersteller sehe ich keine Chance, diese Fehler noch zu beheben, solange ich sie nicht nachvollziehen kann. Mir fehlen schlicht und ergreifend die Informationen, um es fixen zu können.
Ich will dokumentieren, was ich für die 0.5.0 noch machen will und was ich erst später sehe. Welche Tickets würdest du denn lieber früher gelöst sehen?
Ich habe nur allgemein, als Odo sich mal wieder von seinem PC/C64/Software/VS gemobbt fühlte und wir uns in der ShoutBox "unterhielten" mal auf's Log geschaut und da ist mir halt aufgefallen, dass die letzten Aktivität schon eine Weile her ist.
Mir war auch nicht ganz klar, was mit der 0.5.0 Version ist, weil diese auf Deiner Webseite nicht erwähnt war.
Das ist etwas kurz geschrieben. Gemeint ist: Nach so langer Zeit ohne Reaktion vom Ersteller sehe ich keine Chance, diese Fehler noch zu beheben, solange ich sie nicht nachvollziehen kann. Mir fehlen schlicht und ergreifend die Informationen, um es fixen zu können.
Den Kommentar fand ich einfach amüsant formuliert. Vermutlich war es aber weniger Absicht, homorvoll zu klingen.
Hast übrigens PM.
Ähm, wir nutzen zur Zeit libusb-win32 v1.2.6.0: http://sourceforge.net/p/opencbm/code/ci/master/tree/windrv/
Äh ja. Hab' ich sogar gemeint. 
So oder so um Meilen frischer als die V0.1.irgendwas, die sonst so andernorts in diversen Treiberpaketen für diese Geräte zu finden sind. Es gibt hier und da ellenlange "hilfreiche" Text, die Probleme mit unsignierten Treibern beim Windows-Boot diagnostizieren und diskutieren. Stellenweise sogar hier im Forum. Kann man sich alles sparen wenn man die neueren (signierten) libUSB-Treiber nimmt anstatt antike unsignierte.
Zitat
Wieso sollte das helfen? Halte ich für ein Gerücht.
Siehe Threadverlauf. Mir ging's mehr ums IEC-Kabel.
Siehe Threadverlauf. Mir ging's mehr ums IEC-Kabel.
Ist die Sache mit dem "extrakurzen" IEC-Kabel nicht vor allem ein Problem bei der Kombination von Zoomfloppy und 1571? Wenn ich mich recht entsinne gehen da die IEC-Signale direkt auf die Pins des AVR und so hoch wie das serielle Schieberegister da getaktet wird würde ich mich nicht wundern, wenn die Anstiegszeit der Signale da kritisch wird. Ein kurzes Kabel hat weniger Kapazität, die vom Pullup geladen werden muss und sollte daher steilere Flanken liefern.
(eine bessere Lösung wäre ein TTL-kompatibler Eingangspuffer auf der Zoomfloppy-Platine, aber vermutlich bringt der zusätzliche Verkauf von extrakurzen Kabeln mehr ein)
Die Idee mit Kapazität, Impedanz und so ist interessant. Auf der ZF-Mailingliste wird gerade genau das Gegentiel diskutiert: ZU KURZE Kabel bereiten bei einigen 6522 Probleme, mit längeren gibt es eher keine.
V0.40 vom August 2014. Scheint noch immer die aktuellste zu sein:
6502.org/users/sjgray/software/cbmxfer/cbmxfer.html
Frische Ware:
Change Log
==========
0.41 Mar 12,2016
* Added support for copying .P00 files to/from disk image. Check "Write P00" option to enable P00 creation.
* P00 files can now be viewed.
* Removed "show CMD window" option.
* Add "Create new folder" option in drop-down menu
* Enable "Cancel All" option for multi-file rename
* Fix "Lock View" in viewer
* Add 16/32 character wide font view option
* Temp fix for TRUE/FALSE settings in INI not recognized in non-english Windows
(German,French,Spanish now recognized - Will need to properly change INI save/load routines at some point)
* Add option to remember/use SRC/DEST paths
* Config options/settings are now automatically saved when you click OK and when you exit the app
(removed "Save as Default" button)
* Window layout (sized using ">>" buttons) are now rememebered
* Fix for "1571 (XM1541)" return string
