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:
https://github.com/mist64/visualize_1541
Plase share your own results!
-
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.
nibconvertfrom the nibtools package by default writesG64files aligned to the longest gap, which will usually align to sector 0.↩ -
and the SA-400/SA-390 mechanism used in Commodore’s dirst devices↩
-
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.↩
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.
Well, Michael here focused on the data layout, probably because the reason for low performance is a well-known anecdote: the predecessor drive, the VIC-20’s 1540 sold with a bug, the shift register in the 6522 VIA chip didn’t work and Commodore engineers worked around it by lowering bandwidth. To maintain compatibility, this “bug” then was carried over to follow-up drives. Plus there’s also other overhead slowing down things… Anyway, just think of the countless hours users of the “highest-selling single computer model of all time” (Guinness Book) spent worldwide while waiting for floppy. An expensive bug.
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.
Thanks. Added “48 tpi” to the statement.
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.”
Is it possible to make such a visualisation of an Amiga Disk (Image)?
Or does anybody know such a tool?
Great work and information. 👍
what version of Python should be used
I get this error message
Traceback (most recent call last):
File “visualize_1541.py”, line 2, in
from PIL import Image, ImageDraw
ImportError: No module named PIL
You need to install PIL:
pip install Pillow
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!
This page is the resource we all needed in 1981 🙂 It’s very, very good. But if I may request a few edits to make things clearer for readers? Also a few typo fixes.
When you use the term “speed” you probably should edit this so as to clarify whether are referencing disk rotation rates, or the rate of magnetic signaling, or both.
> Every track starts at the bottom and is read counter-clockwise
??? I puzzled over what this meant for some time. I finally think I figured it out.
If you meant that the animated GIF of the disk layouts shows the Track start at the 6 o’clock position, you may want to rephrase that. Bottom can mean a low number or a side of a disk.
It’s a beautiful animation BTW. I just wish we could see a larger version. How did you make it? I don’t see any of the blue. I am not colorblind.
> Higher tracks are shorter, and they contain fewer sectors.
Higher tracks? You see how this collides head-on with your earlier use of the word “bottom”? If you meant “higher-numbered tracks”, say that.
>When a disk is formatted, the pattern of 0x55 (alternating 0 and 1 bits) is written into this area
I could be confused but is this 00000000 xxxxxxxx 00000101 00000101 ?
I wish we could see the Cosmic Relief disk in higher resolution. Pretty amazing.
> 2. and the SA-400/SA-390 mechanism used in Commodore’s dirst devices
First drives
>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
1.5 times the size? I think you dropped the “times”.
What is G64?
Sch Sch Schööööön
I had to stare at the first animation for about 30 seconds before I caught the blue line. 🙂
Great work! Thanks for making the Python code available too. You know, at a high enough image resolution, the PNG could be a viable disk. A form of optical storage. A good phone camera could probably read the image and recreate the disk data. You may have created a new form of “optical” storage. 😉
I would like to request the ability to change color modes for those of us who are colorblind. From the text, I can assume you chose red and green, but all I can see is solid black disks.
@Pat: 0x55 (=$55) means the 8-bit sequence 01010101.
@Micropois: The ‘fix’ for the broken shift register was to do all the shifting in software in the KERNAL, which is the reason for the lowered bandwidth; the software solution couldn’t go any faster. The C64 used a different chip (6526 instead of 6522) whose shift register worked fine, but continued with the software solution for compatibility with the existing drives. (And also probably due to the same time constraints that led them to ship the it with VIC-20 BASIC essentially unchanged at all.)
A 1571 drive hooked up to a C128 (operating in C128 mode) could finally move data at a reasonable speed, but 5¼” floppies were on the way out by then.
Fascinating stuff!
The last custom format I haven’t read much about was later Vorpal with no sync. All I heard was that the system had to re-frame the data on the fly. How would you even do this?
Your blog has quickly become one of my favorites. Keep up the amazing work!
I absolutely love these kinds of visualizations of technology I grew up with and still love exploring. Thanks!