I was wondering about those numbers in the previous video, things just did not add up. Thanks for coming back to the topic and give us an update on it.
Thanks for the update. I remember suffering through this as a kid while waiting for games to load. Then I was shocked at how fast the Apple II disks were (but appalled by the graphics and sound).
Waited video arrives. I thought your previous method worked in percentage wise but apparently it was not able to show the difference between 2040 and 2031 or between 1541 and 1541 flash. Very nicely and simply done. Thanks a lot for the clarification.
Both videos very interesting... I do remember being surprised that the C64 disk games seemed to take about as long as loading a cassette game did on the Amstrad CPC 464. I knew it was partly to do with using a serial bus on the drive but this really shed some light on it.
I recently found your channel and I glad I did. I’ve only recently dusted off my old commodore gear and as an electrical engineer, I’m much more capable now to repair and go through my stuff than when I was when it was packed up. I’m also originally from Harrisburg, pa…. So I knew people who worked for and with commodore. I only regret that I don’t have as much equipment that had back in the day since my son has already asked me for a C64 and I only have one that still needs repair, lol. There was a time I had literally several c64s, vic20s, plus4, c16, plus monitors and drives…. who knew in the 80s that I’d want these “old slow” computers 40 years in the future. My father worked in IT and we got tons of defective commodore systems we would repair or part out. My son is very interested in retro computing and 6502 based stuff specifically. He has an Atari 2600 in his room (my original console growing up). I’m encouraging it since he’s learning to program BASIC and do electronic repair. I also recently built him a commodore “retro box” that is basically an intel nuc board in the case of a commodore amiga 3000 that the board was not repairable. It’s a Linux based nuc with VICE and amiga emulators on it, it’s a clean package and lets him do his commodore computing until I can get him a real C64. You have a new subscriber and I look forward to your future videos. :) I also seem to remember 25+ years ago there was cable I made from spare parts laying around that connected a 1541 drive to a regular x86 PC via the db9 serial port and then there was a piece of software that looked like Norton commander that allowed the IBM PC to read and write to the commodore drive and disks…. That allowed me to download c64 software from the internet, write it to a commodore disk drive, the be able to connect the drive to my c64 and then use my downloaded commodore software right in true commodore hardware. I’m looking into recreating that in the near future.
Hi @trssho91, I'm super happy you found me. It's great that your son is interested in your hobby, and I'm sure it will serve him well to build his foundational knowledge using these old devices if he chooses a career in IT. The cable you remember from 25 years ago is likely the X1541, and the software you described is likely Joe Forster's Star Commander. There are modern equivalents today. I use Nate Lawson's ZoomFloppy with OpenCBM software. Have fun!
@@commodorehistory I had the same thoughts about how development learning the basics. It’s how I started as well. I remember using the cable and software, it couldn’t recall the names…. Thank you for the modern equivalents.
@@trssho91Since I will always have a Windows 98 SE retro-PC anyway, I prefer the X-cable and Star Commander. ZoomFloppy costs four times as much, and OpenCBM seems to be slower than Star Commander (out of the box, but there seems to ba a way to use the Star Commander routines in OpenCBM). Are you sure your cable was on the serial port of the PC? All X-cables I heard of use the parallel port.
i would guess that it's just a matter of how you talk to your multiplexer. Once the drive sent a byte, it can already fill up the register again. And send it as soon as the computer is done processing the first byte @@commodorehistory
It may be because of how complicated the handshaking is for the GPIB used to interface with the 2031. I'm speaking from experience, here. I tried to interface a 2031 (in what appears to have been a 1541 drive case but badged 2031) to a kit-built computer and it was mostly a success except that the drive itself seems to have had a subtle fault which caused disks to fail after only a few days in storage no matter what brand of disk you used, but I had to write the interface routines myself so I know how complicated a program needs to be to use the drive. The only other thing I can think of is that the limiting factor was not the transmission method but the CPU speed within the drive case, and/or the RAM in the 2031 was slow and required "wait states" to allow it to catch up to the CPU.
The most amazing thing about this whole story is how successful the c64 was in spite of its numerous bugs that had real world effects that users had to deal with constantly.
Thanks for the update. You should repeat this test with Fast Load cartridge and of course with JiffyDOS. They are the most widely used disk drive accelerators, it would be nice to see how they compare with each other and with 1541 Flash. Yes, I know there are some test videos out there but all with loading games etc. This kind of bare bones testing will be more honest.
You're welcome! I should have corrected them in the original video but I had already put so many hours into the video I didn’t have the motivation to do so. Live and learn…
These numbers better reflect the changes to performance that the cost reductions had. I still remember comparing Oregon Trail which would load to menu on my Apple in about 10 seconds, and then each load after that was generally only 2 or 3 seconds. And that was a game written completely in basic. The C64 with the same game, did have better graphics and what not, but it was always 90 seconds to load anything. That was always a turnoff for me when looking at getting another system to play with back in the day.
Hi. These times make more sense that those of your previous video. Yet, the floppy peak data rate is about 21KB/s (for the slower inner tracks), so, even the 2040 is wasting 90% of the time during the reading. Sure, sector interleaving and track changes can reduce the effective data rate a lot. But there is an Apple2 game, Lode Runner, that gets loaded in almost no time because it reads the sectors in any order they pass under the disk head, so it takes only a little more than a revolution to read a whole track. A trick like this isn't possible for Commodores, and this makes me question what are the advantages of having a separate computer for the floppy when the main CPU has nothing to do but to wait for the data?
It'd be useful to include JiffyDOS in the benchmarks as the established leader of 8-bit Commodore disk turbos to see how far it's from the speed potential of a working shift register. Practically every 8-bit IEC-bus Commodore (VIC-20, C64, C64, SX64, C128, C128D, C16, and Plus/4) machine and IEC disk drive (1540/1541, 1571 and 1581) is supported by JiffyDOS, and it's extremely compatible. The only drawback is that it replaces the cassette ROM routines since it lives in the same address space.
Another drawback is that the original hardware must be modified. I prefer a fast loader cartridge - no modifications needed, and it does not only spare the tape drive, but speeds that up as well.
@@NuntiusLegis There's no reason why you couldn't use JiffyDOS as a cartridge. Ultimate1541 cartridges for instance allows you to replace the C64 ROMs on the fly with whatever else you have stored. On the drive side you'll however need to swap the ROM. You could also use higher capacity ROMs on the C64 and drive side and use switches to map the higher bit address lines to switch between several different ROMs. Doing things like that are also period correct power user things, as were things like doing the parallel mod for the drive, working around the serial problem in the first place and getting the drive to work at PET drive speeds.
I prefer the Final Crtridge III, which is not just a speeder for disk AND tape, but also a freezer, a nice BASIC toolkit, a machine language monitor, etc. And no ROM change or anything, just plug & play.
@@NuntiusLegis Ultimate1541 has support for FC III as well and many many other things, including REU and of course the drive and cassette emulator, networking and so forth.
@@jammi__That costs five times as much as a FC III, I prefer the real drives over emulated ones, and the "support" for other cartridges (these being included in the firmware) is probably illegal.
You mentioned some kind of ram in the drives. Does this act as a cache? If so, you need to clear it before you do the read test. (on the first machine)
I'm pretty sure no 5.25" Floppy drive will try to cache anything in the modern definition of cache you are implying. They will not even keep track of the fact if you have replaced the disk between writing and reading. Also I don't think it would have helped at all. The actual reading speeds from the disks should be able to keep up with the 300 RPM (or 5 Hz) rotation, so for a nice sequential file stored on the (at least) 17 sectors of a single track to be read in 0.2 seconds, the transfer speed of the read-head needs to be at least 17*256/0.2 = 21.8 KB/s. So these drives will generally be able to read a single sector from the disk into their RAM very quickly (and cache it in that sense), but then it takes most of the time to actually push the data through the communications link to the computer.
The commodore DOS code was analyzed at a detailed level in the book “Inside Commodore DOS”. There is no caching. It’s a tremendous reference, so if that kind of thing is interesting to you, I highly recommend it.
I was wondering about those numbers in the previous video, things just did not add up. Thanks for coming back to the topic and give us an update on it.
Thanks for the update. I remember suffering through this as a kid while waiting for games to load. Then I was shocked at how fast the Apple II disks were (but appalled by the graphics and sound).
Thank you for taking the time to include the oft forgotten 1540 + VIC combo. My favorite!
Waited video arrives. I thought your previous method worked in percentage wise but apparently it was not able to show the difference between 2040 and 2031 or between 1541 and 1541 flash. Very nicely and simply done. Thanks a lot for the clarification.
Both videos very interesting... I do remember being surprised that the C64 disk games seemed to take about as long as loading a cassette game did on the Amstrad CPC 464. I knew it was partly to do with using a serial bus on the drive but this really shed some light on it.
I recently found your channel and I glad I did. I’ve only recently dusted off my old commodore gear and as an electrical engineer, I’m much more capable now to repair and go through my stuff than when I was when it was packed up. I’m also originally from Harrisburg, pa…. So I knew people who worked for and with commodore. I only regret that I don’t have as much equipment that had back in the day since my son has already asked me for a C64 and I only have one that still needs repair, lol. There was a time I had literally several c64s, vic20s, plus4, c16, plus monitors and drives…. who knew in the 80s that I’d want these “old slow” computers 40 years in the future. My father worked in IT and we got tons of defective commodore systems we would repair or part out. My son is very interested in retro computing and 6502 based stuff specifically. He has an Atari 2600 in his room (my original console growing up). I’m encouraging it since he’s learning to program BASIC and do electronic repair. I also recently built him a commodore “retro box” that is basically an intel nuc board in the case of a commodore amiga 3000 that the board was not repairable. It’s a Linux based nuc with VICE and amiga emulators on it, it’s a clean package and lets him do his commodore computing until I can get him a real C64. You have a new subscriber and I look forward to your future videos. :) I also seem to remember 25+ years ago there was cable I made from spare parts laying around that connected a 1541 drive to a regular x86 PC via the db9 serial port and then there was a piece of software that looked like Norton commander that allowed the IBM PC to read and write to the commodore drive and disks…. That allowed me to download c64 software from the internet, write it to a commodore disk drive, the be able to connect the drive to my c64 and then use my downloaded commodore software right in true commodore hardware. I’m looking into recreating that in the near future.
Hi @trssho91, I'm super happy you found me. It's great that your son is interested in your hobby, and I'm sure it will serve him well to build his foundational knowledge using these old devices if he chooses a career in IT. The cable you remember from 25 years ago is likely the X1541, and the software you described is likely Joe Forster's Star Commander. There are modern equivalents today. I use Nate Lawson's ZoomFloppy with OpenCBM software. Have fun!
@@commodorehistory I had the same thoughts about how development learning the basics. It’s how I started as well. I remember using the cable and software, it couldn’t recall the names…. Thank you for the modern equivalents.
@@trssho91Since I will always have a Windows 98 SE retro-PC anyway, I prefer the X-cable and Star Commander. ZoomFloppy costs four times as much, and OpenCBM seems to be slower than Star Commander (out of the box, but there seems to ba a way to use the Star Commander routines in OpenCBM).
Are you sure your cable was on the serial port of the PC? All X-cables I heard of use the parallel port.
Serial 1541 flash beating parallel 2031 = Very surprising results to me.
Yeah, I don’t see how it’s possible. I did a regular load from basic afterward and confirmed the time with that.
i would guess that it's just a matter of how you talk to your multiplexer. Once the drive sent a byte, it can already fill up the register again. And send it as soon as the computer is done processing the first byte @@commodorehistory
It may be because of how complicated the handshaking is for the GPIB used to interface with the 2031. I'm speaking from experience, here. I tried to interface a 2031 (in what appears to have been a 1541 drive case but badged 2031) to a kit-built computer and it was mostly a success except that the drive itself seems to have had a subtle fault which caused disks to fail after only a few days in storage no matter what brand of disk you used, but I had to write the interface routines myself so I know how complicated a program needs to be to use the drive.
The only other thing I can think of is that the limiting factor was not the transmission method but the CPU speed within the drive case, and/or the RAM in the 2031 was slow and required "wait states" to allow it to catch up to the CPU.
The most amazing thing about this whole story is how successful the c64 was in spite of its numerous bugs that had real world effects that users had to deal with constantly.
Great videos, Dave! Enjoyed every minute!
Thanks for the update. You should repeat this test with Fast Load cartridge and of course with JiffyDOS. They are the most widely used disk drive accelerators, it would be nice to see how they compare with each other and with 1541 Flash. Yes, I know there are some test videos out there but all with loading games etc. This kind of bare bones testing will be more honest.
A bunch of folks mentioned this. I’ll try to put something together. Thanks for the feedback!
@@commodorehistory That's great!
Excellent, thanks for the update. Subscribed.
Thanks for the sub!
Thanks for correcting the record. I knew those original results were WAY off the mark.
You're welcome! I should have corrected them in the original video but I had already put so many hours into the video I didn’t have the motivation to do so. Live and learn…
I would like to compare Commodore Plus/4 and C1551 disk drive as well (parallel port).
These numbers better reflect the changes to performance that the cost reductions had. I still remember comparing Oregon Trail which would load to menu on my Apple in about 10 seconds, and then each load after that was generally only 2 or 3 seconds. And that was a game written completely in basic. The C64 with the same game, did have better graphics and what not, but it was always 90 seconds to load anything. That was always a turnoff for me when looking at getting another system to play with back in the day.
Nice video. Could you make Something like Diskturbo. That would be very interesting
thanks for the suggestion. I'll see what I can do.
Te Obliterator URL should be in your notes just under the video.
Hi. These times make more sense that those of your previous video. Yet, the floppy peak data rate is about 21KB/s (for the slower inner tracks), so, even the 2040 is wasting 90% of the time during the reading. Sure, sector interleaving and track changes can reduce the effective data rate a lot. But there is an Apple2 game, Lode Runner, that gets loaded in almost no time because it reads the sectors in any order they pass under the disk head, so it takes only a little more than a revolution to read a whole track. A trick like this isn't possible for Commodores, and this makes me question what are the advantages of having a separate computer for the floppy when the main CPU has nothing to do but to wait for the data?
The DOS code can live inside the disk drive and not consume any system memory.
It'd be useful to include JiffyDOS in the benchmarks as the established leader of 8-bit Commodore disk turbos to see how far it's from the speed potential of a working shift register. Practically every 8-bit IEC-bus Commodore (VIC-20, C64, C64, SX64, C128, C128D, C16, and Plus/4) machine and IEC disk drive (1540/1541, 1571 and 1581) is supported by JiffyDOS, and it's extremely compatible. The only drawback is that it replaces the cassette ROM routines since it lives in the same address space.
Another drawback is that the original hardware must be modified. I prefer a fast loader cartridge - no modifications needed, and it does not only spare the tape drive, but speeds that up as well.
@@NuntiusLegis There's no reason why you couldn't use JiffyDOS as a cartridge. Ultimate1541 cartridges for instance allows you to replace the C64 ROMs on the fly with whatever else you have stored. On the drive side you'll however need to swap the ROM. You could also use higher capacity ROMs on the C64 and drive side and use switches to map the higher bit address lines to switch between several different ROMs. Doing things like that are also period correct power user things, as were things like doing the parallel mod for the drive, working around the serial problem in the first place and getting the drive to work at PET drive speeds.
I prefer the Final Crtridge III, which is not just a speeder for disk AND tape, but also a freezer, a nice BASIC toolkit, a machine language monitor, etc. And no ROM change or anything, just plug & play.
@@NuntiusLegis Ultimate1541 has support for FC III as well and many many other things, including REU and of course the drive and cassette emulator, networking and so forth.
@@jammi__That costs five times as much as a FC III, I prefer the real drives over emulated ones, and the "support" for other cartridges (these being included in the firmware) is probably illegal.
Nice follow up, thanks. It’s still faster than Tape which we had to deal with here in Europe. Well, me as a kid anyway.
Tape witth fastloader is faster than disk without fastloader.
You mentioned some kind of ram in the drives. Does this act as a cache? If so, you need to clear it before you do the read test. (on the first machine)
I'm pretty sure no 5.25" Floppy drive will try to cache anything in the modern definition of cache you are implying. They will not even keep track of the fact if you have replaced the disk between writing and reading.
Also I don't think it would have helped at all. The actual reading speeds from the disks should be able to keep up with the 300 RPM (or 5 Hz) rotation, so for a nice sequential file stored on the (at least) 17 sectors of a single track to be read in 0.2 seconds, the transfer speed of the read-head needs to be at least 17*256/0.2 = 21.8 KB/s. So these drives will generally be able to read a single sector from the disk into their RAM very quickly (and cache it in that sense), but then it takes most of the time to actually push the data through the communications link to the computer.
@@ShieTar_ But the 1541 isn't just a floppy drive -- the unit is complete computer with its own CPU, RAM and ROM.
The commodore DOS code was analyzed at a detailed level in the book “Inside Commodore DOS”. There is no caching. It’s a tremendous reference, so if that kind of thing is interesting to you, I highly recommend it.
How do you know the drive wrote the data to sequential sector.