Why Was the Commodore 1541 disk drive so slow?

[@StarsManny]

Videos like yours are the main reason why I don't watch tv any more. Seriously, the production quality and entertainment value are top notch. 5 stars! ⭐⭐⭐⭐⭐

[@commodorehistory]

@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!!!

[@8-bitwallofdoom]

I was living in Berkeley, CA during college years and met Bryce Nesbitt (inventor of 1541 Flash!, he later went on to work at Commodore and the Amiga) and Bob Skyles at a Commodore Users group which took place at the Lawrence Hall of Science. I bought one that evening. Bryce was over my place a few times and gave me a custom ROM for my 64, and an assembler that he ended up wiring (which smoked the Commodore Macro assembler that I had been using). Skyles later went on to develop QuickSilver, an IEEE cartridge port interface that I used with an SFD-1001 that was purchased from "Protecto Enterprises" when they were blowing them out. Thank you for that reminder and kudos for a great video series.

[@commodorehistory]

Awesome memories! Thank you for sharing!

[@boredwithusernames]

Please don't give up posting these videos, they are well researched and very well put together with quality narration. I was aware that the via chip had a bug but you have clarified _and_ demonstrated that bug so that I now fully understand it. Thank you, please keep these videos coming 👍

[@commodorehistory]

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!

[@BlueBarnTech]

That was a fantastic deep dive, really appreciated it. I feel like 10 year old me just learned why I was so frustrated 30+ years ago. Amazing story.

[@kevinfisher5492]

Very informative. It is a real pity that Commodore didn't issue a fix for the 1541 speed issue. The 1541 Flash certainly showed it was possible.

[@rbrtck]

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. 🙄

[@realrealqbok]

"State permits nude bathing!"

[@commodorehistory]

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... :)

[@markbanash921]

A friend of mine was doing his Master's in computer science at Colorado-Boulder and he bought a C64 because he said it was the most inexpensive machine that you could buy that you could still do real computing with. But that 1541 drive drove him nuts. Thanks to your video I now understand why.

[@markpitts5194]

Just found you. Here to stay! Please keep going. You have a good voice for this. Soothing but engaging.

[@commodorehistory]

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

[@stupossibleify]

Great video, enjoyed every minute. I never really noticed the speed frustrations of the 1541, mainly because owning a floppy drive came much later after years of enduring the C2N tape machine. By which time most software was optimised with turbo loaders, either software or ROM-based, so the disk drive felt blistering fast for someone with a low bar! Incidentally, I had one of the many clones: the Oceanic, which was such a joy in operation and aesthetics.

[@commodorehistory]

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

[@brianjonesg8aso403]

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.

[@DSP107]

Thanks for the video! The CBM history is soo plagued with gossip & myths, that this kind of content worths a lot! Neither I did know anything abiut this VIA flaw! And what. Incredible is how they managed to make things not even half-better with a NEW processor, a NEW CIA, and a NEW system design!! Also without the constraint of backwards compatibility!!! I can't Imagine the success of the machine the C64 was intended to be, without all the "bad luck" it found in it's path! Anyway, thanks again, and I hope to hear from you again!

[@JeffTiberend]

I love videos like this. They help me learn more about the computer I used and loved in the 80's. At least till I got to mess with a relative's Mac Plus.

[@GeorgesChannel]

Great videos lately, Dave! Keep them coming :)

[@commodorehistory]

Thank you George!

[@MurderMostFowl]

This video was far more interesting and entertaining than I thought it would be. Thank you! I also loved that you included some original list prices. It’s hard for me to comprehend those prices even though I’m gen X and was very familiar with mid 80’s computer prices. Just astonishing… about $6k in current dollars for the 2040. Wow!

[@commodorehistory]

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

[@clovislyme6195]

I wrote an entire course of lecture handouts using C64 Easy Script and the 1541. As you can see, I lived to tell the tale, but it was touch and go at times. Here in the UK at least there was a book on programming the 1541, I worked my way through it, The author dedicated it to "My 1541 drive, may it rot in Hell."

[@GrandpasPlace]

Wow that brings back memories. One of my first computers was a C64 with the 1541 drive. I used to say, you start a game loading then go make lunch, after eating lunch it might be done loading the game. lol I used to mod my 1541 with a chip socket, flat ribbon cable and a connector to the cartridge port. I know I dont have the mod instructions any more but it would speed up loading and saving so you could copy a game in 4 disk swaps.

[@radekhn]

I knew this story in parts. I think Bill Herd spoke about it or wrote in his book, or maybe I read article on the internet. However you nicely put the most important facts into one video so all the details are there. Thank you. When I was young, I .... happen to be Atari guy. There was not many chances to get any microcomputer back in then in my country so I was happy for anything I could get. You know the Atari has its SIO which in fact uses standard UART communication. When I first start interest myself in how C64 is working, I mean the IEC bus. It was like hitting the wall at full speed. That bit banging protocol is a real nightmare. Just a little piece of serial, if running at 9800 Bd that's one KiB per second (roughly). That will "turbo" the IEC in the sky. I really feel pity for the engineers who faced incredible unlucky with that series of "bad events" leading to the slow IEC.

[@TastyBusiness]

Cool! Never seen that particular disk drive speed improvement before.

[@martythomas2383]

I had a C64 in my teens. I had three disk boxes full of copied games. They were all double sided with the notch cut out by scissors. Weekends spent typing in programs from computer magazines. My favourite games were M.U.L.E., Dragonriders of Pern, Racing Destruction Set and Ghostbusters. I think GEOS was incredible, especially compared to modern desktops I loved the banging noise on the 1541 and the music. Great times.

[@tarstarkusz]

22:40 The problem with this is these problems can be at least partially overcome. Fast loaders did a pretty good job at speeding up the 1541. The 1581 had all the same problems and was every bit as slow as the 1541 hooked up to a 64 or a 1571 in 64 mode. But I have a fastloader for the 1581 that can load a 50k program in about 9 seconds.

[@ApoplecticDialectics]

OK I've never heard of or seen a 2031. It has the heavy metal look of Apple // floppies. That is cool. This is a great channel. Stick with it.

[@commodorehistory]

Thanks for the kind feedback!

[@GeorgeStyles]

would love to see how this compares to software solutions like the action replay "backup" loading. I dont recall it being 3 mins plus to load an entire a++ game of the era from a 1541. Also a technical video about how software fastloaders in this style of video would be a priority watch from me. Great video - thank you

[@ExtendedJet8]

Fascinating video. Honestly I'm surprised the 1541 Flash! wasn't a little faster than it turned out to be. It would be interesting to see it compared to a more common and much simpler accelerator, like an Epyx Fastload.

[@commodorehistory]

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

[@HeatedFireFly]

Thanks for the video, a lot of time and work put into it. Can you use the same Flash 1541 on the SX-64? I have all my old equipment but not the room to enjoy them. My SX-64 is here but the software was packed away by the insurance company. The a long story there. I still not in my own place. Caring for someone else. But watching your video gives me flash backs to my younger days. At C.O.M.P. Computer Operators of Marysville and Port Huron. The 80's were a lot of fun. Did the 8-bit and Amiga computers back in the days.

[@Mr_ToR]

Whe you make your next floppy performance compoarison video, could you please also include to your comparisons proper parallel mods for the 1541/c64 like the Dolphin dos, Thomas'/8-Bit Resurgence's (Tri-Logic Phantom) parallel interface or ZoomFloppy/Burst nibbler etc. Thnx

[@Frietsk]

cool video, indeed nifty and fancy put together!

[@garybob4]

i remember that gcr encoding deal; i think it was a scheme to handle sync marks to be written on the disk, as opposed to the synchronization being done with a physical hole on the disk using a photo transistor creating sync pulses. the gcr was some crazy scheme that took 8-bit data and converted that into 10-bit data so that the binary value would not be able to have enough consecutive 1's - which might be misinterpreted as a 'sync mark' by - i think it was a hardware sync detector. this crazy scheme had to convert all the 8-bit 'normal data' into 10-bit gcr code which was then written to the disk, then the process was reversed when reading the data. not really sure why they didn't just use the hole punched on disks, which was there for this very reason.

[@rbrtck]

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

[@WhoLover]

Hey man, dunno if you will read this. I'm loving this video so far as it's the first I've watched from your channel. I've subscribed and turned on notifications, because you make really good and thorough content that is fun and interesting, not laborious and lecture-like. You're awesome and keep it up!

[@commodorehistory]

@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!

[@bw6378]

I had one of the flash kits. It was kinda scary for me as a kid to go in and bend pins on that super expensive 1541. lol Alas most of my commodore stuff didn't survive the decades and multiple moves. Thanks for the video and memories!

[@commodorehistory]

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.

[@oidpolar6302]

That is why very important to leave a warning notes right in the design documents to avoid any "production optimisers" involved in the defects adding

[@misterskippy2u]

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?

[@rbrtck]

Mistakes were made. Someone might have missed something.

[@rbrtck]

@@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.

[@BG101UK]

It would be great to see one on how the (parallel?) Dolphin DOS and the serial fastloader cartridges e.g. Freeze Machine, Action Replay worked (with really quick read AND write), if you haven't already and are willing to do so. Maybe something on JiffyDOS? I'll have to look through your other videos. I certainly enjoyed this one.

[@HughEchols]

Wow, the memories. Back when the 1541 came out I bought a calibration disk from the back ads in COMPUTE! Magazine for $10. The local Commodore shop hated Disk Drives because they went out of calibration regularly due to the way copy protection on the Commodore would beat up the drive heads. They paid me $15 each for the calibration and I did 5 to 10 a week. Put some nice change in my pocket.

[@commodorehistory]

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

[@MaPf818]

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.

[@HughEchols]

@@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.

[@MaPf818]

@@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.

[@HughEchols]

@@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.

[@junker15]

Welp this dispels the myth that CBM Marketing demanded the 1541 be compatible with the 1540, and that's why the 1541 was slow. I didn't know about VIA bugs...

[@commodorehistory]

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.

[@rbrtck]

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.

[@rbrtck]

@@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.

[@paxwebb]

I always knew the 1541 was slower than the 1540, but I remember hearing it was slowed down deliberately because the C64 couldn't handle the transfer "speed" of the 1540. I always wondered how it was possible the Vic20 had faster I/O than the C64 lol

[@rbrtck]

@@paxwebb We have to be very careful about the context of what we're discussing. At the moment, we're discussing the data transfer rates of these devices when used straight out of the box, and *only* this. Both the VIC-20+1540 and C64+1541 use basically the same slow data transfer protocol, except that when it was first used in the VIC-20, there was no consideration for any cycles being "stolen" from the CPU by the graphics chip. When the C64 later had its own different problems and had to resort to using the slow protocol, the cycles that the VIC-II stole had to be compensated for, and this was done in a way that slowed down the slow protocol even more (by about 10-12%). Neither of these cases was expected, and none of this should have happened, but it did, and Commodore *management* didn't care about fixing the problems (had to go through them for the funding).

[@halnovemila9698]

Amazing video! so informative! ❤funny how it ends! 😅 many kudos to you Dave! it really takes a lot of work, time, dedication and rehearsal to make a good video like you did. 💪💪💪👏👏👏

[@commodorehistory]

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

[@dcarlin3]

Thank you for the video! Never knew there were TWO shift register issues - the 6522 bug, and then the missing traces for the 6526. The missing traces seems like classic Commodore to me! And the "what could have been" portion of the video was really interesting, shame we couldn't have had that performance back in the day. I'd love to know more about how "burst mode" works on 1571/1581 - did Commodore finally get the shift register going?

[@8bittimes]

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

[@1337Shockwav3]

"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.

[@rbrtck]

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.

[@benjaminnice]

Awesome vid, more detail on the bugs I read about then showing what could of been.

[@bierundkippen720]

*could HAVE been

[@carminone]

The sound at 8:41 scared me to death LOL.

[@97channel]

When I first learned through the internet that the 1541 drive was notorious for being slow, it took me by surprise. Because my experience as an owner was of it being lightning fast, commercial software would typically load in around seven seconds. My C64 was preowned, and it came with a huge stack of pirated games on disks. It also came with an Action Replay cartridge. All of the disk software had been copied using the Fast Load feature, and the only way to load the copies was by using the loader on the cartridge. I never once loaded from disk without it, as I never owned any authentic copies of software on disk or ones created without the Action Replay cartridge. I bought all my genuine copies of software on cassette, and would often copy them over to blank disks using the cartridge so that I could load them up in way under ten seconds. I've never actually seen it documented, that the Action Replay cartridge could facilitate loading of most typical C64 games in around seven seconds. I feel like I'm the only person to have ever experienced it, but I know there must be thousands, possibly into the millions, of others who loaded software this way. So for me, the 1541 drive was the polar opposite of slow. It takes longer for my laptop to boot into Windows, than it ever did for me to load from disks on the C64.

[@stephenwhite506]

Nice video. It would be interesting to also see how the software solutions (eg JiffyDos, action replay etc) compare in that table. Also, hardware parallel solutions like the Phantom etc.

[@commodorehistory]

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

[@dieSpinnt]

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!:)

[@dougjohnson4266]

Still better than tape. Thankfully for JiffyDos and other fast loaders for the C64 + 1541.

[@mikecook317]

man! I enjoyed this video! I didn't follow all the technical stuff but that's ok this was still really interesting to me. I see the MSD dual drive in the background, i used to drool at the thought of having that but I was 15 and I could barely afford the blank disks. Anyway, it might be interesting to run the benchmark on a C64/PET drive combo with a parallel interface. I'd love to see that MSD or 8050 or something similar in action.

[@commodorehistory]

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!

[@bricefleckenstein9666]

1:36 Ah, the old MSD SD-2. I had one on my BBS for a long time, wore one of the drives out, could not find a TEC to replace it with so had to go with an louder (but last as long) TEAC instead. NOT the same company or drive - the TEC (Tokyo Electric) drives were only sold to OEM manufacturers, could not be found on the end market - quieter than a TEAC but comparable longevity.

[@Explore531]

hello im really big fan on the Commodore 64 but I was wondering did they made LT. Kernel Hard drive for that too its has 20 megabyte

[@commodorehistory]

Lt. Kernal was a really amazing device for its time. It's not mentioned in this video, however, because it wasn't made by Commodore.

[@bricefleckenstein9666]

The 1541 by default had a very slow data rate for it's serial bus interface. There were quite a few add-in cards, and at least one software method, that would increase that data rate to 10-25 times faster - at the cost of some compatability at times. And no, I didn't have one as a kid - I'd already served a tour in the Navy and gotten out by the time the 1541 and the C64 were created.

[@Martin_Demsky]

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.

[@rbrtck]

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.

[@bricefleckenstein9666]

@@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.

[@rbrtck]

@@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).

[@bricefleckenstein9666]

@@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.

[@mindbenderx1174]

I thought Peddle would Live forever, I don't think he gets the love he deserves, he's sorta the Telsa to Edison of the Electronic world.

[@nicholas_scott]

Great video. I heard the serial lines were omiitted on the C64 because of the location of screw holes, and basically a miscommunication between the team members. I remember trying fast-load carts back in the 80s, and they didn't really make much of a difference. But, truth be told, I got my C64 after havng a TA-99/4a with a TAPE DRIVE...so the 1541 seemed like light speed to me.

[@commodorehistory]

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 :)

[@rbrtck]

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).

[@DJOzYBoY]

thanks for the vid I subbed and wish you good luck from another youtuber

[@commodorehistory]

Thanks man, I appreciate that. I’ll sub right back.

[@larryg2320]

The video, starting at 12:29 , shows MOS6502. Is the shift register the 6522 ?

[@commodorehistory]

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.

[@marizuokereke7347]

Great detective work! Thanks for explaining this. It was so weird that we could load faster from cassette than from floppy 😂

[@lurkerrekrul]

The fastest software-only loader I ever saw was the Epyx Vorpal loader, although I'm pretty sure that other companies had their own version of it. It used a special format, but games would load in literal seconds. Epyx released a software package that would allow you to convert single files to this format, so that they would load at the increased speed. A later version of the Super Snapshot cartridge came with a utility disk, which allowed you to do essentially the same thing. I used these a few times for some of my most used files, but I never used them for everyday usage, because you couldn't copy the converted files with anything other than the programs themselves. I liked the extra speed, but disliked that they weren't normal files.

[@raulrrojas]

I have a cartridge called fast load, very popular here in Argentina. Thaught you was going to mention about it, because it accelerates quite much the reading time. Cheers¡

[@commodorehistory]

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

[@bierundkippen720]

SuperSnapshot V5 is even faster.

[@michaeldavison9761]

Interesting video and I note you have a separate 5v and 12v supply in the 1541. I had to do a similar modification when the mains transformer failed O/C in my 1541(240v UK model).

[@commodorehistory]

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!

[@MrHowlinAlan]

Great video, well done!

[@winstonsmith478]

Also, FCC RFI emission standards for home devices. Agree 100% with your T-shirt.

[@DugB0915]

could you do a video on how the Vorpal utility kit from Epyx worked? I always found that amazing at how fast it was without any hardware modifications. Granted you had to convert the disks from regular to Vorpal...but it was amazing.

[@commodorehistory]

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

[@CJWarlock]

Very interesting topic. Thanks for the video. :)

[@davesherman74]

Oh yes, I still have my C64 and 1541. You know the drives were slow when Flight Simulator put up a 2:00 timer to let you know how long to wait for it to load.

[@commodorehistory]

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

[@pfcrow]

It would be interesting to show the effective data rate. 15K is 15*1024*8 bits. The stock 1541 speed you measured is (4*60+22.60) seconds. That works out to 468 bits per second. Adjust to 10 bits per byte, as there's typically some signaling overhead, and it's 585 bps. Now to put that into perspective, the Atari SIO port ran at 19.2K, which is over 32 times faster! Real performance is a bit slower as it spends time waiting for the drive to read each sector before doing the transfer. And the Atari would have run even faster, but the engineer designing it was using a line analyzer that couldn't run at faster speeds. Atari's last drive bumped the speed up when running DOS XE, but that was really late in the commercial life of the system. I had always heard that the Commodores were slow, but I never knew just how bad it was.

[@commodorehistory]

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/

[@pfcrow]

@@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.

[@commodorehistory]

@@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 :)

[@rbrtck]

@@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.

[@nutsnproud6932]

I had a c64 as a boy and it took a year of paper rounds to save for a floppy drive. What a disappointment.

[@sanjyuu2298]

Would be more safe to use a DIP socket in between with one pin removed than bending out the physical pin. Quite a contraption that 1541 Flash is, for such modification though, i would expect more speedup than one minute (i wonder what clock frequency is used on IEC bus). Would be nice to check if the disk should be formatted with different interleave with 1541 Flash installed, so maybe it could gain few seconds.

[@commodorehistory]

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

[@sanjyuu2298]

@@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 ... :)

[@commodorehistory]

@@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! :)

[@sanjyuu2298]

@@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.

[@RollerCoasterLineProductions]

You think commodore is bad? My first PC was a TI994A w a tape drive. I got a C64 and 1541 for Xmas and that was a welcome improvement, eventually I got an Epyx fast load cartridge and that really sped things up.

[@commodorehistory]

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

[@be236]

Just found your channel... can you do similar videos for the Commodore 1571 and 1581 too?

[@commodorehistory]

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

[@bricefleckenstein9666]

0:56 The 2040 and it's PET used the full IEEE 488 parallel bus for it's interface, not the "cut down serial version" the C64 used. Of course it was faster!

[@baconsledge]

I loved the hammering copy protected software used to try to destroy the drive.

[@HardDriveGuruOfficial]

I feel for Bob Russell, seriously. Hopefully his bad luck streak eventually stopped!

[@RandomBitzzz]

I can't believe I'm just barely coming across your channel. This is good stuff! I saw that you have an MSD drive in your collection, and IIRC it has an IEEE 488 interface on it. Have you done any benchmarking on an MSD drive attached to a C64 via an add-on IEEE 488 interface? I've always wondered how fast this drive could've been with a better interface than the slow serial one on the 64.

[@commodorehistory]

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.

[@sideburn]

I see you’ve got a Video Toaster (label branded on front of an Amiga 2000) on the rack. I’ve got one as well but that’s the first one other than mine that I’ve seen.

[@commodorehistory]

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

[@sideburn]

@@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.

[@paulstubbs7678]

Interesting list of calamities, however how do the various fast loaders compare, and what tricks do they use? Something for a follow up vid?

[@commodorehistory]

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

[@garbo8962]

I purchased a Commodore 64 with a 1541 disc drive for my son but had a few games for myself. Slowest one you had to insert the first disc then after 8 to 10 minutes remove it then insert a second disc. Took over 22 minutes to load my game. I would come after midnight after working 14 hours and while growing a beard waiting for disc to load up would often fall asleep. Had the worst color ribbon printer that you might have been able to print out 11 color pages. After we had the POS printer a couple if years it got harder & harder to purchase color printer ribbons for them.

[@Vile-Flesh]

I remember the God awful loading times and some games took longer than others to load. Zaxxon and Floyd of the Jungle took FOREVER to load.

[@SvdSinner]

Are you saying my childhood fantasy of upgrading my Vic20's tape drive to a disk drive may not have been as good as I imagined?

[@scottlarson1548]

Less than ten years later I owned a modem that could transfer data faster than the 1541. It's also funny to me that while the 1541 had essentially another computer in it Ohio Scientific computers (which I used) were using floppy drives as little more than fast 40 track cassettes controlled by the CPU.

[@EmperorKonstantine01]

1541 Hardware and software Hacks came in around 1987 not many people new about douibling or tripling the speed. The data bit Speed of tranfer was standard to prevent parity or software errors, a simple manufacturer default.

[@rbrtck]

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.

[@ScottyBrockway]

It still amazes me how slow the PET drives are with hardware GCR encoding/decoding and parallel. They should load in seconds not minutes, definitely a software problem for the most part. Software loaders these days over serial have reached 50 times speedup, which is crazy. Are you going to look at any of the other hardware speeders like speeddos or dolphindos? Skyles made a lot of interesting bits of hardware, as did Batteries not Included. I wonder how all the different IEEE-488 interfaces for the vic20 and c64 stack up against each other.

[@ericanderson85]

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.

[@raymitchell9736]

Wasn't there an article in some Commodore magazine that claimed that the cassette drive was faster data transfer than the 1541 drive... that the reason why it didn't appear to be was that the cassette images were recorded 2x and that they were compared with each other that's what sometimes gave you the "Verify Error?" message, but if you could bypass that 2nd verify operation that the data would load faster... Is _THAT_ true, I never verified that... Of course I had to upgrade my 1540 to be a 1541 to make it work with the C64... which in hindsight was really a downgrade. I think I still the 1540 ROM... oh well... long ago in a Galaxy Far Far away

[@cocusar]

I understand that the shift register is certainly a faster way than bitbanging, but why not an UART? I don't recall if the CIAs had one, maybe not? having a serial communication with full hardware handshake would've been really easy to achieve even with a din5 (tx, rx, 2 handshake signals and ground), and technically push data as fast as the transceiver interface could on the cable between the disk drive and the computer; if one device is busy, you'd have the handshake signals to wait for it, so no lost bytes!

[@commodorehistory]

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

[@eupher2]

When I used the Commodore 64 with the 1541 as a kid, I always had the Epyx Fast Load Cartridge. I still use them today. Just press Run/Stop and the Commodore Key, and the disks load a lot faster. I guess a 2 minute load becomes 10 to 15 seconds.

[@commodorehistory]

Did you happen to see the video I did about Epyx Fastload? kzbin.info/www/bejne/pobNgH-Cq9OboKc

[@eupher2]

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

[@iguanac6466]

How well does the Flash solution load copy protected software using copy protection methods like Vorpal/V-Max? How about the demos that rely on 1541 timing? Broken?

[@commodorehistory]

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.

[@iguanac6466]

​@@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.

[@commodorehistory]

@@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?

[@Mr_ToR]

1:50 Peddle leaving commodore for Apple? could you provide a reference for this please ? Never heard of it

[@commodorehistory]

Commodore: A Company on the Edge. Page 172

[@bozimmerman]

Brian Bagnal's "A Company on the Edge" for one, chapters 11->12. Peddle worked on the Lisa, and the Apple III. This was around 1978. He later returned to Commodore, but then left again in 1981 I think?

[@Mr_ToR]

@@bozimmerman Thank you both for the quick reply.

[@killr0y]

@@commodorehistory That whole book is really sus.. Most reports are that Peddle didn't leave Commodore until 1980 (including Bill Mensch's 'In Memoriam' to Chuck). There's nothing on Chuck's wiki that suggests anything of the sort. In addition, there are metric tons of inaccuracies in that book. For example, there are quotes claiming Chuck had some kind of royalty deal with Tramiel where he was supposed to get $1 per every PET sold, which would equate to "millions of dollars"... I find that interesting since there were only about 219,000 PETS ever sold.

[@commodorehistory]

@@killr0y how about Chuck Peddle saying that he was at Apple and came back to Commodore: kzbin.info/www/bejne/m5-rd2yigtiYhpo

[@melkiorwiseman5234]

I have an old 2031 drive. I used it with a kit-built computer, but it wasn't really a success. With hindsight, I think that there was something wrong with the write bias since a disk would format and save and then read back just fine, until you left it for a day or two after which the disk would be completely unreadable. You could reformat it, save to it and load from it, then a day or two later the same problem would occur. Disk completely unreadable. The same thing happened with any disk regardless of brand, so I can be about as sure as possible that it was a drive problem and not a disk problem. I made my own hardware (and programmed my own software) interface to use the kit-built computer with the GPIB/IEEE-488 standard. It used 7 chips. 3 chips did the I/O address decoding while the remaining 4 chips handled the data and control signal transfers (2 latches for outputs and 2 buffers for inputs). The GPIB used an 8-bit data bus and (I think it was) a 7-bit control bus, so I configured the data bus at an even-numbered address and the control bus at an odd-numbered address so that A0 (address line zero) could be used to select which of the two was being addressed.

[@commodorehistory]

Your hardware solution sounds really cool!!

[@melkiorwiseman5234]

@@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.

[@nickolasgaspar9660]

My experience with the Commodore drive port is limited to the SD2IEC modern solution. Back in the days I had an Atari 8bit with a 1050 and I have to say that the SD2IEC is slow in comparison, but nothing close to what I hear from other C64 users. I guess the drive itself must have been even slower than the SD2IEC solutions.

[@axemanracing6222]

Have you tried the Backbit yet?

[@nickolasgaspar9660]

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

[@a4000t]

Sd2IEC is very slow w/o jiffydos.

[@Okurka.]

24:23 The C64 doesn't have a MOS 6502.

[@commodorehistory]

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.

[@wackyworldofwindios3476]

my atari 8-bit left the c-64 in the dust loading disk games.

[@commodorehistory]

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.

[@a4000t]

The funny thing is Jiffydos was out in 85,and it is amazing so few knew about it. It really helped speed the 1541 up. Irony is commodore didn't buy jiffydos it and add it default to c64's,

[@commodorehistory]

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.

[@Hefty54]

Let me make it simple its all in the programing. Commodore had Tracks and Sectors to read to preform the program unlike IBM program which started track one sector one in a straight path no jumping around loading the game. Commodore programing went something like this. Insert disc first line says goto track 30 sector 5 then it says after reading that line of code at the end of the code it tells the disc drive to goto track 1 sector 12 and so on. So the line of code reading on the commodore has the drive it jumping all over the place reading the disc making a lot of noise as the read head is jumping from this track and sector to that making it very slow in loading. Slow programing makes for slow loading. Oh and were talking lots of tracks and sectors in order for the game to start playing.

[@CJWarlock]

What's up with the audio level? Itr barely peaks at -15 dB on my DJ mixer. And it's after already turning the gain up (abour +3dB). Please normalize the audio level in further videos. Cheers. :)

[@commodorehistory]

Good feedback. I’m using Final Cut Pro for editing and I try to keep the audio levels right at the line below where the audio becomes yellow and red. Music has to be cut back -15dB and voice has to be bumped up usually around 6dB. The end result is a few yellow spikes and what you heard. I listened to it after I uploaded and it sounded like a reasonable level. What should I be using to check?

[@CJWarlock]

@@commodorehistory It's a good practice to make sure that the speech occupies the amplitude rail-to-rail. You can either achieve it in a fast or proper way. Fast way: normalize the speech to 0 dB. Proper way: compress the speech (as a whole separate track) in such way that the peaks from explosive sounds (like P, B, D, TZ etc.) and/or occasional louder accents and laughs aren't too far (amplitude-wise) from the regular speech. Human ears have "a compressor built-in", microphones don't. The secret to a pleasant speech quality is to simulate that natural compression. Let's say regular material is at -12 dB and peaks are at -4 dB. You don't need that much difference to make the accents heard. A soft knee, fast attack compressor at -12 dB and ratio of 8:1 or 12:1 will do the trick nicely. Of course the -12 level won't be the limit, the peaks above -12 will be reduced. That's where the soft knee characteristics come in handy. You want the compression to be kinda smooth but not too much. Then, after having such speech audio compressed , normalize it to 0dB. And so, you have the speech audio track ready for further use. Music track level - it's your choice completely. Separate music at the start can be at 0dB no problem. Between spoken parts - around -9 dB, maybe -6 dB is a good idea. It depends on the character of the music of course. Also, pay attention to the mid range. If there's a lot of stuff going on in the mid range - such music will be perceived as louder. Hence you might wanna put it at -9 or even -12 dB. Also, you might wanna test the 3-band EQ with a wide mid-range and -6 dB on that mid range. Music for background - firstly, it mustn't mask your voice. Check the spectrum of your voice for dominant frequencies. Then, go to the music track, 31-band EQ and turn these freq's 6 dB down. Or you can turn the wide mid-range to -9 dB or -12 dB. The difference between a compressed speech and background music is usually good when it's 18 - 24 dB. It depends on the character of the music. Make use of the rail-to-rail amplitude for the signal that is the most important. KZbin will attenuate the audio track during playback anyway. Unfortunately, I don't know it this forced attenuation can be switched off. Nevertheless, it's a good idea to make a full use of the amplitude and let the user to decide about the volume. While it's possible to turn the volume down on a mobile device, it's still very hard and beyond reach of a regular user to boost the volume. I have a PC and a stereo system with a pro DJ mixer. Many people don't have such listening environment and are left with only what the manufacturer of a mobile device gave them.

[@commodorehistory]

@@CJWarlock I greatly appreciate your detailed reply. I think most of it is over my head, though. I guess the basic question is, how can I know what the output dB level is of the audio? The audio track in FC Pro shows me a dB level, and I increased the voice track to +6 dB, but I don't know what the baseline output level is. I'm serious about taking feedback. I want to improve the quality of my content, but a lot of this is stuff that I just don't have expertise in.

[@CJWarlock]

@@commodorehistory Thanks for appreciating my work. :) I appreciate your will for learning and betterment of your videos.:) It's always a pleasure to see such good will. :) As for the audio editing details, it's really not that hard to get the basic picture of it all. While at the moment I'm not gonna guess what to tell you more and write it, I can recommend videos by Jason Yadlovski. Although he speaks about DaVinci Resolve, his style of explanation of complex things is very useful and effective for learning. :) Just search for audio-specific topics in his videos. Also, you might wanna just search for audio-specific phrases I've used in my previous comment (maybe adding "final cut pro" at the end of these phrases) and see what you'll find. There's no substitute for self-learning and understanding - that satisfying moment when all elements of the puzzle just click together. :) Let's just say that a "line out" output has an amplitude of 0.775 V. Maybe seeing audio level referenced to voltage amplitude is the key for your easiness of learning. :) -3 dB is basically signal amplitude/2. -6 dB is signal/4. And so on. Every -3 dB is basically the signal's amplitude divided by 2. It's not a linear scale, it's a log scale. Let's say that a smartphone's earphone output has an amplitude of 1 V. This means that if you'll put an audio signal through it that has a rail-to-rail amplitude (the sample envelope occupies the whole available space at the Y axis), then the whole available voltage will drive the headphones and the smartphone user will be happy. If you'd have an audio level of -12 dB, then this would mean that only 1/8 = 0.125 V would drive the headphones at best (in the loudest moments). The smartphone user would't be happy about this. ;) Some words could be hard to understand while environmental noise bleeds through because the audio level is too low. Some people watch videos in public places, where there is background noise and chatter. They can always turn the video's volume down but they don't like too quiet audio in videos because they have no choice then (no possibility to boost the volume). So, it's always a good idea to normalize the audio do 0 dB so that its amplitude reaches from rail to rail and the output signal in the user's device is at full 1 V (and not the 1/8 of it). :) Use an audio effect on the speech track that is called "normalize" or "normalization". Set the level to 0 dB. This would be your first step. As for the compression - I suggest you'll leave it for the 2nd step. Meanwhile, just read about it in your free time and get ready to implement. :) Experiment bravely with audio. :) I wish you success. Cheers!

[@CJWarlock]

Example video: Jason Yadlovski - "3 TIPS to Blend Together DIALOGUE and MUSIC Better in DaVinci Resolve 18 | Make Some Space"

[@007cantos]

Still beat the heck out of the tape drives, which us poor folk used

[@gregoryarmijo-dz9gv]

My c64 loaded fast cause I also had an Epyx Fast load cartridge. Also I remember a few 'software' disk fast loaders. Vorpal was one that was way faster then my Fast load cartridge. Rescue on fractals used a software fast load that loaded the game in like 10 sec. On file aka cracked games since the speed loader was software it either worked or didn't. Pepridge Farm Remembers.

[@Mr_Meowingtons]

How the hell do you leave 2 traces out!😳 no one looked at the sample boards? when I worked at a board manufacture we had at least 5 people along with the designer looking over the boards and testing WoW some one got fired that is a huge F up

[@speedbird737]

Heads should have rolled for such a mess up!!! At least I could use both sides of a 5 1/4 inch diskette by cutting a write notch!!

[@saganandroid4175]

1:50 Best newspaper clipping ever! Nude sunbathing, C= and TGIF services. 5:40 good to have this disclaimer, but why not just replace the misleading timing info? Does KZbin still allow you to update existing vids?

[@commodorehistory]

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: kzbin.info/www/bejne/bYSzo2iJZcp4j68feature=shared

[@JonRowlison]

So they cut the disk time from a little over 4 minutes down to just over 3 minutes. For all its faults, the Apple 2 could read through a whole 5.25" disk in about 45 seconds. There were also "turbo" programs for the Apple 2 that could cut that down to about 20 seconds... same 140k disk.

[@commodorehistory]

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.

[@JonRowlison]

@@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.)

[@flyguille]

Wait! 2.5min for 15k write? That is compared to. MSX TAPE recotder at 2400 baudios!. It did less than 5 min for 16k module at 1200 baudios. And less than 2.5m at 2400 baudios. Because an msx readion 16k from disk is about 8 SECONDS.

[@commodorehistory]

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: kzbin.info/www/bejne/bYSzo2iJZcp4j68feature=shared

[@Shazam999]

Awesome thanks.

[@AiMR]

I don't wanna hear your 1541 slow crying, I had to live with a cassette drive 🤣

[@a4000t]

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

[@herrbonk3635]

Never understood why they used these shitty proprietary chips, when there were cheap standard TTL shift registers available.

[@regularguy519]

EPYX fast cartridge? No mention of it in this video. I had one.. It cut the load speeds to a fraction of the time it would normally load an Electronic Arts Original game... No BS

[@commodorehistory]

No mention in that video, but I did an entire video about how Epyx Fastload works: kzbin.info/www/bejne/pobNgH-Cq9OboKcfeature=shared

[@regularguy519]

@commodorehistory heck yeah! Thank you!

[@DAVIDGREGORYKERR]

Why could it not have used the INTEL 8251 UART which supports 8bit, 1 start bit 1.5 stop bits and can operate at 1152000 bits per sec

[@commodorehistory]

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.

[@NotMarkKnopfler]

Yeah - as you correctly point out, the bench-marking aspect could be better. Watching the video, my first thought is that the BASIC interpreter is adding a LOT more overhead than the disk drives. If you could write the equivalent test programs in assembler then you're as close as you can be to just testing the hardware and removing the software aspect. Calling ROM/BIOS routines to do the disk IO is probably fine - just avoid the BASIC interpreter! 👍

[@commodorehistory]

I did a follow-up: Update to my previous video on why the Commodore 1541 disk drive was so slow kzbin.info/www/bejne/bYSzo2iJZcp4j68

[@CB3ROB-CyberBunker]

remarkable how much of a '1541 original board' the 2031 actually already is... it's all already in the same place. just some 'other chips' being logic chips. behold the worlds first tin can clock oscillator :P just about as big as 2 chips lol.

[@Nalianna]

Waiting? no. I remember waiting 18 mins for space invaders to load... from cassette tape.