mouse pointer destroyed

[meynaf]

Seems Winuae doesn't like to be idle...

Run winuae in windowed mode and bootup some normal wb config.
I don't know if there is something special to do on the Amiga side. That problem appears to be random.
Now untrap the mouse with mmb.
Then use the "_" icon to put winuae to sleep (cpu usage drops).
Wait for a very long time - might be one hour and maybe more. I often have an amiga setup still running while doing something else, btw (like editing with notepad++ and assemble with phxass).
And finally return to your Amiga setup by clicking on the winuae icon in the task bar (this is windows 8.1's taskbar for me).

Now what ? Sometimes the mouse pointer is completely destroyed (sprite displayed incorrectly as if its data got damaged). Everything else still work fine.
Rebooting the Amiga doesn't fix the problem : the fresh reboot still has garbage gfx instead of the pointer sprite. The only fix is to quit completely then restart.

Looks strange but it happens quite often, though really far from every time. Both 3.0.0 and 3.1.0 have shown that problem. Dunno for other versions.

[Toni Wilen]

There is no normal WB config.. RTG? Custom? What resolution? Depth? If RTG, hardware cursor enabled?

And so on..

Config and logs as usual

[meynaf]

This is a carbon copy of my A1200 config. V39 workbench, AGA active (no RTG).
It's my ugly - but readable and eye-friendly - 640x256 8-color wb (with some nice filter active).

The only log i have is winuaebootlog.txt. Doesn't seem useful here, since nothing fails at bootup.
What else do you need ?

[amilo3438]

Have you tried with loading the config into new winuae version and saving back from that version? (under a new name, or make a back-up of old one)

[Toni Wilen]

Does the corruption remain if you create state file, quit emulator, run it again and load it? (First remove all unneeded expansions)

[meynaf]

Originally Posted by amilo3438

Have you tried with loading the config into new winuae version and saving back from that version? (under a new name, or make a back-up of old one)

Config files were created with 3.0.0 and this version has the problem.
So no, it is not an old config file conflict.

Originally Posted by Toni Wilen

Does the corruption remain if you create state file, quit emulator, run it again and load it? (First remove all unneeded expansions)

Haven't checked (it takes time to reproduce and is random, as i said), but my guess is that it will not remain (why would it, as it's not a problem in the amiga part because a full reboot doesn't fix it, huh ?).
Anyway I'll try this next time it happens. Could take a while...

[Toni Wilen]

Originally Posted by meynaf

Haven't checked (it takes time to reproduce and is random, as i said), but my guess is that it will not remain (why would it, as it's not a problem in the amiga part because a full reboot doesn't fix it, huh ?).
Anyway I'll try this next time it happens. Could take a while...

I'd like to know if it is caused by corrupted chip ram or some other chipset register was suddenly changed. (Statefile would help to see it)

Also when it happens, create state file first and then enter debugger and check sprite pointer in copper list (o command), check if it points to correct sprite data or something else.. (Or you can also use Amiga-side monitor program or something to check it)

[meynaf]

Originally Posted by Toni Wilen

I'd like to know if it is caused by corrupted chip ram or some other chipset register was suddenly changed. (Statefile would help to see it)

Did you read what i wrote ? The problem survives a reset !
This means it's impossible that's just chipmem corruption or changed chipset register, as these would be correctly set back.

Originally Posted by Toni Wilen

Also when it happens, create state file first and then enter debugger and check sprite pointer in copper list (o command), check if it points to correct sprite data or something else.. (Or you can also use Amiga-side monitor program or something to check it)

It is not related to the Amiga side. Chipmem is 100% correct.

Hopefully in the meantime i was lucky enough to get it again, so i made a save state, quit, then restart and then load the save state.
And i saw the normal mouse pointer.

In short, the answer to your question is : no, it does not remain. Not even a small glitch.

[Toni Wilen]

I must have been too tired, I read it "full reboot does fix it" each time..

[meynaf]

Originally Posted by Toni Wilen

I must have been too tired, I read it "full reboot does fix it" each time..

Not a problem as long as you know your mistake now
You must also be quite flooded with reports which have nothing to do with bugs on your side so i understand your reaction...

So what could alter the appearance of a sprite, and what is the effect of a long time spent in the background doing nothing ?

Perhaps you can try running the windowed uae and send it to oblivion while you play some other game... This is how i got it last time (but the mere fact of running another directx program isn't enough).

[meynaf]

Got it again !
This time i played with settings on both sides, without effect.
It's not only the mouse pointer, but all sprites, that get broken.

See how old protracker looks now...

[Toni Wilen]

Statefile?

At least screenshot confirms sprite size does not change (not FMODE related) and both sprite planes are still active. Position also appears to be correct, not sure how it is possible that sprite control words are correct but data words are not.

Strange..

[meynaf]

Originally Posted by Toni Wilen

Statefile?

Seems you're tired again.
I told you earlier that it does not appear in the statefile.

Originally Posted by Toni Wilen

At least screenshot confirms sprite size does not change (not FMODE related) and both sprite planes are still active. Position also appears to be correct, not sure how it is possible that sprite control words are correct but data words are not.

Strange..

Sprite control words are correct and data words are correct too.
What is incorrect is how the sprite is displayed.

In short, everything in the Amiga side is correct, but something prevents proper display of the sprites.

[Toni Wilen]

Originally Posted by meynaf

Seems you're tired again.
I told you earlier that it does not appear in the statefile.

No, I was not tired this time. I still want it, it can give some extra hints.

[Mclane]

Where are your logs and configs, you seem sure its not them but you may have missed something...

[Toni Wilen]

I didn't ask for logs because I don't think it will help in this situation.

[meynaf]

Originally Posted by Toni Wilen

No, I was not tired this time. I still want it, it can give some extra hints.

Does the statefile contain stuff that's not related to the state of the emulated machine ?

Originally Posted by Mclane

Where are your logs and configs, you seem sure its not them but you may have missed something...

Why would them help, the emulator doesn't even notice there is something wrong...

[Toni Wilen]

Originally Posted by meynaf

Does the statefile contain stuff that's not related to the state of the emulated machine ?

Some but the point of statefile is that I can use it to try different things to find out how to cause identical corruption to re-appear. (For example perhaps sprite data is read from wrong address = I need exact same memory contents)

[meynaf]

Why don't you just try the reproduction steps I gave you ?

[Toni Wilen]

Originally Posted by meynaf

Why don't you just try the reproduction steps I gave you ?

Because it requires too much time and is too unreliable and I can almost guarantee it won't happen unless I have exactly same config and possibly similar hardware too (if it is timing related or some other memory corruption bug that depends on timing).

EDIT: Statefile is the easiest way to get lots of background information to narrow down possible reasons before trying something too random.