Re: DSK format specification

["Michael Pender" <mpender@hotmail.com>]

Andy McFadden <fadden@fadden.com> wrote in message
news:OU7Qa.1395$dk4.59598@typhoon.sonic.net...
>
> It's similar.  Sectors have a physical order (by default written straight
> from 0 to 15) and a logical order (skewed around).  The mapping between
> them is fixed for each filesystem, and is different for DOS,
Pascal/ProDOS,
> and CP/M.  (It happens that logical sector 0 is mapped to physical sector
> 0 in all established formats, which means that you'll see track 0 sector 0
> at the start of every disk image regardless of ordering.)

When I wrote the routine in ProBlock to copy a disk to a file, I never
proposed the file as a standard type because I thought the file format
should include header information to deal with some of these variations
first.  I knew about the variations between DOS and ProDOS, but I never even
considered CP/M or Pascal.

One thing I did have in mind to add as a feature is a block/sector list to
support sparsely populated disks.  Often many of the sectors or blocks on a
data disk will be unused and copying them into the archive file is just a
waste of space.  Also, it would be helpful to have information about the
physical media format.

For example, ProDOS would automatically recognize the 1 Meg memory area or
my Laser 128 as a slot 5 ram disk (/RAM5 ?).  Before I started any heavy
programming work with HyperC, I would copy the disk image from my 5.25" or
3.5" drive to the ram disk because the speed of ram access *far* exceeded
the speed of a 5.25" drive or 3.5" drive.

The downside is that a literal block-by-block copy from one disk to another,
e.g. the floppy to the ramdisk, would leave the target disk thinking it was
only the size of the source disk, vis the ~1024 K actually available.  This
could be fixed easily enough by copying only the populated blocks from the
5.25" disk or 3.5" disk and setting the used block map of the ram disk.

I think its time for a new DSK format that includes at least these features:
-  support for 256 byte, 512 byte, and 1024 byte blocks
-  a used-block map for supporting sparse disks
-  other information such as the date the media was formatted, original name
of the volume, etc.

The new format would be a super-set of other formats and the embedded
information would help eliminate many of the problems of dealing with
archived media from 4+ different operating systems (DOS 3.3, ProDOS, Pascal,
CP/M, etc.)  However, I haven't spent much time thinking about support for
copy-protected disks of the era.  I'm not sure there is a good way to deal
with those.

Any thoughts?  Any recommendations for other features to be added to the new
format?

- Mike