Defining Disk Image Dump Standard

On Thu, Jun 01, 2000 at 11:12:11AM -0700, Sellam Ismail wrote: 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