"overlapped" sectors on Agat disks after commit f5d026d

[shattered]

After commit f5d026d, this happens:

% samdisk scan --agat a840-003.scp --scale=120 -c0 -h0                 
[a840-003.scp]
Cyl 0 Head 0:
250Kbps MFM, 21 sectors,  256 bytes/sector:
  0.0  0[o] 1[o] 2[o] 3[o] 4[o] 5[o] 6[o] 7[o] 8[o] 9[o] 10[o] 11[o] 12[o] 13[o] 14[o] 15[o] 16[o] 17[o] 18[o] 19[o] 20[o] 

I guess it's because code in Track::data_extent_bytes is designed for ISO MFM disks, can't think of a quick fix for that :)

[simonowen]

Part of the issue seems to be that Agat reading has marked the sectors as MFM (which is effectively ISO MFM), so it seems fair to use ISO MFM rules. Shouldn't they be using Encoding::Agat?

Is it possible to create working Agat disks using the PC FDC? If an original Agat system accepts them then various checks could be relaxed to treat them as normal ISO MFM, and the custom Encoding::Agat type can be removed.

That won't immediately fix the 'o' indicator, but I will change Track::data_overlap to return false for any encoding except MFM and FM, which will avoid it being displayed when it doesn't apply.

Do you have an Agat sample image you can share? It would be useful to add to my collection of disk images, which are helpful in regression testing. If you don't have a shareable sample image at that moment, could you re-run your scan with the --offsets flag to display track positions? It would be good to know how marginal the overlap test is.

[shattered]

No, PC FDC cannot read or write those disks, so I guess a new Encoding is needed after all.

Rescanned with --offsets -- https://gist.github.com/shattered/884003ae806fdaa450d8001a62140e2a

That image has personal data on it, but you can use HFE images produced by agath-dsk-to-hfe.pl for testing (script is available via http://www.torlus.com/floppy/forum/viewtopic.php?f=19&t=1385). They look a bit different:

  0.0  0[o] 1[o] 2[o] 3[o] 4[o] 5[o] 6[o] 7[o] 8[o] 9[o] 10[o] 11[o] 12[o] 13[o] 14[o] 15[o] 16[o] 17[o] 18[o] 19[o] 20 
         6250: 16 297 297 297 297 297 297 297 297 297 297 297 297 297 297 297 297 297 297 297 297 [294]

[simonowen]

I calculated that if the gap is below 306 bytes, SAMdisk considers it an overlap with normal ISO MFM. That figure includes 256 bytes of data, plus header, sync and other gaps. Your scan shows 297 bytes, so it's only just below the threshold.

I've committed a small update that limits get_extent_bytes to MFM and FM, which also affects the data_overlap check. If you change it to use Encoding::Agat it will no longer flag them as overlapping.

[shattered]

Thanks -- https://github.com/simonowen/samdisk/pull/9 sets encoding to Agat.

btw, bitrate autodetection could use RPM info from SCP header -- I'm using a 360RPM HD drive, and SCP software stores this info:

a840-003.scp: SuperCard Pro disk image, version 0x19, disk type 0x44, copies 5, tracks 0 to 159, both heads, flags 0x06: SPLICE TPI=96 RPM=360 TYPE=PQ READ-ONLY

[simonowen]

I don't trust the metadata in disk images as it relies on the user selecting the right disk type when dumping. 3rd party tools sometimes use fixed values in these type of header fields too, so it seems better to always auto-detect.

Now I've committed 7507d74398d098065e01440ad5909984d2f65f85 and merged #9, I think this issue is resolved?

[shattered]

Yes, thanks!