Getting two ZoomFloppies to Work on the Same Windows 10 Box

You have probably made poor decisions in life when you come to the conclusion that you need so many Commodore drives hooked up to your PC that you need more than one ZoomFloppy, but here I am to tell my story. I have used the ZoomFloppy with a Parallel Port modded 1541 for a while now, but I got it in my head that I also wanted a 1581 hooked up. Since (I am paraphrasing here) you can’t use the faster transfer methods (parallel) with a second drive hooked up I decided that in order to not be plugging and unplugging crap all the time I would need a second ZoomFloppy. According to the documentation and posts at the ZoomFloppy Users group this setup should be possible. Once again I wouldn’t be writing this post if all had gone according to plan.

The First Attempt

I got my brand new ZoomFloppy in the mail from RETRO Innovations. I also highly recommend the very well made ZoomFloppy case from COREi64. Hooking it all up is beyond this post, if you have questions about it just let me know. Needless to say I got everything hooked up and the drivers installed. Now to try this out. So the documentation for cbmctrl says to use the -@<plugin>[:<bus>] to address different devices. As I mentioned before the new ZoomFloppy has a 1581 hooked up to it. Here goes nothing.

Any one else seeing the problem? Needless to say I went up to about 20 before I figured out something was up. I spent some time trying to figure out if I was missing something about what “bus” meant, but I mostly spent a day getting nowhere. I have an irrational fear of internet forums, but it looked like I was going to have to ask the pros. The entire thread is here, but I am going to give the highlights below.

My initial query.

So windows 10 box with 2 zoomfloppies installed. How the heck do I access the
drive on the second ZF? I have played with the @ parameter, but have no idea
what to set the bus value to. Any help would be appreciated. Thanks!

Spiro, the dev for opencbm, came back and asked me some questions and had me send him some debug output. After a day or two he came back with this response.

Hello Christopher,
after seeing your answers, I was a little bit surprised, so I had to dig
in further. It was more complicated than I thought, but I have figured
it out:
Well, after looking at the sources, using multiple ZoomFloppy devices
works - BUT, there is a big gotcha!
You have to have both ZF devices equipped with different serial numbers!
Unfortunately, currently, there is no "official" way to generate serial
numbers.
There is a command-line option to xum1541cfg to set a serial, but it is
currently commented out. The only way this can be done at the moment is
to modify the sources of the ZF firmware: file xum1541/descriptor.c,
lines 117-121:
// Serial for attaching more than one xum1541.
static USB_Descriptor_String_t SerialNumString = {
Header: { Size: USB_STRING_LEN(3), Type: DTYPE_String },
UnicodeString: L"000", // <-- THIS "000" has to be modified
};
For example, you could modify the "000" to "001" for one ZF, and to
"002" for the other one.
Then, you have to recompile the firmware.
Afterwards, you could access the ZF with serial "001" wth -@xum1541:1,
and the ZF with serial "002" with -@xum1541:2.
I think the most important change to make this work is to implement the
set-serial command to xum1541cfg, which also requires some changes to
the firmware. However, as I am not able to compile the firmware at the
moment, I cannot do this on my own.

Well it looks like I am going to modify some firmware code to get this working.

Building the Firmware

I have more than one Linux box sitting around, so getting the source to build wasn’t too hard for me, but if you just want the fruits of my labors here are the links to two sets of firmware, one with a serial number of 1 and one with a serial number of 2.

Step 1 is downloading the source from here and unzip it somewhere handy. Step 2 is installing the necessary compiler and its necessary components. I was using a Debian box so all I had to run was “apt-get install gcc-avr binutils-avr avr-libc”. Step 3 is actually changing the serial number in the code. I changed line 120 in xum1541/descriptor.c to “UnicodeString: L”001″”. Back to the command line and I just ran “make”. Alright, it worked on the first try and now I have xum1541-ZOOMFLOPPY-v07.hex in the xum1541 directory. I renamed this one to xum1541-ZOOMFLOPPY-S1-v07.hex then I repeated this all, but for a serial number of 002. I named that file xum1541-ZOOMFLOPPY-S2-v07.hex. These are two files I have provided above. Now that I have these firmware images I copied them into the opencbm directory on my Windows 10 box.

Updating the Firmware

First thing to remember is that the firmware updating tool (xum1541cfg.exe) is not multi ZoomFloppy aware. It simply addresses the first one it finds, so for the process of updating the firmware make sure to only have the ZoomFloppy you want to update plugged in. So lets update the one with the 1541 hooked up to serial number 1.

C:\Program Files\opencbm>xum1541cfg.exe -f update xum1541-ZOOMFLOPPY-S1-v07.hex
Success. xum1541 now in bootloader mode.
Run your firmware update program now.
USB request for XUM1541 close failed, continuing: libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is
not functioning.

Well….shit. We are so close. I found a thread on the ZoomFloppy User group here that talked about a similar problem. To save you some time the thread talks about two things. The first is that when you are updating the firmware the ZoomFloppy enters a programming mode that is registered as a completely different device to the PC and that means you have to separately install the libusb-win32 driver with Zadig for that device. So after the above error you need to run Zadig and install the driver. Once that is done will need to yank the power of the ZoomFloppy and then plug it back in to restart it. Ok lets try programming it again.

C:\Program Files\opencbm>xum1541cfg.exe -f update xum1541-ZOOMFLOPPY-S1-v07.hex
Success. xum1541 now in bootloader mode.
Run your firmware update program now.
USB request for XUM1541 close failed, continuing: libusb0-dll:err [control_msg] sending control message failed, win error: A device attached to the system is
not functioning.

Same damn problem. The other point made in the thread is that he had to go find an older xum1541cfg.exe file. The only older version I could think of finding was the one pointed to in the ZoomFloppy manual here. Copy out opencbm-ZoomFloppy-2.0-i386\exe\xum1541cfg.exe to C:\Program FIles\opencbm\xum1541cfg-OLD.exe. DO NOT OVERWRITE THE ONE THAT IS ALREADY THERE. For whatever reason, nibwrite and nibread will start crashing if you replace the 0.4.99.98 version with this older version. Ok, so lets try this one more time.

Mission Accomplished! Notice that if you omit the bus number it defaults to the first ZoomFloppy it finds. Looks like we are good to go. If you have also made poor choices and need to run two ZoomFloppies on one Windows 10 box I hope this helps and as a parting gift here is a link to my experimental CBMXfer that can address multiple ZoomFloppies.