Apple II emulators accept disk images in "DOS order" or "ProDOS order". What's the difference? Why have two different formats?
Add a comment
|
1 Answer
The reasons are partly technical and partly historical.
The basic Apple II disk image formats are unadorned and unstructured. The files just hold a copy of the disk data, from the first track to the last, as read by the operating system. The way in which the data is read from the physical floppy determines the ordering.
If your disk imaging program runs under DOS 3.3, it will start at track 0 sector 0 (t0s0), reading 256 bytes. It continues on that track through t0s15, then advances to the next track (t1s0). It stops when it reaches t34s15. If an emulator wants to read (say) track 10 sector 7, it seeks to file offset (10 * 16 + 7) * 256 = 42752 and reads 256 bytes.
If your disk imaging program runs under ProDOS, it will start at block 0, reading 512 bytes, and continue through block 279. If an emulator wants to read block 100, it seeks to offset (100 * 512) = 51200, and reads 512 bytes.
The trouble comes because the 512-byte ProDOS blocks don't map neatly on top of DOS 3.3 sectors. While 5.25" ProDOS disks still use the same 256-byte sector structure in the low-level disk format, the higher-level blocks are mapped across non-adjacent sectors. ProDOS block 0 occupies sectors 0 and 2, not 0 and 1.
If an emulator wants to read track 0 sector 1 from a DOS-ordered disk, it can do trivial math ((0 * 16 + 1) * 256) and seek to offset 256. For a ProDOS ordered disk, that sector is actually the first half of block four, so the emulator would seek to offset 4 * 512 = 2048.
Various disk imaging programs are available, some written for DOS, some for ProDOS. Because neither format was widely accepted as the One True Way, emulators have to cope with both. In many cases the format can be auto-detected, but it's generally best to use file extensions to identify the format (.po / .do). Fortunately the sector/block conversion can be managed with a simple lookup table.
Many emulators also support "nibble" images, which contain the raw bytes as read from the drive, one track at a time. The track format contains sector numbers in the address header fields, so there is no ambiguity about the ordering.
The order in which sectors physically appear on a track is irrelevant except for performance. Tools like Bag of Tricks allowed one to "skew" the sectors in a way that made reads of consecutive sectors faster. DOS 3.3 wasn't fast enough to read the track in a single revolution, so the idea was to interleave the data such that, at the point DOS had finished reading and processing sector N, sector N+1 was about to pass under the drive head. Because the sectors were explicitly numbered in the address field, this was invisible to DOS and ProDOS, and has no effect on disk images.