28 Dec
2022
28 Dec
'22
1:01 p.m.
There have been a few versions of the utility imd2raw.c floating around
that will take Dave Dunfield's ImageDisk-created images (i.e. an .IMD file)
and make a linear binary image devoid of any metadata. This is similar to
the function of Dave's IMDU.COM program's /b switch.
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
28 Dec
28 Dec
2:59 p.m.
On 12/28/22 10:01, David Schmidt via cctalk wrote:
There have been a few versions of the utility
imd2raw.c floating around
that will take Dave Dunfield's ImageDisk-created images (i.e. an .IMD file)
and make a linear binary image devoid of any metadata. This is similar to
the function of Dave's IMDU.COM program's /b switch.
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
David, may we assume that the original IMDU does things correctly?
Thanks,
Chuck
3:58 p.m.
> 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 cisin(a)xenosoft.com
4:05 p.m.
Chuck Guzis wrote:
David, may we assume that the original IMDU does
things correctly?
"Correctly" is not a word I'd necessarily use - but what is true is that the
original imd2raw.c does it *differently* than IMDU.COM. I am using IMDU as my oracle, and
have tuned imd2raw.c so that it matches what IMDU does (with respect to sector ordering).
It's the case that various tools can make their own assumptions about sector skew (or
not), and can compensate (or not) as they see fit. IMDU's contract is that you'll
get a binary image out in logical rather than physical sector order.
4:22 p.m.
On 12/28/22 13:05, David Schmidt via cctalk wrote:
It's the case that various tools can make their
own assumptions about > sector skew (or not), and can compensate (or not) as they see
fit. >
IMDU's contract is that you'll get a binary image out in logical >
rather than physical sector order.
Just to clarify, if the formatted order is 1,3,5,2,4, IMDU will return
the sectors numbered as 1,2,3,4,5, right?
Works for me for data recovery. Probably works for the original
equipment, but not optimally.
--Chuck
7:08 p.m.
Chuck Guzis wrote:
Just to clarify, if the formatted order is 1,3,5,2,4,
IMDU will return
the sectors numbered as 1,2,3,4,5, right?
A visual way to think about this is with IMDV. If you bring up a skewed image in IMDV and
move forward through the sectors with the right arrow, it increments the _logical_ sectors
by one (and you may see the _physical_ sectors flip all over the place). So it outputs
disk images in the order you'd see them coming out of the upper-right hand side of the
screen, the logical sector order. I believe that is in keeping with what you wrote above.
Works for me for data recovery. Probably works for
the original
equipment, but not optimally.
It is not at all good for original equipment. It is good for emulation and manipulation
tools. The original .IMD has all the metadata to "do the right thing" for
reconstituting a disk image for real hardware. A linear image is for when you've shed
the mortal coil.
(Sorry for the delayed responses... the website is giving "server errors" until
a few hours pass after a thread is updated. It's quite annoying. Since I normally
consume digests, the website is where I need to go to make individual responses.)
20 Jul
20 Jul
11:38 a.m.
Following up: I published an update to this tool that helps make "bad" rips more
square. ImageDisk will create an IMD file that faithfully lacks sectors that it can find
no trace of. So reading marginal media that has unreadable and unlocatable sectors will
have a track that is perhaps shorter than tracks that came before it because it's
lacking unfindable sectors. Worse than that, IMD will decide that's the new norm and
stop looking for that sector on later tracks as well (unless you have it analyze every
sector which is slow, but at least it improves fidelity in reading marginal media).
That's a different problem. For cases where you're missing a sector here or there
and the rest of the sectors are fine within tracks, this new option to fill in missing
sectors will help.
Recall that the function of IMDU and this tool (imd2raw) is to take a rich IMD image and
linearize it into a raw image. That image really needs to be square in order to have it
make any sense because there's no metadata anywhere to explain where or why a sector
might be missing. So the only reasonable thing to do in this situation is to pad out the
missing sector with zeros or xE5s so that subsequent tracks and sectors can be located
reliably with consistent offsets. The default behavior is still to be exactly like IMDU
was, but the optional –f or --fill-missing parameter will make this change for the output
image and indicate missing sectors with a '0' in the graphical display.
https://github.com/RetroFloppy/imd2raw
1:12 p.m.
thank you
b
On Mon, Jul 20, 2026 at 11:38 AM David Schmidt via cctalk <
cctalk(a)classiccmp.org> wrote:
Following up: I published an update to this tool that
helps make "bad"
rips more square. ImageDisk will create an IMD file that faithfully lacks
sectors that it can find no trace of. So reading marginal media that has
unreadable and unlocatable sectors will have a track that is perhaps
shorter than tracks that came before it because it's lacking unfindable
sectors. Worse than that, IMD will decide that's the new norm and stop
looking for that sector on later tracks as well (unless you have it analyze
every sector which is slow, but at least it improves fidelity in reading
marginal media). That's a different problem. For cases where you're
missing a sector here or there and the rest of the sectors are fine within
tracks, this new option to fill in missing sectors will help.
Recall that the function of IMDU and this tool (imd2raw) is to take a rich
IMD image and linearize it into a raw image. That image really needs to be
square in order to have it make any sense because there's no metadata
anywhere to explain where or why a sector might be missing. So the only
reasonable thing to do in this situation is to pad out the missing sector
with zeros or xE5s so that subsequent tracks and sectors can be located
reliably with consistent offsets. The default behavior is still to be
exactly like IMDU was, but the optional –f or --fill-missing parameter will
make this change for the output image and indicate missing sectors with a
'0' in the graphical display.
https://github.com/RetroFloppy/imd2raw
1
days inactive
1301
days old
7 comments
4 participants
participants (4)
-
Bill Degnan -
Chuck Guzis -
David Schmidt -
Fred Cisin