IFW wrote:Is there an "official" format that actually supports using those bytes?
Yes there is. Apple's DiskCopy 4.2 format fully supports reading and writing of the tag bytes and is very well understood. The "Basic Lisa Utility" (BLU) is the best and most commonly used utility for working with Lisa disks and uses the DiskCopy 4.2 format for floppy operations.
http://sigmasevensystems.com/BLU
This is a quote from the BLU manual describing the DiskCopy 4.2 format in detail:
----------------------------------------------------------------------------------------
Offset Size & Contents
diskName ($00) $40 Bytes; A Pascal string (length byte followed by $3F ASCII characters, padded
as necessary) containing the name of the disk. For a Lisa disk, this string is
typically “-not a Macintosh disk-”. BLU includes its version number in the
padding after the string, and “Twiggy Image” if appropriate.
dataSize ($40) Long Word (4 bytes, MSB first); The total number of bytes (not sectors) in data
fields in the image. A data field is $200 bytes per sector. For an image of an
entire disk, the dataSize is $200 times the number of sectors on the disk,
ie.: Twiggy:$000D4C00, 400k:$00064000, 800k:$000C8000
tagSize ($44) Long Word (4 bytes, MSB first); The total number of bytes of tag fields in the
image. Tags are an extra $C bytes of "scavenger" information per sector on
Twiggy, 400K and 800K Lisa and Macintosh disks. If there are no tag bytes in
the image, this field will be zero. For an image of an entire disk, the
tagSize is $C times the number of sectors on the disk,
ie. Twiggy:$00004FC8, 400k:$00002580, 800k:$00004B00
dataChecksum ($48) Long Word (4 bytes, MSB first); Checksum of all the data fields in the disk image.
tagChecksum ($4C) Long Word (4 bytes, MSB first); Checksum of all the tag fields in the disk image.
diskType ($50) One Byte; Indicates the type of disk: 400K:$00, 800K:$01, Twiggy:$54
formatByte ($51) One Byte; Indicates the format of the disk: 400K:$02, 800K:$22, Twiggy:$01
fileFormat ($52) Two Bytes; Always $0100
userData ($54) dataSize Bytes; The data fields for the disk. These are in order from sector
zero through the end of the disk. Data fields are $200 bytes each.
tagData ($54+dataSize) tagSize Bytes; The tag fields for the disk. These are in order from
sector zero through the end of the disk. Tag fields are $C bytes each.
Note that all of the tag fields follow all of the data fields in the image.
For an image of an entire disk, the offset of the first tag field is thus:
Twiggy:$000D4C54, 400k:$00064054, 800k:$000C8054
The value $1A is used as a trailing pad byte to fill the last x-modem block; this is not part of the DiskCopy image, but it does no harm to leave the padding at the end of the file.
The checksum algorithm is to add a word (two bytes, MSB first, not sign extended) to a 32 bit accumulator, then rotate the 32 bits right 1 bit. The tag bytes of sector 0 are skipped when calculating the tagChecksum.
For a DC42 image file to be recognized by the DiskCopy application running on a Macintosh, the file creator should be “dCpy” and the file type should be “dImg”.
The DiskCopy application will not recognize a Twiggy image as valid as it has no knowledge of Twiggy disks. The values used for a Twiggy image have been invented for BLU.
---------------------------------------------------------------------------------
As you can see, the file format has a small header, the raw sector data, and the tag bytes appended to the end of the file. The Kryoflux already generates the proper sector data, and the header could be recreated offline. All I need to do is save the tag data in sector order and append it to the end of the file.
Thanks,
Rick
