My friend Steve Gray pointed out an error in this video. I said the 8250 is not compatible with the 8050, but that is not accurate. The 8250 will read and write 8050 disks but will give an error on the first try, but after that it works fine. The only issue is REL files are different on 8250/SFD-1001.
Back in the day, a buddy of mine ran a BBS on his C64, and he used a 1541, for his boot disk, and then 2 SFD1001's as data drives, it was amazing how much disk space he had on his BBS at the time.
I have used IEEE-488 drives with my C64, there were huge advantages to doing that, provided you could deal with them not being 1541 compatible. Not a big deal for me as I was writing my own software, and used a customized version of the rom for Commodore's IEEE-488 interface I made. edit: yes, it took quite a while for Commodore to deliver the IEEE-488 interface, not entirely sure how long, but I know I had to wait at least 8 months for it to get delivered, after I had gotten the SFD-1001, while buying both at the same time (it was supposed to be a bundle). I never used the 'PET' drives for a BBS, but I know people who did. Instead, I upgraded the SFD-1001 drive I used for development, and the 8250 we used for 'production' to 32K RAM, and ran the customer information system I developed mostly on the drive, with the C64 mostly running the user interface. At some point we added a second 8250, which gave us 4MB storage, which could do things like scan for data on 2 drives in parallel, at the speed the drive mechanism supported, while the C64 could keep itself busy with displaying the results. That setup outperformed similar software running on a PC/XT with its hdd. Even a PC/AT merely came close.
I always thought Commodore really missed the boat when they didn't release an SFD-1001 with the C64 connector. Really, those would have sold. Commodore was weird that way. Multiple 8 bit lines with similar spec, but incompatible drives and BASICs. BTW I guess the algorithm sent me here from "My Developer Thoughts." Of course, I subscribed immediately.
I had an 8050 up until 15 years ago during a move I had to give up quite a bit of my collection. I solely used it with my C64 using a cable that directly connected to the cartridge port, presumably a commodore cable for this very purpose. It was fast that was for sure. I used Quickee Mail, I think that was the name, to download newsgroup data, unzip it onto the 8050 to read the newsgroup info and then repack and send back out. i can just remember it being so massive and also had so much capacity. I had traded a SupraTurbo 28 for the Amiga 500 for it.
I had an IEEE-488 adapter and one of these dual pet drives for a while. It's been a long time.. even had some Hard drives that I used and later moved to the CMD hard drive (that was sweet with Jiffy Dos ROMs.. ).. I loved those old commodore systems. I had an eprom burner that I used to make custom ROMS with.. change the default color schemes and the wording on the start up screen.. those were the days.. when games fit on a singled sided floppy... now you need a dual layered DVD disk at least.
What always interested me about Commodore disk drives up through the C64 were that unlike IBM and Apple drives (and the later Amiga ones, of course) the Commodore ones were entire computers in their own right, with CPU, and the same amount of RAM as their parent system.
Yeah, it was a really cool design. With Commodore devices, the computer just sent commands and let the drive carry out all the work. None of the DOS code had to live on the computer and consume resources.
@@commodorehistory I seem to remember some C64 programs that actually sent code to the drive to be run in parallel with the code in the 64 itself. And then the less-wise programs that used the drive motors and such to make music (wearing out the drive faster).
A videotheque check-in / check-out / reservation system is another use case for these big capacity drives, but the real bummer is that the IEEE-488 interface uses the cartridge port instead of the user port, wasting the precious cartridge slot.
Actually you can use a 1540 with a C64 if you turn off the screen when you load/save. Or so I've heard, I have never tried it. I've got another IEEE-488 interface for C64 but it they kinda suck since you can't use both serial and IEEE-488 at the same time. Now that configuration would be awesome. Great video as always! PS. Santa, please bring me a 8250lp or SFD-1001 for next Christmas.
My head-canon for this was always that Commodore themselves were using the PET drives internally via early boards that took a while to get to production. To cover the period when the 1541 was being developed and then going through it’s development hell phase of trying to fix the performance issues. Based on absolutely nothing of course, just seemed like a reasonable scenario for the early photos to feature those PET drives. Would love to see a repeat of your performance tests as my guess is those PET drives would perform much better than the stock 1541 setups.
I love the big CBM dual disk drives. I have two 8050s which sort of work, but both have unreliable drive units zero, which probably saw a lot of use. I need to refurbish them further, but keep pushing this as it will be hard and not guaranteed to work. I still don't know exactly what's wrong with them.
I wrote my own BBS for the C64 and used a 1541 as my boot disk and two 8250 drives for messages, files and games. I used a Skyles Electric IEEE-488 adapter to connect the drives. I really wish I could find a Skyles Electric IEEE-488 adapter now!!
Awesome setup for a BBS! I generally collect Skyles stuff, but I don't have one of their IEEE-488 adapters. I'd also like to get a Commodore IEEE-488 cartridge, but they've soared out of my price range over the years.
SEQ, USR, and PRG are basically the same - sequential files that can only be loaded in en bloc via LOAD (with the first two bytes in the file being used as the target address in RAM), or from the beginning via OPEN; accessing specific sections directly (random access) is not possible with these files. (It is only a convention to use PRG for programs, SEQ for data, and USR for whatever you want.) REL files allow for random access to specific data records, so are better suited for a database. Setting up or accessing REL files is quite inconvenient in C64 BASIC, but can be done.
@@NuntiusLegis what about the DEL file type, why would the filesystem want to keep track of files which were deleted, and the scratch command removes them from the directory anyway?
@ Usually the DEL type for a scratched file does not show up in the directory and is only used as a flag for the system, so it knows the space on disk is free to be used for something else. With special tricks and some tools, DEL entries in the directory can be created, and usually serve cosmetic purposes (like separator lines).
Great to see someone else covering these old IEEE-488 drives! I think you may be running DOS 2 ROMS on your 2040 - these later ROMs are typically the 4040 ROMs so I think that makes it a 4040 🙂. The DOS 1 2040 and 3040 were less compatible with the DOS 2 machines that you suggest, because they had an extra sector on tracks 18-24 compared to the DOS 2 drives. I spent quite a while banging my head against that brick wall in this video th-cam.com/video/sTCOTXtfprY/w-d-xo.html while trying to write an "original" 2040 demo disk.
I wonder why did Commodore change anything on the drives and the computers,, instead of leaving them alone and selling them with the newer computers. Maybe a different size form factor, but I would leave it to be fully compatible if I was in charge.
Even when I was little, reading the manual to my new 64, this whole thing felt like it was for the PET owner who was writing their own BASIC or what have you and wanted to transfer over business data. But why would you do that other than for color, hmm...
Hey Doug! I'm using a thing I got off aliexpress for like $5, which probably explains the quality :( It didn't look awful on my screen, or I wouldn't have published it, but it clearly looks awful to other folks because you're the second person to mention it. I'll have to find a better solution.
@@commodorehistory happy to show you the stuff I use for capture. Believe me, I went through a dozen different options before finding things that did not stink!
Just the activity light on Drive 0 is broken. The other two work. I was going to fix it before recording the video but didn't have any spare LEDs laying around.
Minor nitpick - can you do what Robin from 8-Bit Show and Tell does, and hit C= + 2 to change the text to white when you're typing? Your video capture is *very* hard to read, and it's actually clearer to look at what's going on on the monitor!
Yeah, I'll look into what I can do to make the screen grabs look better. I didn't realize how bad it was, so I appreciate you mentioning it. That said, if you're expecting Robin quality from my videos, you're going to be disappointed. He's good at creating content. I'm a hack. Thanks for watching, and thanks for the feedback! I'll try to improve.
@ Reading from the filmed CRT was a bit hard because of the line pattern on the screen (resulting from different refresh rates of the monitor and the camera I guess), but I didn't have a problem to read from the captured image. I also used to switch to white in the old days when my C64 was hooked up to a TV, but nowadays, with a proper monitor, I don't do that anymore. 8-Bit Show and Tell and your channel cover different topics, and you are also very good at your type of content. Your videos have a better production value I would say, like those animations showing the sectors on a disk, I wonder how you did that.
I know it's an absolutely pointless effort, but here's to hoping some bored hobbyist(s) find a way to get using disk images+fast loading working with those 2mb disks so we can way more efficiently archive our stacks of c64 disks in hindsight, on original hardware 😅
How did the 2040 give that disk the model type of "2A" when I thought the 1541 gave it that and the DOSes are different versions (for example, the 1581 gives them all "3D," and I thought the 1571 in 71 mode gave a different one also but I don't remember what it is and mine's broken so I can't just test it now)?
If the SFD ten-oh-one (easier to say than "one thousand one") wasn't directly compatible with the 64 then why did they give it a 1541-style of case? And while we're at it, why wasn't that the standard capacity for all 5.25" Commodore disk drives moving forward instead of dropping back down to SSDD for the 41 and only DSDD for the 71?
It was a matter of price vs. performance I guess. To get the most capacity out of a disk, it needs a high precision mechanism, which may have been too expensive for the mass market.
OK, I'm confused. If the 8050 can save 1MB at a time then how do we have fewer blocks on that disk (2052) than we'd have on a disk formatted by the 1581, but which is only 800K? And by the way, if the 8050 is double-sided then why wasn't the 1571 made for the same density, and then why wasn't the 1581 already HD, since HDs came out in 1986 and the 81 came out in 87?
it's what I mentioned about the 2040 and 4040 showing that they could store 340K "per unit". It's because there were two disk drives in one enclosure, not because the individual 2040 and 4040 drives had a higher capacity than the 1541. The 8050 and 8250 were both listed in that table in the same manner. I should have been more clear in explaining that.
it's not 'copy protection' it's called 'selling deliberate broken software that despite the fact ti's advertised to work with a c64, only works with a c64, and one, very specific, diskdrive, commodore themselves ever sold as well, and some clones thereof' that diskdrive being the cheapest piece of crap they ever made: the 1541. as obviously the c64 as per spec connects to -any- diskdrive or harddisk made by anyone. those do not have to run on a 6502. they just have to run accordingly to the protocol as in the manuals of the c64. your software has an obligation to work with -anything- that confirms to that standard. not just a 1541. (who wants a 1541 anyway. they're slow. even back then they were the lousiest pieces of shit commodore ever made much less the entire market ever made to connect either to ieee488 or cbm serial ;) loading code into the diskdrive or fucking around with invalid sectors is not 'c64 compatible as per spec. the latter is even to be considered 'deliberately selling an outright broken product'.
this won't run off the 5MB bernoulli drive i just hookked up to my 64. which complies with the standard and kernel routines in every way' 'screw your broken software' 'money back;'
the same thing happened in the 'pc days' when most of that crap would only run from a cdrom drive with mscdex and usually only on D: :P not from your novell netware server :P guess what. that doesn't mean your shit is broken. it means the software they sold you is broken :P
"...There's a reason I'm doing this!" Well sure, but EVERYTHING has a reason anyway, even if it's insignificant and accidental. But what about there being a PURPOSE you're doing this?
My friend Steve Gray pointed out an error in this video. I said the 8250 is not compatible with the 8050, but that is not accurate. The 8250 will read and write 8050 disks but will give an error on the first try, but after that it works fine. The only issue is REL files are different on 8250/SFD-1001.
Back in the day, a buddy of mine ran a BBS on his C64, and he used a 1541, for his boot disk, and then 2 SFD1001's as data drives, it was amazing how much disk space he had on his BBS at the time.
I have used IEEE-488 drives with my C64, there were huge advantages to doing that, provided you could deal with them not being 1541 compatible. Not a big deal for me as I was writing my own software, and used a customized version of the rom for Commodore's IEEE-488 interface I made.
edit: yes, it took quite a while for Commodore to deliver the IEEE-488 interface, not entirely sure how long, but I know I had to wait at least 8 months for it to get delivered, after I had gotten the SFD-1001, while buying both at the same time (it was supposed to be a bundle).
I never used the 'PET' drives for a BBS, but I know people who did.
Instead, I upgraded the SFD-1001 drive I used for development, and the 8250 we used for 'production' to 32K RAM, and ran the customer information system I developed mostly on the drive, with the C64 mostly running the user interface.
At some point we added a second 8250, which gave us 4MB storage, which could do things like scan for data on 2 drives in parallel, at the speed the drive mechanism supported, while the C64 could keep itself busy with displaying the results. That setup outperformed similar software running on a PC/XT with its hdd. Even a PC/AT merely came close.
This is so cool, I always wondered if anyone used the drives compute capabilities like this.
That sounds like a really amazing setup!
I always thought Commodore really missed the boat when they didn't release an SFD-1001 with the C64 connector. Really, those would have sold. Commodore was weird that way. Multiple 8 bit lines with similar spec, but incompatible drives and BASICs. BTW I guess the algorithm sent me here from "My Developer Thoughts." Of course, I subscribed immediately.
Always nostalgic to see the old hardware put through its paces. Thanks for sharing this!
I had an 8050 up until 15 years ago during a move I had to give up quite a bit of my collection. I solely used it with my C64 using a cable that directly connected to the cartridge port, presumably a commodore cable for this very purpose. It was fast that was for sure. I used Quickee Mail, I think that was the name, to download newsgroup data, unzip it onto the 8050 to read the newsgroup info and then repack and send back out. i can just remember it being so massive and also had so much capacity. I had traded a SupraTurbo 28 for the Amiga 500 for it.
The 8250lp is a beauty. One use case for the high capacity would be a large database using REL files.
I had an IEEE-488 adapter and one of these dual pet drives for a while. It's been a long time.. even had some Hard drives that I used and later moved to the CMD hard drive (that was sweet with Jiffy Dos ROMs.. ).. I loved those old commodore systems. I had an eprom burner that I used to make custom ROMS with.. change the default color schemes and the wording on the start up screen.. those were the days.. when games fit on a singled sided floppy... now you need a dual layered DVD disk at least.
What always interested me about Commodore disk drives up through the C64 were that unlike IBM and Apple drives (and the later Amiga ones, of course) the Commodore ones were entire computers in their own right, with CPU, and the same amount of RAM as their parent system.
Yeah, it was a really cool design. With Commodore devices, the computer just sent commands and let the drive carry out all the work. None of the DOS code had to live on the computer and consume resources.
@@commodorehistory I seem to remember some C64 programs that actually sent code to the drive to be run in parallel with the code in the 64 itself. And then the less-wise programs that used the drive motors and such to make music (wearing out the drive faster).
@ Quite useful is "spooling", printing directly from disk, while the C64 is free to do other things.
A videotheque check-in / check-out / reservation system is another use case for these big capacity drives, but the real bummer is that the IEEE-488 interface uses the cartridge port instead of the user port, wasting the precious cartridge slot.
Actually you can use a 1540 with a C64 if you turn off the screen when you load/save. Or so I've heard, I have never tried it.
I've got another IEEE-488 interface for C64 but it they kinda suck since you can't use both serial and IEEE-488 at the same time. Now that configuration would be awesome.
Great video as always!
PS.
Santa, please bring me a 8250lp or SFD-1001 for next Christmas.
Accurate on the 1540 compatibility, but I've never tried that either. Thanks for watching!
@@commodorehistory That might be suitable for a youtube short. :)
My head-canon for this was always that Commodore themselves were using the PET drives internally via early boards that took a while to get to production. To cover the period when the 1541 was being developed and then going through it’s development hell phase of trying to fix the performance issues. Based on absolutely nothing of course, just seemed like a reasonable scenario for the early photos to feature those PET drives.
Would love to see a repeat of your performance tests as my guess is those PET drives would perform much better than the stock 1541 setups.
This is actually somewhat likely, I feel.
Awesome video as always!
Very cool and interesting! Thanks for sharing
I love the big CBM dual disk drives. I have two 8050s which sort of work, but both have unreliable drive units zero, which probably saw a lot of use. I need to refurbish them further, but keep pushing this as it will be hard and not guaranteed to work. I still don't know exactly what's wrong with them.
I wrote my own BBS for the C64 and used a 1541 as my boot disk and two 8250 drives for messages, files and games.
I used a Skyles Electric IEEE-488 adapter to connect the drives. I really wish I could find a Skyles Electric IEEE-488 adapter now!!
Awesome setup for a BBS! I generally collect Skyles stuff, but I don't have one of their IEEE-488 adapters. I'd also like to get a Commodore IEEE-488 cartridge, but they've soared out of my price range over the years.
Winter Games is a challenging game to load on the Commodore 64 I owned that game discovered it required several attempts to load it successfully.
When copy protection pushes to crack, instead of preventing it
I've always wondered: what are the sequential, relative and user SEQ, REL and USR files, and what were the use cases for them?
SEQ, USR, and PRG are basically the same - sequential files that can only be loaded in en bloc via LOAD (with the first two bytes in the file being used as the target address in RAM), or from the beginning via OPEN; accessing specific sections directly (random access) is not possible with these files. (It is only a convention to use PRG for programs, SEQ for data, and USR for whatever you want.)
REL files allow for random access to specific data records, so are better suited for a database. Setting up or accessing REL files is quite inconvenient in C64 BASIC, but can be done.
@@NuntiusLegis what about the DEL file type, why would the filesystem want to keep track of files which were deleted, and the scratch command removes them from the directory anyway?
@ Usually the DEL type for a scratched file does not show up in the directory and is only used as a flag for the system, so it knows the space on disk is free to be used for something else.
With special tricks and some tools, DEL entries in the directory can be created, and usually serve cosmetic purposes (like separator lines).
@@NuntiusLegis I know this last part, as I had "Dir Master" and used to create my own PETSCII graphics in the filesystem's directory.
@NuntiusLegis all better answers than I could have provided. Thank you!
Great to see someone else covering these old IEEE-488 drives! I think you may be running DOS 2 ROMS on your 2040 - these later ROMs are typically the 4040 ROMs so I think that makes it a 4040 🙂. The DOS 1 2040 and 3040 were less compatible with the DOS 2 machines that you suggest, because they had an extra sector on tracks 18-24 compared to the DOS 2 drives. I spent quite a while banging my head against that brick wall in this video th-cam.com/video/sTCOTXtfprY/w-d-xo.html while trying to write an "original" 2040 demo disk.
Indeed, the 2040 is running 2.0 ROMs. I meant to cover that in the video but forgot. Sorry about that, but good catch!
Cool video - new subscriber.
Thanks, man! I appreciate the sub.
Are the LEDs out on the 2040?
Annoyingly, just the activity LED for drive 0. The other two work. I was going to fix that before doing the video but didn't have any LEDs on hand.
I wonder why did Commodore change anything on the drives and the computers,, instead of leaving them alone and selling them with the newer computers. Maybe a different size form factor, but I would leave it to be fully compatible if I was in charge.
Even when I was little, reading the manual to my new 64, this whole thing felt like it was for the PET owner who was writing their own BASIC or what have you and wanted to transfer over business data. But why would you do that other than for color, hmm...
Neat! I want one of those adapters. BTW, it's 10 x easier to read the real C64 screen than it is your screen capture. What are you using for capture?
Hey Doug! I'm using a thing I got off aliexpress for like $5, which probably explains the quality :(
It didn't look awful on my screen, or I wouldn't have published it, but it clearly looks awful to other folks because you're the second person to mention it. I'll have to find a better solution.
@ Strange, it was the other way round for me, the capture was easier to read.
@@commodorehistory happy to show you the stuff I use for capture. Believe me, I went through a dozen different options before finding things that did not stink!
are the drive LEDs on the 2040 broken?
Just the activity light on Drive 0 is broken. The other two work. I was going to fix it before recording the video but didn't have any spare LEDs laying around.
Minor nitpick - can you do what Robin from 8-Bit Show and Tell does, and hit C= + 2 to change the text to white when you're typing? Your video capture is *very* hard to read, and it's actually clearer to look at what's going on on the monitor!
Yeah, I'll look into what I can do to make the screen grabs look better. I didn't realize how bad it was, so I appreciate you mentioning it. That said, if you're expecting Robin quality from my videos, you're going to be disappointed. He's good at creating content. I'm a hack. Thanks for watching, and thanks for the feedback! I'll try to improve.
@ Reading from the filmed CRT was a bit hard because of the line pattern on the screen (resulting from different refresh rates of the monitor and the camera I guess), but I didn't have a problem to read from the captured image.
I also used to switch to white in the old days when my C64 was hooked up to a TV, but nowadays, with a proper monitor, I don't do that anymore.
8-Bit Show and Tell and your channel cover different topics, and you are also very good at your type of content. Your videos have a better production value I would say, like those animations showing the sectors on a disk, I wonder how you did that.
I know it's an absolutely pointless effort, but here's to hoping some bored hobbyist(s) find a way to get using disk images+fast loading working with those 2mb disks so we can way more efficiently archive our stacks of c64 disks in hindsight, on original hardware 😅
Perhaps a cartridge port expander and a fastloader cartridge running at the same time would work? Probably not.
Does the 2040 have a quicker data speed than the 1541?
Yes, quite a bit faster. I did some benchmarks if you're interested: th-cam.com/video/7SPr5S0eEYM/w-d-xo.htmlfeature=shared
Wow, interesting that that drive pair has a fan in it!
How did the 2040 give that disk the model type of "2A" when I thought the 1541 gave it that and the DOSes are different versions (for example, the 1581 gives them all "3D," and I thought the 1571 in 71 mode gave a different one also but I don't remember what it is and mine's broken so I can't just test it now)?
If the SFD ten-oh-one (easier to say than "one thousand one") wasn't directly compatible with the 64 then why did they give it a 1541-style of case? And while we're at it, why wasn't that the standard capacity for all 5.25" Commodore disk drives moving forward instead of dropping back down to SSDD for the 41 and only DSDD for the 71?
The more sophisticated drive was too expensive for most users I guess. I was just able to afford a C64 + 1541 at the time.
Wow, so if you could get 2MB onto a disk formatted by the 8250, why didn't that become the standard for higher-density 5.25" disks instead of 1.2MB?
It was a matter of price vs. performance I guess. To get the most capacity out of a disk, it needs a high precision mechanism, which may have been too expensive for the mass market.
OK, I'm confused. If the 8050 can save 1MB at a time then how do we have fewer blocks on that disk (2052) than we'd have on a disk formatted by the 1581, but which is only 800K? And by the way, if the 8050 is double-sided then why wasn't the 1571 made for the same density, and then why wasn't the 1581 already HD, since HDs came out in 1986 and the 81 came out in 87?
it's what I mentioned about the 2040 and 4040 showing that they could store 340K "per unit". It's because there were two disk drives in one enclosure, not because the individual 2040 and 4040 drives had a higher capacity than the 1541. The 8050 and 8250 were both listed in that table in the same manner. I should have been more clear in explaining that.
"The first disk drive is this... disk drive..."
I think you only need one of those.
CH, if Batteries Included is _out of_ Toronto then which province or whole other country are they *IN?*
You don't actually have to close channel 15 in most cases.
Other than to avoid one of those rare cases to ruin your day. ;-)
@@NuntiusLegis: Right, so no point in bothering to type it until you have to.
it's not 'copy protection' it's called 'selling deliberate broken software that despite the fact ti's advertised to work with a c64, only works with a c64, and one, very specific, diskdrive, commodore themselves ever sold as well, and some clones thereof' that diskdrive being the cheapest piece of crap they ever made: the 1541. as obviously the c64 as per spec connects to -any- diskdrive or harddisk made by anyone. those do not have to run on a 6502. they just have to run accordingly to the protocol as in the manuals of the c64. your software has an obligation to work with -anything- that confirms to that standard. not just a 1541. (who wants a 1541 anyway. they're slow. even back then they were the lousiest pieces of shit commodore ever made much less the entire market ever made to connect either to ieee488 or cbm serial ;) loading code into the diskdrive or fucking around with invalid sectors is not 'c64 compatible as per spec. the latter is even to be considered 'deliberately selling an outright broken product'.
people should never have bothered to even try to make 'clones' of the 1541. they should simply have returned that broken software to their vendors. :P
this won't run off the 5MB bernoulli drive i just hookked up to my 64. which complies with the standard and kernel routines in every way' 'screw your broken software' 'money back;'
the same thing happened in the 'pc days' when most of that crap would only run from a cdrom drive with mscdex and usually only on D: :P not from your novell netware server :P guess what. that doesn't mean your shit is broken. it means the software they sold you is broken :P
"...There's a reason I'm doing this!"
Well sure, but EVERYTHING has a reason anyway, even if it's insignificant and accidental. But what about there being a PURPOSE you're doing this?