Disk Fastloaders

Commodore’s own service manual gives the 1541 disk drive a data transfer rate of 400 bytes a second. A long program of 202 blocks took just over two minutes to load: 128 seconds by Creative Micro Designs’ count, 2 minutes 12 seconds when Ahoy! timed one in 1988. Owners had paid for a disk drive and still got a wait close to tape.

The surprise was inside the drive. The 1541 is a small computer of its own, with a 6502 processor running at 1 MHz, 2K of RAM, two 6522 interface chips and the disk operating system in ROM. The slow part was the cable between it and the C64, and the way the two machines talked across it. Because the drive would run any code it was sent, a program could replace both ends of that conversation. That is what a fastloader does, and by 1988 Ahoy! could say that “most games had a built-in fast loader of some kind”.

For the wider picture across tape, disk and other machines, see Fast Loaders. This entry is about the C64 and the 1541.

Why the 1541 is slow

The drive was slow by accident, and then slow on purpose. Al Charpentier, who led the chip designers at MOS Technology, told IEEE Spectrum in 1985 that Commodore’s serial drive for the VIC-20 “is very slow because the serial-interface portion of the interface controller (the 6522) used on the VIC-20 does not work”. The 6522 had a shift register that could have moved whole bytes in hardware; with it broken, the bits had to be moved one at a time by software. Pasi Ojala later summed up the result as “the dead slow software-driven Commodore serial protocol”.

The C64 could have done better. Its CIA chips had a working shift register: “We fixed the serial-shift register for the 6526,” Charpentier said, “but we couldn’t use it, because the disk drive had to be compatible.” Then the new machine’s video chip made things worse. “Because the processor in the C-64 is turned off for 40 microseconds every 512 microseconds, it kept missing the interrupt signals that control the disk interface.” In Charpentier’s words: “The solution: slow the drive down even further.”

The stock protocol

Jim Butterfield explained the bus in COMPUTE! in July 1983. Data travels on two wires, CLK (clock) and DATA, and a third, ATN (attention), lets the computer call every device to listen for a command. Each wire is shared: a device signals “true” by pulling the line to 0 volts, and the line reads “false” only when every device has let go. Sending one byte goes like this (trace it; it is a description, not a program):

Start:  talker holds CLK true, listener holds DATA true
1. Talker releases CLK        "ready to send"
2. Listener releases DATA     "ready for data" (it may take as long as it likes)
3. For each of the 8 bits, lowest first:
     talker sets DATA to the bit, then releases CLK: "data ready"
     talker holds both lines steady: 20 µs, or 60 µs if a C64 is listening
     talker pulls CLK true and releases DATA
4. Listener pulls DATA true to acknowledge the byte, within 1 ms

The bits go out “without handshake”: the talker does not wait to hear that each one arrived, so the timing has to be generous enough for the slowest listener. Butterfield gave the reason for the C64’s longer hold: “the 64’s video chip may interrupt the processor for 42 microseconds at a time, and without the extra wait the 64 might completely miss a bit.” Those interruptions are the VIC-II’s badlines, when it stops the processor for 40 to 43 cycles to fetch a row of character codes. A pause after the last byte signals the end of the file: if the talker waits more than 200 µs, the listener treats the next byte as the last.

The bit timing is only part of the cost. At Butterfield’s figures of up to 70 µs to set up each bit and 60 µs to hold it, eight bits take about a millisecond. At 400 bytes a second, each byte takes about 2.5 milliseconds, so most of the time goes on the handshakes around each byte and the work each processor does between them.

The padding is built in, so turning off the screen does not help. In VICE’s x64sc, with true drive emulation of a 1541, a 202-block file took about 127 seconds to load through the standard KERNAL with the screen on, and about the same with the screen blanked (see the note at the end for how it was measured).

How fastloaders break the bottleneck

A fastloader runs on both machines. The C64 side sends a routine into the 1541’s RAM with the DOS M-W (memory write) command, starts it with M-E (memory execute), and the two processors then use a protocol of their own. Commodore’s user’s guide documents both commands; M-W carries at most 34 bytes at a time, so the drive code goes across in a series of short pieces. The rest of this section follows the Codebase64 wiki’s description of the techniques today’s loaders combine.

Two bits at a time

Once both ends run custom code, CLK no longer has to act as a clock. A loader can use CLK and DATA as two data lines and move a pair of bits in each step. Something else then has to keep the two machines in step.

Working around the VIC-II

The simplest answer is to remove the badlines. With the screen and interrupts turned off, nothing stops the C64’s processor, so it can count cycles and stay in lockstep with the drive. It still has to resynchronise now and then, because the two clocks differ: on a PAL machine, the drive’s 1 MHz clock runs slightly faster than the C64’s. Magnum Load, a replacement KERNAL ROM, contrasted itself with the cartridges in its 1985 advertising: “Unlike the older cartridge fast loaders … the screen is not blanked during loading.”

Games and demos that want a picture on screen, or music playing, while they load need another answer. Early “IRQ loaders” started each transfer at a chosen raster line ($D012), where no badline could interrupt it. The later 2-bit ATN protocol hands control to the C64. The C64 toggles ATN for each pair of bits, which tells the drive to put the next two on the bus. The bits wait on the lines until the C64 reads them, so an interrupt or a badline in the middle of a byte does no harm. The cost is that no other drive can be active on the bus, because every device responds to ATN.

Whole sectors, decoded on the fly

The 1541 records data in GCR (group code recording), which stores every 4 bits as 5 bits on the disk. Stock DOS reads a sector, decodes it and then sends it byte by byte. Fast loaders move a whole 256-byte sector in one tight loop. The fastest decode the GCR as the sector passes under the head: according to Codebase64, the Booze Design loader and Spindle decode a sector completely in flight, while Krill’s loader and Bitfire decode most of it and tidy up afterwards, which saves drive RAM for other features.

Out-of-order loading

Stock DOS follows a file’s chain of sectors one link at a time, and often has to wait for the next sector to come round under the head. An out-of-order loader spends one revolution scanning the track to find which sectors belong to the file, then reads them in whatever order they arrive, and the C64 side puts them back in order. With a fixed interleave (the spacing between a file’s sectors) the scan can be skipped and the two link bytes in each sector used for data. The price is a disk format that only that loader can read.

Decompressing while the drive reads

While the drive fetches the next sector, the C64 has time to spare. Modern loaders use it to decompress the data that has just arrived, so a file can be stored packed on disk and unpacked as it loads.

Parallel cables

The most direct fix bypasses the serial bus. Ahoy! reviewed several such systems in April 1988. Dolphin DOS, from Micro Accessories of South Australia, equipped “a C-64 and a 1541 disk drive with a full 8 bit, high speed parallel interface”. It loaded a 100-block program in under three seconds, which Ahoy! put at 20 times the standard speed. Fitting it was serious work: a circuit board replaced the drive’s 6502 and 6522, a ribbon cable ran out of the drive to the C64’s user port, and a new KERNAL ROM went into the computer. It fitted only the short-board version of the 1541, and the C64 lost the use of its cassette recorder. RapiDOS, from Chip Level Designs, used a new drive ROM, a replacement 6522 and a parallel cable; Ahoy! timed a 202-block file at 15 seconds.

In the UK, Trilogic advertised its software-only Rocket loader as comparable to “complicated, expensive hardware systems like Dolphin DOS or Professional DOS”, as Commodore Disk User reported in July 1988. JiffyDOS was sold against the same systems: its advertisements stressed that it “DOES NOT require add-on cable or any hardware between computer and drive”.

Burst mode on the 1571 and 1581

Commodore fixed the problem itself in the 1570, 1571 and 1581 drives made for the C128. Their “burst” mode used a synchronous serial protocol, with the bus’s unused SRQ (service request) line as its clock. Pasi Ojala put the gain at “ten-fold”. Craig Bruce found the burst Fastload command about 3.5 times faster than reading files through the KERNAL and DOS on a C128. A C64 can use burst mode too: Ojala’s loader needs two wires, from SRQ and DATA on the serial bus to the clock and data pins of a CIA’s serial port.

How a cartridge fastloader takes over

A fastloader cartridge is just ROM on the expansion port. It does not change how the C64 loads. It changes where the KERNAL goes when a program calls LOAD. The KERNAL’s LOAD routine jumps through a vector in RAM, ILOAD at $0330–$0331. A cartridge points that vector at its own code, so an ordinary LOAD"NAME",8 runs the cartridge’s routine. That routine sends its drive code over with M-W, starts it with M-E and then receives the file using its own protocol.

A game with its own loader never calls LOAD after the first file, so it runs its own fast code whether a cartridge is fitted or not. Replacement ROMs such as JiffyDOS and Dolphin DOS work differently: they replace the KERNAL itself and add new code to the drive’s ROM, so nothing has to be uploaded.

Notable C64 disk fastloaders

Most speed figures from the period are makers’ claims. The Magnum Load and Ahoy! figures are the exceptions: Magnum Load’s were measured by a rival, Ahoy!’s by reviewers.

Compatibility

Speed came at the cost of compatibility, and the period’s advertising shows which way the risk ran. Epyx promised that Fast Load “works with most programs, even copy protected ones”, but its rival’s comparison chart found one program that would not fast load and one that failed to load at all. The Final Cartridge claimed 98 per cent of programs and advertised its on/off switch as the part “we hope you never need”. CMD offered JiffyDOS as “Guaranteed compatible with all software & hardware”, and still supplied a switch back to the stock ROMs.

Disk protection is the usual suspect, since Epyx singled out “copy protected” programs, though the Magnum Load chart does not say why its two failures failed. Hardware was the other risk. Drive code written for a 1541 relies on that drive’s memory map and timing, which is why the advertisements list the drives they support: Datel named the 1541, 1571, Oceanic and 1581; CMD sold JiffyDOS ROMs for Commodore’s drives and for third-party ones such as the MSD, FSD, Excel 2001 and Enhancer 2000. The parallel systems needed the right board revision; Dolphin DOS did not fit the original long-board 1541 or the 1541C.

Modern equivalents

Fastloaders are still being written, and modern drive replacements have had to deal with them. The sd2iec firmware, which puts disk images on an SD card behind a serial-bus connector, has no 6502, so “anything that tries to execute code on the 1541 will not work, this includes every software fastloader”. Instead it watches the M-W commands, recognises the drive code of known loaders (Turbodisk, for example, “is detected by the CRC of its 493 byte long floppy code and the M-E address 0x0303”) and runs its own equivalent. The 1541 Ultimate cartridge, available since 2008, takes the other route: it recreates the drive’s hardware in an FPGA, so uploaded drive code runs much as it would on a real 1541.

New demos and games mostly use Krill’s loader, Spindle or Bitfire, which combine the techniques above: two-bit transfers that survive badlines, GCR decoded in flight, out-of-order sectors and decompression while the next sector is read.

See also

• Fast Loaders
• Cassette Loading
• KERNAL I/O Routines
• Commodore 64
• Commodore 1541
• CIA 6526
• VIC-II
• Disk Protection
• Jim Butterfield
• COMPUTE!
• C=Hacking