Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

cbmctrl on Linux hanging on checking for status #110

Open
nmelnick opened this issue Jan 8, 2024 · 4 comments
Open

cbmctrl on Linux hanging on checking for status #110

nmelnick opened this issue Jan 8, 2024 · 4 comments

Comments

@nmelnick
Copy link

nmelnick commented Jan 8, 2024

I fully acknowledge that this might be a me problem, but appreciate any insight that could be provided.

I have a ZoomFloppy, fresh from RETRO. Machine is a Gemini Lake based machine, running Ubuntu 22.04. Compiled OpenCBM from GitHub master, with the xum1541 plugin, at commit db80d1b against libusb-1.0. Test drive is one of two Commodore 1541 drives connected over serial.

xum1541cfg devinfo reports:

xum1541 device, model 2 (ZOOMFLOPPY), firmware version 8

Any command I run, of status 8, dir 8, command 8 I0:, or detect, with XUM1541_DEBUG=9 results in:

[XUM1541] xum1541_wait_status checking for status

... followed by a hang. Control-C will successfully stop the process, and a subsequent reset command will complain with previous command was interrupted, resetting, and successfully resetting. So, that's the thing. The only command that successfully seems to run is reset, as it doesn't seem to wait for a result. It does cause the red LED to light up as the drive spins for a standard reset, so data is definitely being sent over the line.

The hardware seems fine. Plugging the same ZoomFloppy and set of disk drives into a Windows 11 machine with OpenCBM binaries responds as the documentation suggests. All of the above commands work, I can read and write from the drives. In case one was more sensitive than the other, I changed out USB cables, and I changed out serial cables, to no avail.

I'd love to keep this connected to the Linux box and work with disks from there, but can connect it to the Windows machine if I have to. :) If you have any ideas for things to try, I'd appreciate it.

Thank you for all of your hard work.

@thierer
Copy link
Contributor

thierer commented Jan 8, 2024

Could you please check if the symptoms match what was reported in #108 (especially if the LED turns on again about ~2s after it turned off after plugging the device in) and if so flash the firmware attached to #108 (comment) and see if it helps?

@nmelnick
Copy link
Author

nmelnick commented Jan 9, 2024

Thank you for the reply! That absolutely worked. Thank you.

# xum1541cfg update -f xum1541-ZOOMFLOPPY-v08.hex
finding and preparing device for update...
note: device has version 8 but firmware is not newer (version 8)
warning: version mismatch but proceeding to update anyway
updating firmware...
Validating...
update completed ok!
$ cbmctrl status 8
[XUM1541] scanning usb ...
[XUM1541] scanning bus 002
[XUM1541] device 1d6b:0003 at 001
[XUM1541] scanning bus 001
[XUM1541] device 16d0:0504 at 024
[XUM1541] found xu/xum1541 version 0208 on bus 001, device 024
[XUM1541] xum1541 name: xum1541 floppy adapter (ZOOMFLOPPY)
[XUM1541] xum1541 serial number:   0
[XUM1541] firmware version 8, library version 8
[XUM1541] device capabilities 1b status 00
[XUM1541] [xum1541_init] Tape supported, disk mode entered.
[XUM1541] firmware git revision is 11ce3435
[XUM1541] compiled with avr-gcc version 13.2.0
[XUM1541] and using avr-libc version 2.1.0
[XUM1541] write 16 2 bytes from address 0x7ffc5851305e flags 3
[XUM1541] wrote 2 bytes (48 6f)
[XUM1541] xum1541_wait_status checking for status
[XUM1541] return val = 2
[XUM1541] wait done, extended status 2
[XUM1541] write done, got 2 bytes
[XUM1541] read 16 38 bytes to address 0x7ffc585130b0
[XUM1541] read 27 bytes (37 33 2c 43 42 4d 20 44 ...)
[XUM1541] read done, got 27 bytes
[XUM1541] write 16 1 bytes from address 0x7ffc5851305f flags 2
[XUM1541] wrote 1 bytes (5f)
[XUM1541] xum1541_wait_status checking for status
[XUM1541] return val = 1
[XUM1541] wait done, extended status 1
[XUM1541] write done, got 1 bytes
73,cbm dos v2.6 1541,00,00
[XUM1541] Closing USB link

@thierer
Copy link
Contributor

thierer commented Jan 9, 2024

Thanks for the feedback, glad it works! We're on it :), but for now I suggest you keep using that firmware.

@spiro-trikaliotis
Copy link
Member

This seems to have the same root cause like #108.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants