Re: DSK format specification

["Charlie" <charlied@NOSPAMbboard.com>]

"Michael Pender" <mpender@hotmail.com> wrote in message
news:8dmQa.8407$qn1.3646@nwrddc04.gnilink.net...
> 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?

Rather than creating an entirely new "DSK" format, I would suggest that you add
your features to the Universal Disk Image (2IMG) format.  It is, in my opinion,
the most flexible format.  It uses a header.  Specific information can be found
at:

http://www.a2central.com/programming/filetypes/ftne00130.html

Charlie