davidgiven
Apple 3.5" 400K/800K: Support DiskCopy 4.2 format
Most Apple and Mac emulators expect disk images to be either in the DiskCopy 4.2 format, or in a raw format.
The DiskCopy 4.2 format is described here: https://wiki.68kmla.org/DiskCopy_4.2_format_specification It is basically [Header] [512 x 10 x Sides x 80] [12 x 10 x Sides x 80], with some checksums and padding.
The raw format throws away the 12-byte "tags" and has no header and is simply [512 x 10 x Sides x 80]. Unfortunately it is not a good idea to throw away the tags for preservation purposes, as they contain data useful for reconstruction of a damaged filesystem with Mac disks, and are essential for operation with Lisa disks.
EDIT: The WOZ format (https://github.com/davidgiven/fluxengine/issues/86) supports 3.5" disk images and emulators will likely start supporting it soon. Support from Mac emulators is likely to be hit-or-miss because many do not properly emulate an Apple floppy controller.
The spec doesn't say how the varying number of sectors per track are handled. If it's storing 800kB of data for an 800kB disk then it can't be as simple as a CHS sector array because otherwise it would take more space...
The spec doesn't say how the varying number of sectors per track are handled.
The image format is oblivious to the varying number of sectors per track — they are just laid end to end in logical order.
That said I am not 100% sure how interleaving (which was used for Apple II 3.5") is handled. I believe they are just laid end to end by sector number, in logical (filesystem) order.
Basically, if one strips away the header of an 800K HFS Mac floppy image in DC42 format, the image will mount with the Linux or Mac hfs filesystem driver.
What order is that, though? CHS, HCS, CSH... I'd be happier with a bit more specification here. But yes, the format looks nigh-trivial and should be easily supportable.
They are LBA sorted, from 0 to 1600 (or 800 for single sided disks). Then the extra 12 bytes are setup separately, in the same sorting order.
Only the DC42 that contain Twiggy images do any kind of interleaving.
C 0 H 0 S 1 = 0 C 0 H 0 S 2 = 1 then up head for double repeat sectors then change cylinder set head to 0.
Edit: If track 0 contains 10 sectors and track 4 contains 11 sectors, it doesnt matter, it still follows the same count, there are no holes for the missing sectors: C 0 H 0 S 10 = 10 C 0 H 1 S 1 = 11 C 4 H 0 S 11 = 91 C 4 H 1 S 1 = 92
Do you know of any Linux tools which will validate a DiskCopy image --- in particular, check the checksum?