A reader never needs to know where the 1541 chose to put a file: it follows the track and sector links of the chain. This page is about the pattern those links usually make, which the viewer reports as the interleave of each file, and about the checks the viewer makes on chains and on the BAM. What is said about real images comes from the nine VICE test disks on one Mac (all 35 tracks, no error bytes); they do not say what program wrote them.
Interleave
The disk turns while the 1541 processes a sector, so the next sector of a file is not the next one on the track. The step between neighbouring sectors of a chain on one track is the interleave: 10 for files and 3 for the directory (VICE manual 17.5). The next sector is the previous sector number plus the interleave, counted round the track; if that sector is already used, the next free one after it is taken.
| Chain | Sectors in order | What it shows |
|---|---|---|
File CIA1 in CIA/ciavarious/cia.d64 | 17/0, 17/10, 17/20 | Steps of 10 on a track of 21 sectors. |
File CIA2 in the same image | 17/1, 17/11, 17/2 | 11 + 10 = 21, which wraps to 0; sectors 0 and 1 are used, so sector 2. |
| The directory of the same image | 18/1, 18/4, … | A step of 3 (the link of 18/1 is 12 04). |
The chain is the same whatever the interleave; only how fast a real drive reads it changes. The viewer works the interleave of a file out as the step taken most often between neighbouring sectors on the same track, and shows nothing for a file that never has two sectors in a row on one track.
Where files go
In the real images read for this page, the first file starts at 17/0, the track just
below the directory. The later files start on tracks on both sides of track 18, working
outwards. For example the first eight files of
VIC20/viavarious/viavarious.d64 start at 17/0, 19/0, 16/9, 21/3, 14/9,
23/3, 11/1 and 25/4, and the first four of interrupts/irqdma/irqdma.d64
(about 150 sectors each) at 17/0, 19/0, 10/1 and 27/2. The seven files of
CIA/CIA-AcountsB/cia-b-counts-a.d64 start at 17/0, 17/2, 15/0, 19/0, 16/2,
20/0 and 17/4.
That is an observation of these images, not the documented search order of Commodore’s DOS, which is not described here. A file may start and continue on any track, and a reader must not rely on the pattern.
Free blocks
A DIR listing ends with “blocks free”, the sum of the BAM’s count bytes for
every track except 18. An empty 35-track disk therefore has 683 − 19 = 664 blocks free,
as the viewer shows it. Track 18 is left out because the directory lives on it, even
though files may use its free sectors.
What the viewer checks
Every check is reported as a problem and the disk still opens; the files that can be read are still shown. The pages above say what is correct; these are the ways an image can disagree.
| Check | What it compares |
|---|---|
| Chain loops | A link leads back to a sector already in the same chain. |
| Sector used twice | A chain reaches a sector another file, the directory or the BAM already uses. The chain is followed up to there. |
| Link to no sector | A link names a track above the disk’s last or a sector the track does not have, or a sector beyond the end of the file. |
| Last-sector length | The second byte of a chain’s last sector, the index of the last used byte, is 0. |
| Size field | The block count in the directory entry against the number of sectors in the chain (and, for a REL file, its side sectors). Not checked for GEOS files. |
| File flags | A file that was never closed (a “splat” file), a file type of 5 or more, an entry with no first sector. |
| REL files | Record length outside 1 to 254, side sectors numbered out of order, a different record length in a side sector, more than six side sectors, and the side sectors’ list of data sectors against the file’s own chain. |
| BAM count byte | The free count of a track against the free bits of its bitmap. |
| BAM spare bits | Bits set for sectors a track does not have. |
| Used but marked free | A sector a file, the directory or the BAM uses, whose bit in the bitmap says free. |
| Orphans | A sector the bitmap says is used which no chain reaches. A directory entry whose type byte is zero (a scratched file) is not followed, so its sectors show here if the BAM still holds them. |
| BAM sector | The directory start is not 18/1, the DOS version is not A (or 0), the DOS type is not 2A. |
| Error bytes | Any code of 2 or more, named as its 1541 error (see error bytes); a code not in that table is reported as not defined. |
| Size of the file | Fewer bytes than the tracks need, error bytes cut short, bytes after the last sector. |
An orphan is not always damage: on the one real image that has any
(VIC20/vic6561/victest.d64) 28 sectors of track 14 are marked used and no entry
reaches them, and the disk is otherwise whole. The viewer calls it a problem
because the BAM and the directory disagree, and leaves the cause open.
What is not checked
Whether a file’s contents are valid for its type (a PRG’s load address, a SEQ’s text), whether directory names are unique, whether a locked file may be changed, and the header and data checksums and sector IDs of the real disk, which a D64 does not keep: only the 256 data bytes of each sector are in the file.