Download: CBM_Disk_Transfer_Benchmark_1.1.zip (6 KB)
Version: 1.1 (Dec 23, 2021)

So, exactly how slow is a 1541 disk drive on a Commodore 64? And how fast is your favorite fastload cartridge? You can use this tool on your Commodore 64 to find out… plus or minus a decisecond.

In reality, there are a lot of considerations when it comes to Commodore 64 storage options. Compatibility, cartridge freeze options, convenience, and capacity are all as important as speed. Don’t forget that nostalgic feel of sliding in a floppy, typing load, and feeling the drive head bang around as it struggles with the copy protection. And once you get past JiffyDOS speeds, you probably won’t notice much difference as you climb the ladder squeezing just a few more seconds out of your load time.

But as a personal project, I decided I’d like to time save and load speeds as precisely as possible, so, I fired up Turbo Macro Pro, grabbed my copy of The Commodore 64 Programmer’s Reference Guide, Raeto West’s Programming the Commodore 64, and a Codebase64 article for good measure, and whipped up this little tool you see here. No more stopwatch apps on smartphones!

I’ll paste in some of the documentation below in case you are curious, but not curious enough to download the zip file. But first, let’s look at some data!

My testing methodology is simple. I load DTB up, pop in a freshly formatted floppy (or blank disk image when I use an Ultimate 64), and then run a SAVE test, and finally a LOAD test. DTB writes/reads a 44,956 byte data file, which uses exactly 177 blocks, and times the execution of the KERNAL save or load routine using the CIA Time of Day clock (properly initialized to the correct power mains frequency using this method). You should always start with a blank disk, to avoid inconsistencies in file layout skewing your results.

How about some results! All speeds were measured on an NTSC C64 unless otherwise noted. I used the Ultimate 64 to test DolphinDOS. The rest of the tests were done on real drives and original hardware.

[Update: I am keeping a comparison of transfer rates updated here.]

Load Speed

System	Load Bytes per Second	Load Time	DTB Load Score
1541	403	01:51.5	1x
SD2IEC	502	01:29.5	1x
1581	507	01:28.6	1x
1541 w/ Epyx Fastload	2121	00:21.2	5x
1541 w/ Warp Speed	3017	00:14.9	8x
1541-II w/ JiffyDOS	3746	00:12.0	9x
1541 w/ Super Snapshot 5	4163	00:10.8	10x
1541 w/ Action Replay 5	5352	00:08.4	13x
1541 w/ Retro Replay PAL 3.8q	5352	00:08.4	13x
1581 w/ JiffyDOS	6515	00:06.9	16x
SD2IEC w/ Epyx Fastload	7136	00:06.3	18x
SD2IEC w/ JiffyDOS	9175	00:04.9	23x
1541 w/ DolphinDOS (U64)	9366	00:04.8	23x

(Update: See this post for a comparison that includes Transwarp and Hyperspeed, and more comparisons on this page.)

Save Speed

System	Save Bytes per Second	Save Time	DTB Save Score
1541 w/ Epyx Fastload	342	02:11.5	1x
1541	370	02:01.5	1x
1581	749	01:00.0	1x
SD2IEC w/ Epyx Fastload	870	00:51.7	2x
SD2IEC	871	00:51.6	2x
1541-II w/ JiffyDOS	925	00:48.6	3x
1541 w/ Super Snapshot 5	1170	00:25.4	5x
1581 w/ JiffyDOS	1905	00:23.6	5x
1541 w/ Action Replay 5	2443	00:18.4	7x
1541 w/ Retro Replay PAL 3.8q	2470	00:18.2	7x
SD2IEC w/ JiffyDOS	2775	00:16.2	8x
1541 w/ Warp Speed	2900	00:15.5	8x
1541 w/ DolphinDOS (U64)	5352	00:08.4	15x

Further ruminations can be found in this blog post.

DTB Documentation

PURPOSE.

This tool is provided so that people don’t have to post Commodore 64 disk speed comparisons based on tapping the start button on their smartphone stopwatch app.

SCOPE.

DTB measures KERNAL SAVE and KERNAL LOAD routine execution time on serial devices 8, 9, 10, or 11. It reports speed in bytes per second and then provides a general “score” relative to a C64 and 1541 disk drive with original KERNALs.

METHODOLOGY.

A 44,956 byte data file (which uses exactly 177 blocks on a CBM DOS disk) is saved or loaded using a single call to the respective block transfer routine through the KERNAL jump table ($ffd8 for save, $ffd5 for load). This method allows comparison of fast loaders and the BASIC Load/Save functions.

To avoid incorrect timing due to redirected/disabled interrupts, and issues pertaining to PAL vs NTSC and 50hz vs 60hz power supply, the CIA real-time clock is used. DTB uses the method described here to initialize the speed of the CIA time-of-day clock which should work correctly on any C64.

The clock is reset to zero just before the JSR into the save or load routine, and its value is read immediately after it returns. The timing should be accurate to +/- 100 milliseconds or so.

USAGE

• F1 changes the device number, cycling from 8 to 11. The default is 8, regardless of which device was active when the program started.
• F3 executes a KERNAL SAVE benchmark on the selected device. If the data file already exists, it will be scratched before the timer starts.
• F5 executes a KERNAL LOAD benchmark on the selected device. The file must already exist. If you don’t have it, just do a SAVE first (F3). When the benchmark timer begins, the border color will change. It will change back when the timer stops. (The clock does not display until AFTER the save or load is complete.) Some fast loaders will also blank out the screen.
• F2 reads and displays the error channel of the currently selected device. If the device has not been used since it was powered on, this typically reports the firmware revision.
• F7 tests the time by resetting the time-of-day to zero and displays the clock until some other action is performed. You can press F7 again to freeze the display of the clock. This can be used to verify that the TOD was initialized to the correct frequency. (When the program starts, it will print the TOD clock frequency above the menu, which is usually 50hz for PAL and 60hz for NTSC, BUT NOT ALWAYS.) It should not be necessary to test the clock, but it can be used if you suspect the timing is wrong. Use a stopwatch app and start it at the same time as you press F7. If the time-of-day clock was incorrectly initialized, you should see the clock drift from your stopwatch within a minute or two.

METRICS

After the benchmark save or load completes, the byte count (always 44956) and the total time is printed. Also, DTB provides two useful metrics:

1. Bytes per Second (Bps), which is self-explanatory, and:
2. DTB Score. The DTB score is computed by dividing the measured Bps by the baseline Bps. The baseline Bps is a constant value which is simply the Bps rate of a C64 and 1541 drive with original KERNALs. So, the DTB Score is essentially “how many times faster than stock.” An unmodified C64 with 1541 and no fast load cartridge will score 1x.

BASELINE SCORES

As mentioned above, the baseline speeds are used to calculate the DTB Score of a save or load. I used an NTSC C64 and a 1541 disk drive, both running original KERNAL ROMs, with no fast load cartridge, on a freshly formatted disk.

• Baseline SAVE: 369 Bps (DTB Save Score: 1x)
• Baseline LOAD: 400 Bps (DTB Load Score: 1x)

Thus, a DTB Save score is the measured Bps/369, and a DTB Load score is the measured Bps/400, rounded to the nearest whole number.

CONSIDERATIONS

The Commodore 64 time-of-day clock is quite accurate, but the precision is limited to deciseconds (1/10 of a second). DTB takes measures to try to be as consistent as possible with timing (such as waiting for the clock to update immediately before starting the load or save), but still, 1/10 a second is fairly broad for a benchmark. Therefore, I didn’t bother to provide Bps fractional values or a fractional component to the DTB score. (You can calculate those yourself based on the reported time in deciseconds, if you desire.)

Also, mechanical drives have their own factors (such as where the read head is when an operation starts, etc). Some slight variation can be expected even when running multiple times on the same hardware, and speed can be affected by mundane variables like which tracks the file is stored in. That said, my experiments show that the bytes-per-second value is consistent enough to be reliable as a good benchmark, and the DTB score is an accurate-enough “how much faster is this than the original” metric. For real floppy disks or floppy images, I recommend you format the disk and then do a single SAVE and LOAD benchmark to get your scores.

RUMINATIONS

Of course, once you get to JiffyDOS speeds, a faster save or load speed is probably not as important as compatibility or cartridge freeze features. I’m not releasing this benchmark tool to advocate for any particular fastloader or KERNAL ROM. Your needs will vary based on what you are doing. The speed results DTB gives are as precise as possible given the hardware, but it’s just one data point to consider among many.

In case you are curious: As of now, the setup I use the most is JiffyDOS (KERNAL and drive ROM) on an Ultimate 64, using DMA load for most files, with an SD2IEC drive to use during assembly development. The SD2IEC paired with JiffyDOS provides a great file storage option as long as you don’t need true drive compatibility, in which case, the SD2IEC isn’t useful at all.

Enjoy!

VERSION HISTORY

1.1

• Fixed an incompatibility with Krill’s Transwarp loader that caused Transwarp to slow down the load. This raised Transwarp’s load score from 36x to 40x.