Why Was the Commodore 1541 disk drive so slow?
Вставка
- Опубліковано 17 січ 2024
- UPDATE: I created a follow-up video to provide more accurate benchmark tests for the drives I discussed in this video: • Update to my previous ...
Like millions of other kids, I had a Commodore 64 with a 1541 disk drive when I was growing up. For all the great memories I have of that system, I don't fondly remember how slow the disk drive was. All I wanted to do was play a game of Racing Destruction Set, but I'd have to wait seemingly forever for it to load. I preferred the instant option of playing games from cartridge, but all the great games were on disk. Fast loader solutions worked, so why didn't Commodore just make the 1541 faster in the first place?
This video explores Commodore's history in the disk drive market and explains the intentional cost-cutting and incredible bad luck that resulted in the 1541's dismal performance.
I worked on the technical parts of this video in collaboration with Andrè Fachat, and he did his own video on the technical details of the 6522 shift register bug where he gets deep in the weeds. Please take a look at his video if you enjoyed this one: • 8bit-times Ep.24: The ... - Ігри
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! ⭐⭐⭐⭐⭐
@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!!!
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 👍
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!
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.
"State permits nude bathing!"
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... :)
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.
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."
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.
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...
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 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.
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.
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
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?
@@kennethwozniak3290 That's exactly what the 1541 Flash! Does
The sound at 8:41 scared me to death LOL.
Great videos lately, Dave! Keep them coming :)
Thank you George!
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.
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.
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.
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.
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.
I still have the oceanic drive. Excellent device.
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
I loved the hammering copy protected software used to try to destroy the drive.
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. 💪💪💪👏👏👏
Thanks so much! I really appreciate you watching and taking the time to comment.
Just found you. Here to stay! Please keep going. You have a good voice for this. Soothing but engaging.
awe man, this is the best thing I'll read all year. Thank you so much!!
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.
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
Cool! Never seen that particular disk drive speed improvement before.
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.
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.
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.
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.
It was - watch the follow-up video where I did more useful benchmark tests. Big miss on my part in this video.
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!
Hey, thank you for the positive feedback!! I really appreciate it!
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!
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.
Still better than tape. Thankfully for JiffyDos and other fast loaders for the C64 + 1541.
Awesome vid, more detail on the bugs I read about then showing what could of been.
*could HAVE been
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.
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.
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.
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!
Very interesting topic. Thanks for the video. :)
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.
Great video, well done!
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.
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!:)
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?
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?
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.
Fortunately, there were several excellent and transparent fast load cartridges available later that solved this problem.
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!
@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!
Great detective work! Thanks for explaining this. It was so weird that we could load faster from cassette than from floppy 😂
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.
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.
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.
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!
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.
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 :)
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.
Also, FCC RFI emission standards for home devices. Agree 100% with your T-shirt.
I had a c64 as a boy and it took a year of paper rounds to save for a floppy drive. What a disappointment.
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).
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!
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.
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 :)
I feel for Bob Russell, seriously. Hopefully his bad luck streak eventually stopped!
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.
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.
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.
Still beat the heck out of the tape drives, which us poor folk used
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!
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¡
Definitely, the Epyx Fastload was a game changer for me when I was a kid!
SuperSnapshot V5 is even faster.
I had the epyx Fastload and still do. It introduces a substantial improvement.
Never understood why they used these shitty proprietary chips, when there were cheap standard TTL shift registers available.
Interesting list of calamities, however how do the various fast loaders compare, and what tricks do they use?
Something for a follow up vid?
Yeah, a lot of folks mentioned that. I’ll see what I can put together.
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.
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.
That sounds interesting. I'll see what I can do. Thanks for the comment!
The video, starting at 12:29 , shows MOS6502. Is the shift register the 6522 ?
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.
Hi, then finally on the C128 and 1571 combination the shift register of the 6526 could be used and it felt kinda fast, also the 1581 has the shift registers and supports the Burst Mode, but I found out that on the 1581 the U0 commands for the Burst mode are slightly different and not working with what I created for the 1571 Burst mode 😭
The worst combination is a C16 with a 1551 what would be a parallel transfer but again its all bit-banging and so only 4 (or so) times faster than the serial bit-banging 🙄
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.
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.
Just found your channel... can you do similar videos for the Commodore 1571 and 1581 too?
Nothing Commodore is outside the realm of possibility for future videos. Thanks for watching!
Awesome thanks.
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,
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.
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?
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?
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!!
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.
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.
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.
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.
Waiting? no. I remember waiting 18 mins for space invaders to load... from cassette tape.
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.
I started out with a TI-99/4A also. Great memories :)
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.
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.
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!
You are correct, but neither the VIC-20 nor the C64 have a hardware UART :(
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 UA-cam still allow you to update existing vids?
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: ua-cam.com/video/7SPr5S0eEYM/v-deo.htmlfeature=shared
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.
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.
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
my atari 8-bit left the c-64 in the dust loading disk games.
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.
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.
Hah! I don’t think I ever saw that, or perhaps I just forgot, but that’s funny :)
Lack of FSB and north bridge bottleneck alleviation due to budget modeling (foreshadowing the games shovelware crash of the early 80s) but that wouldn't come for 40 years
1:50 Peddle leaving commodore for Apple? could you provide a reference for this please ? Never heard of it
Commodore: A Company on the Edge. Page 172
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?
@@bozimmerman Thank you both for the quick reply.
@@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.
@@killr0y how about Chuck Peddle saying that he was at Apple and came back to Commodore: ua-cam.com/video/enHF9lMseP8/v-deo.html
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.
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.)
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.
Fairly sure the whole 6522 timing bug can be fixed by a single D latch.
Yup. Watch Andre Fachat’s video that I linked to in the description.
I don't wanna hear your 1541 slow crying, I had to live with a cassette drive 🤣
You poor bastard! How did u manage! I feel for you.
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! 👍
I did a follow-up: Update to my previous video on why the Commodore 1541 disk drive was so slow
ua-cam.com/video/7SPr5S0eEYM/v-deo.html
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. :)
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?
@@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. UA-cam 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.
@@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.
@@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!
Example video: Jason Yadlovski - "3 TIPS to Blend Together DIALOGUE and MUSIC Better in DaVinci Resolve 18 | Make Some Space"
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
15KB in 4 minutes! thats about 500 effective bits per second. A cassette tape can be twice as fast and a lot cheaper.
While on an Apple-2 Locksmith can read a whole 140KB disk in about 20 seconds! 100 times faster and with a disk controller with only 8 simple ICs. Of course it took Wozniak to do it ;)
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: ua-cam.com/video/7SPr5S0eEYM/v-deo.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.
I Just discovered your channel. This video is well thought out and filmed. And your narration is planned and concise. HOWEVER, you seem to be yelling items you think are key information. This is what young people on you tube do and its horribly offputting. Your speaking into a Microphone, don't yell. Yout message will get message across without doing that. Yelling just takes me out of the video. Yelling doesn't make the content better. We are here to listen to vintage computing, just read your content and it will come across. Im losing my hearing from my time in the military and I can still tell you are yelling. Anyway good luck on your channel I hope you take the criticism. Thanks.
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.
24:23 The C64 doesn't have a MOS 6502.
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.
You should have included a benchmark of a modern solution, like JiffyDos for reference.
That wasn't really the purpose of the video. Have a look at www.obliterator918.com/comparison-of-commodore-64-speed-loaders/
@@commodorehistory Great. Thanks
The C64 is an amazing machine. The drive? Well, that's why I ended up being an Apple user. There are tools on the Apple II that can copy an entire 140k disk in mere seconds. And that's with almost zero brains in the drive itself! Sure, Apple charged way too much for their hardware... but man, it was FAST.
Yeah, definitely -- the apple stuff was fast! I had to go with what my parents could afford, so I grew up with Commodore stuff.
Jam in new 323K replacements. Modern replacements run much cooler and use less power.
You may have noticed that the 1541 I used in this video doesn't have the voltage regulators on the board. It has a meanwell PSU in it. :)
Jeez, and I thought loading from cassette was slow
To be fair, in this video the slowness was exaggerated by my basic program reading one byte at a time. I did a follow up video that more accurately depicts their true performance: ua-cam.com/video/7SPr5S0eEYM/v-deo.htmlfeature=shared
@@commodorehistory I watched it, that makes more sense, still slow for a disk drive but much faster than a cassette
Bloody hell the noise is from your video. I had to stand up and check my door 4 times before i realised. It sounds just like my doorbell. I barely have the power to move a little. CURSE YOU.
lol. I’m quite curious which noise it was?
@@commodorehistory For example at 15:13, the transition sound effect. I have a Honeywell doorbell that makes the same sound as heard through the wall while i'm wearing headphones.
funny how they could not be arsed to just fix the 6522 shift register (despite it being multi-vendor from like 50 different suppliers and none of sell a fixed version either ;) aaaand then screwed it up -again- in the 6526 (an otherwise -totally- useless chip (well ok it has a time of day clock, but a crappy one ;) LOL. other than that it's just 'another try at the 6522 which sucks even more ;) lol. it's a shift register people. how hard can it be.
Hey why hogging all the Commodores man?😢
When you're near Pittsburgh, you'll just have to stop by to visit so you can enjoy them with me :)
@@commodorehistory Apologies, I was busy making a joke so I forgot to thank you for the video, nice work. Like someone else mentioned I knew some of it but it was nice to finally get the complete story. Video idea, how could a software only turbo program, loaded from floppy by the very same drive, significantly increase the speed of the 1541? I think it would be interesting to see how it compares to the hardware/cartridge solutions. 2nd idea, compare different disk turbo solutions. 3rd idea, SFD-1001, the pride of my Commodore pieces, a whooping one meg on a floppy back in the day! (Not at a price point I could afford back in the day!)