Bugs in OpenCBM?

  • @Odo: Kleiner Tipp: Für welchen Namen könnte sein Nick eine Abkürzung sein, wenn du mal auf die OpenCBM Webseite gehst? :thumbsup:

    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?
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki
  • syshack schrieb:

    @Odo: Kleiner Tipp: Für welchen Namen könnte sein Nick eine Abkürzung sein, wenn du mal auf die OpenCBM Webseite gehst? :thumbsup:

    Da ist Ryk dran Schuld. Der hat mich gestern mit merkwürdigen Wortkonstruktionen durcheinander gebracht. :P

    syshack schrieb:


    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?

    :dafuer:
    Mitwäre das nicht passiert! :prof:
    :syshack: Meine 3D-Drucker Teile auf thingiverse.com/oobdoo/designs :strom:
    Sammlung | 91 Bücher bzw. 25.261 Buchseiten mit Z80/8080 Power
  • Hallo,

    oobdoo schrieb:

    strik schrieb:


    Dazu ein paar Fragen:
    [*]Welche Firmware- und Bootloader-Version hat dein XU1541?

    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 sourceforge.net/p/opencbm/code/ci/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.


    strik schrieb:


    [*] Hängt das XU1541 an einem USB-Hub? Falls ja: Bleiben die Probleme, wenn du es ohne HUB betreibst? Bringt eventuell ein Wechsel auf einen anderen USB-Port etwas?

    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.


    strik schrieb:


    [*] Kannst du mal auf die neueste Alpha-Version von OpenCBM updaten?

    Alpha? 8|
    Mal schauen. :D

    Alle Versionen, die XU1541 und XUM1541 unterstützen, gelten als Alpha. :p

    strik schrieb:


    Ansonsten kontaktiere mich bitte per Mail, da lese ich häufiger mit und kann dir auch Testversionen bzw. Versionen mit mehr Debugging-Ausgaben zur Verfügung stellen.

    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.
  • syshack schrieb:

    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.
  • GenerationCBM schrieb:

    libusb-win32, v1.2.1.0 vom 29.07.2010

    Okay, das ist frisch. Sehr schön, ersten offensichtlichen Fehler schonmal vermieden. :)

    Ähm, wir nutzen zur Zeit libusb-win32 v1.2.6.0: sourceforge.net/p/opencbm/code/ci/master/tree/windrv/

    Auch zu finden auf meiner HP: trikaliotis.net/Download/xum1541-windrv.zip

    GenerationCBM schrieb:

    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.


    Unseen schrieb:

    Zitat von »oobdoo«
    .-USB error in xu1541_ioctl(sync): usb_control_msg: sending control message failed, win error: Der E/A-Vorgang wurde wegen eines Threadendes oder einer Anwendungsanforderung abgebrochen.

    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!)


    syshack schrieb:

    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:
    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?

    syshack schrieb:

    Schöne Kommentare sind dann z.B.: "Closing, because after so much time, it is unlikely we will fix this issue." :bgdev

    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.
  • strik schrieb:

    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.

    strik schrieb:

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

    Hast übrigens PM.
    ___________________________________________________________
    Meine Kreationen: Deviant Art | Toonsup | Flickr | Youtube
    | Twitter
    Avatar: Copyright 2017 by Saiki
  • strik schrieb:

    GenerationCBM schrieb:

    libusb-win32, v1.2.1.0 vom 29.07.2010

    Okay, das ist frisch. Sehr schön, ersten offensichtlichen Fehler schonmal vermieden. :)

    Ähm, wir nutzen zur Zeit libusb-win32 v1.2.6.0: sourceforge.net/p/opencbm/code/ci/master/tree/windrv/


    Äh ja. Hab' ich sogar gemeint. :whistling:

    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.

    GenerationCBM schrieb:

    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.

    Siehe Threadverlauf. Mir ging's mehr ums IEC-Kabel.
  • GenerationCBM schrieb:

    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)

    Quellcode

    1. 10 x=rnd(-1963):fori=1to81:y=rnd(1):next
    2. 20 forj=1to5:printchr$(rnd(1)*16+70);:next
    3. 30 printint(rnd(1)*328)-217

    sd2iec Homepage
  • GenerationCBM schrieb:

    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
  • Benutzer online 1

    1 Besucher