This artikel originally came from Kevin Thackers' archive at http://www.cpctech.org.uk.

This document describes the standard disk image format. It has the file extension ".DSK".

Disc Information block

The "Disc Information block" is always at offset 0 in the disk image file. If track data exists, then this will immediatly follow the Disc Information Block and will start at offset &100 in the disc image file.

The "Disc Information block" has the following structure:

Notes:

• Track 0 (or Track 0 side 0 for double sided disks) immediatly follows the Disk Information Block, and is at offset &100 in the disk image.
• "MV - CPC" must be present, because it is used to identify the file as a disk image. It is sufficient to check this to identify the file as being a disk image.
• "\r" is the C programming language equivalent of ASCII character 13.
• "\n" is the C programming language equivalent of ASCII character 10.
• All tracks must be the same size.
• "size of track" is used to calculate the location of the data for a chosen track.
• "size of track" includes the &100 byte Track Information Block.
• All tracks must have a "Track Information Block"
• track lengths are stored in the same order as the tracks in the image e.g. In the case of a double sided disk: Track 0 side 0, Track 0 side 1, Track 1 side 0 etc...
• The track blocks are stored in increasing order 0..number of tracks, with alternating sides interleaved if the disc image describes a double sided disk. e.g. if the disk image represents a double sided disk, the order of tracks is: track 0 side 0, track 0 side 1, track 1 side 0, track 1 side 1.... track (number of tracks-1) side 0, track (number of tracks-1) side 1 The tracks are always ordered in this way regardless of the disc-format described by the disc image.
• A standard disk image can be used to describe a copy-protected disk, but will often result in a file which is larger than the same disk described by a extended disk image. For a standard disk image to represent a copy-protected disk:
  • All track sizes in the standard disk image must be the same. This value therefore would be the size of the largest track, and other tracks would have unused space in them.
  • All sector sizes within each track must be the same size, but not necessarily the same size as the sectors for another track. If a track contained different sized sectors, the size of the largest sector should be used. This would result in some wasted space.

Track Information Block

Each Track Block comprises a Track Information Block and sector data. The sector data is always at an offset of &100 bytes from the start of the track block. The data for the next track in the disc image immediatly follows the data for the current track.

The first Track Block is located at offset &100 in the disk image file. The track block starts with the Track Information Block and has this form.

Notes:

• "number of sectors" is used to identify the number of valid entries in the sector information list.
• "sector size" parameter is used to calculate the location of each sector's data. Therefore, The data allocated for each sector must be the same. If the track contains different sized sectors, then the data allocated must be the size of the biggest sector. The "sector size" parameter is used to calculate the location of the sector data.
• Sector data always follows Track Information Block at offset &100 from the start of the track information block.
• Sector data is stored in the same order as the sectors in the sector info block.

Sector info

Notes:

• The following bits are used from NEC765 status register 1:
  • b7 EN (End of Cylinder)
  • b5 DE (Data Error)
  • b2 ND (No Data)
  • b0 MA (Missing Address Mark)
• The following bits are used from NEC765 status register 2:
  • b5 CM (Control Mark)
  • b5 DD (Data Error in Data field)
  • b0 MD (Missing address Mark in Data field)
• For 8k Sectors (N="6"), only 1800h bytes is stored.

General format

Single sided DSK images

• Disc Information Block
• Track 0 data
  • Track Information Block
  • Sector data
• Track 1 data
  • Track Information Block
  • Sector data . . . .
• Track (number_of_tracks-1) data
  • Track Information Block
  • Sector data

Double sided DSK images

• Disc Information Block
• Track 0 side 0 data
  • Track Information Block
  • Sector data
• Track 0 side 1 data
  • Track Information Block
  • Sector data . . . .
• Track (number_of_tracks-1) side 1 data
  • Track Information Block
  • Sector data

The extended DSK image is a file designed to describe copy-protected floppy disk software. It's definition was defined by Marco Vieth, Ulrich Doewich and Kevin Thacker.

This format has been widely adopted and is one of the major file formats used (the other major format is the standard disk image with the "MV - CPC" identifier).

The extended disk image format should be used for copy-protected disc software, or in place of a standard disk image if the resulting image is smaller than in the standard disk image form.

Extended DiSK Format (Rev.5)

The disc image has the following format:

The track blocks are stored in increasing order 0..number of tracks, with alternating sides interleaved if the disc image describes a double sided disk. e.g. if the disk image represents a double sided disk, the order of tracks is: track 0 side 0, track 0 side 1, track 1 side 0, track 1 side 1.... track (number of tracks-1) side 0, track (number of tracks-1) side 1

The tracks are always ordered in this way regardless of the disc-format described by the disc image.

The location of the track information block is found by using the track size table.

DISK INFORMATION BLOCK

The "DISK INFORMATION BLOCK" is always located at offset 0 in the disk image file, and has the following structure:

NOTES:

• An extended DSK image is identified by the "EXTENDED" tag. The track size at offset 32h and 33h, used by the STANDARD disk image is ignored for extended format DSK images.
• If track data exists, then it starts at offset 100h.
• The "EXTENDED" tag is present to prevent existing emulators which support the standard DSK image from interpreting the data wrong and possibly crashing.
• "\r" is the C programming language equivalent of ASCII character 13.
• "\n" is the C programming language equivalent of ASCII character 10.

TRACK OFFSET TABLE

NOTES:

• Depending on the information in the disk information block, the table contains
  • track lengths for a single sided floppy disc
  • track lengths for a double sided floppy disc
• track lengths are stored in the same order as the tracks in the image e.g. In the case of a double sided disk: Track 0 side 0, Track 0 side 1, Track 1 side 0 etc...
• A size of "0" indicates an unformatted track. In this case there is no data, and no track information block for this track in the image file!
• Actual length of track data = (high byte of track length) * 256
• Track length includes the size of the TRACK INFORMATION BLOCK (256 bytes)
• The location of a Track Information Block for a chosen track is found by summing the sizes of all tracks up to the chosen track plus the size of the Disc Information Block (&100 bytes). The first track is at offset &100 in the disc image.

TRACK INFORMATION BLOCK

NOTES:

• Identical to the original DSK format definition.

SECTOR INFORMATION LIST

NOTES:

• Identical to the original definition except for the addition of the sector data length. This value is in bytes and stored in little endian notation. (low byte followed by high byte)
• The location of each sectors data is found by adding the size of the previous sectors, plus the size of the 256 byte header.
• For 8k Sectors (N="6"), only 1800h bytes is stored. Please see extensions below!!!

Extensions to the above specification

1. This extension was proposed by John Elliott. Extension to TRACK INFORMATION BLOCK:

Notes:

1. Data rate defines the rate at which data was written to the track. This value applies to the entire track.

Existing files should have zeroes in these bytes; hence the use of 0 for unknown.

2. Recording mode is used to define how the data was written. It defines the encoding used to write the data to the disc and the structure of the data on the disc including the layout of the sectors. This value applies to the entire track.

Existing files should have zeroes in these bytes; hence the use of 0 for unknown.

3. How to determine the actual rate. The NEC765 floppy disc controller is supplied with a single clock. When reading from and writing to a disc using the NEC765 you can choose FM or MFM recording modes. Use of these modes and the clock into the NEC765 define the final rate at which the data is written to the disc.

When FM recording mode is used, data is read from or written to at a rate which is double that of when MFM is used. The time for each bit will be twice the time for MFM.

Examples:

2. This extension was proposed by Simon Owen.

1. It has been found that many protections using 8K Sectors (N="6") do store more than &1800 bytes of useable data. It was thought that &1800 was the maximum useable limit, but this has proved wrong. So you should support 8K of data to ensure this data is read correctly. The size of the sector will be reported in the SECTOR INFORMATION LIST as described above.

For sector size N="7" the full 16K will be stored. It is assumed that sector sizes are defined as 3 bits only, so that a sector size of N="8" is equivalent to N="0".

2. Storing Multiple Versions of Weak/Random Sectors.

Some copy protections have what is described as 'weak/random' data. Each time the sector is read one or more bytes will change, the value may be random between consecutive reads of the same sector.

To support these formats the following extension has been proposed.

Where a sector has weak/random data, there are multiple copies stored. The actual sector size field in the SECTOR INFORMATION LIST describes the size of all the copies. To determine if a sector has multiple copies then compare the actual sector size field to the size defined by the N parameter. For multiple copies the actual sector size field will have a value which is a multiple of the size defined by the N parameter. The emulator should then choose which copy of the sector it should return on each read.