WinUAE 4.0.0 beta series

[DamienD]

Originally Posted by RomRetro

Hello Marty2AGA,
Great overlays ! Could you help me to found them please ?
Have you any other in this style ? There are beautiful.
Thanks.

Heya RomRetro,

Welcome to EAB

See this thread: Overlay Frame/Picture with LED's?

Thanks a lot DamienD :-) You make me happy !!

And Also Marty2AGA for his great work.

[DamienD]

Retro-Nerd found some others here:

Originally Posted by Retro-Nerd

Found it here (and some more).

https://forums.libretro.com/t/exodus...t-support/9192

I should also post this in the Overlay Frame/Picture with LED's? thread so that it doesn't get lost

[Toni Wilen]

Originally Posted by Marty2AGA

Hello Toni,
First - Big Thanks for the Led Lights

After Loading a Game or here as Example Recall's - Rave nation. The Power LED goes off. Turns the programm the Audio Filter on and i need a seperate Dark Power Led ?

Power led either turns off completely or dims. It depends on hardware but only switch off is "emulated". So I guess I need to add power led mode option

If dimming mode: power led is drawn with reduced brightness (no need for separate image). If switch off mode: nothing is drawn.

[Toni Wilen]

Originally Posted by PeterK

Btw, it takes nearly 30 seconds in non-Jit mode to load my background JPG image and scale it from 1920x1200 to 1280x800. With Jit it comes immediately.

But does 3.6.1 vs 4.0.0 have any speed difference? (It shouldn't. and why does jpeg decoder use floating point?)

Tan() and ATan()

It looks like it caused by another weirdness in x86 math functions..

I noticed JIT already has assembly functions for most trigonometric operations. I'll just copy them to 80-bit native code which also fixes this problem.

The FPU constants as generated by softfloat are 100 % identical to the 68881.

That was implemented when softfloat was added. Even undocumented constants are 100% correct. (Oddly enough 68881 and 68882 are 100% identical, even undocumented constants are identical)

The 80 bit host results (Jit and non-Jit) are still ok, except for a wrong long double infinity number (highest bit in the mantissa).

It probably is Intel/Motorola difference. Unfortunately extended precision is not as stricly IEEE defined as doubles and floats.

The 64 bit FPU constants have several saturation bugs for the very large numbers, which was much better once in WinUAE 1.0 and still in v2.4.0, but I didn't check all versions to find out where the wrong large number handling starts.

In what kinds of operations? Lots of things changed when softfloat was added, FPU emulation was separated to generic emulation + one or more modules that do the actual calculation (softfloat, native etc)

[PeterK]

Originally Posted by Toni Wilen

But does 3.6.1 vs 4.0.0 have any speed difference? (It shouldn't. and why does jpeg decoder use floating point?)

I noticed JIT already has assembly functions for most trigonometric operations. I'll just copy them to 80-bit native code which also fixes this problem.

In what kinds of operations? Lots of things changed when softfloat was added

No, there is no difference in non_Jit slowness compared to 3.6.1, I just never noticed that before since I usually use Jit all the time. It's WarpJPEG.datatype which needs no FPU to work (I can disable it), but strangely, in the disassembly I can find an FMOVEM to save FP0-FP7 to memory and another one restoring the registers from the same memory location. The slowness is the same with or without an FPU: unbelivable 30 seconds. Maybe, I should make tests with other jpeg datatypes.

Yes, I've added all missing trigonometric functions to the Jit in WinUAE 1.0, but that was 12 years ago. The Intel FPU has a very limited set of FPU instructions, but it's much more clever made than the crippled 68040/060 FPU. You can construct all functions by building short routines with these basic FPU instructions. No need for integer calculations or exceptions. This is one point why Motorola has lost the race against Intel.

What do you mean by "operations" concerning the simple reading of "internal" (68881) FPU constants? The constants for the very large numbers which can not be represented by float or double should always return infinity for the 64 bit FPU, but they don't do it anymore. WinUAE 2.4.0 is still ok, but in 3.2.2 the results are already wrong. Somebody must have changed the code, maybe has added some C-compiler based floating point number conversion, which should not be used. Instead of any sort of saturation the returned number should always be infinity for too large constants. Try my FPUconstants proggy.

[Toni Wilen]

Originally Posted by PeterK

The constants for the very large numbers which can not be represented by float or double should always return infinity for the 64 bit FPU, but they don't do it anymore.

It uses now generic 6888x round to double/float routines and they don't return infinity but max or min possible value. So in my opinion this is more correct behavior because it matches other similar rounding operations.

EDIT:

Yes, I've added all missing trigonometric functions to the Jit in WinUAE 1.0, but that was 12 years ago.

Do you have them in normal assembler format? Decoding them from opcodes is not very fun and comments don't seem to be complete.

[Marty2AGA]

Originally Posted by Toni Wilen

Power led either turns off completely or dims. It depends on hardware but only switch off is "emulated". So I guess I need to add power led mode option

If dimming mode: power led is drawn with reduced brightness (no need for separate image). If switch off mode: nothing is drawn.

Sauber .. äh .. great

[PeterK]

I don't know if a too large number is closer to a max value or to infinity?

But I tried to stay compatible to the Motorola decisions (look at the 68881 results for float and double, they are all infinity for too large numbers).

And you get the same results with softfloat!

Let me see what is left from my old code on last existing HDD. Everything else is already dead and lost.

[Toni Wilen]

Originally Posted by PeterK

I don't know if a too large number is closer to a max value or to infinity?

But I tried to stay compatible to the Motorola decisions (look at the 68881 results for float and double, they are all infinity for too large numbers).

Oops. I was only looking at extended precision results, I didn't think about doubles that are of course wrong if value is not infinity.

I am still not sure if extended precision value should be infinity or max (because this does not exists in real world) but I'll use old behavior because it gets automatically fixed if doubles are fixed.

winuae.7z updated.

[PeterK]

Originally Posted by Toni Wilen

trigonometric functions:

Do you have them in normal assembler format? Decoding them from opcodes is not very fun and comments don't seem to be complete.

No, my WinUAE 1.0 source tree with all the formulas for the trigonometric functions got lost on my very old Win98/2000 PC. I never wrote these functions in normal x86/x87 assembler code, just as Jit emit() instructions.

Which functions do you need? I could try to revert the Jit instructions to untested assembler code or at least extract the formulas to rebuild these functions with the availavle FPU commands.

Update: Tan() and ATan() are working correct now. Thanks.

OT: Concerning the slow non-Jit background picture: JFIF 44.8 is 35 % faster than WarpJPEG.

[Toni Wilen]

Originally Posted by PeterK

Which functions do you need? I could try to revert the Jit instructions to untested assembler code or at least extract the formulas to rebuild these functions with the availavle FPU commands.

Some kind of test program for all logaritmic/trigometric functions would be probably better.

[vagrant]

Originally Posted by Toni Wilen

- Fixed crash in lagless vsync mode if CPU speed was on the fly changed.

Hi Toni, sorry I have not had time test this until now.
Unfortunately it is still crashing when I exit whd games, though the crash is now worse, as winuae hangs and I'm forced to restart.
There is amiga hdd activity when it freezes, I wonder if my .hdf has something to do with it?

[Toni Wilen]

Originally Posted by ED-209

Hi Toni, sorry I have not had time test this until now.
Unfortunately it is still crashing when I exit whd games, though the crash is now worse, as winuae hangs and I'm forced to restart.
There is amiga hdd activity when it freezes, I wonder if my .hdf has something to do with it?

Does same happen with JIT off? (But keep fastest possible <> non-fastest possible change)
Does it still happen if you switch to full-window mode? (Ignore graphics glitches etc.. it most likely won't sync properly in full-window)
Do you mean ctlr+alt+del or alt-tab do nothing? Or they do but all windows are stuck "behind" black screen?

[vagrant]

Originally Posted by Toni Wilen

Does same happen with JIT off? (But keep fastest possible <> non-fastest possible change)
Does it still happen if you switch to full-window mode? (Ignore graphics glitches etc.. it most likely won't sync properly in full-window)
Do you mean ctlr+alt+del or alt-tab do nothing? Or they do but all windows are stuck "behind" black screen?

Yep same thing happens with JIT off.
It is working in full-window mode (though cpu is over 400% )
When it crashes the display freezes "as is", then I can only restart the PC via ctrl-alt-del, because as you say, all windows become "stuck behind black screen".

[PeterK]

Originally Posted by Toni Wilen

Some kind of test program for all logaritmic/trigometric functions would be probably better.

I'm always using a modified version of the HSBenchmarks together with my MathLibsUAE (as a direct IEEE mapper to the FPU) for test calculations.

[Toni Wilen]

Originally Posted by ED-209

Yep same thing happens with JIT off.
It is working in full-window mode (though cpu is over 400% )
When it crashes the display freezes "as is", then I can only restart the PC via ctrl-alt-del, because as you say, all windows become "stuck behind black screen".

Full-window should have been almost same. Fullscreen-only makes this difficult..

Does it happen if you don't have RTG enabled?
Add -logflush command line parameter (without it last few log lines will be lost)
Check winuae.exe directory (and log directory if different than winuae.exe dir) for crash dump files.

btw, selecting sign out from ctrl-alt-del menu should be easier and faster, no need to reboot, sign out should automatically kill the program. Then sign in.

[vagrant]

Still happens with RTG disabled.
It seems to be switching from cycle_exact true, to cycle_exact false that triggers the crash. If I just use cpu_speed real, to cpu_speed max there is no crash.

There are no crash dumps being created.
Attached is log with logflush enabled, where I have JIT completely disabled and only cycle_exact switch apon exit causes freeze.

Also side note; while I was testing at some point winuae stopped recognising both my hdf's.. in the GUI all values showed as "?", and logfile showed "hdf not found" errors.. I had to restart PC for them to work again. (hasn't happened since)

[Toni Wilen]

Originally Posted by ED-209

Still happens with RTG disabled.
It seems to be switching from cycle_exact true, to cycle_exact false that triggers the crash. If I just use cpu_speed real, to cpu_speed max there is no crash.

There are no crash dumps being created.
Attached is log with logflush enabled, where I have JIT completely disabled and only cycle_exact switch apon exit causes freeze.

EDIT: Try first with -busywait command line parameter. Does it still happen? ("winuae.exe -busywait")

Use following method to open task manager and create dump file (select winuae.exe, right click, create dump file): https://blogs.msdn.microsoft.com/old...25-00/?p=96035

Make sure JIT is off.

Check also if winuae.exe is still using CPU or if it only shows 0%?

Also side note; while I was testing at some point winuae stopped recognising both my hdf's.. in the GUI all values showed as "?", and logfile showed "hdf not found" errors.. I had to restart PC for them to work again. (hasn't happened since)

This probably means old winuae.exe is still in hung state (or some bad virus checker/security program got confused) and keeps hardfiles locked (if HDF is opened read-write, it gets locked to prevent other programs from also opening it in read-write mode which would be very bad idea)

[vagrant]

Originally Posted by Toni Wilen

EDIT: Try first with -busywait command line parameter. Does it still happen? ("winuae.exe -busywait")

Use following method to open task manager and create dump file (select winuae.exe, right click, create dump file): https://blogs.msdn.microsoft.com/old...25-00/?p=96035

Make sure JIT is off.

Check also if winuae.exe is still using CPU or if it only shows 0%?

Yes it still happens with -busywait
I created a logfile via task manager, without -busywait & JIT, though the filesize is 405mb(!), normal size?
Winuae.exe in task manager shows 'not responding', but still has active CPU, 45-46%