Bug in the 5th sprite emulation

Página 4/6
1 | 2 | 3 | | 5 | 6

Por dvik

Prophet (2200)

imagem de dvik

06-11-2006, 22:27

I'm quite sure that the basic program is doing what you want it to do. The sprites are most likely updated way before line 0 in the draw area. Just for comparison, it would be interesting to see it run on an MSX1 machine as well.

Por Manuel

Ascended (18387)

imagem de Manuel

06-11-2006, 22:53

OK, Wouter fixed the bug. I just tested it on openMSX and on real HW, and they give the same values now. Thanks again for pointing this out!

Here's the diff:

--- openmsx/trunk/src/video/SpriteChecker.cc	2006-11-06 20:05:55 UTC (rev 5855)
+++ openmsx/trunk/src/video/SpriteChecker.cc	2006-11-06 21:11:10 UTC (rev 5856)
@@ -111,7 +111,7 @@
 				// Five sprites on a line.
 				// According to TMS9918.pdf 5th sprite detection is only
 				// active when F flag is zero.
-				if (~status & 0xC0) {
+				if ((status & 0xC0) == 0) {
 					status = (status & 0xE0) | 0x40 | sprite;
 				}
 				if (limitSprites) break;
@@ -216,7 +216,7 @@
 				// Nine sprites on a line.
 				// According to TMS9918.pdf 5th sprite detection is only
 				// active when F flag is zero. Stuck to this for V9938.
-				if (~status & 0xC0) {
+				if ((status & 0xC0) == 0) {
 					status = (status & 0xE0) | 0x40 | sprite;
 				}
 				if (limitSprites) break;

Por dvik

Prophet (2200)

imagem de dvik

06-11-2006, 23:42

The solution is different from blueMSX but this one is most likely more correct. blueMSX doesn't take the F flag into account (which will get slightly different behavior on sprites that are on lines 192-255).

And guess what. This actually also fixes the bug in Dragon Quest 2 intro Smile which I knew was related to th 5S flag. blueMSX failed because the F flag was not taken into account and openMSX because of this invalid check.

Por ARTRAG

Enlighted (6687)

imagem de ARTRAG

07-11-2006, 00:03

It seems I opened a pandora's box with this 5th sprite issue Smile

Por pitpan

Prophet (3145)

imagem de pitpan

07-11-2006, 00:41

Yes, you did. Blame on you Wink

I'm pretty sure that there's still a lot to discover about sprites on TMS9918.

Por dvik

Prophet (2200)

imagem de dvik

07-11-2006, 00:53

I'm pretty sure that there's still a lot to discover about sprites on TMS9918.
One funny thing I noticed (which actually is different between the tms and v9938) is that if you have a sprite collision to the left of the display area (early clocked sprites), they will set the collision bit on the TMS and not on the V9938 (or the other way around).

Other interesting things is that the 5th sprite and sprite collision bits are not set on the actual scanline where the collision/5th sprite occurs. Its set about +/- 3 scan lines from the scan line it actually is.

Por dvik

Prophet (2200)

imagem de dvik

07-11-2006, 00:57

.... and neither of these two cases are emulated correctly. So there is certainly a lot more todo.

Por flyguille

Prophet (3028)

imagem de flyguille

07-11-2006, 02:13

I can understand that in 9938 the enginners though about detecting only what is visible but....

the other difference? WTF ??? processing data of others scanlines that is not the current scanline or just the next scanline??? WTF

Por Manuel

Ascended (18387)

imagem de Manuel

07-11-2006, 08:55

dvik: can you post a small test program for both issues?

Por jltursan

Prophet (2578)

imagem de jltursan

07-11-2006, 15:25

Its set about +/- 3 scan lines from the scan line it actually is.

So the use of this feature to implement the screensplit on MSX1 is even harder due this behaviour. I'm still thinking on a way to do it in a clean way...

Página 4/6
1 | 2 | 3 | | 5 | 6