Windows 10, zoomfloppy, opencbm, cbm-transfer work... nibtools does not

[visualmess]

I will state I had everything working back in 2012 on a Windows 7 64bit machine with nibtools and have a bunch of nib files to prove. BTW my 2 1541 drives do have the Datel Burstnibbler Parallel cable installed and they work.  

So, now that I no longer have a Win7 machine I decided to get it all back and running under Win 10 64bit.  Since opencbm was never installed on this I installed opencbm 0.4.99.99, used zadiag to install the driver, installed latest CBM-Transfer 1.0 and downloaded what I believe are newer nibtools 64bit distribution from jan 2020 and zoomfloppy is on firmware v07.

When I run CBM-Transfer it detects the drive as 1541 (XP1541) and I am able to transfer disks with the mode specifically picked as parallel in the options and those d64 transfers have all worked in vice.  

I now want to transfer some of my copy protected disks using nibread.  If I try to switch to use nibread from within CBM-Transfer it just returns this error when it tries to start backing up the disk.

So I decided to run nibread from the command line and here is what it returns.  I then just stuck in a non-copy protected disk and got the same results.  Any help would be greatly appreciated.

C:\CBMXfer>nibread testrun

nibread - Commodore 1541/1571 disk image nibbler

(C) Peter Rittwage

http://c64preservation.com

Built Jan 16 2020 19:35:02

Drive Version: 73,CBM DOS V2.6 1541,00,00

Drive type: 1541

Bumping...

Initializing

Sending 1541 parallel support code...

Uploading floppy-side code ($03a3 bytes, $300-$6a3)...done.

Starting custom drive code...Started!

Testing communication...done.

Failed port transfer test. Check cabling.

Floppy drive initialization failed

Resetting drive...

Cleaning up...

[PLOBEXRIME]

Here is my output of nibtools (I've built 29-05-2020 both OpenCBM and nibtools from trunk). d64copy (parallel) and nibwrite works fine but nibread always fails. Drive passes extended parallel communication test. Cable is very short and almost zero resistance.

[rittwage]

Unfortunately, no idea what that means. It is not something nibread can output as an error, so it must be something further up the chain in OpenCBM/ZF.

-Pete

[rittwage]

Also, VirtualBox?  Not sure on that one... It introduces another layer on top of the USB libraries that could cause problems. 

It doesn't work on the host?

-Pete

On Tuesday, June 2, 2020 at 5:29:22 PM UTC-4, PLOBEXRIME wrote:

[Dan Gahlinger]

VirtualBox requires USB is set up properly,
make sure go into settings for the VM, USB, and select:

USB 2.0 (OHCI + EHCI) Controller
Check or Click on the Add new USB filter (green PLUS on the right)
and make sure the Zoomfloppy is added with a checkmark

Typically says something like "Nate Lawson and OpenCBM team xum1541 floppy adapter (ZOOMFLOPPY) (0207)"
Or whatever equivalent for your system.

Also, if you're on Windows 10, why aren't you using Hyper-V?
And alternatively VMWare > VirtualBox, but still Hyper-V would be closer to bare metal.

I'm out of testing for a while, but I'll get back to it as soon as I can. :(

Dan.

--
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/4a8b1574-b8b4-49ca-90c2-e0976f9c613d%40googlegroups.com.

[visualmess]

Not sure why someone hijacked my POST with their output unless I am not following the google groups chain of replies correctly.  My original POST has the nibread error in it from the command line respose of trying it and I am not using a virtual machine.  Please read the original post and I hope you have something for me to try!!

[rittwage]

Your issue is that it isn't detecting the parallel connection to the drive at all.

Show the output of 'd64copy 8 test.d64 -t parallel'

-Pete

[visualmess]

It worked fine... I figured when I was choosing parallel as the cable in CBM-Transfer and it worked in the GUI that this would work also since I believe CBM-Transfer uses d64copy under the covers.

C:\CBMXfer>d64copy 8 test.d64 -t parallel

 1: *********************

 2: *********************

 3: *********************

 4: *********************

 5: *********************

 6: *********************

 7: *********************

 8: *********************

 9: *********************

10: *********************

11: *********************

12: *********************

13: *********************

14: *********************

15: *********************

16: *********************

17: *********************

18: *******************

19: *******************

20: *******************

21: *******************

22: *******************

23: *******************

24: *******************

25: ******************

26: ******************

27: ******************

28: ******************

29: ******************

30: ******************

31: *****************

32: *****************

33: *****************

34: *****************

35: *****************       100%   683/683

683 blocks copied.

[visualmess]

I ran nibread testrun command right after the d64copy one worked on the same disk which is not copy protected and here is the error it returned

C:\CBMXfer>nibread testrun

nibread - Commodore 1541/1571 disk image nibbler

(C) Peter Rittwage

http://c64preservation.com

Built Jan 16 2020 19:35:02

Drive Version: 73,CBM DOS V2.6 1541,00,00

Drive type: 1541

Bumping...

Initializing

Sending 1541 parallel support code...

Uploading floppy-side code ($03a3 bytes, $300-$6a3)...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: 'BM'

Format Disk ID: 'BM'

 1.0: (3) 7752 [CBM OK] (weakgcr:4)

 2.0: (3) 7749 [CBM OK] (weakgcr:6)

 3.0: (3) 7752 [CBM OK] (weakgcr:5)

 4.0: (3) 7751 [CBM OK] (weakgcr:3)

 5.0: (3) 7754 [CBM OK] (weakgcr:2)

 6.0: (3) 7755 [CBM OK] (weakgcr:2)

 7.0: (3) 7756 [CBM OK] (weakgcr:2)

 8.0: (3 KILLER NOSYNC!) [Killer Track]

 9.0: (3) 7757 [NDOS]

      (3) 7757 [NDOS]

10.0: (3) USB error in read data(00000000000C5970, 8192): libusb0-dll:err [_usb_reap_async] reaping request failed, win error: A device attached to the system is not functioning.

0 [Unformatted Track]

11.0: USB error in xum1541_ioctl cmd: libusb0-dll:err [submit_async] submitting request failed, win error: A device which does not exist was specified.

USB error in xum1541_ioctl cmd: libusb0-dll:err [submit_async] submitting request failed, win error: A device which does not exist was specified.

[rittwage]

It looks better than the original post, but that is most likely some kind of interference or timeout on the USB bus causing issues. 

It pushes the connection a lot harder than the d64copy does since it expects large amounts of data rapidly. It is transferring whole tracks, not just sectors.

You can try:

1) moving the ZoomFloppy to another USB port, and make sure it's not on USB 3 port or hub.

2) making sure other USB devices are not in use. 

3) moving the cables around to avoid possible interference

4) sheilding the ZoomFloppy device and wiring

5) trying another PC - sometimes some USB implementations/drivers may not be perfect. 

It's something like that... Hope you figure it out!

-Pete

[rittwage]

Also, make sure you are using the newest tested versions of the driver and OpenCBM.

There were "bad" versions of the v07 and v08 ZoomFloppy firmware out there.

See thread here: 

https://groups.google.com/forum/#!topic/zoomfloppy-users/_a68d940z6I

-Pete

[visualmess]

I am using the 2011 v07 firmware that I had when I had set this up on Win 7 64bit in 2012 so thinking probably not bad firmware but will try your suggestions and let you know.  THX for the quick responses

[visualmess]

So I switched the Zoomfloppy between 5 different USB ports on my main computer with 3 being USB 3 and 2 being USB 2 with the same results that d64copy works in parallel mode but nibread fails consistently with the final error being.

USB error in xum1541_ioctl cmd: libusb0-dll:err [submit_async] submitting request failed, win error: A device which does not exist was specified.

I then setup an older laptop I have that is running win 10 64bit and has 3 USB 2 ports on it (believe the laptop is 10 years old) and it was plugged in not running on battery.  I got the same results with it, d64copy parallel mode works but nibread fails.  Everytime I run nibread it will fail at a different point during the read but normally never makes it past the first 1 to 5 tracks before failing.

I have tried 3 different USB cables that I know work since I use them with my Logitech Harmony Remotes and Garmin GPS.  I wonder if the Zoomfloppy is starting to fail based on what you said that nibread pushes the connection more than d64copy? 

On Tuesday, June 2, 2020 at 8:51:08 PM UTC-4, rittwage wrote:

[rittwage]

It's not likely to fail in that way. 

The only other thing I can tell you is to check that you are not using the "bad" v07 firmware. Grab the latest v08 and use that. If it won't let you upgrade firmware, you have another problem that maybe Nate could help with.

Barring that, it may just be something with the parallel wiring. Some people have trouble with it for some reason. Some say shorter cables work, some say longer cables. I've never had the issue so I have no way to troubleshoot that.

-Pete

[visualmess]

I will try the v08 today.  Both 1541 drives I have tested have the original Datel Burstnibbler parallel cable, it is not a homemade one and both drives work when plugged into a C64 userport and use the Burstnibbler 1.9 software.

I do have a 1571 with a hand made parallel cable I bought many years ago.  I will give that drive a try and see its results before upgrading the firmware.  My reasoning is this is the original v07 firmware from 2011 and I have never updated it since I had it all working under Win7 back in 2012.

[visualmess]

Well, I dug out the 1571 and 3 containers later finally found the parallel cable.  Hooked it up ran d64copy in parallel mode and it worked then ran nibread and it worked!!!  So I backed up an original Lords of Conquest that I believe nibread reported fat tracks between 32/33 and then I converted the nbz to g64.  Transfered the g64 image to my Ultimate II+ and tested it and all worked great.

THX so much for all your help

[rittwage]

FYI, on a 1571 SRQ is always used by default, so unless you override it, it doesn't even use parallel.

-Pete

[visualmess]

I did a nibread -t to test the parallel connection from the 1571 and it passed.  How do I override the SRQ?  I see there is a -s parameter but it looks like that is to use SRQ so was assuming if you don't supply the -s it doesn't use SRQ am I not understanding the parm?  I just want to try it as a test.

[rittwage]

At some point years ago I made the default to be SRQ where before you had to use -s. Use "-P" to force parallel on a 1571.