Explicit sector size not supported/working about greaseweazle HOT 5 OPEN

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?

from greaseweazle.

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.

from greaseweazle.

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).

from greaseweazle.

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

from greaseweazle.

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.

from greaseweazle.