The Ultimate Commodore 1541 Drive Talk - Michael Steil 

Personally, I believe that Michael knows more about the 1541 than most Commodore engineers in the 80s did....

Brilliant. I haven’t even thought about this on thirty five years, and you’ve presented an incredible collection of information that was very hard to learn in the 1980s in plain and concise language and images. Well done!

Every time I see this guy I can only think how long it must have taken to just create the presentation, let alone all of the script.

I love these talks from Michael Steil, the 50 minutes went by surprisingly quickly!

The most innovative thing I’ve ever seen was a two-drive copy program that loaded into the drive ram. Once loaded you could disconnect your commodore and the application would copy floppies on its own, detecting when new disks were inserted by watching the r/w sensor.

What an awesome presentation. Super informative and very easy to understand. This is a new reference video for those wanting a great overview of the 1541. Nice job!

I just love these drives. I found the 5.25" DD floppies suprisingly reliable compared to the 3.5" ones. Almost all of my 30+ year old C64 floppies still work flawlessly. And the unique sounds of the drive mechanics remind me of some of my happiest childhood moments at xmas eve. No emulator will ever be able to do this.

Wow... super detailed and so thorough.

Nice presentation, and thanks for the shoutout!

This talk it's brillant!!

I'm late to the party having only just watched this today. Fantastic work Michael! I thought I knew most things about C= disk drives, especially the 1541, but I learned many new things!

Love all of your Talks , Thank you :) QC

Not enough like buttons in youtube for this lecture. Just fantastic!

One the best technical talks ever on any Commodore related subject.

Thank you to VCF for posting this video I attended the talk in Mountain View and remembered feeling for so much information being presented I wish this were being recorded it's taken a bit but it's great to see again, the insight on using NIBREAD was invaluable me on some very tough old discs.

Fantastic stuff, thanks for sharing this 👍

Wow, that's a lot of info. I'm always impressed by how those early engineers figured out how to overcome problems of the day, back when it was necessary to cut corners because RAM and silicon were both extremely expensive.

Wow, thanks for all your effort in putting this all together with such great detail and clarity. Clearly a LOT of work went into organizing all these details! THANK YOU!

For quite some time there I thought he said "Alan Sugar", the founder of Amstrad, now a billionaire... but ofc he is talking about Alan Shugart - whom went on to become the CEO of Seagate until 1998 and passed away some 8 years later.

Wow that was quite excellent .. thank you!

Ever since seeing utilities like block allocation map editors I wondered about the magic of C64 disk drives. Haven't watched this yet, but I know all other talks by Steil and they are densely packed with information. Sure to learn a lot 😭 Edit: wow. that was impressive even with my high expectations. Very cool talk!

00:00 Introduction 00:55 History 04:55 Recording Format 05:35 Tracks 07:40 Sectors 08:15 GCR (Group Coded Recording) 09:35 Sector Format 10:40 Reading a Sector 11:35 Writing a Sector 12:15 Interleave 12:50 File System 15:30 Disk Drive Hardware 18:00 How VIAs are Used 19:50 Software Architecture 21:45 Data Transmission 23:30 Layer 2: Transmission 27:00 Layer 3: Talk / Listen 29:35 Layer 4: Commodore DOS 31:30 Fast Loaders 38:45 Non-standard Formats 40.25 Copy Protection 46:10 Preservation

Very thorough and informative!

Great information, very well presented.

Brilliant, it was even updated from the offline version end of last year

This guy is the best!

Yes, I do certainly want to get an SD2IEC drive or even the newer thing that came out since it did (but I have to be reminded of what that is).

Marvelous!

Awesome!

Yeah, got the first two of these books, that were my "bible" at this time, reading and understanding the ROM dump/disassembly. I almost forgot about most of this stuff, I remember it was very hard to debug the code running on the floppy which was writing / reading the disk, because you could not see what was actually happening (if you didn't own a logic analyzer or other equipment which cost a fortune those days). At least with a parallel cable it was easier, as mentioned in the video, because you could just transfer all bytes read in realtime to the C64 and then analyze what happened in a track.

Superb.

Wow. Awesome.

11 yo me would have been thrilled! (that's when I learned to program the C64 in machine code!)

ooh theres an ultimate talk i somehow missed, this is going to be a fun hour

Fantastic talk! I'll only add that the FC5025 can used to read Commodore disks over USB into a PC. It's a cheap option but the drawback is that it can only read disks, no writing.

My 4th viewing since released!

"The dirt has simply been rubbed off." Haha, OH!

The back of the jacketed disk also has the index hole on the opposite side, and the envelope flaps folded around from the front.

I wish that in that 8/5/3-disk photo on Wikipedia that you dissected, the 3.5er had been turned around so the access hole was facing the same direction as it is on the other two.

Soothing af.

Nice! I always idly wondered what Warp*25 did. Thanks!

That explains why GEOS wouldn't work anymore after my mate validated it. Great talk.

It seems like Fast Hack'em was the best at just imaging a disk, so whatever errors were on there would get copied over, so that protection scheme didn't work after a few years. I can't remember many things Fast Hack'em could not copy faithfully, if any, at least once my parents were rich enough and willing to buy a second drive when I was so young! Thus, the best module was the one that would set the drives up as their own computer and just skip the 64 altogether once the routine was sent to the drives! So no parallel card, hardware mods, etc. I can't remember for sure, but it almost seems like FH could trick the destination drive into copying special formats, thus formatting the disk as it copied. I'll have to set my system back up and try it, though; man, it's been a long time! But of course there were those physical limitations like motor speed that of course it couldn't emulate. But one thing I do remember for sure is that once I got a hold of Fast Hack'em, with its several modules, that was the ONLY 1541-based disk copier I ever used! It was really the best one out there that I had ever heard of, hands down!

So I been using 1571 with Zoom Floppy to convert all my disk to NIB and latter to G64....Any specific setting for nibtools to read specific protection or best default settings?

Actually, device 1 is for the tape drive, but then the tape drive is the unfortunately the 64's default instead of disk 8, so that number can be unwritten.

Sounds like a 1551 on a Plus/4 would be a great tool for playing around 1541 disks.

Hmm, it's interesting that some minifloppy access holes are shorter. But there's another reason that the Commodore 8-bit drives normally only use 35 tracks: Commodore wanted the drives to be able to work very well even with the cheaper, less-reliable disks, and they thought the last 5 were typically problem tracks. Or is that just from the rumor mill?

Guess what. It's easier to say years like 2013 as "TWENTY-thirteen," etc. instead, because they're shorter, due to having fewer syllables. Remember when we did that with the 1900s and before? Well it works for this century too, so try it today!

Interesting, I don't ever remember seeing those listen and unlisten commands before! But since those aren't BASIC commands like "open" and "close" are, I guess it's no surprise. How would you implement them?

Wow, for 4 decades I had never had any idea that the drive could send stuff right to the printer! So are you saying that you could tell the drive to load something right onto paper instead of into the computer's RAM? Such as an "open" command that will read an SEQ file straight to the printer, but when you write PRG into the computer to have it try to read the SEQ that might've otherwise gone into the memory, it's not there, because it went straight to paper instead?

How would you even hook a 1541 to the 64 via parallel? I saw someone do that with a 1001, but not a 1541. Obviously it would still have to start out as serial. So then what: use a serial-to-user-port adapter? If so, then how would that help? Or if not, then what?

Are you sure it's a solder bridge that you cut to change the old drive's device number, rather than just a circuit board trace? And what's the point of having devices 12-30 as drive device numbers if there were no drives that I've heard of with those numbers? Or do aftermarket drives like the Lieutenant Kernal hard drives and the CMD 3.5" floppy drive have those options? I've even seen a Commodore-64-based BBS and it just had some Lt. Kernal hard drives but not that many of them. So how would anyone ever have used them, and what sort of system would have so many?

It’s a little hard now to understand why they even bothered implementing a serial bus - it seems a whole lot of work clocking the data in and out of it - why not a simplified parallel interface to the disk drive (pretty much what Apple did, I think). It seems like wires were expensive in those days, but the price of hardware was coming down all the time, and it must have been a delicate balancing act. Just seems expensive putting a CPU/ROM/RAM in the disk drive!

👍

Why would data on the disk need to help with disk-change detection when the drive has a light sensor that already handles that?

So why would people hook up a Commodore drive to the PC when they could just use a PC drive with the conversion software you're talking about?

"Only one bitS"?

I always knew that Commodore not using the index hole made their drives the slowest of all the micro computer disk drives. Now I know exactly why they were so slow. WTH was Commodore thinking? Everyone else used the index hole because it made it easy to keep the tracks aligned and they didn't need sync bits and the other wasted space so they were able to put more data on a disk. Not using the index hole required a more complex drive controller and data writing with it was "sloppy", which required the large gaps to buffer the ends of the data so lead and lag wouldn't wreck the essential sector data. The "downside" for all the others was to make a flippy disk for single sided drives you had to carefully slide a hole punch between the media and jacket to punch the other holes for the sensor to be able to see the index hole.

That is so much wasted capacity lol.

He lost me at hello lol

"1000 microseconds"? So just a funky, effort-wasteful way of saying "one _millisecond,"_ right?

LOAD "*",8,1

Brilliant but - if the man did not read and speak so quickly, he would make fewer mistakes. Anyone can only read stupid facts. The audience doesn't count.