DiskMaster64 hangs on windows

[jperrin72]

Hi wagiminator,

first of all kudos for this great kit of utililities :)

I have build the adapter, installed it and used it on Linux without any problem. However when I tried it on windows with 2 differents PC, I always get the same behaviour with disk-dir.py :

• the disk drive start reading
• then the python hangs, with both green red and green leds on. Some time I get a "ERROR: Failed to read directory".
• trying to kill and restart the python scripts doesn't work, unless I unplug everything (is the adapter hanging?)

A few thinks worse mentionning:

• one of the PC is a dual boot (Windows/Linux) so I don't believe it could be a hardware/power issue, it only works with linux partition.
• I am running latest github version and firmware 1.1, python 3.12.5 and pyserial 3.5.
• the diskmaster-gui script can read the directory but fails reading/writing disks with the same behaviour (freeze)

I don't know if you have much time to support this but If you could instruct me how to troubleshoot it that would be awesome :)

[wagiminator]

Thank you for this information. Off the top of my head, I have no idea where the error could be. Since I don't have a Windows system myself, I can't check it directly. I had tested it on Windows back then, and it worked. I will certainly look into it, but due to the circumstances just described, it will take some time.

[wagiminator]

Did you install a CDC driver (using Zadig) or did it work out-of-the box?

[jperrin72]

I had to use zadig on the first windows PC, on the other PC it worked out of the box surprisingly. I'm wondering if this could be limitation of python on windows, or pyserial. Knowing the version you tested could allow me to reproduce..

[wagiminator]

I unfortunately don’t remember which test system I used back then. I think it might have even been Windows 7. Theoretically, it could also be the CDC driver; maybe there are some latencies that need to be taken into account. It’s strange that reading the directory works with the GUI version but not with the CLI version. In theory, the same functions are used in the end.

[jperrin72]

I think I can recall the timeouts where different in the code between GUI and CLI version while fetching the BAM blocks...

…

Le 7 sept. 2024 à 17:31, Stefan Wagner ***@***.***> a écrit : I unfortunately don’t remember which test system I used back then. I think it might have even been Windows 7. Theoretically, it could also be the CDC driver; maybe there are some latencies that need to be taken into account. It’s strange that reading the directory works with the GUI version but not with the CLI version. In theory, the same functions are used in the end. — Reply to this email directly, view it on GitHub <#20 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AKFZPLUACEYPN5KOSMEVOWTZVML3TAVCNFSM6AAAAABNNYDOHCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGMZVGUZDMMRYG4>. You are receiving this because you authored the thread.

[wagiminator]

I was able to do a quick test: Windows 10 Pro Version 22H2, Python 3.11.9, pyserial 3.5. The GUI version worked flawlessly, only the progress bar sometimes wasn’t displayed. But that’s an easy fix, which I’ll add soon. The CLI version of disk-dir.py didn’t work for me either. I briefly looked over the code again, and a slightly different method is actually used here. I can’t fix that quickly, I’ll have to dive deeper into it at some point.

[jperrin72]

I had the same behaviour with Windows GUI, directory listing worked but reading a disk failed. Did you experience this as well ?

[jperrin72]

I found an issue on pyserial github that could be related to the problem:

pyserial/pyserial#394

It looks like whenever serial read/write timeout value is changed on the adapter, windows reconfigure the port, which cause issues on Windows only.

this issue has been reported on another project here:
Opentrons/opentrons@981a2c1

"pyserial win32 implementation does a full port
reconfigure when you change a timeout. On specifically FTDI devices, as
with test engineering running an OT-2 test fixture by connecting the
motor controller to a laptop with an FTDI cable and running this
software on the laptop, a port reconfigure during an ongoing serial
transaction - which the host of course doesn't really control - can and
sometimes will corrupt data.
The solution to this is to move timeout setting back to a transaction
timeframe, so that there are overall fewer timeout changes and thus
fewer port reconfigures and thus the problem doesn't occur."

[wagiminator]

Aha, that’s a good starting point.

[jperrin72]

The problem seems clearly to be related to pyserial implementation on Windows - a workaround could be to rework the code to avoid changing timeouts in the middle of a transaction, I did try a few changes without much success. I think I'll stick to Linux for now.

[wagiminator]

I tried it completely without timeout changes, but disk-dir.py and disk-load.py still don’t work. The problem only seems to occur when the fastload firmware is used in the 1541 (but not with the fastread firmware). However, it can’t be the firmware itself, since it works under Linux. So it must be one of the routines in the Python scripts that communicates with the firmware via the DiskMaster.

[jperrin72]

thanks for your looking into this - I was thinking at some point using a logic signal analyzer to compare the same test between windows and Linux. I'll try when I have some time...

[jperrin72]

I have done some tests using my logic analyzer. I took a random image (krestage3.d64) and issued the disk-dir.py command on both linux and win10 platforms.

You'll find a zip file with 3 extract file per platform: csv, txt and kvdat.

KVDAT is proprietary to Kingst software, you can download KingstVIS from their website it and use it offline to drill down into the data.

dir-command.zip

[jperrin72]

You'll see below that the main visual difference is a pause after the first block on Win10

Linux

Win10

[wagiminator]

Interessing, thank you very much. The pause under Win10 should not be a problem in this case, as it is between two completed blocks, but it clearly shows that there are latencies here that might even occur during the transmission of a block.