21 Feb
2008
21 Feb
'08
8:03 p.m.
On Thursday 21 February 2008 22:30, Dave Dunfield wrote:
dd, rawread, rawwrite etc. will only work with diskettes which have a
format that the linux driver understands - There are *MANY* variations on
the soft- sector disk format, and programs like ImageDisk and TeleDisk will
analyze the disk to determine how it's formatted, read that format and
record metadata in the image file so that it can be exactly recreated. dd
and others will typically just report an error if an expected sector header
is encountered.
Hmm.
Having dealt with that sort of stuff in the distant past <g>, some of it
should have occurred to me. The "iso" mentioned in an earlier post suggests
that I might be able to mount the image, though as you point out something's
going to have to interpret the stuff that it finds. I did download some
tools for dealing with cp/m formats, supposed to work similar to mtools,
but haven't installed them yet and at the moment that stuff's on a drive
that's giving me some trouble and which isn't currently mounted. Maybe a bit
more of a look than I've given that would be worth my while, since I'd held
off on installing it thinking that a box with a 5.25" drive was probably a
good part of the plan, never thought about using it on image files...
Sector skew is something I hadn't even thought of at all, in this
context. :-) And as for the allocation interleave, I'm pretty sure that's
at least a part of what's going on. It's been a really long time (maybe 20
years?) since I did some rebuilding of a CP/M filesystem but a glance at the
allocation map in there pretty well confirms this, I remember at least that
much.
other useful tools that work well are
"rawrite" or rawcopy.
though if you must use dos to read floppies, I always prefer teledisk,
however it uses a proprietary format teledisk compresses so it makes
the images smaller, and it also has handlers for errors, etc.
if you use linux/bsd, you can simply put the disk in the drive and use
dd like: dd if=/dev/fd0 of=/home/myhome/outputfile.iso
(modify the path as needed)
Interesting stuff, I've used rawrite for my first linux installation way
back in 1999, as the system I had to install it to then didn't boot from
a CD. :-) At this point
I have some image files that were apparently created with
the ImageDisk program, and while I can use a file viewer (F3 in mc :-)
to see the innards of the file I'm not sure what the original format was,
and am running into a bit of a problem with non-contiguous files. The
images in question are for the Bigboard II, so it's possible they might
even be for an 8" format, and I sure don't have one of those hooked up
to any linux box.
Any hints on getting past this to where I can extract the files into
something I can fiddle with would be much appreciated. I'm basically
looking at assembly source, mostly, and would likely want to end up
with something on a 5.25" format. Only suggestion I've gotten so far is
to set up a dos box, which I suppose I could do, but I'd rather avoid
that if I can, space here being a little short at the moment.
The disk may have physical and/or logical interleave, which will make
sectors within a track appear to be broken up, as well as file allocation
which may also "break up" the data in a logically contiguous file and
spread it around the disk. If it has physical interleave, IMDU will show you this
in a detail track
listing. The IMDV viewer will also allow you to page through the data and
account for physical interleave (the sectors appear in logically ascending
order). Unfortunately, logical interleave is known only to the CP/M BIOS
which deals with the disk. And file allocation is known to CP/M itself.
The problem in terms of BIOS is that I don't know what BIOS was used to create
the image files in the first place -- that's a large part of what's on the
image tha tI'm trying to recover. :-) Sort of one of those chicken-and-egg
situations, I guess.
I do have a preliminary utility I wrote to extract
CP/M files from
ImageDisk CP/M images - Worked very well for me in extracting some CDOS
files, however I didn't get much interest in it so I never bothered to
expand it into a general purpose utility - it is configurable however - I
can make it available if you want to play with it. You will need to figure
out the right parameters for Bigboard disks (the tables for Chucks 22disk
might be helpful).
Sure. I think I may have a copy of 22disk around here (looking...) Yup.
Which tables are you talking about here? There's a file "CPM-TYPE.LST" in
there but it only lists 2 variations on "Bigboard", SS and DS 8", both
being 512 bytes/sector. I have no idea if this also holds true for the BBII.
--
Member of the toughest, meanest, deadliest, most unrelenting -- and
ablest -- form of life in this section of space, ?a critter that can
be killed but can't be tamed. ?--Robert A. Heinlein, "The Puppet Masters"
-
Information is more dangerous than cannon to a society ruled by lies. --James
M Dakin