Some VDP command for linear transfer?

there are only 4 bit in the command part of the command register... the most useful operations first.
i think a memcpy is not as useful in gfx as a rectangle copy.
Also note that the available command set is not orthogonal.

That is not an option. Due to design failures sprite color data must be copied. Also if you want to surpass the low patterns limit (and you will do because it can't mirror sprites) you have to copy gfx. Can't change tables because it implies all the sprite patterns in screen must match with the ones in that table, and that is impossible.

It can also be used to update data in VRAM from another VRAM store location. It has many uses. So I don't know why is not implemented.

Yes indeed that was an option, split in multiple operations. Unfortunately all the checks to do in addition to multiple small commands (with all parameters to set) is even slower than directly doing a LDIRVM + LDIRMV for standard size sprites operations.

We have to check both the source is well aligned but also the destination, so none of them break the line alignment (128-byte for SC5-6 and 256-byte for SC7-8). This can be a bit complex and for Z80 can be even more work than a pair of copies from and to VRAM of small chunks of data.

I.e. draw a character (usually 4 sprites, multicolor body and legs), then a bullet (single sprite), now other character... what pattern?, is aligned any of the source or destination? How many copies implies and what size?. In the worse case, we should do up to 3 operations (1st incomplete line, 2nd block of full lines, 3rd incomplete line) if at lest source or destination are aligned, if not can be even more. Add many checks that we need to do before using the CPU to set the operations to do.

For typical sprite size (4 sprites for a character) using the CPU directly is even faster as said. Unfortunately I am afraid I'll have to use the CPU in any case.

The idea was to use the interrupt time to set SC5 and copy some data CPU-free. Also it would be great on V9958 that works always in bitmap mode (there is no reason to use SC4 on V9958, right?) handle completely the sprites and possibly other VRAM data using only the VDP. It would be really great.

for patterns it would be nice to have a cache. then have masses of things with no copying.
vram pattern allocation array: 64 bytes telling which vram P is free
and 256 patterns in RAM. 256 patterns in the game
with a 256 bytes table RAM P -> vram P

	ld c,the RAM P number
	ld a,(bc)			;B = lookup table RAM P -> vram P
	ld (ix+P),a			;the vram P of YXPC of SAT

and a 256 bytes reference count array for multiple users of one pattern.
every object creation / killing needs to call patternalloc / patternfree with RAM P numbers.

the colorcopy quirk is solved with C mirror bytes array.

but, I didnt mean small sprite mode, I meant 256 patterns in 16x16 sprite mode.

a new sprite enters the screen.
one of the 256 RAM patterns is copied to one of those 64 vram patterns.
and there are dozen sprites onscreen.
they already got their things in vram, no copying.
when they leave the screen then they free their vram slots.
so. 256 patterns and little copying.