fadden
commented
8 months ago Hello!
Let me start by saying that I'm more familiar with Apple II emulators than Mac emulators, so I'm not clear on the filename conventions.
In the Apple II world, ".dsk" usually means ".do", but sometimes means ".po". The result is that anything that wants to handle ".dsk" needs to assume it's one thing, or scan it to try to figure out what it is. That's only an issue for 5.25" disk images though; for 3.5" disk images, it's always straight block order. I've been rejecting ".dsk" as an extension because of the potential ambiguity, but there's no reason to do so for 800KB floppy images.
(FWIW, 80-track 16-sector DOS images are 320KB, so I need to worry about sector ordering up to that point. 50-track 32-sector DOS images are 400KB but sector ordering isn't an issue for those, so I should be safe using 400KB as a threshold.)
In the Apple II world, ".img" was used for weird 5.25" images created by one specific version of Copy ][+ on the Apple II. Nobody uses them. I handle them because supporting weird formats used by 0.001% of disk images is my hobby. The code that opens files and the code that creates files share a "switch" statement (here), and the primary definition specified "physical" sector order for an 800KB disk image, which confused the image creator.
https://github.com/fadden/CiderPress2/blob/main/docs/Manual-cp2.md#filename-extensions lists the extensions and how they're currently handled. ".img" isn't currently in the list.
The code that opens disk images accepts both ".dsk" and ".img" as potential names for DiskCopy 4.2 images. For creation you could use ".image" or ".dc", which I've seen more of than ".img", but mostly I've been looking at CD-ROMs with disk images (which often just use dCpy with no particular extension).
We're pre-alpha (for another few days... almost there), so changing the behavior isn't going to break anything. My question to you is: what do you think the results of cp2 cdi foo.dsk 800k hfs and cp2 cdi foo.img 800k hfs should be? ".dsk" = straight block order, ".img" = DiskCopy 4.2?
NJRoadfan
As reported here: https://68kmla.org/bb/index.php?threads/have-you-seen-ciderpress-2-mac-and-more-disk-image-can-opener.46146/
CiderPress2's type checking is a bit restrictive when trying to create a new disk image with certain file extensions.
-.DSK: This one seems to make sense as it is indeed ambiguous, but some emulators (software and hardware) use this extension for disk images.
-.IMG: This appears to be a logic error looking at the code. Sector ordering should not be enforced for images that are not 140k 5.25" disk. As before, .IMG is a popular extension with many emulators. If an image is larger then 140k, assume it is sector ordered and don't check for ProDOS vs. DOS 3.3 ordering.