Bug in the 5th sprite emulation

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

By ARTRAG

Enlighted (6843)

ARTRAG's picture

29-10-2006, 18:40

Or open, or blue or both does not correctly implemnet the 5th sprite calculation in S0
http://www.msx.org/forumtopicl6689.html

Login or register to post comments

By Manuel

Ascended (18783)

Manuel's picture

29-10-2006, 22:04

What is wrong then, exactly?

By ARTRAG

Enlighted (6843)

ARTRAG's picture

04-11-2006, 11:39

The way in which S0 is computed is very different in the two emulators!
You can see this problem when there are two or more lines in the screen with more than 4 sprites.
The 5th plane returned differs in the two emulators and can change without apparent reasons.

Moreover I suspect that none of the two emulators behave as the true HW!! I do not have a real HW so I cannot answer the question on which is the good one, if any.

The issue seems marginal, but it isn't. In order to develop good techniques of sprite multiplexing must rely on the behaviour of the VDP and on the value of the plane of the 5th sprite in S0.

So anyone committed to solve this emulation problem ?

By Manuel

Ascended (18783)

Manuel's picture

04-11-2006, 14:59

See the reply from AuroraMSX in the other thread: if you do the same, openMSX acts like the real HW. But it depends a lot on the history. It would help if someone would write a program that moves the sprites in some well defined way, so that we can really compare on emu vs HW with a well defined scenario/history.

By ARTRAG

Enlighted (6843)

ARTRAG's picture

04-11-2006, 15:49

Actually the real HW cannot depend on the history.
I have seen the other thread, aurora has only confirmed that the two emulators differ wrt S0.
If you look at JL program in mode 1 (mine) that is perfect to see the differrences, you only need
to place two lines of 5 sprites

http://www.telefonica.net/web2/msxpage/sprflick.rom

By Manuel

Ascended (18783)

Manuel's picture

04-11-2006, 16:22

AuroraMSX doesn't run blueMSX, so he only tried openMSX and real HW.

By AuroraMSX

Paragon (1902)

AuroraMSX's picture

04-11-2006, 18:43

Actually the real HW cannot depend on the history.The hardware doesn't, but the algorithm used in mode 1 might. I dunno, I haven't looked at the code.

I have seen the other thread, aurora has only confirmed that the two emulators differ wrt S0.Impossible, since I've only tested on openMSX and real hardware, like manuel said.

If you look at JL program in mode 1 (mine) that is perfect to see the differrences, you only need to place two lines of 5 spritesAnd the effect you get, both in openMSX and on real hardware depends on the order in which you move the sprites to their end positions. Really.

By ARTRAG

Enlighted (6843)

ARTRAG's picture

04-11-2006, 19:14

Sorry, I was wrong when I said you tested open and blue, as you tested open and the HW

The point is that I feel very strange that the real HW depends on the history of the positions of the sprites
that's way I assumed you was telling of open vs blue.

Actually you are rigth about history dependence when you refer to the multiplexing methods.
Mode 1 basically swaps the part of the SAT below S0 with the part of the SAT over S0
In this way the plane in S0 and the following get on top at next frame.

As you can see, the alghoritm depends on the history in the measure that it depends
on the sequence of values of S0 returned by the VDP.

Even if the S0's returned differ only once, the successive rearrangements of the SAT will differ.
And the effect will be very non linear.
So the behavior of mode 1 will diverge on the two systems after the first differnce in S0.

My guess is that S0 in the real HW does not depend on the history, it would be a real
perversion, if not an HW flaw - not impossible btw, see msx2 and collision detection -

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.

By Manuel

Ascended (18783)

Manuel's picture

04-11-2006, 20:35

ARTRAG: the hardware doesn't depend on history, but the algorithm does, as you already explained yourself.

By ARTRAG

Enlighted (6843)

ARTRAG's picture

05-11-2006, 17:34

A small test sample (thanks Bruno !)

10 Screen 1,2:width 32
20 S$=String$(32,255): Sprite$(0)=S$
30 FOR T%= 0 to 4
40 PUT SPRITE T%,(T%*20,0),2,0: PUT SPRITE T%+5,(T%*20,32),3,0: PUT SPRITE 10+T%,(T%*20,64),5,0
50 NEXT T%
60 GOSUB 1010
70 A%=PEEK(&hf3e7): LOCATE 1, 13: PRINT "CONDIZIONE DI TRE FILE CON 5 SPRITES x LINEA: VALORI DI S0":PRINT (A% AND 64)\64, A% AND 31:T$=input$(1)
80 CLS
90 FOR T%= 0 to 4
100 PUT SPRITE T%,(T%*20,150),2,0: PUT SPRITE T%+5,(T%*20,32),3,0: PUT SPRITE 10+T%,(T%*20,64),5,0
110 NEXT T%
120 gosub 1010:A%=PEEK(&hf3e7): LOCATE 1, 13: PRINT "CONDIZIONE DI TRE FILE CON 5 SPRITES x LINEA: VALORI DI S0 se la prima fila passa in fondo":PRINT (A% AND 64)\64, A% AND 31:T$=input$(1)
130 CLS:GOSUB 2000
140 FOR T%= 0 to 4
150 PUT SPRITE T%,(T%*20,0),2,0: PUT SPRITE T%+5,(T%*20,209),3,0: PUT SPRITE 10+T%,(T%*20,209),5,0
160 NEXT T%:PUT SPRITE 11,(25,10),15,0
170 gosub 1010:A%=PEEK(&hf3e7): LOCATE 1, 13: PRINT "CONDIZIONE DI TRE FILE CON 5 SPRITES x LINEA: VALORI DI S0 Sprites(11) a y=10":PRINT (A% AND 64)\64, A% AND 31:T$=input$(1)
180 CLS:PUT SPRITE 11,(0,10),15,0
190 gosub 1010:A%=PEEK(&hf3e7): LOCATE 1, 13: PRINT "X(11)==0: VALORI DI S0 ":PRINT (A% AND 64)\64, A% AND 31:T$=input$(1)
200 CLS:PUT SPRITE 11,(200,10),15,0
210 gosub 1010:A%=PEEK(&hf3e7): LOCATE 1, 13: PRINT "X(11)==200: VALORI DI S0 ":PRINT (A% AND 64)\64, A% AND 31:T$=input$(1)
220 CLS:PUT SPRITE 11,(-10,10),15,0
230 gosub 1010:A%=PEEK(&hf3e7): LOCATE 1, 13: PRINT "X(11)==-10: VALORI DI S0 ":PRINT (A% AND 64)\64, A% AND 31:T$=input$(1)
240 CLS:PUT SPRITE 11,(-32,10),15,0
250 gosub 1010:A%=PEEK(&hf3e7): LOCATE 1, 13: PRINT "X(11)==-32: VALORI DI S0 ":PRINT (A% AND 64)\64, A% AND 31:T$=input$(1)
260 CLS:PUT SPRITE 11,(256,10),15,0
270 gosub 1010:A%=PEEK(&hf3e7): LOCATE 1, 13: PRINT "X(11)==256: VALORI DI S0 ":PRINT (A% AND 64)\64, A% AND 31:T$=input$(1)
1000 END
1010 V!=TIME
1020 IF V!=TIME GOTO 1020
1030 RETURN
2000 FOR T%= 0 to 31
2010 PUT SPRITE T%,(0,209),0,0:
2020 NEXT T%:return

By ARTRAG

Enlighted (6843)

ARTRAG's picture

05-11-2006, 17:46

Try it on blue, open and the real HW

You'll see that the real HW return the FIRST 5th sprite on the screen
but
OPEN the last one !

This is clear from the first test, where the value in S0 is 14 on OPEN, while sould be 4 on the real HW
It is even clearer in the second test (press space), as moving the first line at the bottom of the screen, OPEN gives 4, while the real HW returns 9.

The other tests on the real HW say that the value of S0 does not depend on the X of the sprites nor on the Y (provided
that the sprites have some lines with the same Y) but only on their plane. Here open seems consistent with the real HW.

(Thanks to Bruno who made the tests on the real HW and on BLUE)

PS
BLUE seems to return the correct values in all the tests

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