Bug in the 5th sprite emulation

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

By dvik

Prophet (2200)

dvik's picture

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.

By Manuel

Ascended (18784)

Manuel's picture

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;

By dvik

Prophet (2200)

dvik's picture

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.

By ARTRAG

Enlighted (6844)

ARTRAG's picture

07-11-2006, 00:03

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

By pitpan

Prophet (3152)

pitpan's picture

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.

By dvik

Prophet (2200)

dvik's picture

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.

By dvik

Prophet (2200)

dvik's picture

07-11-2006, 00:57

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

By flyguille

Prophet (3028)

flyguille's picture

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

By Manuel

Ascended (18784)

Manuel's picture

07-11-2006, 08:55

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

By jltursan

Prophet (2619)

jltursan's picture

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...

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