[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [MiNT] Blue icons in XaAES



Vincent Rivière, 08.12.2012 17:03:02:

On 06/12/2012 01:05, Helmut Karlowski wrote:
It only happens on aranym in combination with it's IDE-interface

Wrong.

I was assuming this because I never see it on my working aranym-setup where I use SCSI-images+hostfs, only the miniPack.

I reproduced the problem with a hostfs only setup.
So definitely, the blue icon problem is not related to the filesystem.

Maybe SCSI fixes it? ;-)

But it goes away if XaAES is restarted (Ctrl-Alt-J).

Partially.

Sometimes the problem disappears when restarting XaAES. Sometimes not.

I observed that it goes away for those icons that have been displayed in the first run ...

Anyway, in every case I tried, XaAES always hung just after restart.

That is because fVDI can not close a physical workstation as discussed countless times. I fixed this:

http://home.arcor.de/zabruder/atari/fvdi_gnu.zip

2) With the exact same filesystem, I didn't reproduce the bug with TOS 4.04.

Does it run in true-colour? What bit-depth do you get?

3) IIRC, EmuTOS does not fully initialize the 256-color palette on Falcon
hardware. I don't know how this could affect fVDI.

That could be a cause.

4) Sometimes, regardless to the wrong palette, only the top part of the
XaAES logo is affected by the blue background =-O
See the attached screenshot.
I wonder how this is is possible. Either something is severely wrong in
ARAnyM, or some interrupt happens during the logo painting...

Yes. Really strange.

5) If I press 'd' when fVDI starts, it enables the debug mode, and the bug
does not happen. I don't know if the change of behavior is related to the
debug mode, or keystrokes, or whatever.

It produces c:/fvdi.log which can become quite large, which points to a timing-issue.

I really wonder what could cause such a bug. It seems that white becomes
blue, and anything else becomes black. Typical from a wrongly initialized
palette. But this does not explain how the phenomenon can occur on half a
bitmap only.
Maybe ARAnyM picks up the palette pickups the palette just once per VBL, or
something like this. I don't know.
Also, I wonder what is wrong: the source bitmap or the blit function? Some
debug traces could help to understand what is going on.

I traced it in XaAES and I think I found that the error happens inside vrt_cpyfm in transform_gem_bitmap in trnfm.c. It was hard enough to find this, and I gave up then.


--
Helmut Karlowski