7

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?

  • 1
    Just about everything is .do/.po (sectors in DOS or ProDOS order), .nib (raw track data) or .woz (applesaucefdc.com/woz). The latter is the cool kid on the block, because it lets you preserve disk images with the copy protection intact, but it's overkill for unprotected disks. Anything that doesn't support .do/.po is broken, IMHO, but you can trivially generate a .nib from them if you need to (CiderPress has a "bulk" disk converter tool). – fadden Nov 5 at 20:46
7

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.

  • 1
    To make things even more confusing, .dsk is also used for DiskCopy images, which originated on the Mac. Fortunately those are only used for 3.5" images and have an identifiable header. In other news, Copy ][+ lets you create .img files that hold sectors like .do/.po, but are in physical order. 2IMG was an attempt to impose order on the chaos, but as you note it didn't really take for 5.25" images. – fadden Nov 6 at 15:36
  • 2IMG is often used for 5.25 inch images that use volume numbers other than 255. – Nick Westgate Nov 7 at 1:27
5

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.

  • That's very helpful! Would you be able to provide links to the documentation ("official," if available) on the formats you mention? Also, for your footnote, linking back to your emulator code for that (if publicly available) would be useful. – Curt J. Sampson Nov 6 at 3:56
  • Oh, and by "orderings," you mean that the sectors are stored in the file in the physical order they appeared on each track, but the logical sector numbers are determined by the interleave used by the particular DOS that's reading them, right? – Curt J. Sampson Nov 6 at 3:59
  • I'm unaware of an official specification for dsk/do/po or nib; WOZ specs are at applesaucefdc.com/woz/reference2 . Re: dsk encoding back to Apple GCR, that's most of what's going on in github.com/TomHarte/dsk2woz/blob/master/dsk2woz.c as it maps from a DSK to a WOZ1 image (I'm behind on the spec, alas). My current attempt to sanitise NIBs is viewable at github.com/TomHarte/CLK/blob/master/Storage/Disk/DiskImage/… though I've actually switched to finding prologues and working backwards, but forgotten to update the big comment. Will do it now. – Tommy Nov 6 at 4:13
  • And, yes, sector contents are stored in DSK, PO and DO files in physical order. So what that means in terms of logical order depends on the filing system. – Tommy Nov 6 at 4:25
  • 1
    To be clear: .do is what you get when a DOS program reads 256-byte sector T0/S0, then T0/S1, and so on, out to T34/S15. .po is what you get when a ProDOS program reads 512-byte block 0, then block 1, out to block 279. The difference in ordering arises because ProDOS blocks are composed of non-consecutive sectors, e.g. block 0 is actually T0/S0 and T0/S2. These are "logical" sector numbers; "physical" usually refers to the actual sector numbers encoded in the address header. A table is used to translate one to the other. – fadden Nov 6 at 19:25

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.