10

I am developing some software for the Commodore 64, and my intention is to use the 1541 as a coprocessor. I'll have the 1541 compute some data for me, and then retrieve this data over the serial line.

I know that the KERNAL routines have earned themselves a reputation for being very slow. I couldn't find any information about exactly how slow though! So what I want as some concept of the relationship between the transfer of X bytes, and knowing how much raster time approximately needs to elapse to transfer this amount of data.

Unless I rethink my design, I will need to transfer a payload of around 40 bytes per frame. If I use the KERNAL routines, what kinds of speeds can I anticipate?

Improve this question
5
  • I think you'll need custom kernal routines that use the CIA shifter. Maybe some derivative of SJLOAD.
    – Brian H
    Commented Mar 8, 2020 at 20:21
  • The shifter solves only half the problem. As supercat already mentioned, a host clocked transfer protocol would resolve most issues and enable transfer close to maximum speed while taking care of C64 side timing oddities.
    – Raffzahn
    Commented Mar 8, 2020 at 20:32
  • @BrianH The shift registers in the CIAs cannot be used with the IEC serial bus; neither the CNT nor the SP pins on either CIA are connected to it.
    – cjs
    Commented Mar 9, 2020 at 2:47
  • Related meta discussion.
    – cjs
    Commented Mar 9, 2020 at 2:57
  • @cjs I didn't elaborate, but was suggesting hardware and software mods might be needed.
    – Brian H
    Commented Mar 9, 2020 at 14:27

1 Answer 1

Reset to default
12

Without any modification Commodore 64 Serial Bus operates at 3200 bit/s (*1).

Effective maximum speed for C64+1541 is about 400 bytes/s.

Sustained speed with turn around and alike is about 300 bytes/s.

I am developing some software for the Commodore 64, and my intention is to use the 1541 as a coprocessor. I'll have the 1541 compute some data for me, and then retrieve this data over the serial line.

Cool. Has been done a few times. First I know of is from ~1984 when a friend used two of his 1541 to calculate a Mandelbrot set, each doing alternating lines, while the C64 just transferred and displayed data.

Maximum application I've ever seen was two C64, with four drives each, hooked up to a PC. So eight 6502 calculating, two shoveling and one 8088 displaying :))

Unless I rethink my design, I will need to transfer a payload of around 40 bytes per frame. If I use the KERNAL routines, what kinds of speeds can I anticipate?

That might not work. 40 bytes per frame means 40x60=2400 bytes/s or about eight times the 300 bytes/s such an application may get using the standard routines.

A C128 with 1571 and burst mode my bring you there - well, or using a 1571 with a burst mode driver on the C64. Or as alternative using Jiffy-DOS. Both this might still be rather tight when it has to happen within screen frame timing.

Then again, since you're already downloading an application to the 1541, you may want to look if there'S still enough space left to add a custom transfer routine - maybe using some of the user commands? Such a routine could work close around timing issues due video access/frame structure.

*1 - This is the effective netto data rate. Counting speed on the Commodore Serial Bus isn't as easy as with regular serial, as timing changes a lot on what part of the protocol we look at. This document is a good compilation of various information pices.

Improve this answer
5
  • 4
    A custom transfer routine could not only be faster, but if it made the 64 responsible for outputting the clock even when receiving data, it could be agnostic to VIC cycle stealing, interrupts, or anything else that would waylay the 6510 for periods of time.
    – supercat
    Commented Mar 8, 2020 at 18:56
  • What do you mean by "sustained speed with turnaround and alike"?
    – Omar and Lorraine
    Commented Mar 8, 2020 at 22:03
  • I think I need to rethink my ideas a little. The point of doing this was to relieve the C64 from having to do this calculation; if it's going to take that long, I may as well do it host-side.
    – Omar and Lorraine
    Commented Mar 8, 2020 at 22:05
  • 2
    @Wilson Initiating, addressing and changing direction is slower than pure data transfer, so with short packets and a lot of direction change over all thruput will suffer. Well, base for this is that data transferred is rather small, while computing effort is comparably high. For a Mandelbrot set this works well, as data is just a screen line, but calculation i quite intense. Even more, the drive can already continue to compute the next line while sending the one just finished. Like all parallel processing it's about to get as much done at the same time as possible.
    – Raffzahn
    Commented Mar 8, 2020 at 22:16
  • @Raffzahn: Incidentally, this makes GET# extremely slow compared with using a SYS to the kernel's input equivalent to CMD and then using GET.
    – supercat
    Commented Mar 9, 2020 at 15:18

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .