Bug in the 5th sprite emulation

Page 3/6
1 | 2 | | 4 | 5 | 6

By ARTRAG

Enlighted (6845)

ARTRAG's picture

06-11-2006, 09:58


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)

By ARTRAG

Enlighted (6845)

ARTRAG's picture

06-11-2006, 12:39

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.

By pitpan

Prophet (3152)

pitpan's picture

06-11-2006, 13:16

duh.

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

By ARTRAG

Enlighted (6845)

ARTRAG's picture

06-11-2006, 15:35

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

By dvik

Prophet (2200)

dvik's picture

06-11-2006, 15:50

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.

By dvik

Prophet (2200)

dvik's picture

06-11-2006, 16:04

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.

By ARTRAG

Enlighted (6845)

ARTRAG's picture

06-11-2006, 17:20

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.

By dvik

Prophet (2200)

dvik's picture

06-11-2006, 17:38


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.

By PingPong

Prophet (3889)

PingPong's picture

06-11-2006, 19:40

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?

By PingPong

Prophet (3889)

PingPong's picture

06-11-2006, 22:09

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.

The program used in the test uses effectively a loop delay in 1020 of two int's to avoid some instability and to ensure 'some reliability' in s0 readed value.

If i remember correctly i've modified directly on the real hw the line to wait 2 ints.

However, to be sure i could re-test the thing on the real hw next week, but i'm sure that my results are correct, at least on v9938.

Page 3/6
1 | 2 | | 4 | 5 | 6