This seems to have been broken for a long while, with an alternative tool called xc3sprog being suggested to be used by Windows developers for their bitstream-uploading needs.
I've already done some initial investigation the matter, some findings in this discord thread:
It seems like the existing m65/fpgatag code already had code in it to say, "if you're running on windows, just give up and don't bother trying", so I suspect someone already dabbled in this area and gave up.
I had to uncomment such prior windows-checks in order to let libusb try do its thing
By default, libusb fails to discover the two FTDI/diligent devices (they aren't iterated over)
Reading online, libusb has known issues in windows, and there was a suggestion to install winusb drivers via the zadig tool
My first attempt of the zadig tool tried to update both "Diligent USB Device (Interface 0)" and "Diligent USB Device (Interface 1)".
This didn't seem to be the right thing to do, I lost the windows COM port to talk to the device, and I also lost other COM ports I need for my work (which was an unexpected surprise :)).
On my 2nd attempt, I only installed the WinUSB driver for the first item - "Diligent USB Device (Interface 0)"
Doing so now permits libusb to locate the device, while also allowing tools like m65/mega65_ftp/m65dbg to access the device via a windows COM port
Upon trying to do a "m65.exe -b bitstream.bit", the devkit responds to the attempt by blacking out the screen, and the two lights on the devkit continuously flash in blue, that's a good sign.
But m65.exe exits almost immediately after, that's not a good sign.
Main distinction in behaviour I see right now is in the time that elapses between the "fpgajtag: Starting to send file" and "Bitstream loaded." messages
On linux, the time taken is about 8-9 seconds
In windows, it does it in 0 seconds.
So in this card, I'll try and dig deeper into libusb to try understand what it going wrong in this attempt to write the bitstream to the device in windows.
If I'm unable to resolve the problem, perhaps I can just put a warning inside m65.exe so that it suggests using the xc3 tool for bitstream uploading instead.
This seems to have been broken for a long while, with an alternative tool called
xc3sprogbeing suggested to be used by Windows developers for their bitstream-uploading needs.I've already done some initial investigation the matter, some findings in this discord thread:
To summarise some experiences so far:
Main distinction in behaviour I see right now is in the time that elapses between the "fpgajtag: Starting to send file" and "Bitstream loaded." messages
So in this card, I'll try and dig deeper into libusb to try understand what it going wrong in this attempt to write the bitstream to the device in windows.
If I'm unable to resolve the problem, perhaps I can just put a warning inside m65.exe so that it suggests using the xc3 tool for bitstream uploading instead.