Quote:

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?

Checking the F flag in blueMSX like you do in openMSX fixed it in blue. So without the fix, the logo is corrupted and with the fix its good.
What I fixed was changing the check (in a couple of places):

if (~vdp->vdpStatus[0] & 0x40) {

to

if ((vdp->vdpStatus[0] & 0xc0) == 0) {

So the previous bug in blue was that only the 5S flag was checked, now both 5S and F has to be cleared to set the 5th sprite stuff in S0.
Not sure what else may be wrong.

Quote:

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.

Can I guess ? Mine is only a conjecture, but I think that the Hw subsystem for the collision check in the v9938 is the same of the TMS - or better is the same of the msx1 mode. Have you tried to see (of a real HW- naturally) if setting the EC bit in the colour attribute in the SAT and setting the EC bits in the colour table before the SAT leads to a correct detection of the collision?

So, when a new release of OpenMSX and of BLueMSX ?

If this bug prevents users from developing msxdev entries I think they should be released immediately. So let us know. I could certainly make another blueMSX release the coming weekend if needed.

Actually, this bug prevents me to implemet a multiplexing scheme for multicolor sprites on MSX1,
but I do not think we'll be able to release our game in msxdev06 so, take you time.

Quote:

Actually, this bug prevents me to implemet a multiplexing scheme for multicolor sprites on MSX1, but I do not think we'll be able to release our game in msxdev06 so, take you time.

I can always send you a beta if you like. Just let me know.

ok thanks, i'll let you know

And for openMSX you can get the latest version from subversion ^_^

And if you want to compile yourself you can of course also get blueMSX from the sourceforge archive.

If you need a binary of openMSX, please ask us on IRC: irc.freenode.net, channel #openMSX, or ask BiFi directly, as he makes Windows builds.

We will certainly not release soon, as we are in the middle of some big changes and they are not very well tested yet. So, this also means that the betas might have some weird behaviour at times. I always run the latest and greatest, and I must say there are no real problems, but small issues can always be there.
OTOH: if you really need something stable, we could easily backport the fix to openMSX 0.6.1 and build it for you. Just ask.

I still have no clue about the Dragon Quest II problem and the other things you mentioned, dvik... The latter certainly scream for a test program.

@manuel, I can certainly do a little test program to show the two things. Currently I don't have my real MSXes set up though and I have some technical problems with the disk drives and flash cards so it may take a couple of weeks. But I can try to do them sooner if someone can try them on real hw.

I have no idea about the problems in DQII. I've been looking for a solution to this bug for a loooong time and probably made some improvments. Can't recall anything that would make any difference though. If I find something I'll let you know.

@dvik just ask me for the latest build, I'm mostly in the channel when everyone is asleep

thanks (in advance), dvik.

Quote:

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?

@pingpong
Actually, I'm very concerned about the level of accuracy of OCM.
There is no info at all about its features, or about compatibility with existing SW,
or about benchmacks... Some hints on the website (gradius running) let us hope that OCM
will be accurate, but no statement is done about this matter.
This sounds like "this is an FPGA, look, the msx can be done, do it yourself"
I orderd the OCM, but I am a bit worried on what i'll get exactly
and I hope that bugs could be corercted later..- or not ?

I assume there will be updates and I know it won't be perfect yet.