Defining Disk Image Dump Standard

From: John Wilson <wilson_at_dbit.dbit.com>
Date: Thu Jun 1 15:34:18 2000

On Thu, Jun 01, 2000 at 11:12:11AM -0700, Sellam Ismail wrote:
>Insert "Disk Side (Head)" (1 byte)

Hard or soft head number? I feel sure I ran into a format (Commodore?) where
the sector headers had the opposite head numbers to the side on which they
were actually recorded.

Also, re having a field that denotes the source machine, this seems dangerous.
What if the disk has dual directories and is supposed to work on more than one
dir structure? What if it's a generic format that works on lots of different
machines (like FAT or RT-11, these disks have become de facto interchange
standards and often exist w/o ever touching the machines for whom that's a
native format)? Also, even if there is a source architecture specifier, I'd
rather see this as a short ASCII string rather than a magic number, so that
we won't need a central authority to assign the numbers, in most cases it's
obvious what short string uniquely identifies the architecture (like with
SCSI vendor and device IDs).

In any case, this is more information than *real* floppies have! All you
(i.e. the computer) need to know in any given instance, is whether this disk
is in *your* format, and you'll find that out when you try to read it. Just
like a real floppy.

The complexity seems to be rapidly getting out of hand, and I wonder
whether this is solving problems that don't really come up that often?

Having something which treats floppies as a black box, like Teledisk, is
handy in some circumstances, but I already dislike Teledisk because it gets
you in the silly situation of being unable to reproduce the disk even on
the machine for which it is intended. In this regard, an open standard is
a big step up from Teledisk, but now that means that in order to reproduce
a floppy on its native machine, you have to grab the spec and write a big
disk copier utility for that machine, which knows how to parse text tags
(please tell me I misunderstood that part) and double-check header formats
to make sure they're really vanilla. All instead of simply writing the
contiguous binary data out in the native format.

I think a nice compromise might be to represent each floppy disk with two
files, one of which contains all the data as a straight binary image in
whatever's the most sensible order for that machine, which would be convenient
for use on the original machine (not to mention emulators), and the other one
contains all the fancy headers and sector descriptors, with pointers into the
binary image. That would make the images easy to move to/from real disks on
the original machine, they'd be easy to manipulate with file system utilities
(or something like the Linux loopback device), and you could use the same
descriptor file with an arbitrary number of binary image files so there'd
be less work involved in cooking up the image files, and they'd use a lot
less disk space. The only down side I can think of is how to make sure the
matching descriptor file and image file don't get separated from one another.

John Wilson
D Bit
Received on Thu Jun 01 2000 - 15:34:18 BST