Next: The D81 disk image format, Previous: The X64 disk image format, Up: The emulator file formats [Contents][Index]

### 17.7 The D71 disk image format

(This section was contributed by Peter Schepers and slightly edited by Marco van den Heuvel.)

Similar to the D64 (1541), the 1571 drive can operate in either single-sided (1541 compatible) mode or double-sided (1571) mode. In this section I will be dealing with the double-sided mode only. For the breakdown of the single-sided mode, see the D64 section.

The D71 has 70 tracks, double that of the 1541, with a DOS file size of 349696 bytes. If the error byte block (1366 bytes) is attached, this makes the file size 351062 bytes. The track range and offsets into the D71 files are as follows:

Track | Sec/trk | # Sectors
1-17 (side 0) | 21 | 357
18-24 (side 0) | 19 | 133
25-30 (side 0) | 18 | 108
31-35 (side 0) | 17 | 85
36-52 (side 1) | 21 | 357
53-59 (side 1) | 19 | 133
60-65 (side 1) | 18 | 108
66-70 (side 1) | 17 | 85

Track | #Sect | #SectorsIn | D71 Offset
1 | 21 | 0 | $00000
2 | 21 | 21 | $01500
3 | 21 | 42 | $02A00
4 | 21 | 63 | $03F00
5 | 21 | 84 | $05400
6 | 21 | 105 | $06900
7 | 21 | 126 | $07E00
8 | 21 | 147 | $09300
9 | 21 | 168 | $0A800
10 | 21 | 189 | $0BD00
11 | 21 | 210 | $0D200
12 | 21 | 231 | $0E700
13 | 21 | 252 | $0FC00
14 | 21 | 273 | $11100
15 | 21 | 294 | $12600
16 | 21 | 315 | $13B00
17 | 21 | 336 | $15000
18 | 19 | 357 | $16500
19 | 19 | 376 | $17800
20 | 19 | 395 | $18B00
21 | 19 | 414 | $19E00
22 | 19 | 433 | $1B100
23 | 19 | 452 | $1C400
24 | 19 | 471 | $1D700
25 | 18 | 490 | $1EA00
26 | 18 | 508 | $1FC00
27 | 18 | 526 | $20E00
28 | 18 | 544 | $22000
29 | 18 | 562 | $23200
30 | 18 | 580 | $24400
31 | 17 | 598 | $25600
32 | 17 | 615 | $26700
33 | 17 | 632 | $27800
34 | 17 | 649 | $28900
35 | 17 | 666 | $29A00
36 | 21 | 683 | $2AB00
37 | 21 | 704 | $2C000
38 | 21 | 725 | $2D500
39 | 21 | 746 | $2EA00
40 | 21 | 767 | $2FF00
41 | 21 | 788 | $31400
42 | 21 | 809 | $32900
43 | 21 | 830 | $33E00
44 | 21 | 851 | $35300
45 | 21 | 872 | $36800
46 | 21 | 893 | $37D00
47 | 21 | 914 | $39200
48 | 21 | 935 | $3A700
49 | 21 | 956 | $3BC00
50 | 21 | 977 | $3D100
51 | 21 | 998 | $3E600
52 | 21 | 1019 | $3FB00
53 | 19 | 1040 | $41000
54 | 19 | 1059 | $42300
55 | 19 | 1078 | $43600
56 | 19 | 1097 | $44900
57 | 19 | 1116 | $45C00
58 | 19 | 1135 | $46F00
59 | 19 | 1154 | $48200
60 | 18 | 1173 | $49500
61 | 18 | 1191 | $4A700
62 | 18 | 1209 | $4B900
63 | 18 | 1227 | $4CB00
64 | 18 | 1245 | $4DD00
65 | 18 | 1263 | $4EF00
66 | 17 | 1281 | $50100
67 | 17 | 1298 | $51200
68 | 17 | 1315 | $52300
69 | 17 | 1332 | $53400
70 | 17 | 1349 | $54500

The directory structure is the same as a D64/1541. All the same filetypes apply, the directory still only holds 144 files per disk and should only exist on track 18.

The first two bytes of the sector ($12/$04 or 18/4) indicate the location of the next track/sector of the directory. If the track value is set to $00, then it is the last sector of the directory. It is possible, however unlikely, that the directory may *not* be competely on track 18 (some disks do exist like this). Just follow the chain anyhow.

When the directory is done, the track value will be $00. The sector link should contain a value of $FF, meaning the whole sector is allocated, but the actual value doesn’t matter. The drive will return all the available entries anyways. This is a breakdown of a standard directory sector and entry:

        00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
        -----------------------------------------------
    00: 12 04 82 11 00 4A 45 54 20 53 45 54 20 57 49 4C
    10: 4C 59 A0 A0 A0 00 00 00 00 00 00 00 00 00 2B 00
    20: 00 00 82 0F 01 4A 53 57 20 31 A0 A0 A0 A0 A0 A0
    30: A0 A0 A0 A0 A0 00 00 00 00 00 00 00 00 00 BF 00
    40: 00 00 82 06 03 53 4F 4E 20 4F 46 20 42 4C 41 47
    50: 47 45 52 A0 A0 00 00 00 00 00 00 00 00 00 AE 00
    60: 00 00 82 15 0D 50 4F 54 54 59 20 50 49 47 45 4F
    70: 4E A0 A0 A0 A0 00 00 00 00 00 00 00 00 00 A2 00
    80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Bytes | Description
$00-$1F | First directory entry
$20-$3F | Second dir entry
$40-$5F | Third dir entry
$60-$7F | Fourth dir entry
$80-$9F | Fifth dir entry
$A0-$BF | Sixth dir entry
$C0-$DF | Seventh dir entry
$E0-$FF | Eighth dir entry

This is a breakdown of a standard directory entry:

Bytes | Description
$00-$01 | Track/Sector location of next directory sector ($00/$FF if its the last sector)
$02 | File type
$03-$04 | Track/sector location of first sector of file
$05-$14 | 16 character filename (in PETASCII, padded with $A0)
$15-$16 | Track/Sector location of first side-sector block (REL file only)
$17 | REL file record length (REL file only, max. value 254)
$18-$1D | Unused (except with GEOS disks)
$1E-$1F | File size in sectors, low/high byte order ($1E+$1F*256). The approx. filesize in bytes is <= #sectors * 254

The file type field is used as follows:

Bits | Description
0-3 | The actual file type
4 | Unused
5 | Used only during SAVE-@ replacement
6 | Locked flag (Set produces ">" locked files)
7 | Closed flag (Not set produces "*", or "splat" files)

The actual file type can be one of the following:

Binary | Decimal | File type
0000 | 0 | DEL
0001 | 1 | SEQ
0010 | 2 | PRG
0011 | 3 | USR
0100 | 4 | REL

Values 5-15 are illegal, but if used will produce very strange results. The 1571 is inconsistent in how it treats these bits. Some routines use all 4 bits, others ignore bit 3, resulting in values from 0-7.

When the 1571 is in is native ("1571") mode, files are stored with a sector interleave of 6, rather than 10 which the 1541 (and the 1571 in "1541" mode) uses. The directory still uses an interleave of 3.

#### 17.7.1 Non-Standard & Long Directories

Most Commodore floppy disk drives use a single dedicated directory track where all filenames are stored. This limits the number of files stored on a disk based on the number of sectors on the directory track. There are some disk images that contain more files than would normally be allowed. This requires extending the directory off the default directory track by changing the last directory sector pointer to a new track, allocating the new sectors in the BAM, and manually placing (or moving existing) file entries there. The directory of an extended disk can be read and the files that reside there can be loaded without problems on a real drive. However, this is still a very dangerous practice as writing to the extended portion of the directory will cause directory corruption in the non- extended part. Many of the floppy drives core ROM routines ignore the track value that the directory is on and assume the default directory track for operations.

To explain: assume that the directory has been extended from track 18 to track 19/6 and that the directory is full except for a few slots on 19/6. When saving a new file, the drive DOS will find an empty file slot at 19/6 offset $40 and correctly write the filename and a few other things into this slot. When the file is done being saved the final file information will be written to 18/6 offset $40 instead of 19/6 causing some directory corruption to the entry at 18/6. Also, the BAM entries for the sectors occupied by the new file will not be saved and the new file will be left as a SPLAT (*) file.

Attempts to validate the disk will result in those files residing off the directory track to not be allocated in the BAM, and could also send the drive into an endless loop. The default directory track is assumed for all sector reads when validating so if the directory goes to 19/6, then the validate code will read 18/6 instead. If 18/6 is part of the normal directory chain then the validate routine will loop endlessly.

#### 17.7.2 Bam layout

The BAM is somewhat different as it now has to take 35 new tracks into account. In order to do this, most of the extra BAM information is stored on track 53/0, and the remaining sectors on track 53 are marked in the BAM as allocated. This does mean that except for one allocated sector on track 53, the rest of the track is unused and wasted. (Track 53 is the equivalent to track 18, but on the flip side of the disk). Here is a dump of the first BAM sector…

        00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
        -----------------------------------------------
    00: 12 01 41 80 12 FF F9 17 15 FF FF 1F 15 FF FF 1F
    10: 15 FF FF 1F 15 FF FF 1F 15 FF FF 1F 15 FF FF 1F
    20: 15 FF FF 1F 15 FF FF 1F 15 FF FF 1F 15 FF FF 1F
    30: 15 FF FF 1F 15 FF FF 1F 15 FF FF 1F 15 FF FF 1F
    40: 15 FF FF 1F 15 FF FF 1F 11 FC FF 07 13 FF FF 07
    50: 13 FF FF 07 13 FF FF 07 13 FF FF 07 13 FF FF 07
    60: 13 FF FF 07 12 FF FF 03 12 FF FF 03 12 FF FF 03
    70: 12 FF FF 03 12 FF FF 03 12 FF FF 03 11 FF FF 01
    80: 11 FF FF 01 11 FF FF 01 11 FF FF 01 11 FF FF 01
    90: A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0 A0
    A0: A0 A0 30 30 A0 32 41 A0 A0 A0 A0 00 00 00 00 00
    B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 15 15 15
    E0: 15 15 15 15 15 15 15 15 15 15 15 15 15 15 00 13
    F0: 13 13 13 13 13 12 12 12 12 12 12 11 11 11 11 11

Bytes | Description
$00-$01 | Track/Sector location of the first directory sector (should be set to 18/1 but it doesn’t matter, and don’t trust what is there, always go to 18/1 for first directory entry)
$02 | Disk DOS version type (see note below) $41 (’A’) = 1541
$03 | Double-sided flag $00 - Single sided disk $80 - Double sided disk
$04-8F | BAM entries for each track, in groups of four bytes per track, starting on track 1.
$90-$9F | Disk Name (padded with $A0)
$A0-$A1 | Filled with $A0
$A2-$A3 | Disk ID
$A4 | Usually $A0
$A5-$A6 | DOS type, usually "2A"
$A7-$AA | Filled with $A0
$AB-$DC | Not used ($00’s)
$DD-$FF | Free sector count for tracks 36-70 (1 byte/track).

The "free sector" entries for tracks 36-70 are likely included here in the first BAM sector due to some memory restrictions in the 1571 drive. There is only enough memory available for one BAM sector, but in order to generate the "blocks free" value at the end of a directory listing, the drive needs to know the extra track "free sector" values. It does make working with the BAM a little more difficult, though.

These are the values that would normally be with the 4-byte BAM entry, but the rest of the entry is contained on 53/0.

Note: If the DOS version byte is set to anything other than $41 or $00, then we have what is called "soft write protection". Any attempt to write to the disk will return the "DOS Version" error code 73. The 1571 is simply telling you that it thinks the disk format version is incorrect.

The BAM entries require some explanation. Take the first entry at bytes $04-$07 ($12 $FF $F9 $17). The first byte ($12) is the number of free sectors on that track. Since we are looking at the track 1 entry, this means it has 18 (decimal) free sectors.

The next three bytes represent the bitmap of which sectors are used/free. Since it is 3 bytes (8 bits/byte) we have 24 bits of storage. Remember that at most, each track only has 21 sectors, so there are a few unused bits. These entries must be viewed in binary to make any sense. We will use the first entry (track 1) at bytes 04-07:

     FF=11111111, F9=11111001, 17=00010111

In order to make any sense from the binary notation, flip the bits around.

                111111 11112222
     01234567 89012345 67890123
     --------------------------
     11111111 10011111 11101000
     ^                     ^
     sector 0           sector 20

Since we are on the first track, we have 21 sectors, and only use up to the bit 20 position. If a bit is on (1), the sector is free. Therefore, track 1 has sectors 9,10 and 19 used, all the rest are free.

In order to complete the BAM, we must check 53/0.

        00 01 02 03 04 05 06 07 08 09 0A 0B 0C 0D 0E 0F
        -----------------------------------------------
    00: FF FF 1F FF FF 1F FF FF 1F FF FF 1F FF FF 1F FF
    10: FF 1F FF FF 1F FF FF 1F FF FF 1F FF FF 1F FF FF
    20: 1F FF FF 1F FF FF 1F FF FF 1F FF FF 1F FF FF 1F
    30: FF FF 1F 00 00 00 FF FF 07 FF FF 07 FF FF 07 FF
    40: FF 07 FF FF 07 FF FF 07 FF FF 03 FF FF 03 FF FF
    50: 03 FF FF 03 FF FF 03 FF FF 03 FF FF 01 FF FF 01
    60: FF FF 01 FF FF 01 FF FF 01 00 00 00 00 00 00 00
    70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    A0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    B0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    C0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    D0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
    F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00

Each track from 36-70 has 3 byte entries, starting at address $00.

    Byte: $00-$02: $FF $FF $1F - BAM map for track 36
          $03-$05: $FF $FF $1F - BAM map for track 37
          …
          $33-$35: $00 $00 $00 - BAM map for track 53
          …
          $66-$68: $FF $FF $01 - BAM map for track 70
          $69-$FF:             - Not used

You can break down the entries for tracks 36-70 the same way as track 1, just combine the free sector bytes from 18/0 and the BAM usage from 53 to get the full 4-byte entry.

Just like a D64, you can attach error bytes to the file, for sector error information. This block is 1366 bytes long, 1 byte for each of the 1366 sectors in the image. With the error bytes, the file size is 351062 bytes.

Next: The D81 disk image format, Previous: The X64 disk image format, Up: The emulator file formats [Contents][Index]