5 ms·

> hardware that we would probably now consider to be inadequate for running a disk controller. Wasn't the disk controller chip in the BBC Micro significantly m

> hardware that we would probably now consider to be inadequate for running a disk controller. Wasn't the disk controller chip in the BBC Micro significantly more powerful than the main CPU? I think some games used it as a coprocessor.

rbanffy 5y ago
That's ludicrous. The 6502 is the best 8-bit processor that ever existed ;-) Now, on a more serious tone, any processor in the machine you could detect could be used to offload some processing from the CPU. I wonder if that wasn't done with 1541 or 1571 Commodore floppy drives. I know there was software that wrote new functionality onto the drive's memory to make disk IO faster. With enough memory, you could sort a text file and write the output to a new file without ever bothering the CPU. I don't think that was ever actually done, but the drives also ran 6502 processors, and the 1571 ran at twice the main computer's clock.
- BuildTheRobots 5y ago
  There's every chance I'm remembering it wrong - the double the clock speed certainly rings a bell. Got a weekly video call with a friend who still regularly hacks on a Beeb, so will try and clarify and update my comment tomorrow :)
  - rbanffy 5y ago
    The Beeb and the Ataris ran at 2 MHz. Apple II, VIC-20, C64, and 1541 all ran at 1 MHz. The 1571 ran at 2 MHz, same as the C128 (except when pretending to be a 64)
    - forinti 5y ago
      The beeb had an additional advantage: RAM ran at 4MHz, so the CPU and the video chip didn't have to compete for access.
      - bullen 5y ago
        Same for the C64... RAM at twice the Hz so the 6510 and SID/VIC-2 accessed it interleaved.
- pkroll 5y ago
  The 1571 was the drive meant for the C-128, which could also run at double speed (2 megahertz!) with the C-64 video chip disabled and the 80-column video running.
- tenebrisalietum 5y ago
  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.
- ecpottinger 5y ago
  One thing you could setup on the Commodore drives is file copying from on drive to another without it going thru the computer, they just talked to each other. You could also do the same thing if you had a straight text file and sent it to the printer (I am not sure which printer models) with again not using the computer after the handshaking was set up.

rbanffy 5y ago

That's ludicrous. The 6502 is the best 8-bit processor that ever existed ;-) Now, on a more serious tone, any processor in the machine you could detect could be used to offload some processing from the CPU. I wonder if that wasn't done with 1541 or 1571 Commodore floppy drives. I know there was software that wrote new functionality onto the drive's memory to make disk IO faster. With enough memory, you could sort a text file and write the output to a new file without ever bothering the CPU. I don't think that was ever actually done, but the drives also ran 6502 processors, and the 1571 ran at twice the main computer's clock.

BuildTheRobots 5y ago
There's every chance I'm remembering it wrong - the double the clock speed certainly rings a bell. Got a weekly video call with a friend who still regularly hacks on a Beeb, so will try and clarify and update my comment tomorrow :)
- rbanffy 5y ago
  The Beeb and the Ataris ran at 2 MHz. Apple II, VIC-20, C64, and 1541 all ran at 1 MHz. The 1571 ran at 2 MHz, same as the C128 (except when pretending to be a 64)
  - forinti 5y ago
    The beeb had an additional advantage: RAM ran at 4MHz, so the CPU and the video chip didn't have to compete for access.
    - bullen 5y ago
      Same for the C64... RAM at twice the Hz so the 6510 and SID/VIC-2 accessed it interleaved.
pkroll 5y ago
The 1571 was the drive meant for the C-128, which could also run at double speed (2 megahertz!) with the C-64 video chip disabled and the 80-column video running.
tenebrisalietum 5y ago
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.
ecpottinger 5y ago
One thing you could setup on the Commodore drives is file copying from on drive to another without it going thru the computer, they just talked to each other. You could also do the same thing if you had a straight text file and sent it to the printer (I am not sure which printer models) with again not using the computer after the handshaking was set up.