problems with border update effects

[koseidon72]

Hi

There is a bug in border line effects.
They aren't displayed well.
BlueMsx emu does this nice, instead.

Have a look please to this peace of software so you can see the differences from Blue and Open emulators.

Have a look in the loading part, for the border turbo multicolor stripes.
(In OpenMsx I can see only big flashes)

Thanks

msx.altervista.org/cas/Hockey.zip

[Manuel]

I see about 4 or 5 colours at the same time. Is that too little?

[koseidon72]

You should see loading strips scrolling, not flashes. Try BlueMsx. As I said, it reproduces that effect as a real Msx does.

Thanks

[Manuel]

I think this is caused by the sync problem... But I'm not sure. Can you make a screenshot of the loading process in blueMSX?

Also note that maybe blueMSX loads CAS way too quickly, as it uses a BIOS patch. I'm not sure if it still does that, but it did do that in the past. This could mean that blueMSX is wrong and not openMSX.

Can someone try this on a real MSX?

[koseidon72]

You're right BlueMsx uses a bios hack for loading but this doesn't impact to the loading sequence, that is speed-up only in time, not in processor.
All the operations are cycle exact during this speed up loading hack.

If you leave me a private mail I can send you a snapshot of Bluemsx loading that piece of software.

My email is: koseidon72@hotmail.com

Thanks

Ps: I've tried it on a real msx and the proper loading stripes effects are very similar to what BlueMsx shows.

[koseidon72]

Hi, I've sent you the picture you asked.
Have you recieved it?

[Manuel]

Yes, thanks a lot!

I created a but ticket in our bug tracker:

http://sourceforge.net/tracker/index.ph ... tid=421861

It's easier if you attach any more information to this bug directly. You do need a (free) SF.net account for it, though.

Thanks for reporting this! (I have no idea what the cause could be, though....)

[koseidon72]

Thanks alot.
I have signed in that forum so I can check

[koseidon72]

Hi, I notice that this bug is still in latest OpenMsx release.
Maybe the author hasn't seen this message.
Please report it to him because it's an important bug or function not implemented about video raster syncronization that is totally missed on border area...

[Manuel]

I'm not sure if it's so important, as other programs seem to work fine when changing the border colour. E.g. the dvik demos also do it and they show no problems...

[koseidon72]

Yes but this is a bug and so you ask for reporting bugs...

Please have a check as I think that it isn't good to know that there is a bug and ingnore it.
Thanks for helping.

[Manuel]

Hi

Yes, it is a bug and I thank you for reporting it. It is put in our bug tracker. (It is certainly not ignored.)

However, we cannot just fix every bug right away. There are other things to do as well and most of them are considered more important by us than this bug. We have to prioritize things. We have more than 50 bugs in the tracker!
As we are all volunteers, we can never guarantee when we will fix a bug. But probably, it will be picked up some time...

If you don't like this: please find someone who wants to look at this bug now and share the fix with us.
Also, it may be helpful to try more games and find details, which games show this problem, which do not (if so), where can the symptom also be seen, etc. This makes the chance that it will get fixed bigger.

Please keep reporting bugs, though!

[Manuel]

I've tested this on a real MSX myself and the bug is invalid. See the comments in the bug entry, which I'll quote here:

Well, I ran Venom Strikes Back! on my real MSX and compared the stripes
with openMSX. When pausing, openMSX shows only 4 or 5 stripes, but when
actually running, there are many more visible (probably some optical
mixing). When running on a real machine, the same effect is visible (I
couldn't pause there, but making some photos reveals only a few bars
visible). Anyway, when loading on my real MSX, you see about the same
amount of visible (illusion) bars as in openMSX. This was with a 1200 baud
tape both on real and openMSX.

Also, Wouter confirms this by theory:
<wouter_> but in any case a 1200baud cas file has far too few information
to update the background color every line (as is visible in the blueMSX
screenshot). 4 or 5 times per frame (as in openMSX) is much more
realistic
<wouter_> but in any case openmsx converts cas files intrenally to 5520
baud wav files, the game uses the BIOS to load the wav file (i just checked
this), the bios routine 0xe4 (TAPIN) waits for at least 10 symbols
(startbit stopbit and 8 data bits) .. 50 frames per second .. so that
makes the blueMSX screenshot completely impossible

The blueMSX screenshot can be explained by the fact that it is using CAS
files directly (without converting to WAV first internally), which gives a
much higher bit-rate, so, the changes of the background can be done more
quickly, resulting in smaller stripes.

Conclusion: openMSX is doing just fine, there is no bug.