Commodore 1541

Commodore’s own specification gave the 1541 disk drive a data transfer rate of 400 bytes a second. A long program took two minutes to arrive. Yet the same specification sheet listed what was inside the box: a 6502 microprocessor running at 1 MHz, 2K of RAM and 16K of ROM. The drive was a small computer in its own right, sitting next to the C64 and doing nothing but running a disk.

That computer is the reason the 1541 is remembered. It was slow at its day job, but it would run any program the C64 sent it, so programmers rewrote the job. Fastloaders, disk copiers and copy protection all worked by putting new code inside the drive.

Fast facts

• Introduced: 1982, as the disk drive for the Commodore 64. It also worked with the VIC-20, SX-64, Plus/4 and C16.
• Processor: MOS 6502 at 1 MHz.
• Memory: 2K of RAM; 16K of ROM holding DOS 2.6.
• Interface chips: two 6522 VIAs (versatile interface adapters), one for the serial bus and one for the disk mechanism.
• Disk format: 35 tracks, single-sided, 683 sectors of 256 bytes; 664 blocks free on a new disk.
• Transfer rate: 400 bytes a second, by Commodore’s specification.
• Connections: two serial bus sockets, so a second drive or a printer can be chained on.

One processor doing three jobs

Commodore’s earlier drives, the 2040, 4040, 8050 and 8250, used three processors: a 6502 to talk to the computer, a 6504 to control the disk and a 6532 to translate data into the code that is written on the disk. Inside Commodore DOS, the standard technical book on the drive, puts the difference in one line: “The 1541 has only one 6502 to do everything.”

The 6502 shares its time between two roles. As the interface processor it talks to the C64 and manages files. About every 10 milliseconds a timer in one of the 6522s interrupts it, and it switches to being the floppy disk controller, which moves the head and reads and writes sectors. The two halves communicate through a job queue in RAM: the interface side writes a job code there ($80 read a sector, $90 write one, $B0 seek a track, $E0 run code in a buffer), and the controller side finds it on its next pass, carries it out and replaces the code with an error number.

Asking the drive a question

Commodore expected owners to look inside. The 1541 User’s Guide documents M-R (memory read), M-W (memory write) and M-E (memory execute), which work over the drive’s command channel. M-W sends up to 34 bytes at a time into the drive’s RAM and M-E runs them. Every fastloader starts that way.

M-R is the safe one to try. This program asks the drive for four bytes of its ROM, at $FED1 to $FED4 (209 to 212 is the low byte of the address, and 254 is $FE, the high byte):

10 OPEN 15,8,15
20 FOR A=209 TO 212
30 PRINT#15,"M-R"CHR$(A)CHR$(254)
40 GET#15,B$:PRINT ASC(B$+CHR$(0));
50 NEXT:CLOSE 15

It prints 17 18 19 21. Those four numbers are the key to the 1541’s disk format.

A drive that changes its own clock

A 1541 disk does not have the same number of sectors on every track. The outer tracks are physically longer, so the drive fits more onto them:

The disk always turns at 300 rpm. Inside Commodore DOS raises the obvious question: “you may wonder how Commodore manages to vary the number of sectors from zone to zone. This is accomplished by varying the rate at which data is read or written.” The drive divides a fast clock by 13, 14, 15 or 16 depending on the zone, so bits go onto the outer tracks faster:

The result is not perfectly even. According to the book, the outer tracks end up at about 4,300 bits per inch against 6,000 on the inner ones, but without the faster clock the outermost track would drop to about 3,500. The sector counts for each zone are the four bytes the program above reads out of the ROM: 17, 18, 19 and 21, stored inner zone first.

Where the 170K goes

Formatting writes 683 sectors, 174,848 bytes in all. Track 18 holds the directory and the block availability map (BAM), which leaves 664 blocks, “an effective storage capacity of 169,984 bytes”, and the familiar 664 BLOCKS FREE under a new disk’s directory.

Even that overstates what a program gets. The first two bytes of every sector in a file hold the track and sector of the next one, so each block carries 254 bytes of program. The DOS also spaces a file’s sectors out rather than writing them side by side: Inside Commodore DOS says they are “staggered in increments of 10”, and the directory in increments of 3. The gap gives the drive time to deal with one sector before the next one comes round under the head.

GCR: how the bits reach the disk

The 1541 never writes a byte to disk as it is. It splits each byte into two 4-bit halves and writes each half as a 5-bit code, so 8 bits of data become 10 on the disk. Commodore called this GCR (group code recording). The codes are chosen so that the recorded stream never has more than two 0 bits in a row, which keeps the drive’s read clock in step, and never more than eight 1 bits in a row. That leaves long runs of 1s free for a different job: DOS 2.6 marks the start of each sector with a sync mark of five $FF bytes, and nothing else on the disk can look like it.

Stock DOS does the conversion in software, one sector at a time. Fastloaders that decode GCR while the sector is still passing under the head are described in Disk Fastloaders.

Why it was slow

The 400 bytes a second has little to do with the disk. It comes from the serial bus between the drive and the computer, which moves one bit at a time under software control with generous timing margins. The fault goes back to a 6522 shift register that did not work in the VIC-20 era, and to the C64’s video chip, which stops the processor for long enough to miss a bit. Disk Fastloaders tells that story from the engineers’ own accounts and follows the protocol step by step.

The mechanism

Commodore fitted mechanisms from two suppliers, Alps and Newtronics, and its service manual covers both. A 12-volt DC motor turns the disk through a belt, with a tachometer holding it at 300 rpm. The head is moved by a four-phase stepper motor, and one step moves it half a track. The stepper can put the head in more than 70 positions across the 35 tracks, but Inside Commodore DOS warns that the head writes too wide a path for the in-between “phantom” tracks to hold data reliably.

A playground for copy protection

A drive that runs any code it is sent can also be told to do things the DOS never would. Inside Commodore DOS devotes a chapter to what publishers did with that: “disk protection involves the deliberate corruption of a given track or sector”, and a small loader checks that the damage is there before it runs the game. When it appeared in 1984, the book found a whole track with no sync mark (error 21) and a single sector with a bad checksum (error 23) to be the commonest. It also suggested that data written half a track out of line might be readable only by a special routine. The methods that followed are covered in Disk Protection.

The 1541 family

The 1571 answered two of the 1541’s limits at once. Its user’s guide promises “up to 339K storage capacity per disk”, double-density MFM disks for CP/M software, and a burst protocol for fast transfers in 1571 mode.

See also

• Disk Fastloaders
• Fast Loaders
• Disk Protection
• Action Replay
• Commodore 64
• MOS 6502
• Commodore