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.
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.
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!
You might think the DOS ROM of the Commodore 1541 disk drive has been analyzed to death. But here are two new resources:
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!
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:
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.
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.
by Mike Pall, published with permission.
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.