I've corrected a problem with the assumption that all imd2raw.c descendants
to date have made: sectors that have a skew (i.e. not 1-1 interleaved)
weren't linearized correctly. The skewed sectors need to be written out in
"sorted" order, which is not necessarily captured/physical order. This is
easily verified by comparing output from "IMDU /b" to earlier imd2raw
outputs on any .IMD that has a sector skew that isn't 1, 2, 3 [...].
It's up on github here:
https://github.com/RetroFloppy/imd2raw
On Wed, 28 Dec 2022, Chuck Guzis via cctalk wrote:
David, may we assume that the original IMDU does things correctly?
Ah, but what is "correctly"?
It is one thing if you are going to use it to recreate a physical disk;
quite another if you intend to use the image in an emulator.
Machine A has sectors on the disk numbered 1,2,3,4,5,
but the file content is in sectors 1,4,2,5,3
Machine B has sectors ordered on the disk as 1,4,2,5,3,
but the file content is in sectors 1,2,3,4,5
... and many others
ALL of those are equally valid ways to get around disk I/O that can't
handle 1:1
One machine uses track 0A,1A,2A...39A,0B,1B,2B...
next machine uses tracks 0A,0B,1A,1B...
Another machine uses track 0A,1A,2A...39A,39B,38B,37B...
. . . and severaal others
and many others.
"Sorted" order might or might not be captured physical order, unless you
happen to know what that machine did.
--
Grumpy Ol' Fred ci...@xenosoft.com
