Msx1 race engine

Nice effect!

Yes, technically, you can change any of the VDP registers and/or VRAM bytes at any point in time and in any order.

However, when the VDP is 'drawing' the screen from left-to-right, and from top-to-bottom, any changes made to VDP registers and/or VRAM will take effect more or less immediately. So you will have to be careful as to when to change VDP registers, and ideally not write into VRAM that is currently 'being drawn' as otherwise you might see 'tearing' or other visual glitches.

So, as santiontanon suggested, it is usually best to do this in the V-blank interrupt handler (H.TIMI at $FD9F) as the VDP is at that moment not drawing anything on the screen.

I assume that in your case it might take the CPU too much time to copy the new data into VRAM and it will not fit in the V-blank? However, it will be perfectly fine to handle the animation by changing VDP 2 in the V-blank interrupt, while outside the interrupt handler you are copying new data into VRAM: you can change VDP 2 halfway through writing to VRAM without any problems.

(I presume you are using a 'front' and 'back' buffer in VRAM to make sure you don't get any glitches on screen while writing into VRAM?)

Note: From your description it is not clear if you are just using BIOS functions or if you are directly writing to VDP registers yourself. If you are doing it yourself, you need to make sure that no interrupts occur while you are changing a VDP register: this usually takes 2 (or 4) OUT opcodes and these should not be interrupted with other OUT opcodes, otherwise data might reach the VDP out-of-order and the results might be unpredictable.

On TMS9918, iirc changing VDP registers also alters the VRAM pointer address, because the VRAM pointer low byte is also used by the VDP to store the register value temporarily.

So if you want to change a VDP register on the interrupt, you need to make sure to cut your VRAM transfers into small enough chunks (e.g. 256 bytes), disable interrupts during the transfer, enable interrupts briefly inbetween transfers to allow the interrupt to occur, and re-set the VRAM address for the transfer of the next chunk.

On V9938 you do not need this, because it has a separate buffer for the VDP register value, although there the buffer is shared with the palette port, so when updating the palette you need to take similar precautions if there is an interrupt handler which changes registers.

(Of course if the VRAM transfer or palette change happen on the interrupt as well, there is no issue.)

Indeed. Probably he has to redefine dynamically a certain number of tiles, I suppose, so this need time

You can in theory use it to your advantage in some situations to get a little faster random access (e.g. when accessing the SAT). However because it is not upwards compatible with the V9938 (and possibly not all TMS9918 clones either, I forgot), I would not recommend it. Also you need to reset it of course after use, pretty sure a in (99h) does that but not sure an out (98h) will... Edit: it does according to my post in the thread I mentioned below.

Ah, I found the thread about it.

@PingPong If someone would test it on the YM2220 (Yamaha's first TMS9918 clone) that would probably tell whether Yamaha was aware of it and purposely upgraded it on the V9938 or if they always implemented it like this.