I'm not sure but I guess you could work it out roughly. Assuming you use the auto-increment and don't need to resend the start address each time you are left with at least 4 instructions per byte sent, lda datatosend,x sta $601 waitloop: bit $601 bpl waitloop
This doesn't take into account any complex loops to write a particular number of bytes or more complex loading of data. So even if you assume it never waits for the VDC ready, going by something like 17766 cycles per frame, going to guess at least 20 cycles per byte written and you are somewhere in the 888 bytes per frame region with no other code operations.
I'm making numbers up and guessing a lot here, but that doesn't sound too far off my experience of using it either.
There are of course things you can do to cheat and speed stuff up. Not the least of which is make use of the internal clock copy.
Thanks! I’m thinking about the possibility for smooth animations but rough estimates don’t look good. Most graphics kind of have to be in VDC memory to get speed and it doesn’t play well with smooth movement and animation since the combination eats memory like nothing else.
And if you assume an expanded 64k Video memory there is plenty of space to store data for animations. The only issue is that the block copy is a solid block, no gaps. So you can't move random shaped objects like on the Amiga to simulate sprites. It's good for moving large areas of screen however.