Hello, Guest the thread was called4k times and contains 76 replays

last post from strik at the

OpenCBM 0.4.99.100

  • Quote

    Aus der ersten Fehlermeldung (genShortCut.vbs) werde ich nicht schlau. Egal, was ich bei mir probiere, es gibt kein Problem.

    Ist dein Desktop irgendwie schreibgeschützt?

    schreibgeschützt ist da nichts, aber ich hab siweso Probleme mit Windows10. Seit ein paar Tagen öffnet sich kein Windows Menü mehr, wenn ich die Windows Taste drücke. Aber das hat nichts mit OpenCBM zu tun, wollte nur mitteilen, die Fehlermeldung aus einer ganz anderen Richtung kommen kann. Eine Installation via Desktop gab es ja bisher nicht.


    Die neue Version hab ich noch nicht probiert.

  • Kann es sein, dass dein Geräte eingesteckt war bevor die udev-Regel installiert wurde? Dann müsste abziehen und neues einstecken helfen.

    Darüber hinaus könnte es auch nötig sein, dass einlesen der udev-Regeln zu triggern: Laut https://unix.stackexchange.com…udev-rules-without-reboot geht das mit:

    Code
    1. udevadm control --reload-rules && udevadm trigger

    Ja du hast recht. Es war eingesteckt bevor ich angemeldet war. Ich habe die Beschreibung im Netz nachgelesen, die Regel gilt für aktive Benutzer!

    Die Regel gelten schon, installiert habe ich heute mittag, bin aber erst heute abend zum testen gekommen.

    Danke, Marc

  • Das verstehe ich nicht:

    Quote

    NOTE: Please really use your normal user account! Do not use your

    administrator account, as that one will not have the necessary rights!

    Müsste es nicht genau umgekehrt heißen?


    Habe die Power Shell als User gestartet. Da ging dann mal gar nichts... - Da keine Adminrechte...
    Als Admin gestartet verlief die Installation reibungslos. Der Fehler, den die runtest.bat anzeigte, ist weg. Alles funktioniert bestens.
    Auch die firmware-update.bat wurde überarbeitet und das Update lief problem los durch. :-)

  • Müsste es nicht genau umgekehrt heißen?

    Eigentlich nicht.

    Als Administrator hast du nicht alle Rechte. Die musst du dir erst durch den UAC-Dialog holen.
    Offenbar scheitert aber die Erkennung, ob man die nötigen Rechte hat manchmal, wenn man das Skript als Administrator startet.

    Als User hingegen erkennt ds Skript dies sofort und startet den UAC-Dialog, um sich die Rechte zu verschaffen.


    Habe die Power Shell als User gestartet. Da ging dann mal gar nichts... - Da keine Adminrechte...

    Hm... Ist bei dir der UAC-Dialog ausgeschaltet? Ich frage mich gerade, wie es auf Deutsch heisst.
    Möglicherweise muss ich das Skript hier noch etwas nachschärfen für diesen Fall?

    Der Fehler, den die runtest.bat anzeigte, ist weg. Alles funktioniert bestens.
    Auch die firmware-update.bat wurde überarbeitet und das Update lief problem los durch.

    Das ist gut, danke.

  • Kriege einen Fehler der sagt:

    Hm... Mit der 0.4.99.101?
    Kannst du mir sagen, welchen Befehl du davor benutzt hattest?

    Ja mit der 0.4.99.101. Und das ist das lustige. Gar keinen Befehl. Auch nach einem neustart mit dem Drive & des Host-Computers kommt diese Meldung glaube ich.

    Ich ueberpruefe das jetzt nochmal und melde mich.


    Ansonsten verwende ich eigentlich nur 2 Befehle. CBMCMD und D64COPY.

  • Ist bei dir der UAC-Dialog ausgeschaltet?

    Ich habe es gerade ohne UAC ("Benutzerkontensteuerung") probiert. Auch damit hatte ich keine Probleme.


    Auch nach einem neustart mit dem Drive & des Host-Computers kommt diese Meldung glaube ich.

    OpenCBM wird doch nicht von sich aus aktiv. Irgend etwas musst du doch getan haben.

  • Ich habe jetzt den Computer neugestartet. Das war das Resultat:

    Hattest du vor dem Neustart schon etwas gemacht?
    Kannst du mal gegenchecken:

    1. Rechner herunterfahren

    2. XUM1541 abziehen und neu anstecken

    3. Rechner wieder starten.


    Passiert das immer noch?


    Als XUM1541 verwende ich ein Arduino Micro mit der Firmware version 0.7

    Die Variante kenne ich noch gar nicht und auch eine offizielle Firmware kenne ich nicht dazu.
    Ist das eine der bekannten Firmware auf einem Eigenbau, oder ist die Firmware selbst kompiliert?

  • Wenn man den rechner Ausschaltet oder das XUM abzieht passiert es nicht mehr. Ich glaube ich weiss jetzt auch warum.

    D64Copy sagt am ende einer erfolgreichen Kopie was von wegen das es die Connection nicht closen konnte. Und ich nehme an dann "stolpert" der naechste befehl dadrueber.


    Das Arduino Micro ist der Chinaversion dem "Pro Micro" sehr aehnlich und lauft mit dieser .hex Firmware einwandfrei soweit ich das beurteilen kann.

    Nur die Pinbelegung ist natuerlich eine andere im vergleich zum "Pro Micro" und man muss das erstmal selber rausfinden.


    Ich hatte vorher mal die 0.9Firmware probiert, aber damit ging leider gar nichts.

  • Ich hatte vorher mal die 0.9Firmware probiert, aber damit ging leider gar nichts.

    es gibt v0.9 ? wusst ich gar nicht

    Oh, wo finde ich diese denn? Nun bin ich aber auch neugierig...

  • Leute, es gibt keine v0.9.
    Es gibt eine experimentelle modifizierte v0.8. Diese war aber nur zum Experimentieren, damit wir das Problem (nur ein Befehl möglich, dann hängt die ZF) verstehen können.
    Nach aktuellem Stand wird diese Änderung nicht in eine neue Version einfliessen, weil wir das Problem PC-seitig lösen wollen. Das sah mal anders aus.

  • Moin,


    ich habe die gleichen Fehlermeldungen unter Win10/64


    c:\Program Files\opencbm>cbmctrl.exe reset

    previous command was interrupted, resetting

    USB error in xum1541_control_msg: LIBUSB_ERROR_IO


    c:\Program Files\opencbm>cbmctrl.exe detect

    previous command was interrupted, resetting

    8: 1540 or 1541

    USB request for XUM1541 close failed, continuing: LIBUSB_ERROR_IO


    Ich habe vor der Installation Alles an Altlasten, was ich finden konnte, deinstalliert und manuell gelöscht.


    Die 1541-II läuft kurz an, danach Dauerblinken der Zoomfloppy.


    Gruß

    Jörg

  • Leute, es gibt keine v0.9.
    Es gibt eine experimentelle modifizierte v0.8. Diese war aber nur zum Experimentieren, damit wir das Problem (nur ein Befehl möglich, dann hängt die ZF) verstehen können.
    Nach aktuellem Stand wird diese Änderung nicht in eine neue Version einfliessen, weil wir das Problem PC-seitig lösen wollen. Das sah mal anders aus.

    Sorry, das war mein fehler. Meinte 0.8 natuerlich.

    Wuerde ja gerne den Post editieren um weiteres Missverstaendnis zu verhindern. Geht aber nicht mehr.

  • was mich noch immer stutzig macht, ist die Funktionsweise von 'rpm1514' bzw. 'cbmrpm41' und zwar, wenn man die Befehle abbricht. Danach ist das Laufwerk ziemlich störrisch und man kann z.B. kein 'dir' ausführen. Ein 'cbmctrl reset' wird zwar korrekt ausgeführt, aber dennoch bekomme ich keine 'dir' ausgeführt:


    ein erneutes 'cbmrpm41' führt dann sogar zu usb-Fehlern (vermutlich, weil der Befehl nicht korrekt ausgeführt wurde)



    Also die Exit-Strategie funktioniert da noch nicht richtig (hat sie bei allen vorherigen Versionen aber auch nicht). Vielleicht kann das noch in v0.5 einfließen. Abbrechen sollte immer ohne anschließende Fehler möglich sein.

  • ich habe die gleichen Fehlermeldungen unter Win10/64

    Kann ich dir testweise eine modifizierte opencbm-xum1541.dll schicken, die du in c:\windows\system32 unterbringen müsstest? Ich will jetzt keinen großen Test starten, aber mit einer Modifikation mal testen.


    Ein 'cbmctrl reset' wird zwar korrekt ausgeführt, aber dennoch bekomme ich keine 'dir' ausgeführt:

    cbmrpm1541 geht auf Track 41 (!), um keine Daten zu überschreiben.Beim Abbruch bleibt es dort stehen. Das sollte natürlich nicht sein.
    Du kannst dein laufwerk mit "cbmctrl pcommand 8 i0" wieder reaktivieren.

    in erneutes 'cbmrpm41' führt dann sogar zu usb-Fehlern (vermutlich, weil der Befehl nicht korrekt ausgeführt wurde)

    Hm... Das ist in der Tat eigenartig. In dem xum1541-Plugin gibt es ein hartes exit(-1), welches bei einem bestimmten Fehler (der hier auftritt) ausgeführt wird. Das dürfte wohl hier ursächlihc sein.
    Die Frage ist: Wieso macht das Plugin dies?

  • Ich habe an der v0.4.99.101 gearbeitet und sie gerade hochgeladen.


    Ich würde mich sehr freuen, wenn ein Kundiger hiervon auch ein Debian 18.04 amd_64 Paket bauen könnte!

    Mit dem nibtools Paket von emulaThor aus dem anderen OpenCBM Thread zusammen könnte ich dann endlich mal probieren,

    meine schon seit Monaten im Bastel-Backlog befindliche USB-XoomFloppy in Betrieb zu nehmen. Dann kann mein olles Thinkpad endlich mal in den wohlverdienten Ruhestand gehen, was aktuell nur wegen des LPT-Ports für das XAP1541-Kabel noch in Betrieb ist.