The 16 sectors of a track pass under the head in a fixed physical order, numbered 0 to 15 here. A file system does not use them in that order: reading two consecutive logical sectors would miss the second one, which has gone past by the time the first has been processed. Each file system therefore numbers the physical sectors in its own scrambled way, so that the next logical sector arrives just when it is wanted. DOS 3.3 and ProDOS chose different scrambles, and a disk image file has to pick one to write the sectors in.
The two tables
| Position in the file | 0 | 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| Physical position, DOS order (.DSK, .DO) | 0 | 13 | 11 | 9 | 7 | 5 | 3 | 1 | 14 | 12 | 10 | 8 | 6 | 4 | 2 | 15 |
| Physical position, ProDOS order (.PO) | 0 | 2 | 4 | 6 | 8 | 10 | 12 | 14 | 1 | 3 | 5 | 7 | 9 | 11 | 13 | 15 |
Read: sector 1 of DOS 3.3 is the one at physical position 13; sector 1 of ProDOS is at physical position 2. The same table the other way, physical position → DOS sector, is
0 7 14 6 13 5 12 4 11 3 10 2 9 1 8 15, and for ProDOS 0 8 1 9 2 10 3 11 4 12 5 13 6 14 7 15. Sectors 0 and 15 are in the same place in both orders.
A ProDOS block is two consecutive ProDOS sectors: block b of track t's 8 blocks is sectors 2b and 2b + 1. In a .PO file the two are next to each other, so block n is at n × 512 bytes. In a .DSK file a ProDOS disk's block is made of two sectors that are not adjacent.
What was compared. The two physical-position-to-sector tables were read out of the KEGS emulator's source (iwm.c, phys_to_dos_sec and phys_to_prodos_sec) and compared with the tables above, which are the traditional logical-to-physical tables as the documentation lists them; each is the inverse of the other.
Telling which order a file is in
Nothing in the file says. The explorer reads the disk both ways and keeps the reading in which a file system makes sense:
- a DOS 3.3 VTOC at track 17 sector 0 with sane fields, a catalogue chain that reads without problems, and files whose sectors add up to the sectors the VTOC says are in use;
- a ProDOS volume directory in block 2 with storage type
$F, 39-byte entries, 13 to a block, a block count equal to the image's, and a next block of 3.
The VTOC alone cannot decide: sectors 0 and 15 are in the same place in both orders, so a DOS 3.3 disk in the wrong order still shows a valid VTOC and the first catalogue sector. On the real System Master read in the wrong order the catalogue shows 7 files instead of 19; the sectors-add-up check rejects that reading. When no file system reads in either order, the extension decides (.po is ProDOS order, anything else DOS order). A .dsk file may be in ProDOS order and a .po in DOS order: names are not reliable, so the explorer does not trust them first.