What are the most common Apple II disk image formats and what hardware disk drive emulators can use them?

Question

Archive.org has plenty of Apple II disk images, such as this DOS 3.3 image which is a .dsk file. I also see .nib and .d13 files, e.g. in this ASIMOV LISP collection. There seem to be further formats around as well; the Ciderpress documentation seems to list a half dozen or more.

The HXC floppy emulator lists .nyb as the only supported Apple II format in the supported disk images list in their documentation. Floppy Emu mentions .dsk, .do, .po, .2mg, .nib and .woz formats. Smartport doesn't say what they use. SDISK II appears to use a .nic format, with a conversion tool for .dsk files. I'm not clear on what SVD uses.

What are the most commonly used formats? Which ones are compatible with multi-platform hardware disk drive emulators? (I'd prefer to buy one emulator that I can use not just with my Apple IIc but with other systems using Shugart SA400 or similar interfaces as well.) Which ones have image manipulation tools for multiple platforms, particularly Linux?

Answer 1

Another partial answer.

.d13 is a format for storing the 13-sector floppy disks that were used on the Apple II before mid-1980, by Apple OS's before before DOS 3.3; i.e. Apple DOS 3.1, 3.2 and 3.2.1, the earliest versions of Microsoft's Softcard-based Apple CP/M 2.2, and maybe by the first version of Apple PASCAL (not sure about that though); those floppies use a simpler GCR encoding scheme (called 5-and-3) and thus they can fit only 13 256-byte sectors per track, as opposed to the 16 sectors of the much more common post-1980 format with more modern (6-and-2) GCR encoding.

I defined this format many years ago when creating ADT13, a fairly straightforward hack of the Apple-DOS-based ADT (Apple disk transfer), which itself has been largely superseeded by the Apple-ProDOS-based ADTPro today. .d13 is simply a variant of the most common format .dsk, just storing 13 instead of 16 sectors per track. The difference between DOS-Ordering and ProDOS-ordering does not apply to the .d13 format since ProDOS never supported 13-sector disks. Thus it consists simply of a concatenation of all 35 (tracks)*13 (sectors)*256 (bytes per sector) bytes on such a disk without any further headers, thus the file size will be 116.480 bytes, or 113,75 KiB.

Thus .d13 is a sort-of-common format for the very earliest Apple II disk-based software, but otherwise of little use. The other way to store such old disk images is the .nib format which stores the raw GCR data that real hardware will see coming into the floppy disk read register (but doesn't store the timing with which it will arrive).

---

Regarding .dsk, .do and .po there's a few things to say:

1. You can store DOS-based disks in ProDOS order and vice versa. So there is really no NEED to have two different orderings.

2. Most .dsk images encountered in the wild use DOS ordering, even if the software stored on them is ProDOS-based.

3. Contrary to the comment by Tommy on another answer, neither DOS ordering nor ProDOS ordering corresponds to the physical ordering (which sector directly follows which other sector on the track) or the physical numbering (which number is stored in the sector's header) of sectors on a 16-sector disk. On a 13-sector disk, DOS order (the only one there is for 13-sector disks) corresponds to the physical numbering, but not to the physical ordering of sectors. The reason for this state of affairs is sector skew, which allows the computer enough time to encode or decode a sector before the next needed sector arrives under the drive's read/write head.
4. DOS ordering vs. ProDOS ordering is only relevant for images of 16-sector 5¼" floppies, as that is the only format usable by both DOS and ProDOS. High-level images of 13-sector 5¼" floppies always use DOS ordering; high-level images of 3½" floppies and hard disks always use ProDOS ordering.
5. The more or less "raw" low-level disk image formats, such as .nib and .woz use physical ordering, corresponsing to neither DOS ordering nor ProDOS ordering.

---

Regarding .2mg - this was supposed to be a common format for all Apple-II high-level disk images. In practice, it is most commonly used for 3½" floppy images as those are not covered by .dsk, .do, .po or .nib.

Answer 2

I can offer a partial answer only:

.dsk, .do and .po are all the same file format: sector contents only, implicitly ordered. The difference is that DOS 3.3 and Pro-DOS use different orderings, so it's fairly common to use .do or .po as a file extension in order to be explicit about which of those filing systems' orderings the disk image should be interpreted in. What a particular tool assumes for a plain .dsk isn't really standardised.

.dsk is far and away the most common format in terms of images distributed, and I would be surprised if there were a hardware drive emulator that didn't support them, though a conversion tool might well be necessary since GCR encoding must be applied to the data to convert it back into its on-disk form and drive emulators often lack either the processing or the temporary storage to do so in real-time.

.nib is an awkward mess in terms of describing a disk. It is a list of the bytes that were read back directly from the Disk II hardware when spinning a disk. What that means is that timing is implicit. Real disks use slip bits for synchronisation — specially crafted on-disk bytes with appropriate holes that allow the disk controller to determine the proper windowing of bits from then on — and you are left with no clue as to where those are. So trying to produce something that would read the same as a NIB when handed to real hardware involves searching for sequences that would work with slip bits inserted*. Which usually means applying some rules about the usual layout of a Disk II disk. Which completely defeats the intended purpose of the thing, of being able to image arbitrary disks.

.nibs are rarely supported in drive emulators, if at all, because of the inherent difficulty in doing that reliably. Really the only context they are reliable in is emulators that aren't actually emulating the physical hardware.

.wozs are relatively new, but are very well-formed. They're just a record of the bitstream per track, with advocated behaviour on how properly to generate weak bits (i.e. produce noise if you go too far between signal). The only simplification it applies is that bit timing is assumed consistent across the track.

It is a relatively new format, though it is definitely supported by at least the Big Mess o' Wires FloppyEmu.

(*) the policy I apply in my emulator is to seek an identifiable epilogue sequence, and treat as much of the following as a sync region as looks reasonable. I have no doubt this breaks at least one piece of protected software.