Sprite "one line" artifact on screen update. Somebody knows why?

In the example above I used a technic to update the sprites attribute table using the copy command (VRAM to VRAM). The sprites trejectories are pre-renderized in another page. This whole loop it something is like.

FOR J=0 TO 128:COPY (0,J)-STEP(239,1) TO (0,4),1:NEXT J
* The sprite attribute was previous setup to be at coordinate (0,4) of PAGE 1 and PAGE 0 has 128 setups (positions) for all sprites. So this unique copy command update all sprites and it is very fast.
Note: Is a put a SET SCROLL 0 before the copy command the artifacts did'nt happen because SET SCROLL waits V-SYNC, but I lose Frames Per Second.

I also made another code now to see if this "middle artifact" occours:
10 SCREEN 5,2 : SPRITE$(0)=STRING$(32,255)
20 FOR X=0 TO 255 : FOR I=0 TO 10
30 PUT SPRITE I, (X*8, I*17),10 ,0
40 NEXT I,X : GOTO 20

And i get that:

The artifact is a little different, but I also don't know how to explain this part between the top and bottom frames.
It is also possible to see it on WebMSX.

I think you may have already identified the reason
If SET SCROLL waits for v-sync and then you issue the copy commands, then the chances are high that these commands will be performed well in time before the VDP actually displays the sprites.

What is probably happening now is that the sprite attribute table is being modified while the VDP accesses it to render the sprites. This leads to undefined behavior. I am not super familiar with the sprite engine in the VDP, but I think it actually processes data 'one line ahead', which might explain some of the artifacts you are seeing.

You could maybe try to put your copy commands on the ON INTERVAL GOSUB function. Or you could make a loop in BASIC checking the TIME variable or directly the "JIFFY" integer that is stored at &HFC9E. These should be updated some time in the V-Blank. However, BASIC is slow, so it might still not give hard guarantees.

As Sandy said, if you modify the SAT (Sprite Attribute Table) during page rendering, the SAT data will be in a undefined stat when the vertical scan will arrive at the point where the VRAM is being modified.
I see 2 solutions to avoid this:
- Update the SAT only during the V-Blank,
- Use 2 SAT and display the screen with one while you modify the other.

@Sandy Brand You say:

Yes, you understood well what I'd like to know: 'Why the sprite engine generates that pattern of image when we update the coordinate X of sprite during the sprite engine access?'

It is important to me specially because I also program in assembly with splitscreens and etc. For this BASIC project I think I can't to improve much more.

I also use this technics, but how you say above, BASIC is very slow and today, the best way I found to wait V-SYNC is to use SETSCROLL 0 (unfortunately only MSX2+ has this instruction).

@Aoineko, it is also a good idea to avoid these glitches.