Visualizing Commodore 1541 Disk Contents

G64 files are C64/1541 disk images that contain all bits as they are physically laid out on the 5¼-inch floppy disk. Let’s visualize them!

This animation shows 28 regular Commodore 1541 disks.

  • A disk contains 35 tracks, counting from the outside to the inside.
  • Every track starts at the bottom and is read counter-clockwise1.
  • Green represents the data. Darker areas have more 0-bits.
  • Red represents a longer sequence of 1-bits.
  • Blue represents a longer sequence of 0-bits.

SYNC, Sector Headers and Data

Track 1 contains 21 sectors. Every sector is prefixed by two small red areas: These are the SYNC marks. The first SYNC marks the sector header, the second one the sector data.

Speed Zones

There are four different speed zones. The first 17 tracks (zone 3) are written at the highest speed: A sector occupies an angle of about 17 degrees. But on the last 5 tracks (zone 0), a sector occupies an angle of about 21 degrees. Yet the linear length of the sectors is about the same – that’s the idea of the different speeds. Higher tracks are shorter, and they contain fewer sectors.

Track # Sectors Speed Zone µs/Byte Raw Kbit/Track
1 – 17 21 3 26 60.0
18 – 24 19 2 28 55.8
25 – 30 18 1 30 52.1
31 – 35 17 0 32 48.8

Tail Gaps

Towards the end of the tracks, there is some unused space. You can see this in the darker and more consistent shading in the image:

About 5 to 10 degrees towards the end of each track are unused, because the space would not fit another sector. Speed zone 2 though looks like it could fit another sector, and in fact, DOS version 1 of the 2040 formatted tracks 18-24 with 20 sectors instead of 19, but this was too tight: If the motor speed was a little off, the last sector would overwrite sector 0.

When a disk is formatted, the pattern of 0x55 (alternating 0 and 1 bits) is written into this area. As long as there are no valid sector headers in the unused space, it can contain anything. There are formatting programs that fill it with all SYNC marks instead:

On some disks, the empty area is about the same size for all tracks. Some formatting programs add extra gaps between the sectors to minimize the tail gap:

40 Tracks

The original 5¼-inch “minifloppy” from 19762 only supported 35 tracks, the 40 track disks came a little later. For compatibility with existing disks3, all 48 tpi Commodore 5¼-inch drives only used 35 tracks, but some users and lots of games used 40 tracks by just extending the format (usually with the slowest speed zone) by 5 tracks.

In this case, the sectors between tracks 31-35 and 36-40 are not visually aligned, because the 5 extra tracks were presumably formatted independently with a different program which used slightly different sector gaps.

There is no specification for the format of the extra tracks. Here is an example that uses speed zone 1 (the second-highest one) with 18 sectors instead of 17:

Custom Formats

Some games used completely custom formats:

This is the game “Cosmic Relief”, which seems to store 11 or 12 sectors per track, with sectors that are about 1.5 the size of regular sectors, and potentially a different encoding. Tracks 17 and 18 have to be in the standard format though: Track 18 contains the directory, and track 17 contains the loader for the custom format, in this case.

Custom formats were usually used for copy protection. The 1541 does not have enough RAM to store the raw bitstream of one track, and the Commodore Serial Bus does not have the data rate to transfer it to the computer in real time. Therefore the only way to copy a disk is sector-by-sector, which only works if the sectors are in a format the copy program understands. Copy programs that supported parallel cables defeated most of these protection schemes.

Create Your Own Visualization

There are lots of copy protection tricks and custom formats that are interesting to look at this way. I have created a Python tool to create these image files from G64 files:

Plase share your own results!

  1. From the drive head’s point of view, a track is an infinite but repeating string of bits with no defined start. Many recording formats, including the MFM-based one of PC disks, used the index hole for a defined start point. The 1541 disk format does not make use of the index hole, so there is no defined track alignment: Any track can be arbitrarily rotated compared to the other tracks. nibconvert from the nibtools package by default writes G64 files aligned to the longest gap, which will usually align to sector 0.

  2. and the SA-400/SA-390 mechanism used in Commodore’s dirst devices

  3. Another reason might have been that the extra tracks would have needed another, slower speed zone for the data to be safe, so it wasn’t as easy as adding 40 track support to the firmware.

11 thoughts on “Visualizing Commodore 1541 Disk Contents”

  1. Good job using colourblind hostile colours you swine ;)

    Seriously though, thanks for the vis and the writeup, I never knew that about C64 disks, it goes a long way to explaining why they were so slow.

    • Nothing in this article explains the slowness of the original Commodore drives. Systems that were an order of magnitude faster were using the exact same disk format.

  2. Great article!

    Nit pick: “all Commodore 5¼-inch drives only used 35 tracks”. Actually the 8050,8250, 8250LP and SFD1001 used about twice as many tracks. Your statement is true for the more common 48TPI format drives though.

  3. Just a nitpick: “MFM-formatted disks used the index hole for a defined start point” is not exactly true. Index hole is an optional feature independent of disk’s underlying format. Some system used it, some did not. MFM also defines a sync word that can be used to locate starting points of individual sectors.

    • Thanks. I changed the sentence to “Many recording formats, including the MFM-based one of PC disks, used the index hole for a defined start point.”

  4. Is it possible to make such a visualisation of an Amiga Disk (Image)?
    Or does anybody know such a tool?

  5. what version of Python should be used
    I get this error message

    Traceback (most recent call last):
       File “”, line 2, in
         from PIL import Image, ImageDraw
    ImportError: No module named PIL

  6. I really like this idea, something new in the way C64 data are shown to the users.
    Great job, nice tool, useful information… and good timing! :-)

    At the same time you published this job I wrote an article for an Italian fanzine about the D64 file format. Since a D64 is the physical representation of a 1541’s single-sided disk in a file format, knowing its structure you can easily understand the functionality of a real Commodore 1541 Disk Drive.
    I also provided a VB5 example (bin and code) to read a D64 and display its information. Nothing really fancy, DirMaster already does the same but I thought it would have been useful to prove that the information in the article are accurate.

    Again, great job!

Leave a Comment