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.
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
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.
- 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 C64 data speed actually ended up being even slower than the VIC-20. You can read the full detailed here: https://imrannazar.com/articles/commodore-1541
They finally got it right in the C128 though!
Also, find it very difficult to find this newsworthy - sorta like being amazed that modern PCs can run MS-DOS.
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.
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.
leibnitz27•1mo ago
badc0ffee•1mo ago
slfnflctd•1mo ago
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.
anthk•1mo ago
coldcity_again•1mo ago
[1]:https://github.com/askeksa/NoCpuChallenge [2]:https://www.pouet.net/prod.php?which=104753
rbanffy•1mo ago
mkesper•1mo ago
is_taken•1mo ago
rbanffy•4w ago
quux•1mo ago
reaperducer•1mo ago
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.