Quote:

Huh? The srite limit was designed to keep the 'load' on the VDP low for handling sprites. Returning the *first* 5th sprite seems more logical then, since the VDP can then stop processing sprites for that line. If it wants to return the *last* sprite on the line, it still might need to process all!

You misunderstand, when I say the first 5th sprite, I mean the first "5th sprite" in the screen,
i.e. belonging to the first line of sprites in overflow in the screen.

If you see that mode 1 des not avoid an error (i.e. leave some sprites hidden),
it is for sure due to the fact that you are in a case of multiple lines with sprites in overflow on
the screen.
If you look at the code, you'll see that, due to the use of S0, the sole condition handled
with 100% of prob. of success is when there is only ONE line with more than 5 sprites.

The behaviour you spotted is wanted, exactly this feature makes mode 1 the best
candidate to spot differences in the emulation of S0 of the different SW and the real HW

Place the sprites on two lines of 5 sprites, use adjacent spriteplanes,
mode 1 is supposed to handle at best ony the last line in the screen
(at best means that all the sprites in that line flicker with freqency 10Hz,
the other line is handled in non optimal way -i.e. one or more - but not all- sprites
disappear with frequency higher that 10Hz or completely)

do this both on blue end in open

you'll see that the line correctly handled DIFFER!
Open manage correctly the second line and blue the first or vice versa

The one who manages the second line probably returns the last 5th sprite in the screen
The one who manages the first line probably returns the first 5th sprite in the screen

they cannot both accurate :-)

The problem with all of those algo is that they try to keep the maximum number of sprites 'on' per frame. this have a bad visual effects during the flickering phase because you have some sprites that partially flicker. like in this scenario:
planes 0,1,2,3 have y=10
plane 4 have y=18
plane 17 have y=200

this implies that plane 4 sprite have only the first 8 pixel's (height) that flicker, the rest is stable. This looks very bad.
a better choice is to have only one sprite set of those that can disappear, each set could of course have only 4 sprites, the rest is hidden in a certain frame. Next frame is the first slot that is hidden and the next is visible. to clarify, in the example above:

frame 1 see displayed sprites planes 0,1,2,3 (sprite 4 is entirely hidden), sprite 17 is showed.
frame 2 see displayed sprites planes 0,1,2,4 (sprite 3 is entirely hidden), sprite 17 is showed.

Notice that sprite 17 is never hidden in all frames because it never need attention by the sprite flcker routine.

blueMSX sets the 5th sprite and bit 6 in S0 if and only if bit 6 and 7 are cleared and there is a 5th sprite detected. bit 5-7 in S0 are cleared on every read of S0.

openMSX sets the 5th sprite and bit 6 in S0 if bit 6 is creared and there is a 5th sprite detected. And I think bit 5-7 in S0 are cleared on every read on S0.

I haven't looked at your example ARTRAG but it would be nice for both the openMSX team and blueMSX team if someone was willing to investigate this further and figure out exactly under what conditions the 5th sprite is set in S0. blueMSX used to behave as openMSX but changed after a similar thread popped up that included some evidence that bit 7 was involved when setting the 5th sprite. I believe openMSX did so too but maybe they found out it wasn't accurate. I'd be happy to get some more info on this.

dvik, i've no real hw, so all i can do is to find and send you
my original SW for testing sprite multiplexing...

http://www.msx.org/forumtopic7248.html

Quote:

blueMSX sets the 5th sprite and bit 6 in S0 if and only if bit 6 and 7 are cleared and there is a 5th sprite detected.

is correct

Quote:

bit 5-7 in S0 are cleared on every read of S0.

is incorrect:

Quote:

if you reread it (twice) inside vblank, it will point to the last handled sprite number. Some simple examples (overflow or no overflow doesn't matter): - sprite 16 Y value of 208 --> 16 - sprites 0,1,2,3,4 on scanline 191 --> 4 - no sprites on scanline 191 --> 31 So, those bits don't just get reset to 00 or 31 after the status register is read.