Skip to content
@deckyard/d64

Drives and computers

Drives

DriveYearMediaCapacityTracksSidesEncodingImage
VIC-154019815¼" DD170 kB351GCRD64
154119825¼" DD170 kB351GCRD64
157019855¼" DD170 kB351GCR + MFMD64
157119855¼" DD340 kB35 ×22GCR + MFMD71
158119873½" DD800 kB802MFM onlyD81

Each drive has its own 6502, RAM and ROM, and runs CBM DOS in firmware. The host sends filenames and commands over the serial bus.

VIC-1540 - for the VIC-20. Its serial timing is too fast for the C64, whose VIC-II steals bus cycles for video; on a C64 it works only with the screen blanked. The 1541 ROM fixed this by slowing the transfer down.

1541 - the same mechanism with the corrected ROM; the D64 format is its disk. 35 tracks, 683 blocks, 664 free after formatting, CBM DOS 2.6. Revisions: 1541 (1982), 1541C (1986), 1541-II (1988), differing in case, power supply and track-zero detection, not in format. About 400 bytes/s, because a bug in the 6522 VIA's shift register forced serial transfer into software; fastloaders and speeder DOSes work around that.

1570 - a single-sided 1571, sold mainly in Europe as a stopgap while double-sided mechanisms were short. 1571 board, 1541 mechanism: burst mode, and a WD1770/1772 controller that reads single-sided MFM disks under C128 CP/M. Its GCR side writes ordinary 35-track D64 layouts.

1571 - the C128's drive. Double-sided, 70 tracks, 340 kB, burst mode, and MFM through the WD1770 for CP/M and (with third-party software) MS-DOS disks. In C64 mode it behaves as a 1541. Double-sided disks are D71, not D64.

1581 - 3½", 800 kB, 80 tracks of 40 logical 256-byte sectors, CBM DOS 10.0, partitions and subdirectories, burst mode. MFM only, through a WD1770/1772: it has no GCR hardware at all, so it cannot read a 1541 disk. Images are D81.

This deck handles D64 only: disks from the 1540, the 1541, the 1570, and a 1571 in single-sided mode. D71 and D81 have different BAM and directory layouts.

Computers

ComputerYearBusDrives
VIC-201980serial IEC1540, 1541, 1570, 1571¹, 1581²
C641982serial IEC1541, 1570, 1571¹, 1581²
C161984serial IEC1541, 1551³, 1581²
Plus/41984serial IEC1541, 1551³, 1581²
C1281985serial IEC + burst1541, 1570, 1571, 1581

¹ in 1541 mode, single-sided. ² at DOS level only - no low-level block access, so fastloaders and copy-protected software do not run. ³ the 264 series' own drive: a 1541 mechanism on the parallel expansion port, several times faster. Same D64 layout.

All five machines use the same serial IEC bus. They differ in speed and in what host software can do with the drive beyond opening files.

Burst mode is a C128 feature: the 1570, 1571 and 1581 carry a CIA shift register that transfers a byte in hardware instead of bit-banging it. On a C64 or VIC-20 the same drives fall back to the slow serial protocol.

GCR and MFM

Both are run-length-limited codes: a floppy stores flux reversals, and a long run without one leaves the reader nothing to synchronise on. Each code bounds the run length at the cost of writing more bits than it carries.

GCR - Group Coded Recording, what the 1540, 1541, 1570 and the 1571's native mode use. CBM's variant encodes each 4-bit nibble as 5 bits chosen so no more than two zeros ever run together: 4 data bytes become 5 bytes on disk, a 25% overhead. The data is self-clocking, so no separate clock track is needed.

The 1541 pairs GCR with zone bit recording. The disk spins at a constant 300 rpm and the drive writes at a constant bit rate, so the longer outer tracks hold more sectors: four zones of 21, 19, 18 and 17 sectors. That is the D64 geometry, and why a 35-track disk has 683 blocks.

MFM - Modified Frequency Modulation, the IBM PC and CP/M standard. A clock bit is inserted between data bits only where the data does not supply an edge. Constant sectors per track, so no zones. The 1571 and 1581 get it from a Western Digital WD1770/1772 controller chip; the 1541 has no MFM hardware.

What a D64 is not

A D64 holds decoded sector payloads: 256 bytes per block and nothing else. GCR encoding, sync marks, header and data checksums and inter-sector gaps are not stored.

So nothing outside the standard layout survives in a D64: non-standard sector counts, deliberately bad checksums, half-tracks, long sectors, data in the gaps - most copy protection of the era. G64 stores the raw GCR bitstream per track and keeps it; this deck does not read G64.

The error table is the exception: it records the read result per block, so a deliberately unreadable sector survives as an error code, though not the cause of the error.

Sources