Problem reading DD 3.5" disks, only one hole (write protection) Amiga/mac

Hi, first of all great work!! I was almost buying one of the standard USB floppy drives, but came across you project that is way much more powerful and universal! I am able to properly read ibm 1440 HD 3.5" disks with no errors at all, so I suppose the hardware and the PC sw are working properly. The drive I am using is a quite good quality Sony original. If it matters the OS is Debian buster.

I have problems in reading some disks. The first comes from a magazine, and is labeled "L'Agorà software". I started by reading it as ibm: it completes properly ("good" sound, no reties, no error reported), but at the end I get:

Autodetecting output geometry
H.SS Tracks --->
No sectors in output; skipping analysis
writing 0 tracks, 0 heads, 0 sectors, 0 bytes per sector, 0 kB total

The I tried fluxengine read amiga --write-flux try1.flux and I end up with:

H.SS Tracks --->
0. 0 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 1 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 2 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 3 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 4 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 5 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 6 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 7 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 8 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0. 9 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.10 XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
1. 0 ................................................................................
1. 1 ................................................................................
1. 2 ................................................................................
1. 3 ................................................................................
1. 4 ................................................................................
1. 5 ................................................................................
1. 6 ................................................................................
1. 7 ................................................................................
1. 8 ................................................................................
1. 9 ................................................................................
1.10 ................................................................................
Good sectors: 880/1760 (50%)
Missing sectors: 880/1760 (50%)
Bad sectors: 0/1760 (0%)
writing 80 tracks, 2 heads, 11 sectors, 512 bytes per sector, 880 kB total

From the resulting .adf I can't extract files with unadf and I can't open it in Workbench (inside fs-uae). So I tried looking inside text and I found among other readable text "AmigaUser Disk è una raccolta su dischetti dimostrativa..." so it's definitely an Amiga disk.

What I find also strange is that (if I understand correctly) it's single sided, and furthermore on side 1, not 0!

I tried on another personal disk where I saved some "programs" (too much time..really don't remember, but the label was definitely written by me). The result was the same, so I used fluxengine amiga --write-flux try2.flux -s ":s=1" that gets the exact same result, but in much shorter time.

I am wondering if for some reason the reading of side 0 has problems from a logical point of view... Is there anything else I can try? Do you want some .flux files to inspect? (in this case please tell me where/how to send them and how I should create them)

On the other side I have disks labeled as Mc Paint 400k (private copy) and MacProject-Multiplan (original). By reading with fluxengine read mac --write-flux McPaint400k.flux I get:

Autodetecting output geometry
H.SS Tracks --->
0. 0 ???XB?B?X???XBX?BBBBBBXB??B?BB?B................BBBBBBBBBBBBBBXB................
0. 1 X.?X?XXXBBB??XX?BBB?BBBBBBBB?X?B................BXBBBBBBBBBBBBBB................
0. 2 X?X?BBB?BBX????BBBBBBBB?B?BB??BB................BBBBBBBBBBBBBBBB................
0. 3 ?X?XBB?B??XBB????BB?BBBB?BBBBB?B................BBBBBBBBBBBBXBBB................
0. 4 ?B????BB?X?B??BBBBBBBBXBBBBBBBBX................BBBBBBBBBBBBBBBB................
0. 5 ????X?B?BXB??XX?BBXBB?BBBBBBB?BB................BBBBBBBBBBBBBBBB................
0. 6 XB?B?X?BBBB?BBB?B?BBBB?BBBBBB??B................BBBBBBBBXBBBBBBB................
0. 7 ?BBB??X?XXXX?X??BBBB?BXBB?BXBB?B................BBBBBXBBBBBB.XBB................
0. 8 XB?B?????BXBB?B?BBXBBBXBBBBB?BBB................BBBBBXBBBBBBBBBBXXXXXXXXXXXXXXXX
0. 9 BX??BX?X?X???B??BBBX?BBBBBBBX??B................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.10 .???XB??BXX???XBBBBBBBBXBBXBBX??XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.11 B?X??B?XXXXXXBXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Good sectors: 409/960 (42%)
Missing sectors: 230/960 (23%)
Bad sectors: 321/960 (33%)
writing 80 tracks, 1 heads, 12 sectors, 524 bytes per sector, 491 kB total

fluxengine read ibm --write-flux McPaint400k_ibm.flux:

Autodetecting output geometry
H.SS Tracks --->
No sectors in output; skipping analysis
writing 0 tracks, 0 heads, 0 sectors, 0 bytes per sector, 0 kB total

So badly damaged disk or some parameter is not right? (opening the image does not reveal a single meaningful human word).

The second disk: fluxengine read mac --write-flux MacProjectMultiplan.flux

Autodetecting output geometry
H.SS Tracks --->
0. 0 XXXXXXBXXX???XXX???B????B???B?B?................BBBBBBBBBBBBBXBB................
0. 1 XXXXX?BXX?XXXXB???B?????B???B?B?................BBBBBBXBBBBBBBBB................
0. 2 ?XBXXX?BXXXXXXB?B??BBBBBBB?BX???................BBBBBBBBBBBBBBBB................
0. 3 ?X?XXXX?XXXXXX?X??X???B???B?XB?X................BBBBBBBBBBBBBBBB................
0. 4 ?XX?XX?X?XXXXX??BBX??B?B??BBX???................BBBBBBBBBBBBBBBB................
0. 5 XXXB???X??XX?XX?BBBB????????X??B................BBBBBBBBBBBBXBBB................
0. 6 ??B?BXX?XX?XXXXXB?B??B???B?BX?BB................XBBBBBBBBBXBXBBB................
0. 7 XXX?X?BXXXXXXX?X?BBXBBB??????XBB................BBBBBBBBXBBBBBBB................
0. 8 XXXXXXXX?XXXXX?X?BBB??????B?B?BB................BBBBBBXBBBBBBBXBXXXXXXXXXXXXXXXX
0. 9 ?BBX?X?X?XXXXX???B???B???BBB??B?................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.10 X?XB?X??XX?BXXXX????BB?????BBBB?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.11 B?XXBX??X?XXXXX?XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Good sectors: 442/960 (46%)
Missing sectors: 303/960 (31%)
Bad sectors: 215/960 (22%)
writing 80 tracks, 1 heads, 12 sectors, 524 bytes per sector, 491 kB total

In this I can find some text inside the image "Picture is too large to display here.BSorry, this disk is full"

Suggestions?

I can look around in my house and find further disks, but before proceeding I'd like to wait for your advice.

Update: I found a 720 DD ibm floppy and I was able to read properly, so the problem is not with 720 DD format, but with non-ibm formats.

Hi there!

Your trouble with the Mac disks looks a lot like the problem I was having. I made a change to the Verilog code for the sampler, and had a radical improvement in behavior. You can try my modified firmware and see if it helps.

As for the "L'Agorà software", I'm a little unclear of the situation. Is it a commercially-manufactured disk? Does the disk have the HD hole in it? If it reads as an Amiga disk, it's most likely written at double-density (DD). But if the disk itself has the second hole, the media itself is high density (HD). And I've learned recently that double-density formatting on an HD disk usually doesn't read well on an HD drive unless you cover the HD hole.

Re Amiga disks: that's really weird. It may be that they're some exotic chimera format where side 1 is Amiga and side 0 is something else --- I've seen a IBM PC/Amiga/Atari ST chimera format before, although it didn't work like that --- but the most likely candidate is IBM, and you've tried that. The other most likely explanation is a drive fault, but you've tried that too and rules it out. I suppose it's possible that one side of the disks have gone bad, but two disks producing completely clean reads on the other side? That's seems very implausible.

If it's a magazine disk, there should be nothing confidential in it --- can you upload the flux file somewhere for me to have a look?

Re the Mac disk: yes, the sampler's bad. I'm currently looking at Jared's fixed sampler so you might want to give that a try. There should be a proper fix out shortly. Sorry about that.

I recorded the flux of "L'Agorà software" with the command: fluxengine read amiga --write-flux LAgora.flux -o LAgora.adf and uploaded to: https://luca.dreamhosters.com/fluxengine/LAgora.flux To clarify, and answer the questions of jboone, here is how the disk looks like: https://luca.dreamhosters.com/fluxengine/LAgora.jpg

In the meantime I found other amiga disks at home and I was able to correctly extract adf images from one of the 11 disks of Atlantis and also from the save-game disk. At the end they were properly readable with unadf.

The puzzle remains with the disk called "Programmi" that still (tried again now, just to be sure) gives the same result of good data only on side 1, same as "L'Agorà software", so maybe if we fiund something to fix the first also on the second will be fixed.

I updated the firmware with FluxEngine-sampler_hax.hex and tried again on the same MacProjectMultiplan with the following result:

H.SS Tracks --->
0. 0 B...............................................................................
0. 1 ................................................................................
0. 2 ................................................................................
0. 3 ................................................................................
0. 4 ................................................................................
0. 5 ................................................................................
0. 6 ................................................................................
0. 7 ................................................................................
0. 8 ................................................................XXXXXXXXXXXXXXXX
0. 9 ................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.10 ................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.11 ................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX

On another mac floppy I get:

H.SS Tracks --->
0. 0 ................................................................................
0. 1 ................................................................................
0. 2 ................................................................................
0. 3 ................................................................................
0. 4 ................................................................................
0. 5 ................................................................................
0. 6 ................................................................................
0. 7 ................................................................................
0. 8 ................................................................XXXXXXXXXXXXXXXX
0. 9 ................................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.10 ................................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
0.11 ................XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
Good sectors: 800/960 (83%)
Missing sectors: 160/960 (16%)
Bad sectors: 0/960 (0%)
writing 80 tracks, 1 heads, 12 sectors, 524 bytes per sector, 491 kB total

While reading I got a lot of

  3.1: 399 ms in 103424 bytes
       0 records, 0 sectors; 
       Required sector 0 missing; 
       Required sector 1 missing; 
       Required sector 2 missing; 
       Required sector 3 missing; 
       Required sector 4 missing; 
       Required sector 5 missing; 
       Required sector 6 missing; 
       Required sector 7 missing; 
       Required sector

But I end up with a 490K .img file. Now it's time for me to find a way to read it. With standard mount -t hfs no luck, hmount complains "volume is smaller than 800K (Invalid argument)". I'll keep investigating on this...

Another (silly, forgive me) question: do I really need windows to upload the firmware or is there some way to do it with linux? At the beginning I was thinking to upload the firmware once and then forget (so I used a friend's PC, since my home is linux-only since years :) ). I was supposing that further development would come from the PC sw, but now I'm realizing that maybe it's necessary to change also the firmware.

Belatedly --- sorry about the delay --- hurray that it works! The sampler change has been merged to trunk, so that should now be available in the latest release.

I think your second disk is a single-sided 400kB disk. These are exactly the same as 800kB disks except side 1 is unused. You're lucky that yours is blank, things can get very confused if a disk is formatted 800kB and then 400kB, as side 1 still contains the data from the old disk... To use an image in an emulator, you'll have to convert it to (probably) DiskCopy format. Writing this directly is on my list of things to do (#85). You might be able to tell FluxEngine to write a .ldbs file and then use libdsk to convert this into something your emulator can handle but I haven't found a way to do that yet.

Sadly, yes, Windows is required. Cypress haven't produced a firmware uploader for Linux.

Belatedly --- sorry about the delay --- hurray that it works! The sampler change has been merged to trunk, so that should now be available in the latest release.

Good, I just set up a Virtuabox WinXp to reprogram without going to friends PCs, and updated now the firmware to the last github version.

I think your second disk is a single-sided 400kB disk. These are exactly the same as 800kB disks except side 1 is unused. You're lucky that yours is blank, things can get very confused if a disk is formatted 800kB and then 400kB, as side 1 still contains the data from the old disk... To use an image in an emulator, you'll have to convert it to (probably) DiskCopy format. Writing this directly is on my list of things to do (#85). You might be able to tell FluxEngine to write a .ldbs file and then use libdsk to convert this into something your emulator can handle but I haven't found a way to do that yet.

Ok, I'll have a look to it and if I'll find something useful (unlikely) I'll write again here. Glad to hear that it's on your todo list :)

Sadly, yes, Windows is required. Cypress haven't produced a firmware uploader for Linux.

Thanks for clarifying explicitly so that I decided what to do (see Virtualbox etc..above)

Concerning the "L'Agorà software" and the flux file that I provided, are there any news/ideas? As said I am not so eager to read specifically that disk, in that case it's just curiosity, but I am very curious to be able to read the other floppy that is behaving similarly, called "Programmi", that maybe contains something personal, from my childhood ;)

(just to be sure I retried with updated firmware and client and I got the exact result)

davidgiven / fluxengine

Problem reading DD 3.5" disks, only one hole (write protection) Amiga/mac #165