Error when reading a 2.88 floppy to hfe format

[Olivier-ADLER]

i get this error when writing an HFE file from a 2.88 DOS floppy dump.

Found 5760 sectors of 5760 (100%) Traceback (most recent call last): File "C:\Users\runneradmin\AppData\Roaming\Python\Python38\site-packages\cx_Freeze\initscripts\__startup__.py", line 139, in run File "C:\Users\runneradmin\AppData\Roaming\Python\Python38\site-packages\cx_Freeze\initscripts\console.py", line 18, in run File "gw.py", line 3, in <module> File "C:\hostedtoolcache\windows\Python\3.8.10\x86\lib\site-packages\greaseweazle\cli.py", line 69, in main File "C:\hostedtoolcache\windows\Python\3.8.10\x86\lib\site-packages\greaseweazle\tools\read.py", line 244, in main File "C:\hostedtoolcache\windows\Python\3.8.10\x86\lib\site-packages\greaseweazle\image\image.py", line 29, in __exit__ File "C:\hostedtoolcache\windows\Python\3.8.10\x86\lib\site-packages\greaseweazle\image\hfe.py", line 222, in get_image struct.error: ushort format requires 0 <= number <= 0xffff

Writing an IMG file from the same floppy works correctly. The image is readable by HxCFloppyEmulator or other floppy image tools and give the correct file content and the correct 2.88 Mo size. HcxFloppyEmulator show the correct fomart with 36 sectors by track.

This mean that the floppy is readable and does have a correct formatting.

Writing a kryoflux or SCP file does not work neither. When reading that inside HxCFloppyEmulator the format is unknown and the track analyzer show a full empty floppy.

I suppose that those file formats are not compatible with 2.88 Mo floppy.

[keirf]

Indeed HFE format cannot represent the track length of a 2.88 Mo floppy, so that format is unusable.

SCP and KF formats do work fine. For example:

gw convert --format=ibm.2880 a.img a.scp
gw convert --format=ibm.2880 a.scp b.img

And you should see a.img and b.,img are identical. I think HxCFloppyEmulator does not automatically handle the 2.88 Mo bit timings. You should raise this issue with the author,

[Olivier-ADLER]

You are right this is a Hxc problem.

I was able to do the conversion from a 2.88 IMG to SCP and got the right IMG back after the opposite conversion.

I was able to dump a 2.88 floppy to SCP too, and convert it to IMG. The IMG was fine.

But the SCP do not open correctly inside HxCFloppyEmulator. Aufit give the same problem. Here is what we get inside Aufit, HxC analyzer give the same result :

Definitely the GreaseWeazle V4 is working fine with 2.88 Floppy. I need now to check if a 4 MB formatted 2.88 floppy will be dumped correctly. For reference i was using a Mistsubishi MF356C drive.

The only way actually would be to dump such a floppy as SCP, write it back to another floppy, and check if the files are read correctly through a normal floppy controller with the 2MGUI TSR.

I'm surprised that USB 1.0 is able to manage the flux transfer of a 2.88 Mo Floppy. How did you success in doing that with the small amount of RAM in the controller ?

[keirf]

Worst case flux rate is a flux per microsecond. The flux is encoded to eight bits so that's 8Mbps which is approximately the limit of full speed USB. In practice the flux rate will average somewhat less than a flux per microsecond, which helps. I have patches to add compression to the USB link but actually even ED does seem to work pretty okay without.

[Olivier-ADLER]

Thanks for the reply. Yes it should average around 7 Mbps because if i remember correctly this is the speed i could get on my USB link. Does GW report an error if the USB link is saturated and some packets are lost during transfer ?

I did report the 2.88 HxC problem to its developer who should correct it this week in a new release. A fast fix has been done the day i did report.

[keirf]

Yes if the link is too slow and buffers overflow an error will be reported. Actually host tools will retry the operation a couple of times automatically before reporting the failure. But rest assured that data will not be silently lost.

The HxC author is very responsive to bug reports (same as me!).