In need of testers for libusb1

[Spiro Trikaliotis]

Hello,

I know that there are people who have problems using ZoomFloppy. The
devices seems to not react on certain commands or does not appear at
all.

One of the things that come to mind that might be the problem is the
libusb library. OpenCBM currently uses libusb0, which is really outdated
and unsupported for some years now. There had been some problems on
MacOS, for example, where OpenCBM could not find the ZF at all when
using with libusb0. With libusb-compat, which is a layer on top of the
newer libusb1 to provide backwards compatibility, it worked.

I have worked on porting OpenCBM to libusb1. The Linux variant is
working for me, Windows works too (but still needs some manual steps for
installing, I will fix this soon), and Mac OS is still untested.

I am asking here for people who are willing to test the version for me.
This is especially true if you have had problems with the ZF in the
past. I would like you to test it with the newer variant.

For Linux and Mac OS, just compile it as you have always done. You just
need to checkout the "libusb0_and_libusb1" branch from the GitHub
repository:

https://github.com/OpenCBM/OpenCBM/tree/libusb0_and_libusb1

Make sure that the libusb1 development package (libusb-1.0-0-dev on
Debian based systems) is installed before compiling it, and it should
work. If both libusb0 and libusb1 are available, the build system
prefers libusb1.

For Windows, I will work on automating the install process. Currently,
the libusb DLL has to be stored "by hand" at the right location. Just
contact me, and I will tell you how to install it. The documentation is
not finished yet.


I am interested in two things:

1. Are there any regressions with this? This applies to anyone.

2. For people who have had problems before, does the new variant fix
the problems?

Please give me feedback, and do not forget to tell me if you are running
on Windows, Mac OS or Linux, and also tell me the version of the OS.

Thank you in advance!

Regards,
Spiro.

--
Spiro R. Trikaliotis
http://www.trikaliotis.net/

[Spiro Trikaliotis]

Hello,

* On Fri, Mar 01, 2019 at 10:08:35PM +0100 I wrote:

> I am asking here for people who are willing to test the version for me.
> This is especially true if you have had problems with the ZF in the
> past. I would like you to test it with the newer variant.

If there is someone who also owns an XU1541 (that is, not ZF, but the
simpler device), feel free to test it, too.

All the tools have been ported, including xum1541cfg (for updating the
ZF) and the XU1541 tools usb_echo_test, read_event_log and
xu1541_update. So, you can test them, too.

[Nate Lawson]

I can do macOS tests with ZoomFloppy.

-Nate

> --
> 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.
> For more options, visit https://groups.google.com/d/optout.

[Arnd Menge]

And I can test on Windows with ZoomFloppy.

-Arnd

[Pontus Berg]

HERO!

/Pontus Berg
 Mobile: +46 735 082860

 Skype: BacchusBerg

[Spiro Trikaliotis]

Hello again,

* On Fri, Mar 01, 2019 at 10:08:35PM +0100 I wrote:

> I have worked on porting OpenCBM to libusb1. The Linux variant is
> working for me, Windows works too (but still needs some manual steps for
> installing, I will fix this soon), and Mac OS is still untested.

I am not sure if everyone has understood me correctly. Linux should be
testable "as it is" (if you checkout the branch libusb0_and_libusb1,
that is).

For MacOS, it also should work if you do not use the Ports file. I
cannot adjust the ports file, as I do not know anything about this.
Here, I need external help.


LINUX AND MACOS
===============

The Linux and MacOS instructions were given in my previous mail:

> For Linux and Mac OS, just compile it as you have always done. You just
> need to checkout the "libusb0_and_libusb1" branch from the GitHub
> repository:
>
> https://github.com/OpenCBM/OpenCBM/tree/libusb0_and_libusb1
>
> Make sure that the libusb1 development package (libusb-1.0-0-dev on
> Debian based systems) is installed before compiling it, and it should
> work. If both libusb0 and libusb1 are available, the build system
> prefers libusb1.

WINDOWS
=======

For Windows, I created an installation package. Please follow the
instructions here:

In principle, it is simple:

1. Uninstall the current OpenCBM, if it is still installed.

2. Install the driver for ZoomFloppy with ZADIG (https://zadig.akeo.ie/).
It is important to choose the "WinUSB" driver. This is a difference
to the online instructions that are currently available, which asked
to use libusb-win instead. libusb-win supports libusb0 only, but we
want to use WinUSB which supports libusb1!

3. Get the (special) OpenCBM package from
https://spiro.trikaliotis.net/Download/opencbm-0.4.99.99/opencbm-0.4.99.99-libusb1.zip

4. Unpack it, go into the directory where you uninstalled it and execute
"install.cmd" as Administrator.

Afterwards, everything should be installed in C:\Program Files\OpenCBM.

I tested it myself on Win7, Win10 and WinXP. For XP, I had to use an
older ZADIG-Version that still supports it! But, I was only able to test
it in VMs, as I do not own a native Windows anymore.

> I am interested in two things:
>
> 1. Are there any regressions with this? This applies to anyone.
>
> 2. For people who have had problems before, does the new variant fix
> the problems?
>
> Please give me feedback, and do not forget to tell me if you are running
> on Windows, Mac OS or Linux, and also tell me the version of the OS.

[Pontus Berg]

I'm not using ZoomFloppy but a mini version by Swedish friend Björn Hutmacher and I tried on a Windows 10 machine that didn't have any previous installation.

Installing the USB driver and OpenCBM was easy enough. My general comment would be that my understanding was that OpenCBm normally lands in c:\OpenCBM which has the advantage that the patch doesn't contain any space. They can always cause troubles in command line tools.

The result was still that I got an error saying that the "firmware version is too low (7 > 8)" when trying to run "d64copy.exe 8 jallajalla.d64

/Pontus Berg
 Mobile: +46 735 082860

 Skype: BacchusBerg

[Pontus Berg]

Everything I try end up in the complaints on version numbering, including "cbmctrl.ece detect"

/Pontus Berg
 Mobile: +46 735 082860

 Skype: BacchusBerg

[Pontus Berg]

I should also say that there is no firmwareupdate.bat in the OpenCBM folder, as indicated in the manual.

/Pontus Berg
 Mobile: +46 735 082860

 Skype: BacchusBerg

[Spiro Trikaliotis]

Hello,

* On Fri, Mar 08, 2019 at 01:07:03PM +0100 Pontus Berg wrote:

> Installing the USB driver and OpenCBM was easy enough. My general comment would
> be that my understanding was that OpenCBm normally lands in c:\OpenCBM which
> has the advantage that the patch doesn't contain any space. They can always
> cause troubles in command line tools.

To be more precise, it lands in %ProgramFiles%\opencbm. That is, it
lands there were Windows believes that program belong.

This seems to be the best place from my point of view.

> The result was still that I got an error saying that the "firmware version is
> too low (7 > 8)" when trying to run "d64copy.exe 8 jallajalla.d64

Well, this has nothing to do with libusb1. The firmware 8 was already
added before, it fixes a problem with the 2031 drive.

I will generate a new version of the plugin that will allow to handle
firmware 7 and 8. The differences are so small that I think this makes
sense in this special case.

[Pontus Berg]

Spiro,

Agree on the program placement, but just to highlight that this might be a change for people with the previous setup.

I saw the conversation you had with Björn - many thanks for the quick action. I alo see from the repo that you have implemented the changes. 

Is the ZIP file [1] updated or how do I install the update? I have cloned the repo but I have no clue how to build it. Just cloning a repo is an effort - I'm way out of my comfort zone here... Sorry ;-)

[1] https://spiro.trikaliotis.net/Download/opencbm-0.4.99.99/opencbm-0.4.99.99-libusb1.zip  

/Pontus Berg
 Mobile: +46 735 082860

 Skype: BacchusBerg

[Spiro Trikaliotis]

Hello Pontus,

* On Fri, Mar 08, 2019 at 01:31:48PM +0100 Pontus Berg wrote:
> I should also say that there is no firmwareupdate.bat in the OpenCBM folder, as
> indicated in the manual.

The manual is misleading: The file is in the folder from where you
installed OpenCBM. That is, it is in the folder where you pressed on
"install".

[Spiro Trikaliotis]

Hello,

I just uploaded a NEW Windows binary version of OpenCBM.

You can get it here:

https://spiro.trikaliotis.net/Download/opencbm-0.4.99.99/opencbm-0.4.99.99-libusb1-v2.zip

The difference to the previous one is that the new one ("v2") allows for
being used with firmware 7 or firmware 8. That is, you do not need to
update your firmware just to check the libusb1 support.

The firmware variants 7 and 8 only differ in a timing difference on the
(parallel) IEEE bus, fixing a problem with the 2031 drive. Otherwise,
they are identical.

I found out that too many people had problems with the update.


I am adding the original instructions again here, I just fixed the
download link:

> https://spiro.trikaliotis.net/Download/opencbm-0.4.99.99/opencbm-0.4.99.99-libusb1-v2.zip

[Pontus Berg]

Spiro,

As you know, I'm using Björns interface and not the original ZoomFloppy and I use a 1571.

The new package installed fine and all looked good - I have transferred a handfull of disks and it all looks fine.

Had a chat with Jani who does the d2d64 and that one complains about my "X-cable", but I do believe this is purely related to that program (not fully supporting the 64 bit environment).

Is there anything you would like me to test beyond the obvious d64 copy that it passed with flying colours?

/Pontus Berg

 Mobile: +46 735 082860

 Skype: BacchusBerg

[Spiro Trikaliotis]

Hello Pontus,

thank you for the feedback.

* On Mon, Mar 11, 2019 at 12:51:16PM +0100 Pontus Berg wrote:

> The new package installed fine and all looked good - I have transferred a
> handfull of disks and it all looks fine.

That's good, thank you.

> Had a chat with Jani who does the d2d64 and that one complains about my
> "X-cable", but I do believe this is purely related to that program (not fully
> supporting the 64 bit environment).

BTW, is the source of d2d64 available somewhere? I could not find it on
his page.

> Is there anything you would like me to test beyond the obvious d64 copy that it
> passed with flying colours?

Well, whatever you do normally. If I tell you what to test, you will
most probably test what I have already tested. It would be good if you
could test the way YOU work with OpenCBM.

[Modeler]

Working fine here on Debian 9 (Stretch) x64_64. The only thing I had to tweak was in debian/rules:

< UDEVRULESDIR=/lib/udev/rules.d/

> UDEVRULESDIR=/etc/udev/rules.d/

This is true of the master branch though.

[Spiro Trikaliotis]

Hello,

* On Mon, Mar 11, 2019 at 02:23:09PM -0700 Modeler wrote:
> Working fine here on Debian 9 (Stretch) x64_64. The only thing I had to tweak
> was in debian/rules:
>
> < UDEVRULESDIR=/lib/udev/rules.d/
> > UDEVRULESDIR=/etc/udev/rules.d/

Are you building Debian packages yourself (that is, use
dpkg-buildpackage?) If not, that line above does not have any effect on
you.

And: If you are using dpkg-buildpackage, the change above is clearly
wrong. For udev rules installed from packages, /lib/udev/rules.d/ is the
right place, not /etc/udev/rules.d. Look into the Debian package policy
document.

[Pontus Berg]

Spiro,

D2d64 is based on nibtools and that is seemingly only 32 bit. I believe the source is not available.

Jani says it works if you use 32 bit OpenCBM.dll, but that seems like the wrong approach. 

[Modeler]

Hi Spiro,

Yes I'm just running "dpkg-buildpackage -b" from the branch. Sorry you are right about the package policy, in which case I think the issue is with line 63 of debian/rules:

mkdir -p $(CURDIR)/debian/tmp/etc $(CURDIR)/debian/tmp/etc/udev/

Because of the mismatch, the dh_install phase fails as it's looking for debian/tmp/lib/udev. So maybe alter that line to:

mkdir -p $(CURDIR)/debian/tmp/lib/udev/

You don't need the "$(CURDIR)/debian/tmp/etc" as the "-p" will create the whole tree from the second argument.

Cheers,

Dan

[Spiro Trikaliotis]

Hello Dan,

* On Wed, Mar 13, 2019 at 03:26:51AM -0700 Modeler wrote:
>
> Yes I'm just running "dpkg-buildpackage -b" from the branch.

Please note that this is not supported at the moment. I started the
Debian patches, but never finished them because of lack of time.

> Sorry you are
> right about the package policy, in which case I think the issue is with line 63
> of debian/rules:
>
> mkdir -p $(CURDIR)/debian/tmp/etc $(CURDIR)/debian/tmp/etc/udev/

You are right, this should read:

> mkdir -p $(CURDIR)/debian/tmp/etc $(CURDIR)/debian/tmp/lib/udev/

That is, /etc is needed (for ld.so.conf), but the udev rules are in
/lib/udev/.

I will fix it.

Thank you for the report.

[Pete Rittwage]

nibtools can be compiled for 64-bit opencbm, but unless your operating system is 64-bit only, there is no real point to do this other than the exercise. 

Jani's version does not have source, so it can't be changed...

[Spiro Trikaliotis]

Hello Pete,

* On Wed, Mar 13, 2019 at 05:01:28PM -0400 Pete Rittwage wrote:
> nibtools can be compiled for 64-bit opencbm, but unless your operating system
> is 64-bit only, there is no real point to do this other than the exercise. 

Well, the official way to install 0.4.99.99 is to use install.cmd. That
one uses the bitness of the OS. Thus, there will be no 32 bit OpenCBM
DLL on a 64 bit machine.

Using a 32 bit DLL on a 64 bit machine is unsupported!

> Jani's version does not have source, so it can't be changed...

Well, to be honest, he violates the GPL. OpenCBM is under GPL, even the
opencbm.h file. Michael Klein wanted to prevent tools that rely on
OpenCBM, but are not open source.

There is nothing I can do about.


Please note, also, that nibtools also contains files that fall under the
GPLv2:

- cbm.c
- include/DOS/cbm.h
- include/DOS/kernel.h
- kernel.c
- md5.c

Thus, nibtools not only falls under the GPL because it links against the
OpenCBM API, it also itself falls under the GPL "directly"! Any
derivative work that does not replace these files with something else
(and does not remove the OpenCBM dependancy) has to be given by the
license requirements of the GPL. Closed-source is not allowed!

[Pontus Berg]

Pete,

My understanding from Jani was that it always referenced the 32 bit OpenCBM.DLL and that wouldn't be the one used active in my pure 64 bit scenario.

Looking at the Nibtool github (and again forgive me if this is all wrong - I don't code for a living and tend to get lost in the maze of online repos and build files):

"\WSDK\" contains a make file that references the same DLL for 32 and 64 bit. Is that right? 

OPENCBM_DLL_DIR_x86  = ..\..\opencbm-0.4.99.98\i386

OPENCBM_DLL_DIR_x64  = ..\..\opencbm-0.4.99.98\i386

In a portion of the same file for an older version of OpenCBM (commented out as it's replaced of course) there was a separation between the two.  

#OPENCBM_DLL_DIR_x86  = ..\..\opencbm-0.4.3rc2-i386

#OPENCBM_DLL_DIR_x64  = ..\..\opencbm-0.4.3rc2-amd64

In combination with the section headed "Target platform" the same DLL is picked regardless.

/Pontus Berg
 Mobile: +46 735 082860

 Skype: BacchusBerg

[Arnd Menge]

Hello Pontus,

you are right, the two references should be different and each one should point to the OpenCBM directory with the corresponding binary files.

For example:

OPENCBM_DLL_DIR_x86  = ..\..\opencbm-0.4.99.99-libusb1\i386
OPENCBM_DLL_DIR_x64  = ..\..\opencbm-0.4.99.99-libusb1\amd64

-Arnd

[wwe...@t-online.de]

Am Sonntag, 10. März 2019 21:53:25 UTC+1 schrieb Spiro Trikaliotis:

Hello,

I just uploaded a NEW Windows binary version of OpenCBM.

The difference to the previous one is that the new one ("v2") allows for
being used with firmware 7 or firmware 8. That is, you do not need to
update your firmware just to check the libusb1 support.

The firmware variants 7 and 8 only differ in a timing difference on the
(parallel) IEEE bus, fixing a problem with the 2031 drive. Otherwise,
they are identical.

 This works all on my Windows 10 Home 32bit with Zoomfloppy, a 1571 with JiffyDos, seriell connected..

Only the firmware v8 have problems with the nibtools:

-------------------------------------------------------------------

C:\Users\Werner\Downloads>nibread ytest.nib

nibread - Commodore 1541/1571 disk image nibbler
(C) Peter Rittwage and the rest of the C64 Preservation Project team
http://c64preservation.com
Revision 2014 - Built May 20 2018 18:36:27


Drive Version: 73,JIFFYDOS 6.0 1571,00,00
Drive type: 1571
Bumping...
Initializing
Sending 1571 SRQ support code...
Uploading floppy-side code ($0454 bytes, $300-$754)...done.
Starting custom drive code...Started!
Testing communication...done.
Passed initial communication test.
Testing code upload...done.
Passed code verification test.
Passed all basic port checks.


18.0: (2)
Cosmetic Disk ID: 'JD'
Format Disk ID: 'JD'


 1.0: (3) 7685 [CBM OK] (weakgcr:1)
 2.0: (3) 7685 [CBM OK] (weakgcr:1)
 3.0: (3) 7685 [CBM OK] (weakgcr:1)
 4.0: (3) 7685 [CBM OK] (weakgcr:1)
 5.0: (3) 7685 [CBM OK]
 6.0: (3) 7685 [CBM OK]
 7.0: (3) 7685 [CBM OK] (weakgcr:1)
 8.0: (3) USB error in xum1541_wait_status: LIBUSB_ERROR_PIPE
USB error in xum1541_ioctl cmd: LIBUSB_ERROR_PIPE

-------------------------------------------------------------------

-------------------------------------------------------------------

C:\Users\Werner\Downloads>nibwrite g128d1s2.nib

nibwrite - Commodore 1541/1571 disk image 'remastering' tool
(C) Peter Rittwage and the rest of the C64 Preservation Project team
http://c64preservation.com
Revision 2014 - Built Sep 27 2017 00:32:20


Loading "g128d1s2.nib"...
Successfully loaded 336128 bytes.
Parsing NIB data...
NIB file version 3
Successfully parsed NIB data for 41 tracks
Aligning tracks...
 1.0: (3:7872) [align=GAP]
 1.5: (0:0) [align=NONE]
 2.0: (3:7872) [align=GAP]
 2.5: (0:0) [align=NONE]
 3.0: (3:7873) [align=GAP]
 3.5: (0:0) [align=NONE]
 4.0: (3:7872) [align=GAP]
 4.5: (0:0) [align=NONE]
 5.0: (3:7872) [align=GAP]
 5.5: (0:0) [align=NONE]
 6.0: (3:7872) [align=GAP]
 6.5: (0:0) [align=NONE]
 7.0: (3:7872) [align=GAP]
 7.5: (0:0) [align=NONE]
 8.0: (3:7872) [align=GAP]
 8.5: (0:0) [align=NONE]
 9.0: (3:7872) [align=GAP]
 9.5: (0:0) [align=NONE]
10.0: (3:7862) [align=GAP]
10.5: (0:0) [align=NONE]
11.0: (3:7872) [align=GAP]
11.5: (0:0) [align=NONE]
12.0: (3:7872) [align=GAP]
12.5: (0:0) [align=NONE]
13.0: (3:7872) [align=GAP]
13.5: (0:0) [align=NONE]
14.0: (3:7872) [align=GAP]
14.5: (0:0) [align=NONE]
15.0: (3:7872) [align=GAP]
15.5: (0:0) [align=NONE]
16.0: (3:7872) [align=GAP]
16.5: (0:0) [align=NONE]
17.0: (3:7872) [align=GAP]
17.5: (0:0) [align=NONE]
18.0: (2:7195) [align=GAP]
18.5: (0:0) [align=NONE]
19.0: (2:7197) [align=GAP]
19.5: (0:0) [align=NONE]
20.0: (2:7197) [align=GAP]
20.5: (0:0) [align=NONE]
21.0: (2:7197) [align=GAP]
21.5: (0:0) [align=NONE]
22.0: (2:7198) [align=GAP]
22.5: (0:0) [align=NONE]
23.0: (2:7197) [align=GAP]
23.5: (0:0) [align=NONE]
24.0: (2:7198) [align=GAP]
24.5: (0:0) [align=NONE]
25.0: (1:6629) [align=GAP]
25.5: (0:0) [align=NONE]
26.0: (1:6629) [align=GAP]
26.5: (0:0) [align=NONE]
27.0: (1:6629) [align=GAP]
27.5: (0:0) [align=NONE]
28.0: (1:6629) [align=GAP]
28.5: (0:0) [align=NONE]
29.0: (1:6629) [align=GAP]
29.5: (0:0) [align=NONE]
30.0: (1:6629) [align=GAP]
30.5: (0:0) [align=NONE]
31.0: (0:6297) [align=GAP]
31.5: (0:0) [align=NONE]
32.0: (0:6298) [align=GAP]
32.5: (0:0) [align=NONE]
33.0: (0:6298) [align=GAP]
33.5: (0:0) [align=NONE]
34.0: (0:6297) [align=GAP]
34.5: (0:0) [align=NONE]
35.0: (0:6297) [align=GAP]
35.5: (0:0) [align=NONE]
36.0: (1:0) [align=NONE]
36.5: (0:0) [align=NONE]
37.0: (1:0) [align=NONE]
37.5: (0:0) [align=NONE]
38.0: (1:0) [align=NONE]
38.5: (0:0) [align=NONE]
39.0: (1:0) [align=NONE]
39.5: (0:0) [align=NONE]
40.0: (1:0) [align=NONE]
40.5: (0:0) [align=NONE]
41.0: (1:0) [align=NONE]
Using device #8
Drive Version: 73,JIFFYDOS 6.0 1571,00,00
Drive type: 1571
Bumping...
Initializing
Sending 1571 SRQ support code...
Uploading floppy-side code ($0454 bytes, $300-$754)...done.
Starting custom drive code...Started!
Testing communication...done.
Passed initial communication test.
Testing code upload...done.
Passed code verification test.
Passed all basic port checks.

Testing track capacity at each density
--------------------------------------------------
Density 0: 6244 6244 (300.29rpm) margin:0
Density 1: 6660 6660 (300.30rpm) margin:0
Density 2: 7136 7136 (300.29rpm) margin:0
Density 3: 7684 7685 (300.32rpm) margin:1
--------------------------------------------------
Drive motor speed average: 300.27 RPM.
Track capacity margin: 6

 1.0: (3:7872) WRITE [weak:1]
 2.0: (3:7872) WRITE
 3.0: (3:7873) WRITE
 4.0: (3:7872) WRITE
 5.0: (3:7872) WRITE
 6.0: (3:7872) WRITE
 7.0: (3:7872) WRITE
 8.0: (3:7872) WRITE
 9.0: (3:7872) WRITE
10.0: (3:7862) WRITE
11.0: (3:7872) WRITE
12.0: (3:7872) WRITE
13.0: (3:7872) WRITE
14.0: (3:7872) WRITE
15.0: (3:7872) WRITE
16.0: (3:7872) WRITE
17.0: (3:7872) WRITE [weak:1]
18.0: (2:7195) WRITE [weak:1]
19.0: (2:7197) WRITE
20.0: (2:7197) WRITE
21.0: (2:7197) WRITE [weak:1]USB error in xum1541_wait_status: LIBUSB_ERROR_PIPE
USB error in xum1541_ioctl cmd: LIBUSB_ERROR_PIPE
-------------------------------------------------------------------

nibtools is the newest version r649 from 03-Feb-2019

If I reinstall the firmware v07, all works without problems.

Werner

[Spiro Trikaliotis]

Hello Werner,

* On Sun, Mar 17, 2019 at 05:19:46AM -0700 wwe...@t-online.de wrote:

> Only the firmware v8 have problems with the nibtools:

[...]

> If I reinstall the firmware v07, all works without problems.

Thank you for this report! You are not the first to tell me about the
problems. Until now, I thought it would be a problem with my changes to
libusb1, but I did not consider the firmware as culprit.

[Nate Lawson]

> On Mar 17, 2019, at 1:52 PM, Spiro Trikaliotis <an-zoomfl...@spiro.trikaliotis.net> wrote:
>
> Hello Werner,
>
> * On Sun, Mar 17, 2019 at 05:19:46AM -0700 wwe...@t-online.de wrote:
>
>> Only the firmware v8 have problems with the nibtools:
> [...]
>> If I reinstall the firmware v07, all works without problems.
>
> Thank you for this report! You are not the first to tell me about the
> problems. Until now, I thought it would be a problem with my changes to
> libusb1, but I did not consider the firmware as culprit.

If v7 works but v8 does not, it’s also possible the issue is a different AVR gcc or libc version. Easiest way to tell is for Spiro to recompile v7 source with his latest toolchain and verify if it works or not.

-Nate

[wwe...@t-online.de]

>> If I reinstall the firmware v07, all works without problems.
>

> libusb1, but I did not consider the firmware as culprit.

If v7 works but v8 does not, it’s also possible the issue is a different AVR gcc or libc version.

That is a good point.

Spiro, I now have downloaded the last available v07 from your OpenCBM SourceForge site. I wonder a little, this v07 have a size of 38.036 bytes. My v07 (from http://www.root.org/~nate/c64/xum1541/ ; from  the old install zip ) have a size of 28.638 Bytes. This old v07 works. The newer (greater) one v07 have the same problems as v08 on my system....

Werner

[Spiro Trikaliotis]

Hello,

The file xum1541-ZOOMFLOPPY-v07.hex was compiled on October 8th 2014 by
me! It replaced the older one from Dec 6 2012 by Nate.

So, there was a non-working file in the repo since 4.5 years, and nobody
noticed?


In case anyone else wants to test, I uploaded all HEX files for
zoomfloppy here:

https://spiro.trikaliotis.net/Download/xum1541-ZOOMFLOPPY-testfw.zip

[wwe...@t-online.de]

So, there was a non-working file in the repo since 4.5 years, and nobody
noticed?

No ;-) .

The xum1541-ZOOMFLOPPY-v07-spiro.hex works without problems with libusb0 but not (nibtools) with libusb1

Werner

[PLOBEXRIME]

Windows 7 x64, XUM1541 with latest firmware v08, simply does not work. libusb1-v2 package from this topic is compiled to work with libusb1 but Zadig installs libusb0 driver. No device is found then by any of OpenCBM tools. The only way I can get my device back to operation is to revert back to release version opencbm-0.4.99.99 with v07 firmware.

[wwe...@t-online.de]

Hi,

Am Mittwoch, 10. April 2019 00:24:46 UTC+2 schrieb PLOBEXRIME:

to work with libusb1 but Zadig installs libusb0 driver.

 you must select and install "WinUSB (v6.1.7600.16385)" for libusb1 in Zadig.

Werner

[PLOBEXRIME]

I've also tried WinUSB with no luck. My device is XUM1541 7406 with v08 firmware (xum1541-PROMICRO_7406-v08.hex). Win 7 x64 SP1 Polish with latest updates. Steps to reproduce:
1) installed WinUSB (v6.1.7600.16385) driver with latest Zadig (2.4), the device was reinstalled and is visible in devices manager as "xum1541 floppy adapter (PROMICRO_7406)" in "Universal Serial Bus devices" category
2) "install xum1541" with administrative rights using above 0.4.99.99-libusb1-v2.zip package
3) included OpenCBM path in system PATH variable
Any OpenCBM tool i.e. "cbmctrl reset" throws:
"error: no xum1541 device found
An error occurred opening OpenCBM, aborting..."

In order to get device working again ("visible" to OpenCBM) is to:
- reinstall OpenCBM from release package (opencbm-0.4.99.99.zip)
- reflash device with v07 firmware, since 0.4.99.99 release is compiled with XUM1541_VERSION = 7 and won't work with v08
- reinstall driver with Zadig to libusb-win32 (v1.2.6.0) or tell Windows to install driver from windrv\amd64 directory

If there is a way to get more details on "no xum1541 device found" I'll be happy to provide it here.

[Spiro Trikaliotis]

Hello,

* On Tue, Apr 09, 2019 at 03:24:46PM -0700 PLOBEXRIME wrote:
> Windows 7 x64, XUM1541 with latest firmware v08, simply does not work.
> libusb1-v2 package from this topic is compiled to work with libusb1
> but Zadig installs libusb0 driver.

You have to tell Zadig to use the driver you want. That is, select the
driver from the dropdown menu.

Otherwise, nothing will work, this is to be expected.

[frank128]

On Friday, March 1, 2019 at 10:08:39 PM UTC+1, Spiro Trikaliotis wrote:

Hello,

I am asking here for people who are willing to test the version for me.
This is especially true if you have had problems with the ZF in the
past.

I volunteer as tester for Linux Mint. openCBM worked fine in the past with Win7 on my old AMD PC.  Now on my new PC with a ROG Crosshair VII Hero board /Ryzen 2700x Win7 is no option anymore.

I compiled opencbm (from https://github.com/OpenCBM/OpenCBM) and the nibtools (from https://c64preservation.com/svn/nibtools/trunk) for Linux Mint. I run into this issue - https://github.com/zyonee/opencbm/issues/1 .

 

I would like you to test it with the newer variant.

I have several Disk drives for testing (1541, 1571, 1581).

 

For Linux and Mac OS, just compile it as you have always done. You just
need to checkout the "libusb0_and_libusb1" branch from the GitHub
repository:

https://github.com/OpenCBM/OpenCBM/tree/libusb0_and_libusb1

I will do this.

 

Make sure that the libusb1 development package (libusb-1.0-0-dev on
Debian based systems) is installed

ii  libusb-1.0-0-dev:amd64                                      2:1.0.20-1                                   amd64        userspace USB programming library development files

 

before compiling it, and it should
work. If both libusb0 and libusb1 are available, the build system
prefers libusb1.

OK

Frank

 

[frank128]

My issue still exists in the "libusb0_and_libusb1" branch

$ nibread -D8 t6.nib

nibread - Commodore 1541/1571 disk image nibbler

(C) Peter Rittwage and the rest of the C64 Preservation Project team

http://c64preservation.com

Revision 2014 - Built May 31 2019 11:52:18

* Use Device 8

Drive Version: 73,CBM DOS V3.0 1571,00,00

Drive type: 1571

Bumping...

Initializing

Sending 1571 SRQ support code...

Uploading floppy-side code ($0454 bytes, $300-$754)...done.

Starting custom drive code...Started!

Testing communication...done.

Passed initial communication test.

Testing code upload...done.

Passed code verification test.

Passed all basic port checks.

USB error in xum1541_wait_status: LIBUSB_ERROR_NO_DEVICE

USB error in xum1541_ioctl cmd: LIBUSB_ERROR_NO_DEVICE

$ cbmctrl status 8

hangs after the first execution 

[frank128]

Update nibread behavior with different xum1541 FW :

with xum1541-ZOOMFLOPPY-v07-nate.hex nibread works fine.

with xum1541-ZOOMFLOPPY-v07-spiro.hex

$ nibread -D8 t6.nib

nibread - Commodore 1541/1571 disk image nibbler

(C) Peter Rittwage and the rest of the C64 Preservation Project team

http://c64preservation.com

Revision 2014 - Built May 31 2019 11:52:18

* Use Device 8

Drive Version: 73,CBM DOS V3.0 1571,00,00

Drive type: 1571

Bumping...

Initializing

Sending 1571 SRQ support code...

Uploading floppy-side code ($0454 bytes, $300-$754)...done.

Starting custom drive code...Started!

Testing communication...done.

Passed initial communication test.

Testing code upload...done.

Passed code verification test.

Passed all basic port checks.

18.0: (2) 

Cosmetic Disk ID: 'DS'

Format Disk ID: 'DS'

 1.0: (3) 7809 [CBM OK]

 2.0: (3) 7815 [CBM OK]

 3.0: (3) 7326 [E2S0]

      (3) 7808 [CBM OK]

 4.0: (3) 7816 [CBM OK]

 5.0: (3) 7807 [CBM OK]

 6.0: (3) 7809 [CBM OK] (weakgcr:1) 

 7.0: (3) 7817 [CBM OK]

 8.0: (3) 7814 [CBM OK] (weakgcr:1) 

 9.0: (3) 7815 [CBM OK] (weakgcr:1) 

10.0: (3) 7808 [CBM OK]

11.0: (3) 7821 [CBM OK]

12.0: (3) 7817 [CBM OK]

13.0: (3) 7815 [CBM OK] (weakgcr:1) 

14.0: (3) 7813 [CBM OK]

USB error in xum1541_wait_status: LIBUSB_ERROR_IO

USB error in xum1541_ioctl cmd: LIBUSB_ERROR_NO_DEVICE

15.0:

with xum1541-ZOOMFLOPPY-v08.hex

[frank128]

I bought a xu1541 and compiled in opencbm the xu1541 plugin. No issue her - I can execute multiple detect and status commands without any issues.

My conclusion: The problem is not opencbm or the libusb version. The problem lies in the ZoomFloppy firmware, which crashes with simple commands such as cbmctrl detect and cbmctrl status [drive#] The problem with nibread is probably caused by timing problems in the Zoomflopy firmware - presumably through the use of the new compiler avr-gcc 4.7.2.

The only chance to identify the root cause of the problems is debugging the xum1541 firmware - but: "To enable the debug build, uncomment the appropriate line in the Makefile. ... Debug printing via the UART is not supported on ZoomFloppy since it has to use this pin for the IEC DATA connection. Another route for debugging should be found for it." A working debugging solution is essential to get any progress here!

[PLOBEXRIME]

Hey, since I'm currently working on a device based on XUM1541 I have some conclusions for the issues I had with libusb-1.0

Zadig 2.4 in Windows 7 allows to install one of the driver:

• WinUSB (v6.1.7600.16385)
• libusb-win32 (v1.2.6.0)
• libusbK (v3.0.7.0)

libusb-win32 is compatible with libusb0, while WinUSB is supposed to be compatible with libusb1, but sadly it isn't. With libusb1 build of OpenCBM and any of the available Zadig drivers the device is not visible to libusb1. In other words, libusb_get_device_list() returns a list of devices with no XUM1541 in it. Because support for Windows 7 ends soon and I'm moving to Windows 10,  I treat it as a minor issue, however ZoomFloppy is a commercial product and some users may stick with Windows 7 for some time and find newer builds of OpenCBM problematic.

[Dan Gahlinger]

I can't get it to work on windows 7, get an error every time...

However using it in Virtualbox VM (Linux) seems to work...

I get this error repeated over and over again...

USB error in xum1541_ioctl cmd: libusb0-dll:err [submit_async] submitting request failed, win error: The device does not recognize the command.

I can post the log file it creates if needed, but would really like to know how to fix this.
Using opencbm 4.99.x

Dan.

On Friday, March 1, 2019 at 4:08:39 PM UTC-5, Spiro Trikaliotis wrote:

Hello,

I know that there are people who have problems using ZoomFloppy. The
devices seems to not react on certain commands or does not appear at
all.

One of the things that come to mind that might be the problem is the
libusb library. OpenCBM currently uses libusb0, which is really outdated
and unsupported for some years now. There had been some problems on
MacOS, for example, where OpenCBM could not find the ZF at all when
using with libusb0. With libusb-compat, which is a layer on top of the
newer libusb1 to provide backwards compatibility, it worked.

I have worked on porting OpenCBM to libusb1. The Linux variant is
working for me, Windows works too (but still needs some manual steps for
installing, I will fix this soon), and Mac OS is still untested.

I am asking here for people who are willing to test the version for me.
This is especially true if you have had problems with the ZF in the

past. I would like you to test it with the newer variant.

For Linux and Mac OS, just compile it as you have always done. You just
need to checkout the "libusb0_and_libusb1" branch from the GitHub
repository:

https://github.com/OpenCBM/OpenCBM/tree/libusb0_and_libusb1

Make sure that the libusb1 development package (libusb-1.0-0-dev on

Debian based systems) is installed before compiling it, and it should

work. If both libusb0 and libusb1 are available, the build system
prefers libusb1.

For Windows, I will work on automating the install process. Currently,
the libusb DLL has to be stored "by hand" at the right location. Just
contact me, and I will tell you how to install it. The documentation is
not finished yet.


I am interested in two things:

1. Are there any regressions with this? This applies to anyone.

2. For people who have had problems before, does the new variant fix
   the problems?

Please give me feedback, and do not forget to tell me if you are running
on Windows, Mac OS or Linux, and also tell me the version of the OS.

Thank you in advance!