I remember seeing a Mandelbrot program for the C64 where half the image was computed on the floppy drive because it's basically the same computer as the main C64. I think it had a 6502 instead of a 6510 and different memory.
I believe the Apple II floppy drive was "dumb", that is, controlled by the 6502 of the Apple II, so the machine couldn't do anything/much while loading/saving data. But the C64 + floppy drive was essentially a two-node distributed system.
That was because of the slow serial interface on the VIC and C64 side - IIRC, the UART required was removed from the 64 as a cost-cutting measure and it shipped having to bit-bang data to the drive. Overall, this is a very solid design idea.
With a little extra smarts, the drive could deal with ISAM tables as well as files and do processing inside the drive itself. Things like sorting and indexing tables in dBase II could be done in the drive itself while the computer was doing things like updating screens.
OTOH, on the Apple II, the drive was so deeply integrated into the computer that accelerator boards needed to slow down the clock back to 1MHz when IO operations were running. Even other versions of the 6502 would need to have the exact same timings if they wanted to be used by Apple.
The designers planned on using a shift register in the 6522 VIA chips to implement fast serial loading, but an undocumented bug in that chip forced them to fall back to the slow bit banging version that shipped
I don't know how many of you have seen a 1541 floppy drive in person either but it is massive, it's heavier and possibly bigger that an actual Commodore 64 and pretty expensive at the time too.
it's fun seeing c64 people on the defensive about it, a nice change from getting lectures from them about how their graphics were the pinnacle of 8-bit computing
Part of the size was the internal power supply. And that thing got hot, too. I used them at school, but at home only had the smaller 1541-II with an external power brick.
The Apple II disk drives, on the other hand, were not only cheap (Apple was different then!) and fast, but were powered by the ribbon cable connecting them to the computer.
Oh its MUCH better than that. Commodore did this because they had incompetent management. They shipped earlier products (VIC-20, 1540) with hardware defective 6522, but:
- C64 shipped with 6526, fixed version of 6522 without shift register bug
- C64 is incompatible with 1540 anyway
They crippled C64 and its floppies _for no reason_.
The 1541 is a computer, as defined by "can load and run a program". Enough protocol exists on the stock drive/IEC bus/software to do this. Fast load programs used this and I'm sure some copy protection schemes did.
But it's a computer in the same way as a bare-bones microcontroller with an ARM core is, say, the one in your car keyfob. Sure the CPU is capable but paired with just enough ROM and RAM to do the job it needs to do. And in the 1541's case that was only 2KB of RAM.
Just when I think the demoscene can't blow my mind any further, it breaks through another unexpected wall.
The part where he starts cutting into the cable threw me for a second before I realized where it was going, I actually yelled "WHAT?!" out loud. Seriously unconventional hacking.
Can you upload code to be executed on a stock 1541/1571? Would be fun to see the drive doing things like "read this file, but sorted on columns 3-10" or "add these two files line by line into a third file".
As usually the schematics were available in the manual it was not too hard to add some additional static ram. There were unused address lines available which could be used for chip select.
Can you upload code to be executed on a stock 1541/1571?
Yes. There were disk duplicators that ran entirely on the drives.
You'd upload the program to a pair of daisy-chained drives, put the source disk in one, and the destination disk in the other and they'd go about their business.
You could then disconnect the computer and do other things with it while making all the disk copies you wanted.
I've always wanted a modern equivalent. I thought FireWire might make it happen, but it didn't. And it's my understanding is that USB doesn't allow this kind of independent device linking.
The closest thing I've seen in modern times was a small box I got from B&H that would burn the contents of a CF card onto a DVD-RW.
I love the Commodore 64. I still have a working "portable" C64 that I turn on from time to time and play around with.
So what’s remarkable isn’t that a 1541 can run BASIC or process data internally, but that constraints and packaging decisions (cost-cut bit-banging, slow serial link) shaped a design that was, in practice, more distributed than a lot of modern “smart peripherals.” That’s both a lesson and a reminder: simple external interfaces often mask surprisingly rich internal behavior.
Main lesson was dont do it ever again. Manufacturing cost of C128D, a C128 with build in floppy, was higher than that of Amiga A500. Retail price was also close.
Because doing all the driving, decoding and serial comms pretty much required a computer anyway, so the most sensible approach was to use what they already had in supply.
Also, find it very difficult to find this newsworthy - sorta like being amazed that modern PCs can run MS-DOS.
I remember seeing a Mandelbrot program for the C64 where half the image was computed on the floppy drive because it's basically the same computer as the main C64. I think it had a 6502 instead of a 6510 and different memory.
I believe the Apple II floppy drive was "dumb", that is, controlled by the 6502 of the Apple II, so the machine couldn't do anything/much while loading/saving data. But the C64 + floppy drive was essentially a two-node distributed system.
Yeah the Apple II floppy drive read and wrote the sectors using a tight loop of a couple assembly instructions. So yes couldn't do anything at all.
And yet it was like 1/10 the speed of the Apple II floppy drive.
That was because of the slow serial interface on the VIC and C64 side - IIRC, the UART required was removed from the 64 as a cost-cutting measure and it shipped having to bit-bang data to the drive. Overall, this is a very solid design idea.
With a little extra smarts, the drive could deal with ISAM tables as well as files and do processing inside the drive itself. Things like sorting and indexing tables in dBase II could be done in the drive itself while the computer was doing things like updating screens.
OTOH, on the Apple II, the drive was so deeply integrated into the computer that accelerator boards needed to slow down the clock back to 1MHz when IO operations were running. Even other versions of the 6502 would need to have the exact same timings if they wanted to be used by Apple.
The designers planned on using a shift register in the 6522 VIA chips to implement fast serial loading, but an undocumented bug in that chip forced them to fall back to the slow bit banging version that shipped
I don't know how many of you have seen a 1541 floppy drive in person either but it is massive, it's heavier and possibly bigger that an actual Commodore 64 and pretty expensive at the time too.
it's fun seeing c64 people on the defensive about it, a nice change from getting lectures from them about how their graphics were the pinnacle of 8-bit computing
Part of the size was the internal power supply. And that thing got hot, too. I used them at school, but at home only had the smaller 1541-II with an external power brick.
The Apple II disk drives, on the other hand, were not only cheap (Apple was different then!) and fast, but were powered by the ribbon cable connecting them to the computer.
Oh its MUCH better than that. Commodore did this because they had incompetent management. They shipped earlier products (VIC-20, 1540) with hardware defective 6522, but:
- C64 shipped with 6526, fixed version of 6522 without shift register bug
- C64 is incompatible with 1540 anyway
They crippled C64 and its floppies _for no reason_.
The 1541 is a computer, as defined by "can load and run a program". Enough protocol exists on the stock drive/IEC bus/software to do this. Fast load programs used this and I'm sure some copy protection schemes did.
But it's a computer in the same way as a bare-bones microcontroller with an ARM core is, say, the one in your car keyfob. Sure the CPU is capable but paired with just enough ROM and RAM to do the job it needs to do. And in the 1541's case that was only 2KB of RAM.
Some demos offloaded work to the 1541 - https://csdb.dk/release/?id=820
Some run entirely on the 1541 - https://www.youtube.com/watch?v=zprSxCMlECA
Just when I think the demoscene can't blow my mind any further, it breaks through another unexpected wall.
The part where he starts cutting into the cable threw me for a second before I realized where it was going, I actually yelled "WHAT?!" out loud. Seriously unconventional hacking.
That's nothing; there's an Amiga demo where it runs in the machine without touching the Motorola CPU ever.
There's a whole open challenge[1] - but you might be thinking of this[2] prod.
[1]:https://github.com/askeksa/NoCpuChallenge [2]:https://www.pouet.net/prod.php?which=104753
Can you upload code to be executed on a stock 1541/1571? Would be fun to see the drive doing things like "read this file, but sorted on columns 3-10" or "add these two files line by line into a third file".
Yes you can, back in the day this is how fast loaders worked, they uploaded an optimized serial protocol to the ram on the drive and called into it.
Absolutely. The eprom of TFA was only needed for standalone usage. But 2K of RAM are not much.
As usually the schematics were available in the manual it was not too hard to add some additional static ram. There were unused address lines available which could be used for chip select.
Can you upload code to be executed on a stock 1541/1571?
Yes. There were disk duplicators that ran entirely on the drives.
You'd upload the program to a pair of daisy-chained drives, put the source disk in one, and the destination disk in the other and they'd go about their business.
You could then disconnect the computer and do other things with it while making all the disk copies you wanted.
I've always wanted a modern equivalent. I thought FireWire might make it happen, but it didn't. And it's my understanding is that USB doesn't allow this kind of independent device linking.
The closest thing I've seen in modern times was a small box I got from B&H that would burn the contents of a CF card onto a DVD-RW.
I love the Commodore 64. I still have a working "portable" C64 that I turn on from time to time and play around with.
So what’s remarkable isn’t that a 1541 can run BASIC or process data internally, but that constraints and packaging decisions (cost-cut bit-banging, slow serial link) shaped a design that was, in practice, more distributed than a lot of modern “smart peripherals.” That’s both a lesson and a reminder: simple external interfaces often mask surprisingly rich internal behavior.
Main lesson was dont do it ever again. Manufacturing cost of C128D, a C128 with build in floppy, was higher than that of Amiga A500. Retail price was also close.
Because doing all the driving, decoding and serial comms pretty much required a computer anyway, so the most sensible approach was to use what they already had in supply.
Also, find it very difficult to find this newsworthy - sorta like being amazed that modern PCs can run MS-DOS.