How can I programmatically determine whether an Apple II .dsk disk image is a DOS .do image or a ProDOS .po image?

Question

I'm interested in working with the most common Apple II disk image file format, .dsk.

(I only programmed these machines briefly in Basic around 1979-81 and have not been in the emulator scene, so I'm pretty ignorant of much technical stuff.)

So .dsk files are raw dumps of disk contents with no headers to describe them. But they come in two flavours, one for DOS and one for ProDOS, the two common disk operating systems on the 8-bit Apple II.

.do is the unambiguous file extension for DOS format, in which the image file is a raw dump of the physical 256-byte disk sectors in order.

.po is the unambiguous file extension for ProDOS format, in which the image file is a raw dump of the logical 512-byte disk blocks in order.

So I'd like to know if there is a technique for examining the bytes of a .dsk image to know whether I should proceed to process it as a DOS .do or as a ProDOS .po.

Answer 1

You can't tell if a .do/.po disk image file is in DOS order or ProDOS order unless you recognize something on the disk. If it has a DOS 3.3 or ProDOS filesystem, it's pretty easy. Otherwise... not so easy.

If you want to see how CiderPress does it, take a look at the AnalyzeImageFile function here.

After peeling off .gz/.zip, it checks the file extension. For some things (e.g. .shk) the extension exactly specifies the format, but for .do/.po it acts as a sector-order hint. (To be clear, those extensions don't say whether the disk has a DOS or ProDOS filesystem, just how the data is ordered.)

For these "unreliable" extensions, it attempts to process the disk as various things. Whichever one works first, wins. .do/.po are referred to as "unadorned" formats because they don't have a header like .2mg does, so the only way to figure them out is to try the various operating systems and various sector orderings one at a time. The next functions in the file, AnalyzeImage and AnalyzeImageFS, do that.

Sometimes files are mis-named, so e.g. you can't assume .do is in DOS order. The full set of tests are done, checking the most-likely ordering first to ensure that if the results are ambiguous, the ordering specified by the filename wins.

Each filesystem handler (DOS 3.2/3.3, ProDOS, Pascal, CP/M, RDOS, HFS, Gutenberg) has its own "is this image one of mine" function, as do the various multi-volume formats (Mac partition, MicroDrive, etc).

Some detailed notes can be found in the CiderPress help file; see the Appendix section "About Disk Images"

Answer 2

You can look at the file systems: Here are descriptions of the DOS file system and the ProDOS file system.

They are quite different, so you attempt to list the files on the disk, usually one approach will produce garbage, and one won't. That's pretty obvious to a human, but less obvious to a program.

Also keep in mind that there are .dsk images (in particular for games) that use 16-sector format, but are not DOS: They are just a boot loader followed by game data. So a third outcome is "both attempts produce garbage".

For a program, an additional way would be to do consistency checks (e.g. VTOC matches CATALOG for a DOS disk). But there also broken disks where the VTOC was damaged, but you can still read them. So this method will fail for those.

A final method is to look at the boot loader: If it matches well-known boot loaders, and/or of the OS matches, then you also know which kind of disk it is. But there are disks without OS, and there are also dozens of variants of DOS; so this method also has limits.