Unstable display in Native mode.

[Ed Cruse]

I'm able to duplicate this very easily.

The left side of the Amiga display wiggles back and forth randomly about 1 mm in Native modes with the following settings.

1. NTSC or PAL machine.
2. Full-screen with vysnc or not. Switch to windowed with ctr-f12 stops, starts again when switch back to full-screen.
3. Windows res mode=1280x1024, 1024x768 is stable. Only two I've tried. Windows and RTG at 1280x1024 are stable.
4. FS, Auto-scale is stable.
5. Aspect-ratio and KAR enabled, either vga or tv, either disabled is stable.
6. NTSC or PAL WB screen.
7. Filters that are not stable. Scale2x, hq2x/3x/4x, SuperEagle, Super2xsaI, 2xSaI. The rest I never saw be unstable. Scale2x seems to be the best at being unstable.

I even got it to be unstable using the 4000 quick start, using a box stock 3.9.

I hope this enough to reproduce.

[Toni Wilen]

Can reproduce but only if 5:4 aspect ratio is selected.

[Ed Cruse]

Originally Posted by Toni Wilen

Can reproduce but only if 5:4 aspect ratio is selected.

You're right, 5:4 is the only one that does it. I'd guess memory leakage because of random nature of problem.

[Ed Cruse]

With 1610b1 instability was still only with 5:4 aspect-ratio setting.

With 1610b2 instability is now only with 15:9, 5:4 aspect-ratio is stable. Other then that change it's still the same as my first post of this thread. Persnally I think all the aspect ratios are broken and the ones that work, work by luck. Maybe some odd timing thing.

[Toni Wilen]

I think it must be those filters messing up with FPU mode/state causing different double/float->int conversion results in filter scaling calculations..

[Ed Cruse]

Originally Posted by Toni Wilen

I think it must be those filters messing up with FPU mode/state causing different double/float->int conversion results in filter scaling calculations..

If this is the problem then the difference probably isn't very much until converted to integer. You could be having the problem below.

1.99999999999999 -> 1
2.00000000000001 -> 2

Both numbers are basically the same but converted to integer a lot different. The trick would be to round before converting to an int.

if(num<0.0) num=ceil(num-0.5); else num=floor(num+0.5);

[Toni Wilen]

Actually the problem is that emulated FPU state is mirrored to real FPU state. (FPU emulation uses host FPU which means rounding states must match)

I guess rounding mode must be reset temporarily when doing filter calculations.. How boring..

Originally filtering calculations used fixed point math but it was getting too ugly..

[Toni Wilen]

Does http://www.winuae.net/files/b/winuae.zip fix it? (I couldn't duplicate the problem anymore, not even if I used previous version..)

[Ed Cruse]

Originally Posted by Toni Wilen

Does http://www.winuae.net/files/b/winuae.zip fix it? (I couldn't duplicate the problem anymore, not even if I used previous version..)

That seemed to fix it. To confirm I tried the original b2 again and I was able to duplicated the problem again, so it looks like the fix worked.