Feel free to add comments or other useful info to the bug report.

Quote:

BTW what is the behaviour of S0 in openMSX when there are multiple lines with 5 sprites? Or at least, what was it supposed to return? The very same question holds for bluemsx.

If the 5th sprite bit is cleared, one of these two sprite plane indexes are put in the 5 low bits in S0:
1. If 5 sprites are detected on the current line, the index of the 5th sprite is placed in S0 and 5th sprite bit is set
2. If 4 or less sprites are detected on current line, the index of the sprite plane that has Y-coordinate = 208 is placed in S0.

Note that after the 5th sprite bit is set in S0, the lower 5 bits are not modified anymore until status register S0 is read.

So this is how its implemented in blueMSX, not 100% sure its exactly the same as real HW.

I think that you should emulate also this very special behaviour of the HW:

you know very well that Y=209 is a terminator that says "the SAT end here",
you surely know that the 5th sprite is returned even if the sprites are outside the
screen on under the borders...

Actually THERE IS an undocumented exception:

If Y=208 that sprite plane is skipped in the 5th sprite management,
this means that even if you place 5 or more sprites under the border,
S0 will never return the planes with Y=208 and the vdp will never rise
the 5th sprite flag if the 5th sprite has Y=208.

This Is A Very Particular And Undocumented Fact !!!
(Bruno, thanks again for discovering it)

yes, I know.

Quote:

If Y=208 that sprite plane is skipped in the 5th sprite management, this means that even if you place 5 or more sprites under the border, S0 will never return the planes with Y=208 and the vdp will never rise the 5th sprite flag if the 5th sprite has Y=208.

I'm not sure I understand what you're saying here. In blueMSX the plane with Y=208 is treated the same regardless of what scanline is rendered. A plane with Y=208 always terminates the SAT and will never cause the 5th sprite flag to be set. I'm not sure what the strange thing with this is or am I missing something?

I do apologize, maybe I am wrong on which of them is a delimiter and on which says "skip" but both Y=208 and Y=209 have special meanings.

In particular, the delimiter says “SAT ends here, do not process any further”, the “skip” says “this plane does not count”. The mining of the latter is that if you place on sprites on plane

0 1 2 3 4
Y=207; Y=207; Y=207; Y=207 ; Y= « skip »;

(Where « skip » was 208 in my previous text) the 5th sprite flag says « no 5th sprite » and the plane in S0 is 31. So plane 4 does not exit does not count for the 5th sprite.

Quote:

If the 5th sprite bit is cleared, one of these two sprite plane indexes are put in the 5 low bits in S0: 1. If 5 sprites are detected on the current line, the index of the 5th sprite is placed in S0 and 5th sprite bit is set 2. If 4 or less sprites are detected on current line, the index of the sprite plane that has Y-coordinate = 208 is placed in S0. Note that after the 5th sprite bit is set in S0, the lower 5 bits are not modified anymore until status register S0 is read. So this is how its implemented in blueMSX, not 100% sure its exactly the same as real HW.

This should be OK, with the real HW
Note that the 5th sprite returned in S0 is always the one with higer sprite plane (after the 4th),
independently from the X,Y coordinates of the sprites, (provided that they are on the same line)

Maybe here I am clearer:

Both Y=208 and Y=209 have special meanings, maybe I am wrong on which of those values is a delimiter and on which says "skip", BTW the delimiter says “SAT ends here, do not process any further”, the “skip” says “this plane does not count”.
The meaning of the latter is that if you place on sprites on plane

0 1 2 3 4
Y=207; Y=207; Y=207 ; Y= « skip »; Y=207;

(Where « skip » was 208 in my previous text) the 5th sprite flag says « no 5th sprite » and the plane in S0 is 31.
Plane 4 does not count for the 5th sprite management.

In this other case :

0 1 2 3 4 5
Y=207; Y=207; Y=207 ; Y= « skip »; Y=207; Y=207;

You get that the 5th sprite flag says « 5th sprite » and the plane in S0 is 5.
Again now plane 3 does not count for the 5th sprite management.

duh.

I've got it now. Thanks for sharing this info, Arturo.

Test them on the real HW before using the info, just to be sure
and have a confirm

Just to avoid some confusion, Y=209 in MSX basic is the same as Y=208 in the actual VDP, right?

Another thing I noticed in the result of the test program is that the output in openMSX may be correct. It looks like that if openMSX has the same algorithm as blueMSX, the sprite plane printed depends on when S0 is read. So the value could be either 4, 9, or 14 and all are correct.

*EDIT* It depends on when the sprites are moved, not when S0 is read.

Although it looks like the basic program syncs to VBLANK (the sub routine at line 1010) so maybe the sprites are always moved during the border area in which case the sprite plane in S0 should always be 4.

In this program S0 is red only after one vblank.
The program works very well on real HW and gives each time the same values (equal to those returned by bluemsx).
I do not think that the problem is the one you spotted, if you want to be sure
increase the number of vblank in the loop at 1010 before reading VDP(8).

IMHO that the problem could be due to the fact that openmsx continues to seek for a 5th sprite even
if none has read S0.

Quote:

IMHO that the problem could be due to the fact that openmsx continues to seek for a 5th sprite even if none has read S0.

It sure looks like that.

Quote:

I think that you should emulate also this very special behaviour of the HW: you know very well that Y=209 is a terminator that says "the SAT end here", you surely know that the 5th sprite is returned even if the sprites are outside the screen on under the borders... Actually THERE IS an undocumented exception: If Y=208 that sprite plane is skipped in the 5th sprite management, this means that even if you place 5 or more sprites under the border, S0 will never return the planes with Y=208 and the vdp will never rise the 5th sprite flag if the 5th sprite has Y=208. This Is A Very Particular And Undocumented Fact !!! (Bruno, thanks again for discovering it)

Pleased to give my help, ART.


Will be interesting to know if also the OCM works as the real HW. Anyone know about?