How to change the R18 value while the VDP is running a command

Isn't a write to R18 is delayed till HBLANK by VDP itself?

My theory model:
At the start of the scanline, VDP loads R18 to a delay counter.
The whole display gear is delayed by this amount of cycles, display, sprites, and border.

Keyword "tail", what I meant by blitter action having a tail that hangs into next scanline:

What if one opcode interation of a command is a not interruptible unit.
Like, syncing to DMA pattern can only happen at start of an opcode.

Taking copy speed to be very roughly the speed of outi,
outi is 18 cpu cycles, on the 5.4Mhz dotclock it would be 12 pixels.

And then, if you change R18 from 15 to 0, from point of view of the DMA pattern of the new scanline, the blitter could have an additional 15 pixels "tail" just by that.

@hit9918. let's continue. First, the code pasted is wrong ( copy-paste error ). The real code is similar.
So let's continue with tests. I've done others investigations, but i was extremely confused about the results. I summarize here:
First, during interrupts i'm running in an infinite loop a copy operation (logical) from page 0 to page 1 with xor logical operation. So normally, you see the screen alternatively filled of 255 and 0 (255 xor 255, then 255 xor 0). that's is effectively what i get .
First test: at scanline 156 i fire a line int. my code does this:
(Can you check if i'm doing something wrong?)

void waitscanlines()
{
#asm
	ld c, 0x99
	ld d, 240
	ld e, 7+128
	ld a,2 			; read S#2
	out (0x99),a
	ld a,128+15
	out (0x99),a	;	
1:
	in	a,(0x99)		;wait until start of active area
	and	0x20
	jp	nz,1b

2:
	in	a,(0x99)		;wait until start of HBLANK
	and	0x20
	jp	z,2b

	#endasm
}

void scr_off() // turn off the screen 
{
#asm
	ld a, 0x22
	out (0x99),a
	ld a, 1+128
	out (0x99),a
#endasm
}


void scr_on() // turn on the screen
{
#asm
	ld a, 0x62
	out (0x99),a
	ld a, 1+128
	out (0x99),a
#endasm
}

void lineint()
{

	scr_off(); // screen off
	waitscanlines(); // wait x3, to be sure
	waitscanlines();
	waitscanlines();
	r18Value = (r18Value+1) & 15; // update r18 value, then write
	#asm
		ld a, (_r18Value)
		out (0x99),a
		ld a, 128+18
		out (0x99),a
	#endasm
	scr_on();	// screen  on
}

If i put this code in a line int, approximately at line 156 i get almost no corruption. After 30 seconds however, some random points start to appear. the strange thing is that the glitches are ALL placed at different Y values but ALL at X=0!
After a minute you have almost 10 of those glitches, apparently placed at random Y positions and all with X=0

By contrast, if the code is executed in VBLANK, corruptions are a LOT! in the first 10 seconds i get almost 1000 errors on the entire screen at random X, Y values.

The code is the same. I'm starting to get very confused.
Teoretically the VBLANK should be a more safe place...

Any proposal or test ?

But for practical purposes, it doesn't matter a gap between a scroll and a panel, while parallax scroll wants things without gaps.

So I had hoped that the blanking fix works with just only turning sprites off and leaving display on.
But then I heard that this might make the situation even worse.

Since the approach of stopping the blitter, described here, doesn't work properly and the V/HBLANK approach is also giving you trouble, maybe a more scientific solution can be useful.

If we decompose the problem, we have two independent cases competing for the same resources:

1) To blitt tiles on the background buffer
2) To change the VDP R#18 and flip the buffers

And each case competes for the following resources, respectively:

1) CPU+blitter
2) CPU+VBLANK+(no corruption)

Note: The VDP R#18 and flipping the buffers requires vblank to avoid tearing.

Well, since we know that the only 100% sure case of "no corruption" is to have the blitter stopped, (2) can be expressed as:

2) CPU+VBLANK+(blitter stopped)

For those who studied computer science, you'll find that this problem is very similar to the dining philosophers problem, with 2 philosophers dining. So maybe we can try to use the known solution for such approach.

Since you're blitting tiles of either 8x8 or 16x16, the idea is to blit only a known number of tiles that the VDP is able to perform in less than one frame (one philosopher can't eat forever), then leave the rest of the frame time free for the CPU to change the VDP R#18 on the vertical interrupt. After changing the R#18 the vertical interrupt process will flag a semaphore that releases a new set of blittings by the main thread (outside the interrupt handling routine). The pseudocode would be like this:

[Initialization]
1) Set N to a given number of tiles, like n=20.
2) Release the semaphore so the Main-thread can start blitting

[Main thread]
1) Issue a set of n 8x8 (or 16x16) tiles to the blitter
2) Change the semaphore value. This means the main threat will wait until the next cycle
3) Wait for the semaphore value change, to allow it to process the next set of tiles
4) Loop to (1) to process the next set of tiles

[Interrupt Handler routine]
1) Checks the VDP blitter running status flag
2) If the blitter is still running, decrease the n value. This means that the next cycle of the main thread will run a smaller set of tiles; Wait until the blitter ends its job.
3) Change the VDP R#18 value and flip the buffers
4) Releases the semaphore to allow the main thread to continue blitting

This approach seems very easy to implement and also not prone to race conditions regardless of the blitter speed or CPU speed. For each time that the blitter is not able to perform the given set of tiles, it will automatically reduce the set of tiles for each frame, until the system reaches a balance. This balance will be reached very quickly, so only a few frames will be teared. This even allows the system to work well for normal and turbo CPUs or blitters.

thx, for illustrating the entire process, but i think we want a constant 60 fps rate .... :-(