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 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".
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.
Readit News
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.
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.
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.
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.
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.
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.
Deleted Comment
Also, find it very difficult to find this newsworthy - sorta like being amazed that modern PCs can run MS-DOS.
Deleted Comment