Explicit sector size not supported/working

[ibm5110]

I have a bunch of 5.25" floppies from a system that records 5 sectors/track with 512 bytes/sector in FM. The problem: the sector length ID byte in the header is 0 instead of 2. If I create a custom disk definition, I still can't image the floppies e.g. to IMD (although it should work). Instead, I only get "Ignoring unexpected sector" messages.

Reading c=0-40:h=0 revs=3
Format bitsy.sssd
T0.0: Ignoring unexpected sector C:0 H:0 R:1 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:3 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:4 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:0 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:2 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:1 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:3 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:4 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:0 N:0
T0.0: Ignoring unexpected sector C:0 H:0 R:2 N:0
T0.0: IBM FM (0/5 sectors) from Raw Flux (107522 flux in 604.36ms)

This is the corresponding disk definition:

disk bitsy.sssd
    cyls = 35
    heads = 1
    tracks * ibm.fm
      secs = 5
      bps = 512
      iam = no
      interleave = 2
      id = 0
      rpm = 300
    end
end

If I use the normal ibm.scan format, this is the (expected but unwanted) result:

Reading c=0-40:h=0 revs=1
Format ibm.scan
T0.0: IBM Empty from Raw Flux (35923 flux in 201.77ms)
T1.0: IBM Empty from Raw Flux (33581 flux in 201.75ms)
T2.0: IBM Empty from Raw Flux (33040 flux in 201.75ms)
T3.0: IBM Empty from Raw Flux (34428 flux in 201.76ms)
T4.0: IBM Empty from Raw Flux (34364 flux in 201.76ms)
T5.0: IBM Empty from Raw Flux (33727 flux in 201.75ms)
T6.0: IBM Empty from Raw Flux (33998 flux in 201.75ms)
[...]

Using my own raw stream decoder I can confirm that the ID and Data fields are plain standard with correct CRCs. Only the sector length byte is 0 instead of 2. I need to override this.

[keirf]

Currently it cannot be overridden as bps specifies both the expected data size and the expected N value.

And of course ibm.scan doesn't work because it works out the expected data size from the observed N value.

This can be hacked to work. I wonder how common it is?

[ibm5110]

Hm, can't say how common it is. I'd guess not very much. And I wonder how they were written or read. The system (a TA dds1) uses a WD1791 AFAIK. At least the Bitsy10 uses this FDC. Maybe the dds1 uses a discrete implementation?
So for now I have to stick to .SCP images and my own decoder.

[keirf]

Yeah that's an interesting one. It's not particularly well documented how these broadly compatible FDCs deal with edge cases like requested sector size not same as on-disk sector size. I guess in this case the requested sector size is used and the on-disk sector size field is ignored.

Anyway, this is quite interesting. I would like to support it. It's mainly a question of how to elegantly represent it in the config file.

Any chance you could share a raw SCP image? Even if it's just a few tracks (eg. --tracks=c=0-2 to get 3 cylinders).

[ibm5110]

Any chance you could share a raw SCP image? Even if it's just a few tracks (eg. --tracks=c=0-2 to get 3 cylinders).

Of course. You can examine for example disk image 03.scp.
The images are on our FTP server: ftp://computermuseum.informatik.uni-stuttgart.de/bitsy/sw/box1

[ibm5110]

And BTW the images 06..08 have a physical sector size of 488 bytes (still standard IBM headers/CRC). The ImageDisk file format can handle this. I don't know if gw supports this, yet.

[sweproj]

Just a comment i dont know if its relevant.
I had the exact same issue for som FM 80k disc for ABC80, Luxor

The thing was that i had forgotten to set the "rate = 125" in the diskdefs.cfg

Adding my def

disk abc.80.1
cyls = 40
heads = 1
tracks * ibm.fm
secs = 16
bps = 128
rate = 125
end
end