Why Do C64 GEOS Boot Disks Break? (Part 1)
The most fragile things in the universe (next to C64 PLA chips) are C64 GEOS boot disks. Because of its copy-protection, the “Graphic Environment Operating System” had to be booted from the original disk every time. The disk failed so often that the box came with a second “backup” boot disk.
Reading the Raw Bits of a C64/1541 Disk without a Parallel Cable
An unmodified Commodore 1541 disk drive cannot transfer the raw bits of a whole track to the computer it is attached to: The Commodore Serial Bus is too slow to transmit the data in real time as it arrives from the read head, and the drive only has 2 KB of RAM, which is not enough to buffer the 8 KB of a whole track.
Making of the Book "Anatomy of the 4040 Disk Drive"
To my surprise, Hilaire Gagne, the author of “Anatomy of the 4040 Disk Drive”, commented on my blog post about the reconstruction of his book.
Fitting 44% More Data on a C64/1541 Floppy Disk
The physical data format on a Commodore 1541 5¼-inch floppy disk as used by the C64 is completely defined in software. The drive’s operating system fits 170 KB on a disk. This article explores different strategies, each with its pros and cons, to fit up to 246 KB.
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!
Building the Original Commodore 1541 DOS Source
You might think the DOS ROM of the Commodore 1541 disk drive has been analyzed to death. But here are two new resources:
Book "Anatomy of the 4040 Disk Drive" by Hilaire Gagne
Hilaire Gagne: Anatomy of the 4040 Disk Drive
(HTML, 632K)
Analyzing the ROMs of Third Party Disk Drives for the C64
Most Commodore 64 users had a 1541 disk drives, but there were always also third part options. Most of them claimed full 1541 compatibility, which sounds impossible without using the same ROM. Let’s analyze the ROMs of some third party drives!
Original Commodore Source Code Collection
Over the years, the ROM source code of many Commodore computers and peripherals has appeared. I have been collecting them in a git repository here:
Commodore Peripheral Bus: Part 3: Commodore DOS
In the series about the variants of the Commodore Peripheral Bus family, this article covers the common layer 4: The “Commodore DOS” interface to disk drives.
Commodore Peripheral Bus: Part 2: Bus Arbitration, TALK/LISTEN
In the series about the variants of the Commodore Peripheral Bus family, this article covers the common layer 3: the bus arbitration layer with the TALK/LISTEN protocol.
Commodore Peripheral Bus: Part 1: IEEE-488
In the series about the variants of the Commodore Peripheral Bus family, this article covers the lowest two layers (electrical and byte transfer) of the IEEE-488 bus as found on the PET/CBM series.
Commodore Peripheral Bus: Overview
The well-known Serial Bus (aka Serial “IEC” Bus) of the Commodore 64 that connects to disk drives such as the 1541 is just one variant of a whole family of busses and protocols used by the line of 8 bit Commodore machines from the PET to the C65. This is the first article of a multi-part series on the Commodore Peripheral Bus family.
Video of a Real C64 Defragmenting a Disk
Here is a 21 minute video of defrag1541 running on a real Commodore 64 – with sound!
A Visual Defragmenter for the Commodore 64
For decades, PC users have been able to relax by watching the computer defragment a disk. Now C64 users can do the same! Introducing “defrag1541”, a disk defragmentation tool for C64 and 1541.
The story of 15 Second Copy for the C-64
by Mike Pall, published with permission.
The story of FCopy for the C-64
by Thomas Tempelmann, reprinted with permission.
Inside Commodore DOS [PDF]
A 256 Byte Autostart Fast Loader for the Commodore 64
Update: The source is available at github.com/mist64/fastboot1541
LOAD"$",8
Commodore computers up to BASIC 2.0 (like the Commodore 64, the VIC-20 and the PET 2001) only had a very basic understanding of mass storage: There were physical device numbers that were mapped to the different busses, and the “KERNAL” library had “open”, “read”, “write” and “close” functions that worked on these devices. There were also higher-level “load” and “save” functions that could load and save arbitrary regions of memory: The first two bytes of the file would be the (little endian) start address of the memory block.