I can confirm that Scott Nelson (me) is not dead yet. Minor Quibble: Fastload was only almost a normal cartridge. It had a tiny bit of hardware magic that let it swap out the cartridge. (It's just a capacitor and a resistor.) Reading memory from $f400 would slowly swap in the cartridge. Not reading from cartridge memory for a while swapped it back out. I asked for a "real" switch, but that would have been a whole gate, adding maybe $0.30 to the parts cost, which was more than Epyx was willing to pay for. If you want to look at the code using Fastload's debugger, you can either modify the cart to always pull that line low, or write some code that reads from $f400 a lot, then make a copy into ram. Fastload does what it does without blanking the screen (or turning off the sprites, which /also/ cycle steal). If you want to know what can be done if you /do/ blank the screen, take a look at the vorpal disk enhancer. (same code was also used in the Barbie(tm) game) Fastload is about 5 times faster. Vorpal is about 25 times faster. There might even be some Wondermat formatted diskettes still floating around (which might make sense to you if you know what a Formaster machine was).
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.
I reverse engineered the Fastload cart a while back and the best non technical explanation is : magical hamsters. This video however gives the best accurate technical explanation.
Exactly what I explained back in 1985. I was rebuffed and told what I said was impossible and that FastLoad spun disks faster and destroyed them!! The destructive power of urban legends.
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.
@@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!
@@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.
Topic idea: my uncle ordered a seemingly uncommon interface device from a company called "Interpod" that let us use an 8050 with a C64. Even though the 8050 was an older design, it was built like a tank, didn't overheat, offered more storage and disk duplication. Those "Interpod" boxes might be interesting to explore for ten minutes of video.
I've been searching for an explanation on fast loader cartridges for years! And to think this particular product was available so soon after the C64's introduction to market - and with very few dev tools or shared experience
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.
The SD2IEC guys implemented many of the common fast load protocols by analyzing and reverse engineering them like you did in this video. This is an impressive amount of work. I found it easier to just emulate the entire drive including the 6502 and the two 6522s.
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 :)
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.
I want to put emphasis (as a 32 year / experience developer) how much work this video represents, and how it passionnate me to listen to :) because i grew up with a C64 but never really understood fast load mecanics. The only faster thing was the 21 seconds backup by charles leborgne but had a parallel cable from the user port to the 1541 pia. This was a completely different purpose. I love how epyx "inserted" themselved into the existing desing, it's almost a piece of art !
Thanks for the thorough research and explanation. Comparing this to the fast load and save routines that my brother and I wrote, I see two differences. First, we disabled interrupts and blanked the screen so we didn't have to worry about bad lines. Second, we only synced once every 256 bytes. We sent 11K bytes per second.
Many thanks for that great explanation! One thing I learned was that it was monitoring the VIC-II chip for badlines, so it would be able to run even with the screen enabled. Ingenious!
Great analysis and description. Back when I was a teenager I wrote my own fast loader very similar to the way Fastload uploaded the fastload code to the 1541. It was semi-fast still bit banging 1 bit per clock but not AS fast. Always wondered how Epyx did it. But they're both still held back by the underlying disk service routines which took their own time to load a block, decode it, put it into buffer etc. Then there was Vorpal Load which was all kinds of next level insanity including its own custom disk format...
Wow, what a great idea for a video; thanks for putting the time into presenting it so clearly. I would never have guessed that there was this remote execution option that you explain at around 17 minutes!
Brilliant explanation of the Epyx Fast Loader. When the devices are in sync like that you can really send data rather quickly as you show. For the C64 OS hobby project I was doing a while back, I used Covert Bitops 1 bit fast loader as it could also be used with IRQs and was very resilient that way and I wanted loading to go in the background since the whole "demo effect" of my OS was that it could multitask and update other apps running while one of them were loading something from disk. Its only around 3.3 times faster than kernal though - not a lot but still good for my purpose and faster.
I just discovered your channel as this video was recommended to me on Twitter. What a great video, I loved every bit of it and you’ve gained a new subscriber. I recently learned 6502 by writing a disassembler which i then further modified to become an emulator. Then i rewrote it having learned a lot and i’m slowly trying to make it into a Plus/4 emulator. There’s a few videos documenting the progress of this v2 of it on my channel. Thanks again!
I've been so curious for so many years how this worked. So glad you figure it out! The other one I've been dying to know about is how GEOS implements their own fastloader since the drive seek seems to work and sound way different. There doesn't seem to be any info about GEOS's version out there
Once again but not as often as I'd like, the YT algo recommends something really worth watching. Subbed, will be watching more of your stuff and would love to see a comparison of the different fastload payloads, bus format and overall speed. One that I've always wanted to learn about is Vorpal Kit, also by Epyx. Cheers!
This video was so interesting and well-done. Thanks so much for your time, effort and research in putting this together! I'd never seen a wire-level analysis of Commodore IEC bus communications. Even better, followed by an explanation of how a well-known fast loader speeded it up. Nice!
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.
FANTASTIC Video! I just finally got a chance to watch it without interruption. Thanks for taking the time to make this one! I just did a more beginner focused thing with logic analyzers and I am going to point folks this way to look at a real world straightforward example that shows how useful they are in seeing how things work on the wire(s).
It had issues with some copy protection schemes but it didn't take long for companies to create their own fast load routines for their games and still have copy protection. Back in the day I had JiffyDOS installed that could be turned off when necessary and no cartridge needed (it also had other nice features built in). I believe JiffyDOS is still being sold to this day. Another interesting speed up scheme was for the tape drive. One that stands out to me is "Turbo Tape" which was a type in program from a magazine ("Compute's Gazette" if I remember correctly).* The nice/weird thing about TT was that you needed it to SAVE your program to tape, but it was NOT required when loading and it still worked great and loaded very fast. In fact it was several times faster than a stock 1541. * Man I miss those good old type in programs from magazines, even if they had errors in them 50% of the time!
@@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 very much for posting this video. There seems to be very little information on the Internet about how it works in detail - reading the SD2IEC project code helps but that doesn't explain what's going on. Fortunate timing-wise for me as well, I bought an Epyx Fastload cartridge about the same time as this video was posted. I was hoping I could get it to work with an Arduino/PC loader program I've been working on (like a simpler SD2IEC but no SD card, uses serial port instead). Your video has been a great help in getting this to work, probably wouldn't have happened otherwise. Many thanks 😊
Very nice. I love how you actually showed example transmissions. There is other info on the net available, however you might be the first for epyx fastload in particular especially to that detail. The c64 wiki shows some disassembly of some other products and explains a bit. But before your video here the best and most comprehendaable video so far was done by MICHAEL STEIL and is called THE ULTIMATE 1541 TALK. Have you seen it? It was a very good live talk and spends more time in history but also gets into detail later. It doesnt specifically show one specific fsstloader, but brings many examples and what techniques they used often in combination to improve the speed. Anyone having seen your video might be interested in that other aswell, it is also on UA-cam :) Michael also did great talks about the c64 and the 6502 cpu familiy in high but understandable detail.
Really enjoying this. You have done a service to humanity with this vid. I don't know if UA-cam still lets you create "living documents" but it would be great to see added - any new details/corrections/insights that grow over time. If not, there's always an option to upload an enhanced version later. 25:00 Probably more accurate to say the VicII borrows bus cycles, rather than CPU cycles. Though the IEEE Spectrum VicII timing cycle chart might(?) not be 100% accurate, it might have been useful to explore exactly what's going on here (personally I would love to know if there's any wasteful DMA going on related to Sprites even when they're off). 25:48 Really need to know how you're selecting start and stop for each measurement because they're not all the same. The two previous measurements were for single cycles. The 3rd measurement was for 2 cycles. 26:44 But aren't there various software wedges even faster than Epyx Fastload? Krill loader maybe? 27:15 Would be useful to know what the name of the "previous video" is so people can search for it. 28:49 I sure hope Suburu is compensating you for the free ad space. :-)
It's interesting to think that the Commodore 64 had one of the first universal serial buses back in the day, which is something that everyone takes for granted now on their computers. One port with a daisy chain of peripherals. I remember having dual drives and a printer attached this way when I was in college in the 1980's.
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).
Great video. I wasn't a Commodore boy, but I always enjoy seeing a well presented video about a cool piece of software from the 80's. I think this will be a nice go to reference for that C64 fast loader.
I worked with a guy who worked on the C64 and 1541 design. He argued for using more that one data line, like the PET drive, but lost out because upper management wanted the cheapness of the 1 bit line.
Same. When I was a kid, Fastload was what I could afford. There were much faster solutions on the market over the years, but I was so grateful to have Fastload.
And the neat thing about this is that none of it requires special chips or anything else that takes advantage of FastLoad being on a cartridge, aside from not needing to swap disks around. It's just a program that runs off the ROM. So you could put that same program on a disk and have it run as the first step of booting a program, and speed up the boot process the same way. Which is exactly what software companies did once they figured out their own methods to override the 1541's routines (and Epyx, I presume, just stuck this exact loader onto all of their own games). In fact, if anything, there's a drawback to being on a cartridge you're expected to leave inserted and forget about, and probably the reason on-disk fast loaders were able to break Epyx's speed record: Epyx doesn't know if you're going to want to leave the cartridge in while you're working with multiple drives or other serial devices like a printer. An on-disk loader knows that all you're doing right this moment is loading their game, and won't be touching your other devices until you're done playing and do a full reset. So it's free to monopolize that connection and transfer the data as quickly as it physically can. Actually, now that I type that out loud, I wonder if any fast loader routines required you to power-cycle the 1541 afterward in order to purge the custom loader from its RAM and be able to use the drive normally again.
I didn't have the Epyx, but I did have the Expert Cart. It had a burst mode that loaded games in about 3 seconds. Even though this mode was something I seldom used, the speed was impressive.
At the end is a good explanation as to why commodore created a slow and reliable serial bus protocol on their original c64 hardware but it really boggles the mind why they didn't update the serial bus to use something like fastload when they re-released the c64 and 1541 drives many years after the initial release.. having a drive that was greater than 5x faster would have been a major selling point for almost zero additional cost.
Actually the design wasn't that way because reliability was favored over speed, it was that way because the original faster transfer method couldn't be used when the first disk drives appeared, thanks to a hardware bug, so they had to implement a slower transfer mode in software to work around that bug and even though later hardware did not have this bug anymore, the alternative software method had to be kept otherwise only specific versions of drive and computer would be able to work together. Today that would be solved by updating the driver of the OS, updating the firmware of the disk drive or both. But in the 80s, you couldn't just load a firmware update over the Internet and the drivers where hardcoded into your operating system kernel which was stored on a ROM. The loader module from Epyx is the "code distribution method" of its time and it does exactly what we would do today: It patches the OS and the drive's firmware. This patching just isn't persistent.
you know whats wild the fastload plus the sd2iec work together to go even faster loading wise, they coded to work together and it makes the C64 blitzing fast, theres even a version of GEOS for SD
Fantastic video! Is there anything special about the ATN line? Any reason you couldnt use it for a 3rd bit, assuming you only have one drive on the bus? Also, does the fastload upload the drive code every time you load, or does it retain it for subsequent loads? I have a vague recollection of the Epyx FL blanking the screen to avoid badlines - am I misremembering? It's still impressive that 2bit loaders works without a synced clock. I guess there's a hard limit for the number of bytes you could send before the clocks become too desynced? After all, the 1541 runs at 1Mhz, whereas the c64 runs at 0.985MHz (PAL) or 1.023MHz (NTSC).
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!
This "slower to load than stock" thing also affected some game collections on tape. A good example is the Cascade 50... it could have been done much wiser. It had the turbo loader written to the tape for each game with the trbo data following it. -For a good few games it would have been way faster to save the game with stock protocol -It might have been even faster to store the turbo loader twice on each side of the tape, so there will be backup for a corrupt part, but then have multiple games stored sequentially with their turbo data only. Of course this would have required file names to be stored in the turbo data, which would have been closer to how TurboTape etc worked. -One extremely unsettling thing with Cascade 50 was that despite the turbo you would wait several minutes staring at the light blue screen with no clue if anything was actually loading. No alternating color bars, no progress indicator of any kind.
Just found your channel, and I learned a lot from this video. The last section of the video, though, the audio was WAY too low. Even with my laptop volume and UA-cam volume both at 100% (and these laptop speakers are LOUD), I couldn't understand most of what you said.
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.
Extremely interesting. Never owned a C64, but used them once or twice. Often wondered why the 1541 was so much slower than the 4040 drive on my school PET. How about a similar video for the Atari 1050 with a US Doubler and SpartaDOS ?
it would have been super cool, if the CIA chip had a 64 bytes FIFO integrated and then run with 115kbaud. the FIFO - even just 8 FIFO bytes would have been good enough to relieve the cpu from constant polling. once per PAL line would have been enough to read out the data and store it somewhere. that would have been good enough to load fast data in the background and still have a program running. just these 8 bytes of serial FIFO would have been good enough to beat every machine out there at this time.
Whilst we're on the subject of speeding things up. I remember on another 8bit machine finding a type-prog to speed up the Print Command. The actual code to use Print in basic was situated or Called at a certain address. The type-in program moved that address location to somewhere far earlier in the computers memory. The program when run was indeed quicker, especially if you were moving many characters around the screen.
@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
Wonderful video! One question I have is regarding the track seek time. The C64 dictates the sending speed, but does the 1541 have any method to tell the 64 to "wait" to receive the next block of data as the drive is not ready yet (and is still seeking the data), or is it assumed the drive always pre-buffers faster than the C64 can accept over the wire?
Fantastic analysis of this cartridge, once again I totally understand how that works now thanks to how you have explained it. One question regarding the design of the 1541 memory map if I may ask? Back at timestamp 15:41 I see that Commodore mapped the VIA I/O spaces to $1800 and $1C00, was there any reason that they chose these specific locations for the I/O space? Was it an internal hardware consideration? I would appreciate any insight that you or any viewers could provide 👍
Cool! Never had any of these types of carts for my C64, so my 1541C... My own small projects would not have been speed up as much I guess then anyway... and Games/Demos probably at least had RLE compression/encoding (with I guess this type of faster "protocol") via a "loader" routine. I would maybe tried to do a RLE type of protocol but that would mostly been slower I guess and take more space on disk...
Awesome analysis and explanation of the tech behind the FastLoader. Aside from modern replacements like SD2IEC and JiffyDOS, did anyone ever just update the 1541 ROMs to include updated fast loader-type code and other bug fixes (or work-arounds)? *Edit: I re-discovered the "1541 Flash!" from your previous video on the 1541 slow speed, so I guess that answers my question. But I was also thinking of whether someone had done a ROM-only software upgrade/swap.
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.
I always thought that the different fastloaders sent their code to the 1541 during the boot phase of the C64 (the black screen)... Seems I was wrong...
Wasn't the C64 disk loading so slow, because it was made to be compatible with the VIC 20? And the VIC had some error in it's serial chip, so Commodore had to bodge it at the last minute and have the VIC use a slow software routine? And then to remain compatible the 1541 used that protocol, even though the C64 far outsold the VIC. So fastloaders just ran their own software on both ends, running in RAM on both the computer and the disk drive, to do it much faster, as Commodore ought to have done from the start?
@@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.
@@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 UA-cam 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!
When on the C64 were you loading a PRG and printing at the same time? I don't think there was much worry about multiple device accessing the peripheral bus at the same time!
Fastload uploaded code with each load command, except if you were loading the directory. Not much worry about other devices accessing the bus, but if the c64 were to attempt to use ATN for data, it would confuse other devices on the bus.
I had a C64c and the Diskdrive(in fact I still have them). for some reason the fastload cartridge totally past me by. no idea why I didn't get 1 back in the day.
And what happened on second access to the same disk drive? Was the fastload code transferred again? Or was it already active and left operating by a next reboot?
Want their a middle ground answer why it was so slow? You simplified it way down but I recall it being EXTRA slow from factory due to a bug in addition to handling the kitchen sink. So it shouldn’t have been quite as slow as it was? Am I misremembering that?
Did the Epyx Fastload code need to be read first for every file operation, or was it done just once, the first time the 1541 was used after a power cycle?
There are no smarts in the code. It uploads to the drive with every load. I linked to the disassembly in the description of the video so you can check it out.
I read that Commodore intentionally made the 1541 as slow as it was to maintain compatibility with the VIC20. There was a brief period in 1982 where the 1540 drive which was made for the VIC-20. The C64 didn't work well with the 1540, so the 1541 was basically a 1540 with a fix to make it compatible with the C64. Also, the 1541 was backward compatible with the VIC-20. So more than anything, you can blame the VIC-20 for the C64 being so slow for all those years. However when the C64C shipped in 1986, Commodore really should have either licensed Epyx's Fastload to have it on the ROM for bootup, where C64C users can have access to the additional speed boost without needing a cartridge. Come to think of it...imagine if the C64C shipped with an extra 512K ram, a built in 3.5 inch floppy and a mouse? That really would have made the bundled copy of GEOS sing. Also, programmers would have been incentivized to make use of that extra ram. In every respect, this is what Apple did with the AppleII series computer. The name remained the same, but Apple kept updating/expanding, yet keeping the "Apple II' name. Commodore really should have done the same with the C64...also improve BASIC, but keep it backward compatible!!!! Coulda, Woulda, Shoulda. I miss Commodore.
@@commodorehistory Just watched it. Amazing vid! This is why UA-cam 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!!!
I never had c64 but i always wondered if 1541 can be used as coprocessor, and i see it can, but with limited amount of data due to transfer speed. I wonder if it is it possible to load data from disk to 1541 memory
Probably works the same way the fast disk copier worked. Turn off the screen, disable interrupts, and use both clock & data lines as 2 data lines. Need to have perfect timing since you don't have a clock signal.
I can confirm that Scott Nelson (me) is not dead yet.
Minor Quibble:
Fastload was only almost a normal cartridge.
It had a tiny bit of hardware magic that let it swap out the cartridge. (It's just a capacitor and a resistor.)
Reading memory from $f400 would slowly swap in the cartridge.
Not reading from cartridge memory for a while swapped it back out.
I asked for a "real" switch, but that would have been a whole gate, adding maybe $0.30 to the parts cost, which was more than Epyx was willing to pay for.
If you want to look at the code using Fastload's debugger, you can either modify the cart to always pull that line low, or write some code that reads from $f400 a lot, then make a copy into ram.
Fastload does what it does without blanking the screen (or turning off the sprites, which /also/ cycle steal).
If you want to know what can be done if you /do/ blank the screen, take a look at the vorpal disk enhancer.
(same code was also used in the Barbie(tm) game)
Fastload is about 5 times faster.
Vorpal is about 25 times faster.
There might even be some Wondermat formatted diskettes still floating around (which might make sense to you if you know what a Formaster machine was).
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? 😂
I reverse engineered the Fastload cart a while back and the best non technical explanation is : magical hamsters. This video however gives the best accurate technical explanation.
Are the hamsters re-newable? And is the initial handshake done with muesli or vegetables?
Exactly what I explained back in 1985. I was rebuffed and told what I said was impossible and that FastLoad spun disks faster and destroyed them!! The destructive power of urban legends.
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.
Topic idea: my uncle ordered a seemingly uncommon interface device from a company called "Interpod" that let us use an 8050 with a C64. Even though the 8050 was an older design, it was built like a tank, didn't overheat, offered more storage and disk duplication. Those "Interpod" boxes might be interesting to explore for ten minutes of video.
I don't know why the UA-cam algorithm recommended this video, but I'm so glad it did! It always seemed like magic.
I've been searching for an explanation on fast loader cartridges for years! And to think this particular product was available so soon after the C64's introduction to market - and with very few dev tools or shared experience
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.
The SD2IEC guys implemented many of the common fast load protocols by analyzing and reverse engineering them like you did in this video. This is an impressive amount of work. I found it easier to just emulate the entire drive including the 6502 and the two 6522s.
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.
I want to put emphasis (as a 32 year / experience developer) how much work this video represents, and how it passionnate me to listen to :) because i grew up with a C64 but never really understood fast load mecanics. The only faster thing was the 21 seconds backup by charles leborgne but had a parallel cable from the user port to the 1541 pia. This was a completely different purpose. I love how epyx "inserted" themselved into the existing desing, it's almost a piece of art !
Wow, thank you!
Thanks for the thorough research and explanation. Comparing this to the fast load and save routines that my brother and I wrote, I see two differences. First, we disabled interrupts and blanked the screen so we didn't have to worry about bad lines. Second, we only synced once every 256 bytes. We sent 11K bytes per second.
Many thanks for that great explanation! One thing I learned was that it was monitoring the VIC-II chip for badlines, so it would be able to run even with the screen enabled. Ingenious!
Great analysis and description. Back when I was a teenager I wrote my own fast loader very similar to the way Fastload uploaded the fastload code to the 1541. It was semi-fast still bit banging 1 bit per clock but not AS fast. Always wondered how Epyx did it. But they're both still held back by the underlying disk service routines which took their own time to load a block, decode it, put it into buffer etc. Then there was Vorpal Load which was all kinds of next level insanity including its own custom disk format...
Wow, what a great idea for a video; thanks for putting the time into presenting it so clearly.
I would never have guessed that there was this remote execution option that you explain at around 17 minutes!
Brilliant explanation of the Epyx Fast Loader. When the devices are in sync like that you can really send data rather quickly as you show. For the C64 OS hobby project I was doing a while back, I used Covert Bitops 1 bit fast loader as it could also be used with IRQs and was very resilient that way and I wanted loading to go in the background since the whole "demo effect" of my OS was that it could multitask and update other apps running while one of them were loading something from disk. Its only around 3.3 times faster than kernal though - not a lot but still good for my purpose and faster.
I just discovered your channel as this video was recommended to me on Twitter. What a great video, I loved every bit of it and you’ve gained a new subscriber. I recently learned 6502 by writing a disassembler which i then further modified to become an emulator. Then i rewrote it having learned a lot and i’m slowly trying to make it into a Plus/4 emulator. There’s a few videos documenting the progress of this v2 of it on my channel. Thanks again!
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've been so curious for so many years how this worked. So glad you figure it out! The other one I've been dying to know about is how GEOS implements their own fastloader since the drive seek seems to work and sound way different. There doesn't seem to be any info about GEOS's version out there
Once again but not as often as I'd like, the YT algo recommends something really worth watching. Subbed, will be watching more of your stuff and would love to see a comparison of the different fastload payloads, bus format and overall speed. One that I've always wanted to learn about is Vorpal Kit, also by Epyx. Cheers!
This video was so interesting and well-done. Thanks so much for your time, effort and research in putting this together! I'd never seen a wire-level analysis of Commodore IEC bus communications. Even better, followed by an explanation of how a well-known fast loader speeded it up. Nice!
Those out-takes. It's like trying to say How much code can the fast code load if the fast code could load code! Great video! 😎
Most folks don’t stick around to watch them :)
Beautiful job using those 'scope trace graphics.
Thank you! I've always wondered what Epyx, CMD, etc.. did that the kernal developers didn't have time to implement.
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.
FANTASTIC Video! I just finally got a chance to watch it without interruption. Thanks for taking the time to make this one! I just did a more beginner focused thing with logic analyzers and I am going to point folks this way to look at a real world straightforward example that shows how useful they are in seeing how things work on the wire(s).
It had issues with some copy protection schemes but it didn't take long for companies to create their own fast load routines for their games and still have copy protection. Back in the day I had JiffyDOS installed that could be turned off when necessary and no cartridge needed (it also had other nice features built in). I believe JiffyDOS is still being sold to this day.
Another interesting speed up scheme was for the tape drive. One that stands out to me is "Turbo Tape" which was a type in program from a magazine ("Compute's Gazette" if I remember correctly).* The nice/weird thing about TT was that you needed it to SAVE your program to tape, but it was NOT required when loading and it still worked great and loaded very fast. In fact it was several times faster than a stock 1541.
* Man I miss those good old type in programs from magazines, even if they had errors in them 50% of the time!
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 very much for posting this video. There seems to be very little information on the Internet about how it works in detail - reading the SD2IEC project code helps but that doesn't explain what's going on. Fortunate timing-wise for me as well, I bought an Epyx Fastload cartridge about the same time as this video was posted. I was hoping I could get it to work with an Arduino/PC loader program I've been working on (like a simpler SD2IEC but no SD card, uses serial port instead). Your video has been a great help in getting this to work, probably wouldn't have happened otherwise. Many thanks 😊
I’m so happy you found it helpful. Thank you for taking the time to comment! Good luck getting it to work!
Awesome work Dave, those logic analyzer animations were especially amazing!
Thank you Robin!
So the drive is just spinning the disc on the slow move waiting for things to send. Love the deep dive!
Wanted to let you know how awesome this was. Thank you! I’m slowly getting my head wrapped around the C64 and how it worked.
Thanks for watching, and for taking the time to comment. I appreciate it!
Awesome deep dive and excellent presentation, thanks for sharing this!
Very nice. I love how you actually showed example transmissions.
There is other info on the net available, however you might be the first for epyx fastload in particular especially to that detail.
The c64 wiki shows some disassembly of some other products and explains a bit.
But before your video here the best and most comprehendaable video so far was done by MICHAEL STEIL and is called THE ULTIMATE 1541 TALK. Have you seen it? It was a very good live talk and spends more time in history but also gets into detail later. It doesnt specifically show one specific fsstloader, but brings many examples and what techniques they used often in combination to improve the speed.
Anyone having seen your video might be interested in that other aswell, it is also on UA-cam :)
Michael also did great talks about the c64 and the 6502 cpu familiy in high but understandable detail.
Yeah man, I’m a huge fan of Michael’s site! I met him at VCF West last year.
Really enjoying this. You have done a service to humanity with this vid. I don't know if UA-cam still lets you create "living documents" but it would be great to see added - any new details/corrections/insights that grow over time. If not, there's always an option to upload an enhanced version later.
25:00 Probably more accurate to say the VicII borrows bus cycles, rather than CPU cycles. Though the IEEE Spectrum VicII timing cycle chart might(?) not be 100% accurate, it might have been useful to explore exactly what's going on here (personally I would love to know if there's any wasteful DMA going on related to Sprites even when they're off).
25:48 Really need to know how you're selecting start and stop for each measurement because they're not all the same. The two previous measurements were for single cycles. The 3rd measurement was for 2 cycles.
26:44 But aren't there various software wedges even faster than Epyx Fastload? Krill loader maybe?
27:15 Would be useful to know what the name of the "previous video" is so people can search for it.
28:49 I sure hope Suburu is compensating you for the free ad space. :-)
Fascinating and amazingly detailed video! Thank you Dave!
Great video, can't imagine the time it took to put that all together. Some day I hope to get deep enough back into this hobby to be at that level.
You can do it!
Very nice and thorough explanation! I appreciate the work you put into your videos and your level of knowledge.
It's interesting to think that the Commodore 64 had one of the first universal serial buses back in the day, which is something that everyone takes for granted now on their computers. One port with a daisy chain of peripherals. I remember having dual drives and a printer attached this way when I was in college in the 1980's.
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).
I've gotta' get one of those logic analyzer, thanks for the demo and the fine work exploring the Epyx product.
Hey, thanks for watching!
Finally a video about it !
I hope you dig it.
Great video. I wasn't a Commodore boy, but I always enjoy seeing a well presented video about a cool piece of software from the 80's. I think this will be a nice go to reference for that C64 fast loader.
Excellent work. Just the right amount of information explained clearly, perfect for my aging steam driven brain to accept.
Glad it was helpful!
This kind of visual explanation is great. Love it! Thanks.
Glad you enjoyed it. Thank you for watching!
Really cool stuff. Great editing and work on breaking it all down. Clever solution!
I knew the programmer of the Fastload cartridge. It was Scott Nelson at Epyx. Haven't seen him in years though, not sure how he's doing.
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.
I love this. Especially the sound effects. Sound effects make everything better. In real life too. :)
I worked with a guy who worked on the C64 and 1541 design. He argued for using more that one data line, like the PET drive, but lost out because upper management wanted the cheapness of the 1 bit line.
Who was the guy?
Thank you for sharing this information. Very nicely explained.
Glad it was helpful!
I had a Fastload in the late 80s. It was a game changer.
Same. When I was a kid, Fastload was what I could afford. There were much faster solutions on the market over the years, but I was so grateful to have Fastload.
And the neat thing about this is that none of it requires special chips or anything else that takes advantage of FastLoad being on a cartridge, aside from not needing to swap disks around. It's just a program that runs off the ROM. So you could put that same program on a disk and have it run as the first step of booting a program, and speed up the boot process the same way. Which is exactly what software companies did once they figured out their own methods to override the 1541's routines (and Epyx, I presume, just stuck this exact loader onto all of their own games).
In fact, if anything, there's a drawback to being on a cartridge you're expected to leave inserted and forget about, and probably the reason on-disk fast loaders were able to break Epyx's speed record: Epyx doesn't know if you're going to want to leave the cartridge in while you're working with multiple drives or other serial devices like a printer. An on-disk loader knows that all you're doing right this moment is loading their game, and won't be touching your other devices until you're done playing and do a full reset. So it's free to monopolize that connection and transfer the data as quickly as it physically can.
Actually, now that I type that out loud, I wonder if any fast loader routines required you to power-cycle the 1541 afterward in order to purge the custom loader from its RAM and be able to use the drive normally again.
I didn't have the Epyx, but I did have the Expert Cart. It had a burst mode that loaded games in about 3 seconds. Even though this mode was something I seldom used, the speed was impressive.
A really good deep dive. Thanks!
Glad you liked it!
What an awesome video, explaining really well what's going on. Brilliant, splendid job.
At the end is a good explanation as to why commodore created a slow and reliable serial bus protocol on their original c64 hardware but it really boggles the mind why they didn't update the serial bus to use something like fastload when they re-released the c64 and 1541 drives many years after the initial release.. having a drive that was greater than 5x faster would have been a major selling point for almost zero additional cost.
I assume to keep them compatible with the earlier revisions. Commodore did eventually correct this slowness with burst mode on the 1571.
Actually the design wasn't that way because reliability was favored over speed, it was that way because the original faster transfer method couldn't be used when the first disk drives appeared, thanks to a hardware bug, so they had to implement a slower transfer mode in software to work around that bug and even though later hardware did not have this bug anymore, the alternative software method had to be kept otherwise only specific versions of drive and computer would be able to work together. Today that would be solved by updating the driver of the OS, updating the firmware of the disk drive or both. But in the 80s, you couldn't just load a firmware update over the Internet and the drivers where hardcoded into your operating system kernel which was stored on a ROM. The loader module from Epyx is the "code distribution method" of its time and it does exactly what we would do today: It patches the OS and the drive's firmware. This patching just isn't persistent.
Check out my previous video on the topic: ua-cam.com/video/kaeFV0oZaps/v-deo.htmlfeature=shared
This is a great channel.. I've got various Commodore machines, and fun and interesting to watch all this stuff.
Welcome aboard!
GREAT JOB! Thanks for that interesting video!
Greetings, Doc64!
Thank you very much!
you know whats wild the fastload plus the sd2iec work together to go even faster loading wise, they coded to work together and it makes the C64 blitzing fast, theres even a version of GEOS for SD
Yeah, the sd2iec folks are super smart. I've been using sd2iec devices for many years and love them.
Subbed!!! Brilliant!
Awesome, thank you!
Nice to see such a knowledgable nerd with some muscles!
Fantastic video!
Is there anything special about the ATN line? Any reason you couldnt use it for a 3rd bit, assuming you only have one drive on the bus?
Also, does the fastload upload the drive code every time you load, or does it retain it for subsequent loads?
I have a vague recollection of the Epyx FL blanking the screen to avoid badlines - am I misremembering?
It's still impressive that 2bit loaders works without a synced clock. I guess there's a hard limit for the number of bytes you could send before the clocks become too desynced? After all, the 1541 runs at 1Mhz, whereas the c64 runs at 0.985MHz (PAL) or 1.023MHz (NTSC).
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!
The beauty of clock and data is that the timing isn’t critical
Just to clarify, for the fast load case, receiving a byte is CPU cycle timing critical / exact, but handshaking is not.
Thanks. This explains a lot. I had so many fast loaders, especially for tape games.
You're welcome!
Way above my head. Maybe sometime I will understand more. Very interesting.
Glad you enjoyed. Let me know if there's anything I could do a better job of explaining.
Hey, Thanks! Love the detail effort and explanation. Keep it up.
Thanks for watching, and for taking the time to provide positive feedback!
Now, THAT's what I call a clear and good explanation! Thanks!
Glad it helped! Thanks for taking the time to provide positive feedback.
This "slower to load than stock" thing also affected some game collections on tape. A good example is the Cascade 50... it could have been done much wiser. It had the turbo loader written to the tape for each game with the trbo data following it.
-For a good few games it would have been way faster to save the game with stock protocol
-It might have been even faster to store the turbo loader twice on each side of the tape, so there will be backup for a corrupt part, but then have multiple games stored sequentially with their turbo data only. Of course this would have required file names to be stored in the turbo data, which would have been closer to how TurboTape etc worked.
-One extremely unsettling thing with Cascade 50 was that despite the turbo you would wait several minutes staring at the light blue screen with no clue if anything was actually loading. No alternating color bars, no progress indicator of any kind.
Just found your channel, and I learned a lot from this video. The last section of the video, though, the audio was WAY too low. Even with my laptop volume and UA-cam volume both at 100% (and these laptop speakers are LOUD), I couldn't understand most of what you said.
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.
Incredible video and super well done, thanks
Thanks for watching, and thanks for taking the time to leave positive feedback!
thanks for going straight to the "how it works" without clickbaiting the info until the end! I subscribed!
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.
Would it be possible to share the sound effects you used for attention line pull high / pull low? Thanks!
It’s from epidemic sound
Extremely interesting. Never owned a C64, but used them once or twice. Often wondered why the 1541 was so much slower than the 4040 drive on my school PET.
How about a similar video for the Atari 1050 with a US Doubler and SpartaDOS ?
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.
it would have been super cool, if the CIA chip had a 64 bytes FIFO integrated and then run with 115kbaud. the FIFO - even just 8 FIFO bytes would have been good enough to relieve the cpu from constant polling. once per PAL line would have been enough to read out the data and store it somewhere.
that would have been good enough to load fast data in the background and still have a program running.
just these 8 bytes of serial FIFO would have been good enough to beat every machine out there at this time.
Whilst we're on the subject of speeding things up.
I remember on another 8bit machine finding a type-prog to speed up the Print Command. The actual code to use Print in basic was situated or Called at a certain address. The type-in program moved that address location to somewhere far earlier in the computers memory.
The program when run was indeed quicker, especially if you were moving many characters around the screen.
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
The wall of commodores made me cry. I wish I had kept my C64 and action replay.
Wonderful video! One question I have is regarding the track seek time. The C64 dictates the sending speed, but does the 1541 have any method to tell the 64 to "wait" to receive the next block of data as the drive is not ready yet (and is still seeking the data), or is it assumed the drive always pre-buffers faster than the C64 can accept over the wire?
Fantastic analysis of this cartridge, once again I totally understand how that works now thanks to how you have explained it. One question regarding the design of the 1541 memory map if I may ask? Back at timestamp 15:41 I see that Commodore mapped the VIA I/O spaces to $1800 and $1C00, was there any reason that they chose these specific locations for the I/O space? Was it an internal hardware consideration? I would appreciate any insight that you or any viewers could provide 👍
Honestly don’t know why they made those mapping decisions.
Cool! Never had any of these types of carts for my C64, so my 1541C... My own small projects would not have been speed up as much I guess then anyway... and Games/Demos probably at least had RLE compression/encoding (with I guess this type of faster "protocol") via a "loader" routine.
I would maybe tried to do a RLE type of protocol but that would mostly been slower I guess and take more space on disk...
Nice. How about a video about different fast loaders on tape?
Subscribed! Thank you for this and your other vids
Thank you for watching!
Good work! Thank you! That was very educational!
Thanks for watching, and for taking the time to write a positive comment. Much appreciated!
I've been searching for this video for years lol.
I've been wondering this for about 40 years. Now I know and can start wondering how other stuff works.😄
Great video!
Awesome analysis and explanation of the tech behind the FastLoader. Aside from modern replacements like SD2IEC and JiffyDOS, did anyone ever just update the 1541 ROMs to include updated fast loader-type code and other bug fixes (or work-arounds)? *Edit: I re-discovered the "1541 Flash!" from your previous video on the 1541 slow speed, so I guess that answers my question. But I was also thinking of whether someone had done a ROM-only software upgrade/swap.
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
Speeddos mostly was known only in EU countries and was available before dolphin dos. Fully parallel protocol modification.
Really cool video. I learned a lot. Subscribed!
Thanks for the sub!
Great video! Question: What happened to the ":" in m-w and m-e? I didn't see it on the bus view.
Guessing BASIC eats it? It's definitely not sent across the wire.
Epic collection!
Awesome video! Thanks!
Thanks for watching!
Great presentation! JiffyDos Next?
More than a little awesome to have you comment on a video I did. I’m a fan of your work. Thank you!
I always thought that the different fastloaders sent their code to the 1541 during the boot phase of the C64 (the black screen)...
Seems I was wrong...
Wasn't the C64 disk loading so slow, because it was made to be compatible with the VIC 20? And the VIC had some error in it's serial chip, so Commodore had to bodge it at the last minute and have the VIC use a slow software routine? And then to remain compatible the 1541 used that protocol, even though the C64 far outsold the VIC. So fastloaders just ran their own software on both ends, running in RAM on both the computer and the disk drive, to do it much faster, as Commodore ought to have done from the start?
If you have time, give my previous video a watch: Why Was the Commodore 1541 disk drive so slow?
ua-cam.com/video/kaeFV0oZaps/v-deo.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 UA-cam 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!
When on the C64 were you loading a PRG and printing at the same time? I don't think there was much worry about multiple device accessing the peripheral bus at the same time!
Fastload uploaded code with each load command, except if you were loading the directory. Not much worry about other devices accessing the bus, but if the c64 were to attempt to use ATN for data, it would confuse other devices on the bus.
Excellent video. Subscribed !!! 😄
Awesome, thank you!
A most excellent video.
curious to see how much faster 1541 FLASH + EPYX Fastloader would be TOGETHER
I had a C64c and the Diskdrive(in fact I still have them). for some reason the fastload cartridge totally past me by. no idea why I didn't get 1 back in the day.
And what happened on second access to the same disk drive? Was the fastload code transferred again? Or was it already active and left operating by a next reboot?
Can you test the OC-118N drive and compare it to the 1541?
Want their a middle ground answer why it was so slow? You simplified it way down but I recall it being EXTRA slow from factory due to a bug in addition to handling the kitchen sink. So it shouldn’t have been quite as slow as it was? Am I misremembering that?
My apologies for the self-promotion, but I did an entire video on why the 1541 was so slow: ua-cam.com/video/kaeFV0oZaps/v-deo.htmlfeature=shared
Did the Epyx Fastload code need to be read first for every file operation, or was it done just once, the first time the 1541 was used after a power cycle?
There are no smarts in the code. It uploads to the drive with every load. I linked to the disassembly in the description of the video so you can check it out.
I read that Commodore intentionally made the 1541 as slow as it was to maintain compatibility with the VIC20. There was a brief period in 1982 where the 1540 drive which was made for the VIC-20. The C64 didn't work well with the 1540, so the 1541 was basically a 1540 with a fix to make it compatible with the C64.
Also, the 1541 was backward compatible with the VIC-20.
So more than anything, you can blame the VIC-20 for the C64 being so slow for all those years. However when the C64C shipped in 1986, Commodore really should have either licensed Epyx's Fastload to have it on the ROM for bootup, where C64C users can have access to the additional speed boost without needing a cartridge.
Come to think of it...imagine if the C64C shipped with an extra 512K ram, a built in 3.5 inch floppy and a mouse? That really would have made the bundled copy of GEOS sing. Also, programmers would have been incentivized to make use of that extra ram.
In every respect, this is what Apple did with the AppleII series computer. The name remained the same, but Apple kept updating/expanding, yet keeping the "Apple II' name.
Commodore really should have done the same with the C64...also improve BASIC, but keep it backward compatible!!!!
Coulda, Woulda, Shoulda.
I miss Commodore.
Regarding your mention of why the 1541 was so slow, have a look at ua-cam.com/video/kaeFV0oZaps/v-deo.htmlfeature=shared
@@commodorehistory Just watched it. Amazing vid! This is why UA-cam 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!!!
I never had c64 but i always wondered if 1541 can be used as coprocessor, and i see it can, but with limited amount of data due to transfer speed. I wonder if it is it possible to load data from disk to 1541 memory
Yes, technically possible to use the 6502 CPU to co-process something. What you'd do with that limited RAM and slow transfer rate... no idea!
wanna try dolphin dos.. via parallel then.. flys. or even action replay's warp 25
Probably works the same way the fast disk copier worked. Turn off the screen, disable interrupts, and use both clock & data lines as 2 data lines. Need to have perfect timing since you don't have a clock signal.
Fastload doesn’t disable the screen. Watch the video and you’ll see that it monitors the raster line and avoids data transmission when badlines occur.