[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