Quote:

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.

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.

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;

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

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

Yes, you did. Blame on you

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

Quote:

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.

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

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

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

Quote:

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

Quote:

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

The screensplit is Waves is done using 5th sprite but as you can see there is several black lines between the screen 3 and screen 2 part to hide this effect.
In MSX Unleashed we synchronized splits to VBLANK which is the only stable synchronization point. The problem though is that you have to have quite a big amount of code that always execute the same number of instructions since its more than half a screen between VBLANK and where in the next frame you actually want the split.
In the sequel to MSX Unleashed I can promise you and orgy of screensplits

Quote:

In the sequel to MSX Unleashed I can promise you and orgy of screensplits

Quote:

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.

For me it's not possibile....

Anyone know if the OCM works in the same way of real hw?

dvik - hmm, I still see corruption of the logo in Dragon Quest II: left of the II there is a block of background color. Are you sure it should be fixed in openMSX?