Hi Scott!!! It is so wonderful that you took the time to comment! I unsuccessfully attempted to contact you while I was working on this video because I had about a zillion questions for you. I did figure out how the cartridge code disappears and commented that in the disassembly I did. I put links in the description. Thank you soooo much for taking the time to comment. I really appreciate it! I was going to look at vorpal next.

25 times faster? Yikes! It's too bad that Commodore didn't incorporate some kind of fast drive code into the 1571 ROMs. Even 5 times faster is a big deal. 25 times faster would have been mind-blowing for the time.

While holding this cartridge in my hand and reading this comment. I've got to say, my mind is kinda blown! I can't get enough learning about how old school hardware works. Thank you

Scott Nelson, hero to an entire generation of computing! I am an Atari guy, but many of my friends had C64's and this cart was indispensable. One did not buy a C64 without this cart back then.

You might say that reports of your demise have been greatly exaggerated? 😂

You have been vindicated. The disassembly is there for everyone to see. Fastload doesn't do anything to modify the FDC code on the 1541. It just stuffs a job into the queue and lets Commodore's native FDC code spin the drive and move the head like it always does.

You’re definitely smarter than I was in 1985, that’s for sure lol

@@DerekLippold Telling the truth is usually a sign that you're not so smart. I could have used these people's false assumptions to make some gimmick and make a lot of money if I had been smart!

@@francoisleveille409 Yeah you could have made RAM Doubler!

@@clifffton I think you refer to SoftRAM but I barely got to know this one. When I got my first PC - after using the Amiga for many years - I went directly to Windows NT.

Are the hamsters re-newable? And is the initial handshake done with muesli or vegetables?

I was surprised by how complex Scott Nelson's Epyx Fastload implementation was. It required deep knowledge of the inner workings of the c64 and 1541, which wouldn't have been widespread in 1984. I tried contacting him to learn more about how he developed this, but wasn't able to get in touch with him.

Atari's SIO predates it by a few years (1979) and didn't have the transfer rate problem that makes it weird it took Commodore till the 128 to have the issue solved out of the box or the 1551 for the TED series if you want to include that but those drives were always rare and only works on the TED.

@@Psy500 Commodore's IEC bus was first available June 1980 in the VIC-1001, only ~8 months after the Atari 400/800 release in November 1979. Additionally, IEC is really just a serialized version of the IEEE-488 system they already had on the PETs since 1977 (though it wasn't working properly until 1978).

While I appreciate the kind words, I bow in reverence to your creation of pi1541. That's so far beyond my level of knowledge and ability I wouldn't know where to begin. Thank you for taking the time to comment, though. That is very kind of you :)

Mr. White is a legend.

Easier, and more versatile. My understanding is that some existing fast loaders and nearly all copy protection schemes interfere with the SD2IEC because they're expecting it to work exactly like a real drive. Since you're here though, I had a question: Is there any way that the Pi1541's emulator could run on a normal PC, for those of us who have one to spare? Or is it just not possible to get the timing precise enough without being coded to bare metal?

@@stevethepocket SD2IEC's firmware will perform a hash on the data sent to it via the M-W command. This way it can tell what loader, and hence, what protocol to use. If there is not a protocol implemented for that hash value then it will fail to work. No, Pi1541 will not work on a PC. They are very different. However, I have been working on something for all Shugart type drives (PC, Atari St, Amiga etc). It is like a Gotek and a Greaseweazle combined. It sits between the computer and an optional real floppy drive. You can use it in one of three ways, one as a floppy emulator, two as a device to image disks of the real floppy, or three lets you use the real floppy as normal. It can be installed internally and you interact with it via a cell phone via BluTooth.

@@commodorehistory I tried so hard, so many times to get the JiffyDOS protocole working in Pi1541's browse mode but still cant get it to work.

Wow, thank you!

Check out my previous video on the topic: ukposts.info/have/v-deo/o5GWeoxnppCS0ac.htmlfeature=shared

Thanks for the kind words! I subbed back, so I'll check out your videos. It sounds like some really deep info, so I look forward to it.

I too miss those type in programs, but only because my memory is failing.

@@networkgHa! Early type-in programs were super simple but later ones got quite sophisticated. I even remember a drawing program that had some impressive features, though only worked in "hi-res" mode. I think it was called "Doodle". I probably still have it on an old cassette somewhere...

Thank you Robin!

Thanks for watching, and for taking the time to comment. I appreciate it!

Hey, thanks for watching!

You can do it!

Glad you enjoyed it. Thank you for watching!

I hope you dig it.

Thanks for watching, and for taking the time to provide positive feedback!

Welcome aboard!

Glad you liked it!

The really sad part of this is that the 1541 could run a lot faster, but they used a serial protocol that didn't account for the 40 cycle drop out that occurred at the start of each line of text. There's a hardware chip that implements the serial protocol, and Commodore included that chip in the C64, but failed to connect to wires. Yep. Two jumpers is all it would have taken.

You're welcome!

Glad it was helpful!

I tried contacting him prior to making this video but I wasn’t able to :(

@@commodorehistoryI still see his ex-wife on social media now and then, but I didn't keep up with Scott after their divorce decades back.

I'm still around, but since there's not much call for 6502 programming these days, I moved on.

Yeah man, I’m a huge fan of Michael’s site! I met him at VCF West last year.

Glad it was helpful!

Thanks for watching, and for taking the time to write a positive comment. Much appreciated!

Thanks for the sub!

Most folks don’t stick around to watch them :)

Thank you very much!

Awesome, thank you!

Yeah, I’m still not great at video editing, but working to improve.

That was just a few bloopers included at the end anyway, I think.

I’m not familiar with it, but it sounds neat

@commodorehistory it was a machine code program written in basic for the amstrad cpc 464. It left me realising that grx commands like Line, Plot etc could also be speeded up to. But the turbo charged print routine allowed me to overlay several characters with different colours, essentially creating a multicoloured sprite. Cool times way back with the 8bits

Thanks for watching!

I’m staunchly opposed to clickbait. No fancy thumbnails. No deceptive titles. If I have to trick someone into watching my content, it’s not worth their time to watch it.

Awesome, thank you!

Hi Simon! I recall reading a FB comment at one point where someone claimed there were fastloaders that use ATN to transmit data. As you said, I think it could only work if there were a single device on the serial bus since Commodore's native DOS code responds to ATN going low by pulling DATA low. Epyx Fastload does upload the code every time you load a file. It doesn't blank the screen. It uses a table in memory that's indexed by RASTER ($D012) which causes it to hold data low, preventing the 1541 from sending another byte when badlines happen. As far as the clocks getting out of sync, they're not really in sync. At least not in the way a clock is typically used. The protocol syncs at the beginning of each byte. The moment the C64 releases the DATA line, the 1541sends 8 bits, then the 1541 goes back into a wait loop for the C64 to release the DATA line again. The code relies on exact timing for just one byte of transmission.

Hmmm, You'd think they'd leave the fast loader in 1541 ram and use some custom command to check if its in place. That way, all subsequent loads would be faster and would survive a C64 power-down or reboot. Also, it would be faster if the cart loaded up the drive(s) when its loaded. The C64 could even send another M-e command to start the custom loader, and let the drive act as normal unless the M-E is used. I don't know much about commodore computers, I had an Apple II E at that time, but thought I'd chime in anyway. great video, made me subscribe.

As @commodorehistory explained, Epyx FastLoad syncs after each byte is transmitted, so the slight difference in clock speed is not a problem. My brother @dannyepstein and I wrote our own fastload and fastsave routines back in the day. We had used various fastloaders but didn't know how any of them worked, so we came up with our own solutions. We were doing a lot of assembly language programming, so having faster save was also a high priority. We chose to sync only once every block of 256 bytes, then transmit all 256 bytes synchronously. So the 1MHz vs 1.023MHz (NTSC) clock speed was a big problem for us! We found a cycle count for both C64 and 1541 that had minimal clock drift after 256 bytes were transmitted, then wracked our brains to optimize the code on each end to run in that many cycles. Early prototypes were done sending sample data from a Commodore PET (1.0 MHz) to a Commodore 64 (NTSC). Once we got that working we worked out how to get the 1.0MHz code to run on the 1541 with its measly 2 kilobytes of RAM. One advantage of doing our own fastsave was that we could choose an interleave ratio that worked well with fastload. By default the drive used an interleave ratio of 10 to 1, so you had to wait for the 300RPM disk to turn about half a revolution to reach the next sector. I think we used a 4 to 1 interleave, but I'm not sure. By default the drive would simply wait a full revolution to read back the sector just written, verify it, and then spin another half revolution to reach the next block to write. That's 1.5 revolutions for each block written! Our approach was to write a bunch of sectors without verifying them, then verify them all in sequence on the next revolution. This meant sending each 256 byte chuck of data twice!

@@pepsteinvery interesting story, thank you for sharing!

Regarding your mention of why the 1541 was so slow, have a look at ukposts.info/have/v-deo/o5GWeoxnppCS0ac.htmlfeature=shared

​@@commodorehistory Just watched it. Amazing vid! This is why UKposts is so great...a place where once and for all we can figure out the 1541!!! It was the Commodore book "On the Edge" where I read about the backward compatibility. This new reason also makes sense, then again...Tramiel only wanted to ship product, he didn't care much for compatibility. The 1541 brings back so many memories! I remember once building a small/simple DC powered fan which I put on top of the 1541 vent (Those things really did get hot). I had dreams of mass manufacturing them and the untold riches I would make. I still remember the day I did the unthinkable and used scissors to cut a square gap the opposite side of a "Single Sided/Single Density" floppy. People in the schoolyard gave me dire warnings over doing this...and that 'Single Sided/Single Density" meant exactly that. DD/DS (Double sided/Double Density) floppies however costed more! Even after I showed them the hole punched disks giving me a whole new free side to use...my classmates criticized the hole punch as looking 'weird'. One also told me that this was 'hurting the floppy maker company' by literally 'hacking' the disk! There was an argued 'immorality' of ignoring the 'SS/SD' label. Yes, this is what we argued about...before discovering girls. You can never win if someone's mind is already made up: Was a lesson I learned. Thanks for posting these vids!!!

Yeah, the sd2iec folks are super smart. I've been using sd2iec devices for many years and love them.

My previous video goes into the history of why the 1541 was slower than the earlier drives. Check it out if you have a moment.

JiffyDOS is the most famous of the ROM-only upgrades, and while it's still commercially available, it was primarily developed from 1985-1989 so it's not really modern.

@@8_Bit I appreciate the reply and you are right, I mistakenly lumped JiffyDOS into the same era as SD2IEC. But in fiarness, JiffyDOS is still available and popular *today* among the retro hobby folks. So it may not be modern, but I would still consider it a 'modern solution' so-to-speak. :D My question revolved around whether 1541-only ROM upgrades - plug-n-play chip swapping - were ever developed that did not require upgrading the C64. I realize the speed issue was really a hardware problem on both sides, but I was just curious about drive-side only improvements, since it could be used with a number of computer models.

@@JimmPratt Commodore themselves did upgrade the 1541 ROMs somewhat to address some bugs over the years. I'm not sure if anyone's done a comprehensive review of these. But significant speed-up requires changes at both ends unfortunately. It's probably possible to eke out a very small speed-up just with 1541-side changes but I don't know of anyone implementing that.

There’s also burst mode commodore implemented on the 1571 and 1581

Honestly don’t know why they made those mapping decisions.

Guessing BASIC eats it? It's definitely not sent across the wire.

If you have time, give my previous video a watch: Why Was the Commodore 1541 disk drive so slow? ukposts.info/have/v-deo/o5GWeoxnppCS0ac.html

@@commodorehistory Ah OK, didn't know there was one! This video just came up as a suggestion, brand new, though I watch lots of videos about old computers.

@@greenaum yeah, I’m not popular enough for the algorithm to let folks know my content exists :)

@@commodorehistory It'll happen! You've got a fair amount of competition, there's a lot of channels on the same subject, now we 8-bit kids are getting middle-aged, and starting to have a bit more free time and money. But I think there's always room for a good one. Yours presents information you couldn't (and didn't) just get from other UKposts videos, you've clearly put the work in. You explain stuff people might have wondered about, and you present it well. You've got a decent chance I think!

It’s from epidemic sound

lol :) maybe? It’s from the SFX library on epidemic sound

@@commodorehistory ukposts.info/have/v-deo/nKOZZWmZlqB5s5c.html pretty close to some of them :)

My apologies for the self-promotion, but I did an entire video on why the 1541 was so slow: ukposts.info/have/v-deo/o5GWeoxnppCS0ac.htmlfeature=shared

They're on the other side of the room connected to my b128. You can see them over my shoulder in a previous video: ukposts.info/have/v-deo/o5GWeoxnppCS0ac.html

Very good video you made. This drive acceleration has always been a mystery to me.

As an Apple guy we did the same: _Commodore needed ANOTHER 6502 just for the drive? And it was slow as heck?! LOL_ 😂

Fast load was the ‘patch’ to the poorly designed I/O scheme

Thank you! I appreciate you watching and taking the time to comment

Yeah, most of them do. That said, they’re 40 year old computers, so I get regular surprises every time I power one on.