1 - Physical layout

The original media (a 5.25" disk) has the tracks laid out in circles, with track 1 on the very outside of the disk (closest to the sides) to track 35 being on the inside of the disk (closest to the inner hub ring).

Commodore, varied the number of sectors per track and data densities across the disk to optimize available storage.

Since the outside diameter of a circle is the largest (versus closer to the center), the outside tracks have the largest amount of storage.

Track counting starts at 1, not 0, and goes up to 35.

Track's 36…40 are only valid for 40 track disks, although with low-level programming the 1541 drive could access tracks 36…40.

Some copy-protection schemes did this.

Sector counting starts at 0, not 1, for the first sector, therefore a track with 21 sectors will go from 0 to 20.

Track		Sectors/Track	# Sectors	Storage in bytes
01	17	21	357	7820
18	24	19	133	7170
25	30	18	108	6300
31	35	17	85	6020
36*	40*	17	85	6020

* Standard CBM DOS disks had only 35 tracks.

2 - Directory Track

The directory track is contained totally on track 18. Sectors 1…18 contain the directory entries whilst sector 0 contains the BAM (Block Availability Map) and disk name/ID.

Since the directory is only 18 sectors large (19 less one for the BAM), and each sector can contain only 8 entries (32 bytes per entry), the maximum number of directory entries is 18 * 8 = 144.

The first directory sector is always 18/1, even though the t/s pointer at 18/0 (first two bytes) might point somewhere else.

It then follows the same chain structure as a normal file, using a sector interleave of 3. This makes the chain links go 18/1, 18/4, 18/7 etc.

3 - Block Availability Map

Track 18 sector 0 contains the Block Availability Map (BAM) and details about the disk including it's title.

How BAM entries work

Each track has a BAM entry, which consists of 4 bytes. The first byte is the number of free sectors on that track.

The next three bytes form a bit map of the available sectors in little endian format. A 1 represents a free sector, whilst a 0 represents an allocated sector.

As there are 24 bits available but tracks range from 16 to 21 sectors then the unavailable sectors are marked as allocated, i.e. 0.

4 - File format

In the directory a file's location on the disk is stored with the first Track/Sector it occupies and the file length is in sectors not bytes.

Example

The first 2 bytes of that sector consists of 17 and 0 indicating the next sector is track 17 sector 0. The rest of that sector is 254 bytes of data.

The second sector at Track 17 Sector 0 consists of 17 and 10 which points to the third sector. It also has 254 bytes.

The sixth and final sector has Track set to 0. This is not a valid track as they start from 1, so it marks this sector as the final one in the file.

Here, the sectorId is taken as the number of bytes in this sector which contains data, 52 bytes in this instance. All other bytes in the sector after the data is ignored.

5 - D64 Image Format

The .D64 disk image format follows the format as defined for CBM DOS. Images of this format can be used in Emulators like VICE and the PI1541 attached to a real C64.

As stated in Physical Layout, Track numbers start from 1 but Sectors in a track start from 0.

35 track images are exactly 174848 bytes long whilst a 40 track image is exactly 196608 bytes.

The table below shows the position of the start of each 256 byte sector within the .D64 file.

† Track 18 is reserved for the Directory and Block Allocation Map.
* Track's 36…40 are only available on 40 track images.

6 - Auto boot

On the Commodore C128 it was possible to auto-boot a floppy disk that's in the drive when the system is powered up. This does NOT work on the C64.

This only works if Track 1 Sector 0 is allocated and contains a specific signature.

Boot sector format

Example 1

This is from lemon64.com which has an example of a boot sector in DASM.

In this instance it autoboot's CPM:

Example 2

This is from C128BOOT.txt which seems to be different to the above.

The code for the above loader is:

7 - GEOS Extensions

Later on in the life of the C64, the GEOS OS came out. It was a system much like many other windowing OS's (MAC OS, Windows) in that it used icons, windows, a mouse pointer and resource drivers. In order to contain all the information needed for the windowing system (icon, window position, creation time/date), a new filetype called VLIR was needed and directory changes were made. While GEOS files might not be of interest to many of the emulator users, it is likely that these files will be encountered, and knowledge of them would be helpful.

There are actually two types of GEOS files, VLIR and SEQuential. Don't confuse the GEOS SEQuential type with that of the standard D64 SEQ file. They are related, but not the same. VLIR are described in more detail following this paragraph. GEOS SEQuential files are all non-VLIR files, including normal PRG, USR and SEQ types.

GEOS files usually have an entity attached called an INFO block. It contains ICON info, author, file description, load address etc. However, just because an INFO block does not exist for a given file, does not mean that the file is not a GEOS file.

Each GEOS VLIR file or application is comprised of many separate chains (called RECORDS) for different sections of the app/file. Each RECORD can be loaded in separately and overtop of other ones. Below is a dump of the first directory sector of the GEOS 2.0 disk. Note the first entry seems normal enough, but the rest have additional information in the normally unused section of the entry.

The CBM File Type, GEOS file type and GEOS file structure fields are duplicated in both structures

CBM DOS file type

REL files are not permitted with GEOS. If byte 0x18 in the directory entry is 0x00 then it's a standard CBM DOS file, otherwise it's a GEOS file.

GEOS File type

File types 0x0F…0xFF are undefined.

Sources

• GEOS.TXT