7

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.

9

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"

| improve this answer | |
3

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.

| improve this answer | |
  • Yes my proximate goal is to list the files on the disk, later I'll move on to extracting files from the disk. I'm only reading and only care about the most common formats as used sites with lots of .dsk files of old software. I don't care about games using the disk their own. But I did want to allow for techniques and tricks found by writers of emulators and .dsk-consuming tools, who must've had to deal with this over the past twenty years. Perhaps based on the sectors vs blocks approaches. – hippietrail Jun 3 at 3:59
  • 1
    @dirkt that it were that simple; DSK files are sector dumps in physical order, without addresses. DOS 3.3 and ProDOS use different interleaves. So without making a judgment call on whether a disk image is DOS 3.3 or ProDOS, an emulator can't actually determine the addresses to associate with sectors. – Tommy Jun 3 at 4:28
  • 1
    @dirkt The .dsk image formats do not have the sector address field, just the data field for each sector. Thus the emulator must synthesize the sector address field for the RTWS, generating volume, track and sector numbers for each data block based on the sector numbers it assigned to each sequential block of data in the .dsk file. Thus, it must know the interleave used in the .dsk file. – cjs Jun 3 at 8:10
  • 1
    @dirkt they’re definitely in physical order; e.g. for my dsk2woz file format converter I just put responsibility on the user: give it a file extension with a ‘p’ in it if you want the sector to be interpreted in ProDOS order (see the bottom of the README). – Tommy Jun 3 at 12:58
  • 1
    I started to implement some code checking validity of various fields in the DOS VTOC and the ProDOS Volume Directory Key Block and found that of the images I downloaded from various sites, almost all the ProDOS images were in DOS order, which really surprised me. I have no DOS images in ProDOS order and in fact it's not easy to find ProDOS images. For my needs so far it seems that checking for DOS in DOS logical order, and ProDOS in both DOS logical order and ProDOS logical order seems to work. Mapping DOS to and from ProDOS is the same both ways so I'm calling it "flipped" in my code. – hippietrail Jun 4 at 1:37

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.