28 Dec
2022
28 Dec
'22
6: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
7: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
8: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
9: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.
9: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
29 Dec
29 Dec
12:08 a.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.)
695
days inactive
696
days old
5 comments
3 participants
participants (3)
-
Chuck Guzis -
David Schmidt -
Fred Cisin