Metal Gear 3: Return for Jennifer (MSX w/ v9938/v9958/V9990)

I mean horizontally. Thus changing R23 multiple times within a single line.

The reason for this is that the VDP uses "burst mode" to read the bitmap data from VRAM. That is: it calculates the address once (using the value of R23) and then reads 4 consecutive bytes (=8 pixels) from VRAM. R23 can be changed at any time, also within a group of 8 horizontal pixels. But it only takes effect on the next group of 8 pixels. (I'm again simplifying, see the article for details).

Similarly R5 can be changed at any moment in time. But the VDP only uses R5 to calculate the VRAM-address for sprite-attribute fetches. Thus changes only have an effect when the VDP reads the next sprite-attribute-data from VRAM. And that is only at specific moments within a horizontal line.

With Changing R5 I change the base address, and if I have set different SATs at those addresses... 1 st sat starts at 0, 2nd, 0 + 16 etcetc. The second reason I came up with this idea, when I changed the sat in the midden of a 16x16 sprite and not correctly timed at the beginning it changed a centemeter to the right of the left border.
Than I knew SAT is able to change within 1 line. from line to line there is a fluctuation of 32 pixels, compared from line to line, at fixed beginning of SAT change, therefore you need to cover the fluctuations with same sprites of previous SAT and after fluctuation, other sprites. During fluctuation of change you need the last shown of previous SAT and begin with them in the next Sat, to overlap. (also depends on your timing). Bij 16x16 sprites you have 2 overlapping SAT sprites.
As Wouter_ indeed mentions the sprites are updated several times per line at specific times. If I change 3 times sat address table it works.
@wouter_, how many times is the SAT read per line, even when SAT address changes over and over per line? To know the limitations before getting annoyed or frustrated it is not working anymore... Haha

Exactly!!!

Internally the VDP runs at a clock that is divided by 4. So at exactly the speed of the z80a. There was a reason for the 21 mhz crystal I read somewhere before but the VDP is not faster. But maybe I misunderstood that part.

Cannot open, it's seen as a binary file instead a text one. Even on the MSX using TYPE shows binary content.

But what sync method uses to decide that is the middle of the screen? That's the question.