The Ultimate Commodore 1541 Drive Talk - Michael Steil
Вставка
- Опубліковано 8 сер 2024
- A presentation at Vintage Computer Festival West - August 8, 2021 - (VCF WEST 2021)
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 - Наука та технологія
Personally, I believe that Michael knows more about the 1541 than most Commodore engineers in the 80s did....
He is a true fanatic! Has the time, energy and motivation to delve deeper than anyone!
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.
lol
Wonder if he held his breath while writing it as he doesn’t seem to stop to breathe while delivering the presentation. I feel dizzy watching this. Amazing! Gonna have to rewatch (a few times!). 👍
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!
lol
I love these talks from Michael Steil, the 50 minutes went by surprisingly quickly!
Those are the best kinds of talks.
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.
Yeah. That's pretty cool!
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!
We are glad that you liked this video!
Wow... super detailed and so thorough.
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.
It sounds silly but I remember loading GEOS for the first time and how it changed the sound of the 1541 while loading. I thought it was so cool. Disk Turbo! w00t w00t
Nice presentation, and thanks for the shoutout!
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!
Glad that you liked the video and glad that you learned something! :-D
Not enough like buttons in youtube for this lecture. Just fantastic!
This talk it's brillant!!
I agree! I hope that he can do another one like this!
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!
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.
We are glad that you liked this video so much and your support for our organization. Please spread the word!
One the best technical talks ever on any Commodore related subject.
I wondered why you needed a parallel hack to dump NIB level files. I thought it was JUST because it would be too slow otherwise, and people didn't bother, but that part where re-synchronizing to get the rest of a potentially modified long sector - that wouldn't fit in 2KB was the answer - finally explained why.
I'm glad that you liked it!
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.
Love all of your Talks , Thank you :) QC
Glad to hear that you liked them! :-D
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.
Same here! I thought... "Really? Alan Sugar was involved with Apple and Commodore?"
Fantastic stuff, thanks for sharing this 👍
Wow that was quite excellent .. thank you!
Brilliant, it was even updated from the offline version end of last year
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!
Very thorough and informative!
Great information, very well presented.
We agree!
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.
Lots of interesting stuff about that drive.
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).
1541 Ultimate is an alternative to uIEC.
@@vcfederation: Oh, cool, thanks.
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
Thank you for the timecodes. I added them to the Comments so there will be chapters there.
ooh theres an ultimate talk i somehow missed, this is going to be a fun hour
It was fun indeed!
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.
Marvelous!
The back of the jacketed disk also has the index hole on the opposite side, and the envelope flaps folded around from the front.
Interesting.
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.
Sorry to hear that.
@@vcfederation: I don't really think you need to be sorry about that. You didn't even make the image, did you? The Wiki before I knew about it on this video. But with the disks overlapping, how did you isolate them whole? Did you do a whole bunch of reverse graphic work to patch things, or..?
Are you the one who made that image that we see on the wiki, so is that what made it easy for you to separate the disks, because you're the one who shot one disk at a time and then set them together to shoot the set?
This guy is the best!
He really knows his stuff!
Awesome!
Absolutely!
Nice! I always idly wondered what Warp*25 did. Thanks!
I think that this was one of the greatest technical talks that has been done at the Vintage Computer Festivals. So much detail and useful information.
Wow. Awesome.
Yes. A very good talk indeed!
Soothing af.
Pretty cool!
11 yo me would have been thrilled! (that's when I learned to program the C64 in machine code!)
Very cool!
Superb.
Absolutely!
Now someone just needs to create a replica 1541 & magnetic media.
@Lion_McLionhead: I'm sure that someone is working on it!
"The dirt has simply been rubbed off." Haha, OH!
Yeah. So simply, but true.
@@vcfederation: Interesting, isn't it? Some things seem like they'd have to be so complicated... while others from the same category are just this simple, haha!
That explains why GEOS wouldn't work anymore after my mate validated it. Great talk.
My 4th viewing since released!
Yeah. I need to watch it again too!
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!
Fast Hack'em didn't image a disk, it copied the disk track by track to another disk. It was very good at copying and then using parameters to defeat copy protections. Yes, when you had two floppy drives it copied faster. I used Maverick mostly as he had great support with RAM expanders, RAMBoard, different drive numbers, fast file copy, etc. It was the best in my opinion.
@@vcfederation: Of course the 2-drive system copied faster, since there were no disk swaps. But maybe also because it would go straight from one drive to the other. Well, that's when it was in standalone mode. That one particular module in which the drives would start just seconds after detecting disk insertion on both.
But if you're copying a disk bit by bit and track by track, how is that supposedly "not imaging"? You don't need to make one big disk file just for a bit-exact copy to be called imaging, do you? What would be the supposed difference, in your estimation?
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.
Yes. So true!
Sounds like a 1551 on a Plus/4 would be a great tool for playing around 1541 disks.
Perhaps.
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?
I would make a post to forum.vcfed.org and ask around.
@@vcfederation: Yeah, I'll check that out; thanks.
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?
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!
In other countries they say the whole number as in "two thousand thirteen".
@@vcfederation: OK, maybe so. But that doesn't mean you're obligated to do so, right? How do you say 1776? Do you go, "uhh... one thousand, seven hundred seventy-six, uhh..."? How about 1999?
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?
Yes. There are definitely tricks that you can use with the 1541 drive because it has it's own microprocessor (6502) and RAM (2k). You could do more if you use the RAMBoard which bumps it up to 8k.
@@vcfederation: If you meant "because it has ITS own microprocessor/CPU" insteas of "because it has _it is_ own microprocessor...," then this is my reply to that: Oh, yeah, that's (and the RAM) what's always been interesting to me about Commodore and Atari 8-bit disk drives. But wow, I wish someone had taught about the printer trick decades ago!
Hey, since my compatible printer is "buried" right now, will you please make a video of doing this trick?
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?
I suggest looking up any 1541 books here: commodore.bombjack.org/commodore/books.htmor this this page: www.pagetable.com/?p=1031
@@vcfederation: OK, thanks, cool!
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!
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?
Yes. There is an adapter that will go from parallel port to the serial port. A device such as the Zoom Floppy by Retro Innovations: www.go4retro.com/products/zoomfloppy/
@@vcfederation: OK, I see that that thing you showed me is for connecting a PC to the Commodore drives. That's no surprise. Well, it's cool and somewhat unusual, but by several years ago I had heard of a few of these.
However, only now have I seen a video that made it sound like you'd be trying to connect a _Commodore_ computer -- 8-bit and IEC, such as a 64 -- to an IEC drive such as the 1541, via the _Commodore_ computer's parallel port (meaning the user port) to the IEC drive via an interface like this. But this doesn't look like it does that; only that it would connect to a PC with an LPT card (or at least a middle-aged one that has it built into the motherboard). What card supposedly does _that?_ And how might _that_ work?
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?
I'm not sure about devices 12-30. Nothing I know of used them. Hard drives used partitions. The uIEC devices use partitions with subdirectories. They treat a disk image (.d64) as a directory.
@@vcfederation: I've never as of yet had a hard disk for the Commodore 8-bit computers, but I've seen someone with some Lighten Kernals, and he ran Port Commodore at his house down in Salem, here in Utah! I don't suppose they'd HAVE to have partitions unless the 8-bit system severely limited the number of files or contiguous bytes or blocks you could have in one area.
In 1988 my dad was cool enough to add a 128 and 1581 to supersede our 64, and I remember that you could make partitions with it, but with just 3160 blocks (about what: 700-800K on an SD 3.5" floppy disk?), and with how complicated it is to not only make the partitions and then switch to them, it wasn't even worth it. I bet most people with a 1581 felt that way. But of course even with just a 20-40MB hard disk it might make more sense even if ya didn't HAVE to do it.
👍
We are glad that you liked this video so much and your support for our organization. Please spread the word!
Why would data on the disk need to help with disk-change detection when the drive has a light sensor that already handles that?
Not sure. I would google it.
@@vcfederation: Yeah, I guess we can see what that pulls up....
Coming back here later....
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?
Because they file formats are incompatible. You can't take a PC formatted disk and put it into a Commodore drive. By hooking up a Commodore drive to a PC , you are able to copy files or disks and be able to still use them in a Commodore drive when you connect them to a C64, etc.
@@vcfederation: I KNOW that. Ordinarily that would be true. Well, it's not even the file format, but the _disk_ format. But then didn't you just say in the video that the PC drive could do it with that adaptation? I'm talking about _that_ setup. Why wouldn't someone just use that PC drive setup that you said would make it work like a Commodore 8-bit drive?
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.
The simplest explanation for the slow disk drive on the C64 was time to market. The technicians simply did not have enough time to do this property due to very tight deadlines.
Did you watch the same presentation? Almost nobody actually used the sync-hole (pun intended) The major bottleneck in the C64 comes the software control of the serial bus because of a hardware bug in the VIA.
@@Sine1040 , yes I watched it and have even done some 1541 drive programming myself. Its no doubt a mix of them getting stumped at this hardware problem as well as developing a pretty poor solution to the problem seeing how much better you could actually do this with the right software even with the bugs in place. If they had more time, I am sure they would have done it better - but all manufacturers had tight schedules to release stuff in time for certain events, Commodore was no different as the competition was fierce.
@@Sine1040 Texas Instruments used it. IBM used it. So did Xerox. Any computer that used the stock Shugart drives used the index hole.
@@64jcl they could have had an easier job and designed their disk system quicker, and had faster data transfer, with more data on a disk, if they'd used standard Shugart drives instead of only using the bare mechanism.
"Only one bitS"?
I'm not sure I understand the question.
@@vcfederation, you said, "only one bits," so I asked the confirmation question of that because it doesn't make sense with the s in that context.
“Only bits which have a value of 1.”
...is maybe what he should have said, I guess you're saying, right, @@ZipFoxtaur? Or with a faster, more connected rhythm, so it would sound like he was saying "only 1-bits," right?
Now I'll have to rewatch the video to see if that would even make sense. I can't remember the exact context.
He lost me at hello lol
That is so much wasted capacity lol.
So true!
"1000 microseconds"? So just a funky, effort-wasteful way of saying "one _millisecond,"_ right?
It makes it sound larger.
@@vcfederation: Not to those who know basic math, right? Besides: the supposed "point" of it supposedly "sounding bigger" to those who can't math would be...?
LOAD "*",8,1
You never forget that command!
L{SHIFT O} "*",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.
He is German and speaks very well, to say nothing about the speed, as for the German...
That's the beaty of a recorded talk. You can replay it and hear what they said as many times as you want! :)
He did a great talk indeed!