Macintosh 400K/800K disks

All news about KryoFlux go here.
lisa2
Posts: 2
Joined: Tue Apr 29, 2014 9:04 pm

Re: Macintosh 400K/800K disks

Post by lisa2 » Tue Apr 29, 2014 9:24 pm

IFW wrote:All of those are supported already: in order to decode a disk from flux transitions - regardless of format - you have to pretty much simulate what the hardware/firmware/software does on the target platform.
A sector on those decodes to 524 bytes, but only 512 bytes are actually stored in a sector dump - since there is nowhere to store the rest. With a suitable format the rest could be stored as well.
I would like to use my KryoFlux to image Apple Lisa disks. The Lisa 3.5" format is exactly the same as the Macintosh 400K format, but to be useable with the Lisa, the "tag" bytes are required. The quote above states that current KryoFlux decoder does decode the tag bytes, but does not save them. I need to save them somehow.

Rather than re-invent the wheel and write my own decoder from scratch, is there anyway I can peek at the decoder's source so I can modify the Apple 400K/800K decoder to save the tag bytes myself? I would be glad to share my work with the community.

Thanks,
Rick

User avatar
IFW
Posts: 2634
Joined: Mon Nov 08, 2010 2:42 pm

Re: Macintosh 400K/800K disks

Post by IFW » Thu May 08, 2014 10:09 am

Is there an "official" format that actually supports using those bytes?

lisa2
Posts: 2
Joined: Tue Apr 29, 2014 9:04 pm

Re: Lisa 400K disks

Post by lisa2 » Tue May 27, 2014 8:51 pm

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

papa_november
Posts: 2
Joined: Sun Nov 14, 2010 11:49 am

Re: Macintosh 400K/800K disks

Post by papa_november » Wed Jul 02, 2014 3:29 am

How would you handle the resource fork though? DiskCopy and friends appear to stick the checksum in the resource fork.

Post Reply

Who is online

Users browsing this forum: No registered users and 2 guests