Bugs in OpenCBM?

OpenCBM hat garantiert (noch) Bugs, gar keine Frage. Das riecht aufgrund der deutschsprachigen Fehlermeldungen aber eher nach USB-Bugs, also mehr Windows-seitig. Was für USB-Treiber hast du im Einsatz, wie alt/welche Version?

Wenn mir OpenCBM dergestalt abraucht (ich benutze immer nur die Konsolenbefehle), dann halte ich mich mit "warten" garnicht grossartig auf. Floppy aus, USB-Gerät abziehen, kurz warten bis Windows das gemerkt hat (Tonsignal), USB-Gerät wieder rein, Floppy wieder an.

Zitat von oobdoo

cbmctrl version 0.4.0.80, built on Mar 8 2009 at 14:53:31

Jarrömmm... Das ist die OpenCBM-Version. Welche Version hat die USB-Treiberei?

Da ist übrigens nicht viel mit API. CBMXFer schickt einfach die Kommandozeilenbefehle raus, siehe "cbmxferlog.txt" im Verzeichnis. GUI4CBM4WIN dürfte es auch nicht anders machen.

Zitat von oobdoo

libusb-win32, v1.2.1.0 vom 29.07.2010

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

Zitat

"cbmxferlog.txt" oder ähnliches kann ich nicht finden.

Ach ja, sorry. Das wird nur geschrieben wenn bei CBMXFer in den Options "Log all commands" angehakt ist.

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.

Zitat von oobdoo

XU1541
(...)
.-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.

Ich meine mal irgendwo gelesen zu haben, dass der Entwickler des XU1541 die Entwicklung daran eingestellt hat weil mit der Hardware die Anforderungen an immer korrekt funktionierendes USB und korrekte Behandlung des IEC-Bus nicht gleichzeitig erfüllbar sind.

Hallo oobdoo,

Zitat von oobdoo

cbmctrl version 0.4.0.80, built on Mar 8 2009 at 14:53:31

auch wenn ich vom XU1541 keine Ahnung habe (ich nutze Zoomfloppy), könnte es sein, dass ein neueres OpenCBM helfen könnte. Schau mal hier:

http://spiro.trikaliotis.net/opencbm-alpha#download

wenn Du hier dann nach oben scrollst, stehen in den Änderungen auch Fehlerbehebungen für das XU1541.
Das einzige, was man aus der neueren Alpha-Version nicht verwenden sollte ist xum1541cfg.exe . Das ist eine uralt-Version...

Gruß
Werner

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

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

OpenCBM mit einem XAP oder Zoom läuft bei mir sehr stabil und absturzfrei.

Das mit den kurzen USB Kabel, ähm, ich halte das für ein Gerücht.
Allerdings für nibble copy sollte man direkt am USB hängen, ohne Hub!

Das XU-1541 ist ein Problemkind. USB sollte man nicht per software emulieren ... meine Ansicht dazu.

Aber das Floppy Kabel, - es ist richtig dass es kurz sein soll. Geschirmtes Kabel. Und Masse am Schirm, nicht ATN wie man es oft sieht!!!

Zitat von oobdoo

Das geht karpott, wenn ich den USB rein/raus mache?

Nee da geht nichts kaputt, USB ist hotplug fähig. Ich mach das dauernd.

Zitat von oobdoo

Punkt drei besagt, ich kann problemlos bis zu vier Geräte anschließen. Punkt fünf sagt das Gegenteil davon. Oder wie ist das zu verstehen?

Nee, das Zoomfloppy treibt möglicherweise mit der Hardware schon 4 Laufwerke. Fraglich ist, ob die Laufwerke 4 Geräte treiben können.

Das Problem ist ein ganz anderes:

Im normalen Modus, langsames IEC, macht es kein Problem wenn mehrere Laufwerke dran sind. Der Turbo Modus erfordert kurze Kabel und geringe Buslast. Der S1 wird aber möglicherweise noch gehen mit zwei Laufwerke. Der S2 jedoch verwendet alle Leitungen, und nicht angesprochene Laufwerke sind dadurch irritiert.

Der P Modus konnte noch nie gut mit mehreren Laufwerken umgehen, zudem halte ich es für problematisch, weil die parallelkabel ja direkt am VIA hängen.

Hallo,

Zitat von oobdoo

Die ZoomFloppy sollte hierzu nicht an einem laufenden PC mit dem USB-Kabeln verbunden sein !

Zitat von oobdoo

Das geht karpott, wenn ich den USB rein/raus mache?

Ne, ne ....
Die Anleitung zum ZoomFloppy sagt dazu:

Proper power-on sequence
We have tested leaving the ZoomFloppy connected to powered-on drives for days with no
problems, even though it was not connected via USB. You also can leave the ZoomFloppy
plugged into USB with the drive(s) off with no problems. But while the ZoomFloppy is designed
to be robust, you can avoid unnecessary wear by following these instructions for starting up and
shutting it down.

1. Start with drive off and ZoomFloppy unplugged from the PC’s USB
2. Plug in all cable(s) between ZoomFloppy and drive
3. Plug in ZoomFloppy via USB
4. Turn on drive power switch(es)

Turn off the equipment via the same sequence in reverse, at least doing steps 4 and 3. You don't
need to unplug the floppy drive from ZoomFloppy while not in use. The 15x1 drives with an
internal power supply tend to get hot if left on for a long time, so you may want to power them
off when not in use.

Gruß
Werner

Zitat von wweicht

Proper power-on sequence....
[..blabla..]
....not in use.

Das ist Fremdländisch, dass kannst Du unseren anglophoben Mitmenschen nicht zumuten....

Zitat von oobdoo

"Log all commands" gibts bei mir auch nicht.

CBMXFER v0.25 Beta

Welche Version hast Du?

V0.40 vom August 2014. Scheint noch immer die aktuellste zu sein:
http://www.6502.org/users/sjgr…ware/cbmxfer/cbmxfer.html

Zitat

Das mit dem kürzeren USB-Kabel habe ich auch schon versucht. Keine Änderung. Läuft oder läuft mal nicht.

Kurzes IEC-Kabel wäre wohl der wichtigere Knackpunkt.

Die Länge des USB-Kabels ist eher eine (dumme) Angewohnheit von mir aus anderen Fachbereichen; ob das bei XU1541 & Co. hilft oder nur Placebo ist weiss ich nicht. (Exkurs: Wenn man SDR-Sachen am Rechner macht kann es von Belang sein, ob das Dongle direkt im Port hängt oder an einer Verlängerung, von wegen Vermeidung von Störungen/Interferenzen aus dem Rechner. Oder kurz: mit Verlängerung ist der Empfang u.U. besser.)

Zitat

Wäre mal gut zu Wissen, welche Version die FW meiner XU1541 hat? Wie kann man das Auslesen?

Wenn ich mich recht erinnere (kann's grad nicht testen), sind usb_echo_test.exe und im Zweifelsfall auch read_event_log.exe da hilfreich.

Zitat von oobdoo

Und woher bekommt die? Ich finde die bei mir im Archiv nur als C-Source.

Hier z.B:
http://sourceforge.net/p/openc…/master/tree/xu1541/misc/

Zitat von oobdoo

Manchmal gibts auch ein "USB error in xu1541_ioctl(sync): usb_control_msg: sending control message failed, win error: Ein an das System angeschlossenes Gerõt funktioniert nicht."

Das ist ein USB-Problem.

Dazu ein paar Fragen:

• Welche Firmware- und Bootloader-Version hat dein XU1541?
• 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?
• Kannst du mal auf die neueste Alpha-Version von OpenCBM updaten?

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.