3 ms·

Commodore 64 floppy drive has the power to be a computer and runs BASIC

38 points by rbanffy 10mo ago

leibnitz27 10mo ago
Some demos offloaded work to the 1541 - https://csdb.dk/release/?id=820 https://csdb.dk/release/?id=820
- badc0ffee 10mo ago
  Some run entirely on the 1541 - https://www.youtube.com/watch?v=zprSxCMlECA https://www.youtube.com/watch?v=zprSxCMlECA
  - slfnflctd 10mo ago
    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.
    - anthk 10mo ago
      That's nothing; there's an Amiga demo where it runs in the machine without touching the Motorola CPU ever.
      - coldcity_again 10mo ago
        There's a whole open challenge[1] - but you might be thinking of this[2] prod. [1]:https://github.com/askeksa/NoCpuChallenge https://github.com/askeksa/NoCpuChallenge [2]:https://www.pouet.net/prod.php?which=104753 https://www.pouet.net/prod.php?which=104753
- rbanffy 10mo ago
  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".
  - mkesper 10mo ago
    Absolutely. The eprom of TFA was only needed for standalone usage. But 2K of RAM are not much.
    - is_taken 10mo ago
      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.
    - rbanffy 10mo ago
      If the OS could load specific code into the drive memory. It’s a bit how “channel programming” worked on mainframes. Not sure modern ones still get advantages from that.
  - quux 10mo ago
    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.
  - reaperducer 10mo ago
    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_don_t_know 10mo ago
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.
- Gibbon1 10mo ago
  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.
- badc0ffee 10mo ago
  And yet it was like 1/10 the speed of the Apple II floppy drive.
  - rbanffy 10mo ago
    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.
    - quux 10mo ago
      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
deleted 10mo ago
[deleted]
deleted 10mo ago
[deleted]
drbig 10mo ago
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.
MarkusWandel 10mo ago
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.
kkaske 10mo ago
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.
- rasz 10mo ago
  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.

38 points by rbanffy 10mo ago

leibnitz27 10mo ago

Some demos offloaded work to the 1541 - https://csdb.dk/release/?id=820 https://csdb.dk/release/?id=820

badc0ffee 10mo ago
Some run entirely on the 1541 - https://www.youtube.com/watch?v=zprSxCMlECA https://www.youtube.com/watch?v=zprSxCMlECA
- slfnflctd 10mo ago
  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.
  - anthk 10mo ago
    That's nothing; there's an Amiga demo where it runs in the machine without touching the Motorola CPU ever.
    - coldcity_again 10mo ago
      There's a whole open challenge[1] - but you might be thinking of this[2] prod. [1]:https://github.com/askeksa/NoCpuChallenge https://github.com/askeksa/NoCpuChallenge [2]:https://www.pouet.net/prod.php?which=104753 https://www.pouet.net/prod.php?which=104753
rbanffy 10mo ago
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".
- mkesper 10mo ago
  Absolutely. The eprom of TFA was only needed for standalone usage. But 2K of RAM are not much.
  - is_taken 10mo ago
    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.
  - rbanffy 10mo ago
    If the OS could load specific code into the drive memory. It’s a bit how “channel programming” worked on mainframes. Not sure modern ones still get advantages from that.
- quux 10mo ago
  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.
- reaperducer 10mo ago
  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_don_t_know 10mo ago

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.

Gibbon1 10mo ago
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.
badc0ffee 10mo ago
And yet it was like 1/10 the speed of the Apple II floppy drive.
- rbanffy 10mo ago
  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.
  - quux 10mo ago
    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

deleted 10mo ago

[deleted]

deleted 10mo ago

[deleted]

drbig 10mo ago

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.

MarkusWandel 10mo ago

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.

kkaske 10mo ago

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.

rasz 10mo ago
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.