4 ms·

On the C64/1541 you could definitely upload code to one or more of the 256-byte 1541 disk buffers and make the drive execute it. The problem is you have 3 pins

On the C64/1541 you could definitely upload code to one or more of the 256-byte 1541 disk buffers and make the drive execute it. The problem is you have 3 pins to transmit your data and those are not connected to any communication facility like an ACIA - you have no choice but to involve the CPU in some bit banging there. The 1571 used the burst mode of the CIA IIRC (also IIRC it wasn't done in the 1541 to be compatible with the VIC20) so there were more possibilities there.

rbanffy 5y ago
> The problem is you have 3 pins to transmit your data (...) you have no choice but to involve the CPU in some bit banging there. Well... As long as the code takes longer to compute than it takes to push/pull the data, it's still a win. I really can't think of any practical usage, of course. Maybe transforming ASCII files to EBCDIC ones without involving the CPU, or generating CRC32 values for the files on disk.
- ecpottinger 5y ago
  Did not fast loaders for the drive put a small program on the disk drive?
  - tenebrisalietum 5y ago
    They did, but the CPU still has to manually manipulate the ATN, DATA, and CLK pins. There's no I/O controller, just two "Complex Interface Adapter" which each have 8 I/O ports, readable/writeable by the CPU using standard LDA/STA, etc. instructions. (The CIAs also have a timer and can generate IRQs). IIRC 3 bits from CIA #2 can set/read each pin state. The CIA won't do anything to those on its own at all. I think there were plans to use something like IEEE-488 or GPIB but scrapped due to cost. So you can definitely write a program to implement a faster protocol than the one in the Kernal/1541 ROM (e.g use DATA and CLK as data lines and use ATN to sync, doubling transfer rate), but the CPU will still need to be 100% utilized in the (shorter) transmission.

4 ms·

On the C64/1541 you could definitely upload code to one or more of the 256-byte 1541 disk buffers and make the drive execute it. The problem is you have 3 pins

by tenebrisalietum 5y ago

rbanffy 5y ago
> The problem is you have 3 pins to transmit your data (...) you have no choice but to involve the CPU in some bit banging there. Well... As long as the code takes longer to compute than it takes to push/pull the data, it's still a win. I really can't think of any practical usage, of course. Maybe transforming ASCII files to EBCDIC ones without involving the CPU, or generating CRC32 values for the files on disk.
- ecpottinger 5y ago
  Did not fast loaders for the drive put a small program on the disk drive?
  - tenebrisalietum 5y ago
    They did, but the CPU still has to manually manipulate the ATN, DATA, and CLK pins. There's no I/O controller, just two "Complex Interface Adapter" which each have 8 I/O ports, readable/writeable by the CPU using standard LDA/STA, etc. instructions. (The CIAs also have a timer and can generate IRQs). IIRC 3 bits from CIA #2 can set/read each pin state. The CIA won't do anything to those on its own at all. I think there were plans to use something like IEEE-488 or GPIB but scrapped due to cost. So you can definitely write a program to implement a faster protocol than the one in the Kernal/1541 ROM (e.g use DATA and CLK as data lines and use ATN to sync, doubling transfer rate), but the CPU will still need to be 100% utilized in the (shorter) transmission.