Why Was the Commodore 1541 disk drive so slow? 

@StarsManny, if I based my motivation to continue making videos on the number of views I get, I'd probably not bother making more videos. Positive comments from the few who do take the time to watch are what keeps me going. Thank you for watching, and thank you for the kind words!!!

Awesome memories! Thank you for sharing!

The defective C64 mainboards that were already manufactured could have easily been fixed with two small, short bodge wires during assembly. This was a standard practice back in the day, and several computers/consoles had similar but often more complicated fixes in place. What happened, I believe (based on facts), was that Commodore management was against the 1541 from the start, since the 1540 had been such a failure in sales. They were convinced that everyone would be using the Datasette with the C64 instead, so why throw good money after bad by fixing an issue with using the 1541? Just default to the existing transfer protocol (slowed down even more for VIC-II DMA), and release the product as-is instead of fixing it, since no one was going to buy the 1541 anyway. Of course, management turned out to be utterly wrong, but by then it was really too late to fix the problem in hardware, as the 1541 had lost its CIA chip, as well, as a result of this decision. Now, it wasn't really too late overall, and there is some evidence that Commodore did try to fix the problem with software, since the 1541, like all Commodore drives, is reprogrammable. They created an early fastloader that was used by EA in the game _Mail Order Monsters_ . It sped up the 1541's loading speed by about 3 times, which is better than nothing (about as fast as the Atari drives, out of the box, and faster than the 2031). This solution might have become widespread, but by then the industry had created better solutions, including the _Fast Load_ cartridge by Epyx, which sped up the loading of most things by about 5 times. Epyx also created the _Vorpal_ fastloader that was used with some of their bigger titles, such as _Winter Games_ and others in that series. _Vorpal_ increased loading speed by over 20 times(!), but only worked with the original disks, since it used a special format. If you played a pirated copy of this or other such games, then loading would have been slow. It's still too bad that Commodore didn't at least create a standard and universally compatible way for everyone to make fast disk protocols, but they were always moving on to the next computer, and just left everything to everyone else. 🙄

Thank you!! I absolutely intend to continue making content as time permits. I'm really glad that you enjoy it, so thank you for letting me know. That's really kind of you!

lol. I wanted to include the name and date of the newspaper in the top right corner, and the nude bathing article was there so... :)

This was because including a sensor for the hole would have cost more.

Thank you for the kind feedback!! I have an Oceanic drive also. Great device!

Oceanic was designed and manufactured by Evesham Micros, in the UK. They also made the Dolphin DOS that made programs load in seconds rather than 15 to 20 minutes. It was a small circuit that piggy backed onto the original DOS chip. Fairly easy for someone sensible to fit. I remember demonstrating it at a show in London. people just couldn't believe the speed, and I had to show the PSU unplugged and timed the switch on and load which was well under 1 minute. Oceanic was manufactured in Chai Wan, Hong Kong by an OEM manufacturer. It was a dig seller all over the world.

If the capability was there in the chips, but the traces were eliminated on the circuit board, would it be possible to enable it with jumper wires?

Mistakes were made. Someone might have missed something.

@@misterskippy2u Yes, of course, this problem could have been fixed with two small bodge wires, which was normal for back then, but Commodore management refused to allow that to happen because they believed that the 1541 would sell poorly, just like the 1540 did. How wrong they were! At least in North America and West Germany, but those were big markets.

It was - watch the follow-up video where I did more useful benchmark tests. Big miss on my part in this video.

One of the questions I specifically asked Bob Russell was if Commodore marketing demanded VIC-20 compatibility. He described the C64 as a skunk works project, indicating that marketing was not involved.

The VIA bug that made the VIC-20+1540 slow is more well known than the bug that actually made the C64+1541 slow later, but I'm glad that the word is getting out.

@@commodorehistory Marketing wasn't involved, but management was, and it was management who nixed the idea of easily repairing the defective C64 mainboards during assembly. All it would have taken was two small, short bodge wires, which was less than a bunch of other computers/consoles of that era had. The engineers weren't happy about this, of course, but management justified their decision by sticking to their strong belief that everyone would be using the Datasette with the C64 instead of the 1541, which as we would find out later, proved to be dead wrong. The problem still could have been fixed with software, since the 1541, like all Commodore drives, is reprogrammable (a rare, if not unique capability), and there is some evidence that Commodore tried to do just that. For example, they apparently created an early fastloader that was used by EA in the game _Mail Order Monsters_ (well, it says "FAST DISK LOGIC COURTESY OF COMMODORE BUSINESS MACHINES", so that's how I took it). It sped up the 1541's loading speed by about 3 times, which is better than nothing (about as fast as the Atari drives, out of the box, and faster than the 2031). This solution might have become widespread, but by then the industry had created better solutions, including the Fast Load cartridge by Epyx, which sped up the loading of most things by about 5 times. Epyx also created the Vorpal fastloader that was used with some of their bigger titles, such as Winter Games and others in that series. Vorpal increased loading speed by over 20 times(!), but only worked with the original disks, since it used a special format. So if you played a pirated copy of this or other such games, then loading would have been slow. It's still too bad that Commodore didn't at least create a standard and universally compatible way for everyone to make fast disk protocols, but they were always moving on to the next computer, and just left everything to everyone else.

awe man, this is the best thing I'll read all year. Thank you so much!!

Thank you George!

Yeah, I can’t imagine installing 1541 Flash as a teenager on a computer my parents bought for me that I couldn’t afford to replace.

Hey, thank you for the positive feedback!! I really appreciate it!

That’s a nice side hustle back in the day!

Copy protection did not harm the drives. The missing "track 0" signal did. E.g. every time the drive could not read a track, the drive did move the head to track 0 by moving a fixed number of tracks, causing the head to bang on the end stop.

@@MaPf818 You're right, partially. There were several copy protection schemes that used data on track zero to validate the disk as an original whenever the disk was accessed, thus the drive would go out of alignment. The same Disk validation was done on the ATARI systems but did not result in misaligned heads due to embedded software differences, although it did unnecessarily increase disk wear.

@@HughEchols You mix up the reason and the consequence. The reason for misalignment is the head banging on the endstop because of a missing sensor. Track 0 is not the endstop. Reading track 0 is no problem. To find track 0 is the problem and this was always a problem for these drives, even without copy protections. To be honest, I'm not sure why ATARI systems should be of interest in this discussion. Did they use similar HW or methods? If they are different, they are different. Using the same copy protection but not having the same problem would even prove the copy protection to not be the problem.

@@MaPf818 You're misreading what I'm saying. I'm agreeing the root cause was the hardware issue. It's just that those cp schemes caused the alignment issue to manifest quicker as it would rack the head unnecessarily. The ATARI, TI, and Tandy systems could survive it simply by different design in hardware and embedded software.

Exactly, my grandpapa have had C64 with 1541-II disk drive, it was serial bus, but Final Cartridge III have some turbo mode which helped, i used on my high school ZX Spectrum, because we was learning basically 8080/Z80 assembler and disk drive for ZX Spectrum D40 or later +D disk interface for ZX Spectrum 128k was parallel bus, probably 8-bit, so i loaded program or game in maybe 5 seconds. Now i have also C64 with 1541 Ultimate II+ mainly for chiptune music and loading time is ok, maybe 30 seconds of program like defMON.

It's not just about parallel versus serial, though. The Apple II's drives are pretty fast, and contrary to popular belief, their data connection is serial, not parallel.

@@rbrtck I DID mention the "very slow data rate" before the "serial bus". The various speed-up cartridges and programs for the C64/C128 (perhaps C16 as well, never had one of those) worked by increasing that rate.

@@bricefleckenstein9666 Indeed you did. My bad. But nevertheless, as you know, it is and always has been a popular myth that the C64+1541 were SO slow specifically because they used a serial bus. With the rare exception of parallel interfaces that required hardware mods (e.g. _DolphinDOS_ ), the vast majority of fastloaders were software only, of course, and simply implemented much faster data transfer protocols. Many of them were also 2-bit parallel instead of strictly serial, although they used the same IEC bus and hardware, and this alone cannot nearly account for their sometimes massive increases in throughput. This is just an elaboration on what you said. The protocols were very different, though, as seen in this video. As for the C16, Plus-4, and that whole TED/264 series of computers, they are compatible with the 1541 through their IEC ports, using the same slow protocol, but additionally have their own drive: the 1551. This has a parallel interface (probably 8-bit) that connects through the cartridge port, although the data transfer rate is surprisingly slow: only about 2.5 times or so faster than the standard IEC protocol. That's only half the rate of _Fast Load_ from Epyx, which was hardly the fastest fastloader for the C64. What a waste of a parallel cable! I swear, Commodore were so aggravating with this issue! I wonder what their excuse is for this. Maybe they didn't want it to compete with their CBM or B-series computers for business, I don't know. Anyway, if you have a decent fastloader on cartridge or through using replacement ROMs on the C64+1541, then you have much faster disk transfer than the TED series computers even with their parallel interface. I'm not aware of any fastloaders for those computers that work with the rare 1551, but there is a version of JiffyDOS for the Plus/4+1541 (through the IEC port).

@@rbrtck Wasn't the 1551 a carry-over from the PET drive in basic design, using the FULL standard IEEE-488 standard parallel port? Dunno why that would have been so slow, unless the interface cartridge was deathly slow for some reason.

Several folks mentioned this. I’ll try to put something together. Thanks for the feedback!

I have one 1541 with SpeedDos/DolphinDos, one with Turbo Trans RAM Disk and my very own first one (white ALPS drive model) with working solder connections since the 1980ies. Unusual (Especially when kids are soldering, hehe)! Right here to the left:) Have a look at the C64 Wiki, "Hardware Fast loader", section. Commodore History would definitely have to go into debt and some solutions have even disappeared. Also the truth we do not speak out loud here is that a SD-Card is probably the fastest, accessible, reliable and cheapest storage solution nowadays;) I wish you fun fellow retro freaks!:)

Commodore included a 6526 (or relative) in the 1571 and 1581

"What could have been" is what got me involved in the "Professional DOS" speeder remake a few years ago. I'm usually a ZX Spectrum (clone) person, but seeing the 1541 fly was one of my favorite exercises with Commodore stuff. It speeds up reading somewhere around the factor of 20 or 25.

Yes, that's exactly what "burst mode" is--the way the VIC-20 and C64 were supposed to have worked with their intended drives from the beginning, but could not due to different problems with the hardware (with the C64's problem being easily fixable, but management weren't interested because they incorrectly thought that no one would buy the 1541 anyway). In fact, the C64 can still easily be fixed if you were to solder a couple of bodge wires in the right places. Of course, you'd also need the right load routine/driver, since the KERNAL doesn't support this mode, and it can be found online if you look for it. For convenience, the VICE emulator emulates this hardware fix if you want to try it without modding any hardware. I've tried it with the driver software, and burst mode works perfectly with the C64 in VICE. There is no reason it shouldn't work if you were to fix the real hardware, which works the same way. The main caveat to all of this is that the 1541 doesn't operate in this mode, and there is no easy fix for that, but the 1571 and 1581 work with fixed C64s just fine.

I’ve read the screw hole story also. It may be true, but I didn’t explicitly ask Bob Russell and he didn’t mention it. He just said the traces were removed without his knowledge. Likewise, I started with a TI-99/4A and cassette, so I know what you mean :)

Well, it stands to reason, considering the known changes to the case design from the externally nearly identical VIC-20 case. Those two lines/traces would have had to be re-routed, but they were deleted from the design instead by mistake. They could have been fixed by a couple of bodge wires soldered to the board during assembly, but Commodore management did not consider this worthwhile, since they fully expected not to sell many 1541s anyway. Oops again (and again and again).

*could HAVE been

Thanks so much! I really appreciate you watching and taking the time to comment.

I apologized in the video for how repugnant my benchmark testing was. The BASIC program I used was fetching one byte at a time, which is about as inefficient as I could have gotten. Using reasonable benchmarking, it looks like the c64/1541 can transfer about 400 bytes/second. www.obliterator918.com/dtb/

@@commodorehistory Thanks. That puts it as more like a 3x instead of a 30x difference. But it's still slow, so your point is valid. I do remember hearing C64 people talk about how slow their drives were.

@@pfcrow absolutely, they were slow. I just horribly misrepresented how slow. My mistake. I have distinct childhood memories of staring at the Electronic Arts logo changing colors for what seemed like days while I waited for games to load when I was a kid :)

@@pfcrow Truth be told, the Atari disk transfer rate, out of the box with no hardware mods, is pretty slow, too (of course there are numerous mods to fix this). Floppy drives generally read bits off the disks at more or less 250 kb/s or so, which translates roughly into something like 25-30 kB/s. The BBC Micro (many of which only have 32 kB of RAM) and IBM PC (double density) effectively read disks at this rate, thereabout, while the Atari's effective rate, all things considered except for initial seek time, is around 1.2 kB/s. That's pretty slow, but still about 3 times faster than the C64+1541 out of the box. For some perspective, from my hand-timed measurements of sizable files being loaded, the Apple II's speed when running DOS 3.3 is about 2.2 kB or so, which is similar in speed to what Epyx's _Fast Load_ cartridge can do on the C64, and approaches twice the Atari's unmodded speed. Running ProDOS makes the Apple II's disk transfer rate about 3 times faster than with DOS 3.3 at 6.5+ kB/s, while Epyx's _Vorpal_ (used on _Winter Games_ and subsequent games in that series; original disks only, no pirated copies) reaches 9+ kB/s on the C64. This is all using standard hardware and the IEC port, no hardware mods. In the tests I've done, using optimum sector interleave, JiffyDOS, the most general and compatible solution to this problem, can reach as high as 3.7 kB/s, which for the C64 is pretty darn good, and I got similar results when I tried the "burst mode" (CIA chip hardware bit-shifter) in emulation on VICE (with the 1571, of course). The latter was the C64+1541's originally intended mode of operation, which is about 9 times faster than it ended up being, 3 times faster than a stock Atari drive, and more or less as fast as an Apple II drive (depending on the DOS used). And finally, the fastest modern fastloader on the C64 that I'm currently aware of (off the top of my head, anyway), which is _TransWarp_ , can reach speeds around 19 kB/s. This approaches the speed of the drive reading raw bits from the disk, as well as the effective speeds of the BBC Micro and IBM PC, all on the standard IEC bus. It can fill the C64's entire memory in a little over 3 seconds.

Fastloaders came along at least 3 years earlier in 1984, and the good ones more than tripled the effective speed. Some, such as _Vorpal_ (used on _Winter Games_ and later games in that series), were even 20 times faster. _V-Max!_ was also very, very fast; it was used, for example, in _Defender of the Crown_ . But these super-fast fastloaders, and many others, only worked on original disks. If you played a pirated copy, then you got the usual slow loading instead. All of these fastloaders were reliable. Commodore just didn't have the time to make something better in software when their hardware solution unnecessarily failed.

I appreciate the feedback. I did my best to simplify the technical bits with animations and such. It sounds like I can improve in that area, so I'll keep that in mind for the next video. I'm super happy you enjoyed it otherwise, though!

Did you happen to see the video I did about Epyx Fastload? ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-pUjOLLvnhjE.html

@@commodorehistory Yes I did after the fact. That Cartridge is a must have for any Commodore 64 user.

@WhoLover heck yeah I read this, and I am super grateful that you took the time to type some nice words at me! It's wonderful to hear that you're enjoying the content so far. Let me know how you like the other videos, and thank you for the kind comment!

I swapped out the power supply for a meanwell. I did an earlier video about it. It runs waaaaay cooler now and it’s a lot lighter!

Definitely, the Epyx Fastload was a game changer for me when I was a kid!

SuperSnapshot V5 is even faster.

The PET drives are WAY faster than this video makes them seem. The times in this video are greatly inflated by the test method used and are only useful for relative comparison and not as a benchmark of actual load times on any of these drives. I just modified the test program to create the same file but with a PRG file type. I then loaded it with the standard LOAD command from a 1541 drive and it took 40 seconds. I don't have a PET but loaded the same file on a PET in VICE and the 2031 drive took 15 seconds while the 4040 drive took 7 seconds.

I didn't realize JiffyDOS came out that early. Thanks for the info! I never learned about it until the mid to late 90s, but I've been using it ever since.

Hey, thanks for watching! I've not done any benchmarks on the MSD, but it's a real screamer compared to the 1541 when I connect it via IEEE-488.

I grew up with an Atari 2600 and loved it. I never experienced any of their 8-bit computers, but I absolutely believe you are speaking truth.

That sounds interesting. I'll see what I can do. Thanks for the comment!

I started out with a TI-99/4A also. Great memories :)

I mentioned in the video and in a few other comments that my benchmark tests were awful. Yes, the 1541 is slow, but it's nowhere near as slow as depicted in the video. Have a look at the follow-up video I made that shows more accurate benchmark tests: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-7SPr5S0eEYM.htmlfeature=shared

Have you tried the Backbit yet?

@@axemanracing6222 backbit? No I haven't even heard of it. I will look up but feel free to share info about it.

Sd2IEC is very slow w/o jiffydos.

Your hardware solution sounds really cool!!

@@commodorehistory Thanks. I remember that I originally threw together a very basic address decoding circuit using 5 chips (9 total) which didn't fully decode the I/O address, which meant that the ports were mirrored across several locations, but I later decided to put in more effort and figured out that by rewiring it, I could dispose of 2 of the chips and still fully decode the port address. If I remember correctly, I wound up using an 8-input NAND gate and two quad-XOR gate chips to decode 7 bits of the 8-bit I/O address, with (as I said) the lowest bit (A0) being used to select which port I was accessing. I have since looked up the specs for the GPIB/IEEE-488 bus and it used 8 bits for control rather than 7. So it worked out nicely that I had 8 bits for data and 8 bits for control. I think I put the data port at F0 and the control port at F1. I never did fully develop the software side as it should have had a timeout on error and instead would "lock up" on error, but resetting the system wasn't that big of a problem at the time so although I intended to change it, I never got around to it and the advent of IBM Compatibles more or less killed off "hobbying" computers.

Yeah, the socket solution would be better. I went by the 1541 Flash Instructions, which instruct to bend the pin: archive.org/details/1541-flash-disk-speedup/page/44/mode/2up

@@commodorehistory Thank you for clarification and a manual reference. Bending it out a single time doesn't look that devastating if you plan to leave it as is. Bending it back though ... :)

@@sanjyuu2298 funny you should mention this. After installing and removing 1541 Flash about 5 times, I broke pin 19 off the 6522. I should have listened to you! :)

@@commodorehistory The one who don't fail is the one who do nothing :) You can fix this chip if you have patience, grind away a bit of epoxy to reveal more surface of that pad and solder broken pin, use some wire to make joint stronger a bit or do anything you see fit, then put it where you're not going to pull it out again (although it shouldn't brake that fast). You can also try to solder it as is without grinding, but the joint will be weaker.

It doesn't appear as though there is any way I could replace content from this video. support.google.com/youtube/answer/55770 I did create a follow-up to address the misleading load times: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-7SPr5S0eEYM.htmlfeature=shared

I deeply regret releasing this video before going back to record realistic benchmark results. I linked a follow-up video in the description that has more accurate results. The BASIC program I used in this video was reading 1 byte at a time in a loop. It was as much a cpu benchmark as it was a disk IO benchmark. A stock C64 and 1541 are able to read a 15K prg file in about 41 seconds.

@@commodorehistory I did enjoy this video (and the next one -- which I watched right after it.) I'm just surprised that the drives are BETTER with fast load, which ever solution you use, but still crawl and drag significantly slower than the other systems of the times (8088 or Apple 6502.)

Yeah, a lot of folks mentioned that. I’ll see what I can put together.

You are correct, but neither the VIC-20 nor the C64 have a hardware UART :(

Nothing Commodore is outside the realm of possibility for future videos. Thanks for watching!

I did a follow-up: Update to my previous video on why the Commodore 1541 disk drive was so slow ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-7SPr5S0eEYM.html

Sorry that isn't clear. Yes, the shift register is in the 6522. I didn't want to label it 6522 such as to be clear it was a specific functionality of the 6522. But then I didn't want to label it 6522 shift register because I didn't want to imply the 6522 was only a shift register, as it had other built-in functionality.

Hah! I don’t think I ever saw that, or perhaps I just forgot, but that’s funny :)

You poor bastard! How did u manage! I feel for you.

Yup. Watch Andre Fachat’s video that I linked to in the description.

Indeed. It came in the original box with all original packaging.

@@commodorehistory I think I remember they were sold by newtek as an all in one ready to go package. Mines got the toaster card, gforce 030 accelrator, ad516, etc.

I mentioned in the video that the program I was using was not representative of what the drives are actually capable of. The BASIC program was reading one byte at a time, so I was benchmarking the cpu more than the drive. I posted a follow-up video showing more reasonable benchmark tests: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-7SPr5S0eEYM.htmlfeature=shared

Yes, I know you are reading one byte at at time. But these horribly slow times also probably means the buffer for sectors is located into the floppy controller RAM, another bad design decision. Anyway, thanks a lot for these interesting videos.

Hi. I appreciate all feedback, but what you're seeing in my videos isn't some act. I'm a 52 year old guy, not a kid, and this is how I talk in real life. I'm not a professional actor, and I'm certainly not a professional voice actor. I'm an IT guy who has an interest in the history of Commodore so I decided to make videos about it. I put tremendous effort into creating content. This video took me about three months of effort to research, record and edit. If you look at my oldest videos compared to this one, I think you'll see a lot of improvement, but unfortunately, my voice and speech patterns are just me. If I try to talk differently in my videos, I think it would be noticeable, disingenuous and insincere.

Yes, I re-used the animation I created for the VIC-20 earlier in the video. That said, I'm sure you know the 6510 is a variant of the 6502.

Because commodore wanted to vertically integrate. They had their own chip fab and wanted to supply their own chips where possible. Jack Tramiel had nearly been driven out of business by Texas Instruments just a few years prior when they relied on TI calculator chips and TI decided to enter the calculator market.

Now I wish I would have tested while I had it set up. My uninformed guess is that protection methods wouldn't affect it. I watched 1541 Flash using a logic analyzer and it retains all of the original Commodore IEC protocol, with the only difference being that it can shift bits faster. As to demos that rely on precise 1541 timing, I don't know enough about that to even make a guess.

​@@commodorehistory It just kinda blows my mind that Commodore wouldn't sell retrofit kits that would enable burst mode in a 1541 (and a bodge to replace the missing lines and/or maybe a new kernel for bidirectional high speed communication) unless there was some kind of compatibility reason not to do so.

@@iguanac6466 on one hand I agree. It seems odd that Commodore didn't capitalize on that market, but let other companies do so. On the other hand, they sold 12 million c64s, so they were probably too busy rolling in cash to care?

You can increase the speed gain even further to 25% if you send a "UI-" to the drive and disable the VIC II. (Send a "UI+" to reset it). Same speed increase when using a VIC 20 and you don't need to disable anything on that system.