ZoomFloppy on Linux

[Joel Graff]

I'm currently running ZoomFloppy on Linux and am having an interesting probelm.  Specifically, if I try to access the drive using cbmctrl, it does nothing - no error, no quitting.  However, if I unplug the USB cable and plug it in, it will run whatever command I passed on ("detect", "dir 8", etc.)

Then, if I try to re-run it again, it's the same effect, nothing unless I unplug / replug the USB connection.

So, cbmctrl won't work unless it's running *Before* I plug the Zoomfloopy into my USB port.  Seems like something relatively fixable, but I'm not sure where to start...

[Martin Thierer]

> [...] if I try to access the drive using cbmctrl, it does nothing - no error, no quitting.

By "no quitting" you mean it just sits there with no output and you
have to hit ctrl+c to get the command prompt back?

> However, if I unplug the USB cable and plug it in, it will run whatever command I passed on ("detect", "dir 8", etc.)
> Then, if I try to re-run it again, it's the same effect, nothing unless I unplug / replug the USB connection.

I'm not sure I follow. Are you saying that for the first command after
you plugged the ZF in you get the behaviour you described above (that
is, it hangs without output), but if you re-plug it after you issued
(and canceled) a command, it works for one command and the next
command hangs again?

> So, cbmctrl won't work unless it's running *Before* I plug the Zoomfloopy into my USB port.

I don't understand that, either. If you run cbmctrl without the ZF
plugged in, it will immediately throw an error ("no xum1541 device
found"), right? Is that what you mean? If you plug in the ZF after you
ran cbmctrl once (which threw that error), it then works the next time
you run cbmctrl?

That said, could you please capture the output of "LIBUSB_DEBUG=9
XUM1541_DEBUG=9 cbmctrl status 8", both of an invocation that hangs
and one that works and post them here? (Please attach the output as
files, don't include it in the post).

[Joel Graff]

I figured a little bit out. If I hook the ZF up to my 1541 (which is turned on and has a floppy disk inserted), then plug it into my laptop, the LED flashes a couple times and the 1541 drive spins momentarily. Then there's a few seconds that the LED goes dark on the ZF before it lights up again.

If I run "cbmctrl dir 8" in the terminal *while the LED is dark*, it lists the contents of the floppy disk.

If I wait until the ZF LED comes on, cbmctrl looks like it hangs.  It's looking for a response and it's not getting anything.

I saw in the documentation that libusb 0.1 support was supposed to be deprecated.  I have both 0.1 and 1.0 installed.  0.1 was installed with libusb-dev, which I'm guessing is what cbmctrl was linked against when I built it from source.  Don't know if that could be a contributing factor.

Pastebins:

ZF error - https://pastebin.com/jCJzNdhc

ZF success - https://pastebin.com/Yb6LAmj4

[Martin Thierer]

Ok, that's interesting. This seems at least to be related to a problem
a handful of other people have reported (for example, "frank128", in
the "Trying to debug.." thread earlier on this list). Except for the
part that there's a period where it actually *does* work. Either the
others haven't noticed or yours is different.

> I figured a little bit out. If I hook the ZF up to my 1541 (which is turned on and has a floppy disk inserted), then plug it into my laptop,

It probably doesn't make a difference, but can you try first plugging
the ZF into your laptop and then connecting the 1541?

> [...] the LED flashes a couple times and the 1541 drive spins momentarily.

Are you talking about the LED of the ZF or the 1541? The LED on the ZF
shouldn't flash. It should be on for a short period after plugging it
in, then go and stay off until you issue a command. This is why this
isn't ok, either:

> Then there's a few seconds that the LED goes dark on the ZF before it lights up again.

Is this a new problem? If so, what changed? Or did you just acquire
the ZF? Or is it just the first time you try to use it on linux?

Could you check if dmesg reports anything unusual like the ZF getting
connected and disconnected in quick succession (without you actually
unplugging it)?

> I have both 0.1 and 1.0 installed. 0.1 was installed with libusb-dev, which I'm guessing is what cbmctrl was linked against when I built it from source. Don't know if that could be a contributing factor.

Is this on debian? I don't use it so I'm not sure what the -dev
package installs, but I doubt it's 0.1, more likely the 0.1
compatibility layer for 1.0. I'd normally think it should work, as the
Makefile should prefer 1.0 over 0.1 if both are installed.

*But*, what makes me suspicious: Did you create the logs the way I
told you, that is with *both* XUM1541_DEBUG *and* LIBUSB_DEBUG set?
Because if you did, that would indicate that it's indeed using 0.1, as
the logs you posted are missing the libusb debug output. You can check
which library is used with "strace cbmctrl status 8 |& grep
"openat.*libusb"". (I don't think your problem is related to the
libusb version, but who knows).

As you're apparently feeling comfortable compiling opencbm yourself:
Could you try the version from
https://github.com/thierer/OpenCBM/tree/set_configuration_fix and see
if it helps? (You don't need to *install* this version, but to test if
it has an effect, you have to make the "location" entry for xum1541 in
/etc/opencbm.conf point to the
"opencbm/lib/plugin/xum1541/libopencbm-xum1541.so" subdirectory of
where you compiled it).

[Joel Graff]

An update...

I completely removed opencbm and uninstalled libusb-dev (and the corresponding libusb-0.1 package), then installed the libusb-1.0-0-dev package.

I then cloned your branch and compiled with only libusb-1.0 to link against, then did a make / install on opencbm and the xum1541 plugin.

I had to add a symbolic link to point cbmctrl to /usr/lib/opencbm.so.0 as the library is actually installed in /usr/local/lib...  seems like a simple fix - I can do a PR if it helps?

The behavior is thus:

1. Plugging in the ZF usb cable with the 1541 on  / connected results in the drive spinning up and the ZF led turning on briefly during the spin up (the initial "blink" I saw before is gone)

2. After several seconds, the ZF LED comes on and stays on

3. "cbmctrl detect" works

4. "cbmctrl dir 8" works, but if there's an error (disk not in drive), subsequent efforts to list the directory fail with the same error, unless the USB cable is unplugged / replugged.

So some erratic behavior and an installation issue, but it seems functional thus far!

[Martin Thierer]

> I had to add a symbolic link to point cbmctrl to /usr/lib/opencbm.so.0 as the library is actually installed in /usr/local/lib... seems like a simple fix - I can do a PR if it helps?

Hm. I'm not sure if the entry is supposed to be updated when you
install a new version to a different path. @Spiro? My guess is the
file was created when you first installed your distro's package, which
was installed to /usr and not updated when you installed your
self-compiled version to /usr/local/. But it might very well be that
I'm to blame because I told you to edit the file (which you normally
shouldn't do, as it says in the header of the file).

(To instruct make to install to /usr/ instead of /usr/local/, add
"PREFIX=/usr/" to the command line).

What I don't understand, though, is that this mismatch should already
have happened when you compiled the source for the first time? In any
case, you should make sure that you didn't end up with two versions
(one in /usr/ and one in /usr/local/), but as you had to add the
symlink, probably not.

> 1. Plugging in the ZF usb cable with the 1541 on / connected results in the drive spinning up and the ZF led turning on briefly during the spin up (the initial "blink" I saw before is gone)
> 2. After several seconds, the ZF LED comes on and stays on

That's good to know, but as you simultaneously changed so many things
it's impossible to tell what caused it. Could you please try with the
stock .104 version
(https://github.com/OpenCBM/OpenCBM/tree/v0_4_99_104) if the problem
reappears?

> 4. "cbmctrl dir 8" works, but if there's an error (disk not in drive), subsequent efforts to list the directory fail with the same error, unless the USB cable is unplugged / replugged.

What is this error? With no disk in the drive it should be "drive not
ready". Does it even try to access the disk after the first failed
attempt? Could you post the debug log of when that happens?

[Joel Graff]

Recompiled using the OpenCBM master branch.  I'm seeing effectively the same behavior.

I connect the drive to the ZF, plug in the ZF USB, then turn on the drive.  I run cbmctrl dir 8 on a known good disk and I get a directory listing.  I repeat the command and cbmctrl just sits waiting for a response.  In order to access the drive again, I need to unplug / replug the USB cable.

Debug output from running cbmctrl status 8 - once after replugging the USB 9success), then again without replugging the USB (fail).  With the fail, I unplugged the USB to cause cbmctrl to terminate (~6 second index).

fail = https://pastebin.com/by4BNMJX

success = https://pastebin.com/yv68aYLu

[Spiro Trikaliotis]

Hello,

* On Wed, Feb 09, 2022 at 09:37:39PM +0100 Martin Thierer wrote:
> > I had to add a symbolic link to point cbmctrl to
> > /usr/lib/opencbm.so.0 as the library is actually installed in
> > /usr/local/lib... seems like a simple fix - I can do a PR if it
> > helps?

> Hm. I'm not sure if the entry is supposed to be updated when you
> install a new version to a different path. @Spiro?

When you compile correctly, the path is correct. ;)
Compiling directly from the makefile uses /usr/local/; for ommitting the
"local" part, you have to use the PREFIX.

Note, however, that you should *not* install into /usr/ directly if it
is not comming from the DEB package!

Please also note that if /usr/local/lib/ is just created, you might need
to add /usr/local/lib to /etc/ld.so.conf (or to some file in
/etc/ld.so.conf.d/) and running ldconfig.

So, Joel, if the problem was not the missing ld.so.conf* entry, then I
am one hundred percent sure that you had a mixed installation in the
first place.

No patch is needed!

> What I don't understand, though, is that this mismatch should already
> have happened when you compiled the source for the first time? In any
> case, you should make sure that you didn't end up with two versions
> (one in /usr/ and one in /usr/local/), but as you had to add the
> symlink, probably not.

Thinking about this again, this sounds extremely like there was the
missing reference to /usr/local/lib/ in ld.so.conf.

Regards,
Spiro

--
Spiro R. Trikaliotis
https://spiro.trikaliotis.net/

[Spiro Trikaliotis]

Hello Joel,

* On Thu, Feb 10, 2022 at 03:40:06PM -0800 Joel Graff wrote:
> Recompiled using the OpenCBM master branch. I'm seeing effectively the same
> behavior.

I am not sure how much time you want to invest in order to debug this.

If you can afford doing some tests, I would ask you to:

1. Check out v0.4.99.99 (there is a tag with that) from git
2. Compile that version and test it

Does it work?

If yes, would you mind trying versions "in between" v0.4.99.99 and git
HEAD of master, so that we can find out when it broke? ("git bisect"
will help a lot!)

If you cannot invest that much time, it is ok, too.

[Martin Thierer]

On Fri, Feb 11, 2022 at 12:40 AM Joel Graff <monog...@gmail.com> wrote:
> Recompiled using the OpenCBM master branch. I'm seeing effectively the same behavior.
>
> I connect the drive to the ZF, plug in the ZF USB, then turn on the drive. I run cbmctrl dir 8 on a known good disk and I get a directory listing. I repeat the command and cbmctrl just sits waiting for a response. In order to access the drive again, I need to unplug / replug the USB cable.

I'm confused. When you say "same behaviour", do you mean 1. like when
you start, the problem that made you post in the first place or 2.
after you compiled the version from my "set_configuration_fix" branch,
which led to the problem you described in your mail from Wednesday?

If 1. that's not what I understood at the time, but this would make more sense.

If 2. Is that what you meant with "subsequent efforts to list the
directory fail with the same error", so "the same error" wasn't
whatever error message you got when no disk was in the drive but the
"error" that cbmctrl hung? But that would mean that a. it wasn't
triggered by no disk being in the drive but just doesn't work for the
second invocation and b. there is basically no difference between the
initial behaviour, the version from my branch and what you get with
the master branch?

> Debug output from running cbmctrl status 8 - once after replugging the USB 9success), then again without replugging the USB (fail). With the fail, I unplugged the USB to cause cbmctrl to terminate (~6 second index).
> fail = https://pastebin.com/by4BNMJX
> success = https://pastebin.com/yv68aYLu

From what I can tell that's the same problem as in the first logs you
posted, that's why I came to the conclusion outlined above.

[Joel Graff]

The problem has been the same in all cases, really.  Once I got it to work, it seems as though the issue is it works only once.  The "missing disk error" was proof that it was working properly.  I got a correct response because I had forgotten to close the drive door...  But unless I re-plug the USB cable after cbmctrl completes successfully, it won't do anything on any subsequent attempt to run cbmctrl.  cbmctrl will just visually "hang" because it's waiting for a response from the USB subsystem which never comes.

As for the missing library location, I didn't "install directly" to usr/local myself, of course.  That's just what running "make install" does - I was only following the instructions on github.  To the point, others have noted it as well.  For example:
https://gareth.halfacree.co.uk/2014/12/installing-the-zoomfloppy-on-linux

I can see how an extra entry in ld.so.conf would fix it, but I'm still not clear what I did wrong to have caused it.

In any case, I don't mind bisecting to see if we can find where it broke.  I need this to work better or I can't use it, anyway.  I pulled form master and am running 0.4.99.104, currently.  I'll try going back until I find a version that works and see what I can figure out.

[Martin Thierer]

> The problem has been the same in all cases, really. Once I got it to work, it seems as though the issue is it works only once. The "missing disk error" was proof that it was working properly. I got a correct response because I had forgotten to close the drive door... But unless I re-plug the USB cable after cbmctrl completes successfully, it won't do anything on any subsequent attempt to run cbmctrl. cbmctrl will just visually "hang" because it's waiting for a response from the USB subsystem which never comes.

Ok, thanks for confirming this. So it always worked the first time you
ran cbmctrl or whatever after plugging the ZF in and started hanging
on subsequent attempts, right?

The problem is that right now I don't have many ideas as to what could
cause it :) I had what might have been the exact same problem two
years ago and that turned out to be a linux kernel bug which has since
been fixed. From your log files I can see you're running 5.13, which
should be fine. That said, could you please check in dmesg which
driver is used for the USB port you're using? After you plugged the ZF
in, it should say something like "new full-speed USB device number [x]
using [y]". The "y" is the driver. The bug I was referring to was in
the "xhci_hcd" driver. If you're using a different driver, then maybe
this driver just has the same bug. Although there should be a
workaround for this bug in git master (but not in my branch, it
removed that workaround).

A few more questions:
- If you have both USB3 and USB2 ports, could you try one of the other type?
- Is the problem that the next command doesn't work also true for
"cbmctrl dir"? That's is, does the second command fail if the first
one was a "cbmctrl dir" or only after a "cbmctrl status"? (I know that
sounds strange, but this was the case for my version of the problem).
- Regarding the logs you provided: Was the "failed" attempt also
preceded by a working try? Because the log shows that the ZF thinks it
was either 1. never connected to or 2. became disconnected from USB,
and if 1. then it shouldn't have worked before and if 2. that might
give a hint.

[Joel Graff]

I have another Ubuntu machine I can try that has USB3. I’m using an old 2009 MacBook to test this currently.

And yes, it succeeds on the first attempt after plugging it in, but falls on every subsequent attempt, unless I replug the USB cable.

I’ll try to get the other info you asked for soon.

Sent from my iPhone

> On Feb 11, 2022, at 5:57 PM, Martin Thierer <mthi...@gmail.com> wrote:
>
> 

> --
> You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/CAL3BvCwcsLLAzdnZcDdxaP378JRAfgguopV0U0hnGfPZbQapcg%40mail.gmail.com.

[Spiro Trikaliotis]

Hello Joel,

* On Fri, Feb 11, 2022 at 03:00:18PM -0800 Joel Graff wrote:

> In any case, I don't mind bisecting to see if we can find where it broke. I
> need this to work better or I can't use it, anyway. I pulled form master and
> am running 0.4.99.104, currently. I'll try going back until I find a version
> that works and see what I can figure out.

Note that I mentioned 0.4.99.99, because after that, there were some
bigger changes on the USB code. Thus, this might be a good starting
point for an old version that works.

If this does not work, either, then we might have another problem here.

I forgot if you already anwered this: Which firmware version of the ZF
do you use?

[Joel Graff]

Cloned OpenCBM from master and tried building it on my Ubuntu daily driver system.  Make fails, not sure what's wrong...

https://pastebin.com/Nydf36tm

ZF currently on firmware version 8

[Joel Graff]

I take it back.  Forgot I didn't have cc65 installed.

Once I installed everything, make completed successfuly.  Successfully installed the latest version from master.

Connected everything and it seems to run without error on USB 2.0 and USB 3.0

Currently running Linux 5.16.7 (Ubuntu 20.10) on my daily driver.

The MacBook is running 20.04 and 5.13.0.  I really need to be able to use this from the MacBook, otherwise, I'd call it good. :/

I'll give 4.99.99 and / or upgrading the kernel.

[Joel Graff]

Compiling 4.99.99 failed, giving me a fatal error on an include.  Specifically, it couldn't find "usb.h".

[Martin Thierer]

> Compiling 4.99.99 failed, giving me a fatal error on an include. Specifically, it couldn't find "usb.h".

Spiro would be in a better position to answer this, but I *guess* that
is because the original 0.4.99.99 didn't have libusb1 support and
you're probably missing the libusb0 dev package.

But instead of installing that maybe better try revision 3400b01f
instead, which should include libusb1 support but still is before all
the USB changes that Spiro mentioned took place.

[Joel Graff]

Sorry about the late reply.  I tried upgrading the kernel on my laptop to 5.16, hoping that might fix it and ended up reinstalling ubuntu instead...

Anyway, running 5.13 kernel, OpenCBM at commit 3400b01f appears to run without fail on my old MacBook laptop...

[Martin Thierer]

> Anyway, running 5.13 kernel, OpenCBM at commit 3400b01f appears to run without fail on my old MacBook laptop...

That's good to hear :) To be honest, I didn't expect that. because
between that revision and my "set_configuration_fix" branch there
aren't many changes which I could imagine making a difference.

Did you try the master branch and/or my branch again, after your
reinstall and check if the issue still exists there? Just to make sure
we aren't following a red herring.

If it persists, could you please try the branches "dynlibusb_changes"
and "revert_38fdf837" from my repository? I can't see any of these
changes making a difference, but something clearly does ¯\_(ツ)_/¯. If
this doesn't give a clue I think there's no way around a git bisect.

[Joel Graff]

Just tested on OpenCBM/master.  Seems to work properly now.  Maybe a package conflict or outdated repo package on the previous ubuntu install was messing things up?

For the record:

Machine: MacBok A1181 (2009), 3 GB RAM

OS: Ubuntu 21.10 (impish)

Kernel: 5.13.0-19

OpenCBM: 0.4.99.104

cc65: V2.18 (Ubuntu 2.19-1)
libusb: 1.0-0

Thanks for the help.  I have a *ton* of old disks to test and archive. :)

[Joel Graff]

On an unrelated topic, I just encountered an odd edge case doing a directory listing on a floppy.

That is, when I ran "cbmctrl dir 8", the directory listing simply repeated four track listings ad infinitum.  Breaking the program left the disk drive running.  I tested this on two different ubuntu systems with the same effect.

I'm thinking this is the disk causing the problem - not something on my system.  Seems like an edge case worth checking for.  Happy to ship the disk if anyone wants to try it (though I've no idea if it'll be reproducible.  Unplugging / replugging the USB forces a reset of the drive.

If nothing else, just watching for a repetition of the directory listing (or too many tracks being listed) might handle it well enough, I guess?

[Nate Lawson]

Sectors link to each other so they can have loops. If you generate and image with d64copy it should be easy to verify this. 

I suppose cbmcontrol could keep track of the last sectors seen during a listing and abort when it sees a loop. 

-Nate

On Feb 19, 2022, at 8:59 AM, Joel Graff <monog...@gmail.com> wrote:

On an unrelated topic, I just encountered an odd edge case doing a directory listing on a floppy.

--

You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/2b2434eb-baf9-4adf-bfa8-14fcbec77f9fn%40googlegroups.com.

[Joel Graff]

Forgot to include the pastebin link:
https://pastebin.com/ML1jfAtj

[Martin Thierer]

> That is, when I ran "cbmctrl dir 8", the directory listing simply repeated four track listings ad infinitum. Breaking the program left the disk drive running. I tested this on two different ubuntu systems with the same effect.
>
> I'm thinking this is the disk causing the problem - not something on my system. Seems like an edge case worth checking for. Happy to ship the disk if anyone wants to try it (though I've no idea if it'll be reproducible.
>

> If nothing else, just watching for a repetition of the directory listing (or too many tracks being listed) might handle it well enough, I guess?

Could you create an image of the disk, like Nate suggested ("d64copy 8
test.d64") and run "xxd -s91648 -l2 -g1 test.d64"? If it is what it
looks like (a directory block linking to itself) this will output
"00016600: 12 01"). If that's not the case, I'm interested :)

Otherwise I don't think it would be easy to fix in opencbm or even
worth fixing, to be honest. cbmctrl just asks the drive for the
directory; if you try to LOAD "$",8 from that disk, it would get stuck
in a loop, too.

> Unplugging / replugging the USB forces a reset of the drive.

This shouldn't be necessary, though. If you cancel a command, the next
command should detect that and issue an reset automatically. Doesn't
this work for you?

[Joel Graff]

Running xxd on the image resulted in the output you expected.

In the case of the looping directory call, I can break out of cbmctrl (CTRL + Z), but the drive continues to spin.  Cbmctrl reset does nothing, stating the resource is unavailable.  Shutting off the drive and restarting it doesn't change anything.  I must unplug the USB and plug it in again before it's recognized.

[Martin Thierer]

> In the case of the looping directory call, I can break out of cbmctrl (CTRL + Z), but the drive continues to spin.

Use Ctrl-C to cancel the command. Ctrl-Z will suspend it in the
background, which will not free its resources, most notably the USB
connection.

[Bryce Lynch]

On Tue, Feb 8, 2022 at 2:20 PM Martin Thierer <mthi...@gmail.com> wrote:

> [...] the LED flashes a couple times and the 1541 drive spins momentarily.

Are you talking about the LED of the ZF or the 1541? The LED on the ZF
shouldn't flash. It should be on for a short period after plugging it
in, then go and stay off until you issue a command. This is why this
isn't ok, either:

Weird!  I'm having a similar problem (which is what drew me to this mailing list) and I'm

seeing the same thing.  I thought the LED blinking on the Zoomfloppy was normal.

Also, cbmctrl reliably hangs when I run it, even if I run `cbmctrl dir 8` or 

 

Is this a new problem? If so, what changed? Or did you just acquire
the ZF? Or is it just the first time you try to use it on linux?

New ZF, here, first time trying it (well, second - $dayjob got in the way).

 

Could you check if dmesg reports anything unusual like the ZF getting
connected and disconnected in quick succession (without you actually
unplugging it)?

Nope.

 

---
The Doctor [412/724/301/703/415/510]
https://drwho.virtadpt.net/
"I am everywhere."

 

[Nate Lawson]

Isn’t it control-C to break? You’re suspending the process so it keeps a lock on the device. 

-Nate

On Feb 19, 2022, at 3:36 PM, Bryce Lynch <virtua...@gmail.com> wrote:



--

You received this message because you are subscribed to the Google Groups "ZoomFloppy Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to zoomfloppy-use...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/zoomfloppy-users/CANO8xMg8D3%2BGkByxkpfpGq7AqRUZj5O1oebOx4DjXKUkoW%2BFhQ%40mail.gmail.com.

[Joel Graff]

My mistake.  I had forgotten that.

[Spiro Trikaliotis]

Hello,

* On Sat, Feb 19, 2022 at 09:43:21AM -0800 Nate Lawson wrote:
> Sectors link to each other so they can have loops. If you generate and image
> with d64copy it should be easy to verify this.
>
> I suppose cbmcontrol could keep track of the last sectors seen during a listing
> and abort when it sees a loop.

cbmctrl uses the original floppy code to read the disk. In fact, it does
the equivalent to (neglecting error checking):

100 C0$=CHR$(0)
110 OPEN 1,8,0,"$":REM or whatever was given as argument to cbmctrl dir
120 GET#1,A$,A$:REM LOAD ADDRESS
130 GET#1,A$,B$:REM LINK ADDRESS
140 IF A$="" AND B$="" GOTO 190
150 GET#1,LO$,HI$: REM LINE NUMBER
160 PRINT ASC(LO$+C0$) + ASC(HI$+C0$)*256
170 GET#1,A$:IF A$<>"" THEN PRINTA$;:GOTO 170
180 GOTO 130
190 CLOSE 1

Thus, it cannot do this, because it does not even see the links.

It would need a complete rewrite. Additionally, it would loose
compatibility: The current approach works even for disk drives that are
not know to OpenCBM, while the approach "we'll do it ourselves" needs
knowledge of the drive in question.

Of course, a more elaborate approach could be to use own routines with
known drives, and standard routines with unknown ones, but there are
other, more important improvements for OpenCBM waiting than that.

[Martin Thierer]

> Weird! I'm having a similar problem (which is what drew me to this mailing list) and I'm
> seeing the same thing. I thought the LED blinking on the Zoomfloppy was normal.

To clarify: Blinking isn't strictly an error. My remark was in
reference to Joel's statement that his ZF is flashing after just
plugging it in. Is that what yours does as well? It's perfectly normal
that it blinks while performing a command, like with "cbmctrl dir"
while the data is transferred. But it shouldn't after just plugging it
in and it should stop after the command finished (unless you aborted
the command with Ctrl-C).

> Also, cbmctrl reliably hangs when I run it, even if I run `cbmctrl dir 8` or

In other words it doesn't work at all? Or only sometimes?

>> Could you check if dmesg reports anything unusual like the ZF getting
>> connected and disconnected in quick succession (without you actually
>> unplugging it)?
>
> Nope.

So does that mean you're running Linux? If so, could you compile and
install the version from
https://github.com/thierer/OpenCBM/tree/set_configuration_fix and see
if that helps?

[Joel Graff]

Just as a note, CTRL+C yields the same result - cbmctrl terminates, but the zoomfloppy light blinks as the 1541 drive spins.  replugging the ZF is the only way to fix it.

On Saturday, February 19, 2022 at 6:41:53 PM UTC-6 Nate Lawson wrote:

[Bryce Lynch]

On Sun, Feb 20, 2022 at 12:24 PM Martin Thierer <mthi...@gmail.com> wrote:

To clarify: Blinking isn't strictly an error. My remark was in
reference to Joel's statement that his ZF is flashing after just
plugging it in. Is that what yours does as well? It's perfectly normal

No, just when I do anything with the ZF.  When cbmctrl hangs, it stays lit.

 

In other words it doesn't work at all? Or only sometimes?

The only thing I've gotten to work is `cbmctrl reset`.  No other commands work.

 

So does that mean you're running Linux? If so, could you compile and

Yes.  Kernel 5.16.0-arch1-1, current as of 20220123.

 

install the version from
https://github.com/thierer/OpenCBM/tree/set_configuration_fix and see
if that helps?

I tried that.  It compiled as expected but did not work (i.e., the same thing happened as

with the version I installed from package (r1486.9e547f31-1)).  I also tried compiling and

running from HEAD, which also did not work.

[Martin Thierer]

> Just as a note, CTRL+C yields the same result - cbmctrl terminates, but the zoomfloppy light blinks as the 1541 drive spins.

This part is no surprise.

> replugging the ZF is the only way to fix it.

Are you sure? What happens if you issue a "cbmctrl status 8" or just a
"cbmctrl reset" instead?

[Martin Thierer]

>> To clarify: Blinking isn't strictly an error. My remark was in
>> reference to Joel's statement that his ZF is flashing after just
>> plugging it in. Is that what yours does as well? It's perfectly normal
>
>
> No, just when I do anything with the ZF. When cbmctrl hangs, it stays lit.

What do you mean "it stays lit"? You mean solid? Is the LED already
lit before you start the command? Or does it come on when it starts?
While a command is active it should actually blink.

Ist this really a genuine Zoomfloppy, or some other devboard based
xum1541 device?

>> install the version from
>> https://github.com/thierer/OpenCBM/tree/set_configuration_fix and see
>> if that helps?
>
>
> I tried that. It compiled as expected but did not work (i.e., the same thing happened as
> with the version I installed from package (r1486.9e547f31-1)). I also tried compiling and
> running from HEAD, which also did not work.

Did you install from the opencbm-git AUR package? And how did you
install the version from my tree? By changing the "source" variable in
the PKGBUILD and installing the resulting package? Or didn't you
install it at all and just ran it from the directory where you
compiled it?

[Bryce Lynch]

On Mon, Feb 21, 2022 at 2:23 PM Martin Thierer <mthi...@gmail.com> wrote:

> replugging the ZF is the only way to fix it.
Are you sure? What happens if you issue a "cbmctrl status 8" or just a
"cbmctrl reset" instead?

Note: I've finally had a chance to revisit this particular project.  I'm trying two different builds

of opencbm.

For checkout 9e547f31, the Zoomfloppy's LED blinks five times, goes dark for about a

second, and then comes back on.  At the same time the 1541's activity LED lights up for

about two seconds and then goes dark.  I also get the response "previous command

was interrupted, resetting."

`cbmctrl detect` just hangs until I kill it.  The Zoomfloppy's LED stays on, the 1541's doesn't

come on.

`cbmctrl status 8` results in the output "previous command was interrupted, resetting", no

Zoomfloppy LED blinking, 1541's status LED stays off.

Powering off 1541, installing opencbm checkout e706a8f8, powering 1541 back on, repeating.

`cbmctrl reset` - "Segmentation fault (core dumped)"

`cbmctrl detect` - "Segmentation fault (core dumped)"

`cbmctrl status 8` - "Segmentation fault (core dumped)"

At least for this particular clone of the opencbm repo, it doesn't seem to work as expected.

Just for fun, let me check out a brand-new copy of the opencbm source code and install it.

`cbmctrl reset` - "Segmentation fault (core dumped)"

`cbmctrl detect` - "Segmentation fault (core dumped)"

`cbmctrl status 8` - "Segmentation fault (core dumped)"

Now I'm really puzzled.

[Bryce Lynch]

On Mon, Feb 21, 2022 at 2:27 PM Martin Thierer <mthi...@gmail.com> wrote:

What do you mean "it stays lit"? You mean solid? Is the LED already

It is solid.  The LED turns on and stays on.

 

lit before you start the command? Or does it come on when it starts?

It is not.  Prior to testing the LED is off.  It only comes on when I send a command to

the drive.

 

While a command is active it should actually blink. 

Ist this really a genuine Zoomfloppy, or some other devboard based
xum1541 device?

Looking at the invoice, it's a ZOOMFLOPPY+IEEE from RETRO Innovations.  Looking at the

PCB, it's a ZoomFloppy v1.0, copyright 2010 by Nate Lawson, PCB copyright 2010 RETRO

Innovations.

 

> I tried that.  It compiled as expected but did not work (i.e., the same thing happened as
> with the version I installed from package (r1486.9e547f31-1)).  I also tried compiling and
> running from HEAD, which also did not work.

Did you install from the opencbm-git AUR package? And how did you

Initially I did use the opencbm-git AUR package.  I've tried three different versions installed

from the AUR:

20220117 - opencbm-git-r1484.3be5c7d2-1-x86_64.pkg.tar.xz

20220130 - opencbm-git-r1486.9e547f31-1-x86_64.pkg.tar.xz

0220318 - opencbm-git-r1489.e706a8f8-1-x86_64.pkg.tar.xz

 

install the version from my tree? By changing the "source" variable in
the PKGBUILD and installing the resulting package? Or didn't you

install it at all and just ran it from the directory where you
compiled it?

I uninstalled opencbm-git using pacman, cloned the OpenCBM repo from Github,

compiled it, and installed it the old fashioned way using Spiro's documentation

(https://opencbm.trikaliotis.net/opencbm-11.html):

sudo make -f LINUX/Makefile install install-plugin-xum1541

I used the script utility to record the output of the command so I could go back

later and manually remove the files because they were no longer tracked as a package.

I just tried it again with git commit e706a8f8a5200a8f2f4b2f4bbae9ef0ffeab4baf - same

results.

[Martin Thierer]

> Initially I did use the opencbm-git AUR package. I've tried three different versions installed
> from the AUR:

[...]
> 0220318 - opencbm-git-r1489.e706a8f8-1-x86_64.pkg.tar.xz

Does the version from this package dump core as well? Or only the one
compiled and installed from your direct checkout?