Store 400K/800K Mac disks as IMG, DC42, or SIT?
I'm trying to figure out if I should include IMG, and/or DC42, and/or SIT archives in Macintosh disk archives. I would like to hear any thoughts or suggestions on the matter.
Back in the late 90s, it was common for mac users to archive disk images with Apple DiskCopy on their mac and store them in StuffIt "SIT" archives.
This was necessary because only Apple Macintosh computers could write these formats of disks. It was feasible because one could simply download a "sit" file directly from the web on to their mac and write it to disk.
Apple eventually dropped 400K/800K support and these days they do not even include floppy drives. These days it is virtually impossible to access such sites with an earlier Mac thanks to insane levels of scripting and bloat. Plus, more likely these days people are trying to find boot disk media to get the machine running in the first place.
The thing is, IMG and DC42 are both basically the same thing - uncompressed raw sector images. But DC42 files contain an extra header.
Some Mac archive web sites primarily store IMG, while others use DC42.
The PCE Tools automatically recognize "DC42" as Macintosh variable bit rate 400K/800K images, although its conversion system looks like it is currently be broken. (And not very useful as it only supports TransCopy output)
When decoding streams the Kryoflux only dumps in to plain sector images (IMG). Of course, Kroflux currently does not write Mac 400K/800K sector images of any kind back to floppy.
As far as I can tell, the DC42 header is not very useful outside of a Macintosh file system, and is only used by Apple Diskcopy.
Also, there are actually two "DiskCopy" formats. The DiskCopy 4.2 format is just an uncompressed sector image with an extra header. Later versions use the "ndif" format. Ndif uses RLE compression, and stores information critical to decompression in the Macintosh resource fork. Outside of the Macintosh world "ndif" is an absolute no-go as there are no third party decompressors, the format is undocumented, and once the resource fork is stripped the file becomes useless.
Of course, if I happen to have Kryoflux or SCP dumps of original disks, I'll include those.
Back in the late 90s, it was common for mac users to archive disk images with Apple DiskCopy on their mac and store them in StuffIt "SIT" archives.
This was necessary because only Apple Macintosh computers could write these formats of disks. It was feasible because one could simply download a "sit" file directly from the web on to their mac and write it to disk.
Apple eventually dropped 400K/800K support and these days they do not even include floppy drives. These days it is virtually impossible to access such sites with an earlier Mac thanks to insane levels of scripting and bloat. Plus, more likely these days people are trying to find boot disk media to get the machine running in the first place.
The thing is, IMG and DC42 are both basically the same thing - uncompressed raw sector images. But DC42 files contain an extra header.
Some Mac archive web sites primarily store IMG, while others use DC42.
The PCE Tools automatically recognize "DC42" as Macintosh variable bit rate 400K/800K images, although its conversion system looks like it is currently be broken. (And not very useful as it only supports TransCopy output)
When decoding streams the Kryoflux only dumps in to plain sector images (IMG). Of course, Kroflux currently does not write Mac 400K/800K sector images of any kind back to floppy.
As far as I can tell, the DC42 header is not very useful outside of a Macintosh file system, and is only used by Apple Diskcopy.
Also, there are actually two "DiskCopy" formats. The DiskCopy 4.2 format is just an uncompressed sector image with an extra header. Later versions use the "ndif" format. Ndif uses RLE compression, and stores information critical to decompression in the Macintosh resource fork. Outside of the Macintosh world "ndif" is an absolute no-go as there are no third party decompressors, the format is undocumented, and once the resource fork is stripped the file becomes useless.
Of course, if I happen to have Kryoflux or SCP dumps of original disks, I'll include those.
Comments
You can use NDIF fine, but wrap in BinHex/MacBinary so their resource forks survive. NDIF is more convenient to work in using Disk Copy 6.
Raw images are also suggested - the Disk Copy 4.2 header can be appended if wanted. However, the practicality of using the raw images (without DC42 header) on a real Mac is a concern. (Maybe Disk Copy 6 can handle it?)
I'm pretty sure the FloppyEmu for Mac supports all of these formats.
Storing file archives in SITs is right out.
What I am looking at are large numbers of old SIT files with images inside of them. And these will wind up stuffed inside of 7-zip files with directories for "IMG" and "SIT" (or DC42 and SIT). The only reason I would even bother with the SIT file at all is to have the original "just in case". Although I probably shouldn't bother with them unless they contain something extra.
And SIT files preserve the Mac forks, so yea some of those SIT archives will still have NDIF files in them.
Most of the emulators I have encountered can deal with either regular IMG or DC42.
Of course, some of this would really depend on if or when tools like HxC and the PCE tools can start converting these to flux streams and what data they want. .
BTW, 1.44mb disk images would always be IMG, because those can be written with any image writer even to a brain-dead USB floppy drive.
You can still use USB floppy drives in modern OSX. Granted Aqua didn't recognize it but you can access it in the Terminal.
What OS X does not support is classic HFS, which Mac floppies are.
Also for the crappy USB floppy drive that chances are can write the 800KB files but can't read even if there are drivers I would get this.
http://www.kryoflux.com/
A special controller that uses a Apple Super Drive floppy and converts it to a USB and can read/write 400KB/800KB and 1.44MB.
Tools like the Kryoflux and SuperCard pro are the way forwards. They can already duplicate Mac 400K/800K disks - surprisingly even just using standard floppy drives (the bit rate changes in the steam signal frequency, not the drive motor). But at the moment there are no tools that I know of to convert 400K/800K sector images to stream files.