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

I think i get what you mean but not fully. What i think you should do is try your idea codewise. put a ton of sprites on screen with your technique and see what happens. I have rom templates if you need any so you only need to do something in a loop. You will allready have a keyboard control and inthandler at your disposal.

But thats just what i usually do. I come up with all kinds of ideas and try then out. Sometimes I get what i want and sometimes i get disappointed.

You're well ahead of me then.

The Yamaha VDPs fetch only 8 sprite patterns per line. They can therefore draw only 8 sprite patterns per line. That is a hard limit. There is no software way to display more than 8 hardware sprites during a line of output. It's software sprites or flickering to include more moving objects on your line.

This is distinct from some other architectures, such as the Atari 2500 or the Commodore Amiga, where sprite details can be pushed during a line, potentially causing the same hardware sprite to trigger twice. There is no pushing of sprite details on the MSX; the VDP pulls them at fixed moments. That aspect of the VDP is not programmable.

See Grauw's timing documentation. If you're in a bitmap mode and have reached cycle 130 then sprite locations and contents have been locked in for the line that is about to be serialised. There is no means to change any aspect of sprite output for that line after that point. You are going to get at most eight sprites displayed on your line, full stop.

Sample code is almost done. I always get distracted by other ideas that game up.
Before end of weekend it will be finished...

I came to this concept because I was checking some of my old sources of the 90's and I stumbled on some sources I made for Aerifero / New World Order. It was a screensplit horizontal and vertical, left side of screen scrolling down and right side scrolling upwards.
If you can manipulate VDP R23, during a single line, why not R5?
Just got a aha moment, unfortunately we only have 128kb and 64kb not visible in SCREEN5. So if I would set base at 10000h, and set VDP 17 at 5 with bit 7 set. Theoretically I could use 8 SATs per line., I have the time to send at least 8 bytes to a VDP port. But no time to change the pattern table.. Grrrrr..
Theoretically if what I wrote above is correct, we could use 4 sprites in or mode per 32 pixels.. and have in total 32 sprites per line... But.. theoretically, reality has to be proven.
Get back...
Also I noticed (in OpenMSX) the timing of changing VDP registers within a display line is related to VDP R18. The timing also depends on the value set to VDP R18. Shifting to left or right by about 8 pixels (added to the 32 pixels of line detection fluctuation)

I will test and see. Dual hopes.. I hope you are correct and hope I have it at the right end. I know from the past I can change colors as many times per line as I can. If I can adjust multiple VDP registers per line, and some more than one, why r5 just once. I can remember I changed a VDP R more than one per line and worked. What is so special about r5?
In. my opinion and experience, the VDP is just executing your command, whenever you instruct. If it is in the beginning, midst, or any other position, it will just do what you instruct. Have not seen other behavior..