WinUAE 2.4.0 beta series

[rsn8887]

Regarding the stuttering after switching to double buffer/triple buffer "on the fly", it is still there in last winuae.zip.

Otherwise everything seems perfect in this version, so far. I just tested Vision MegaDemo IV on A500/cycle exact in double buffering low latency vsync screenmode, no stuttering even in last part.

[Toni Wilen]

http://www.winuae.net/files/b/winuae_2400b6.zip

Beta 6:

New vsync should finally work in all modes.

- Removed sound exclusive checkbox, WASAPI exclusive modes are now listed in select menu.
- New RTG vsync using low latency sync method, currently always triple buffered.
- Display selection GUI changed again, now lists both display adapter(s) and connected monitor(s).
- Associated ".uae" didn't set correct icon id (right click on .uae shows wrong or missing icon). Reset .uae association again to fix it.
- Fixed filter panel hang in some situations before emulation was started.
- Low latency vsync keeps list of modes that have already been calibrated, switching back to remembered mode uses stored calibration value.
- Unreliable old-style vsync options are gone. Replaced by low latency + double or triple buffered mode.
- DirectDraw low latency vsync fully implemented.
- RTG hardware cursor positioning fixed in aspect ratio corrected full window modes.

[rsn8887]

Newest Beta (22nd december), A1200 seems fine so far, need to test more. But A500 low latency modes are all at 100% cpu usage now, sound buffer blue at +99. This is booting without any floppy inserted, regardless of sound driver and direct3d/ddraw setting.

Actually, same behaviour when booting A1200 with no floppies/hd attached.

Can be tested with quickstart options.

Last winuae.zip (21st december) worked fine in A500 and A1200 modes (~34% CPU with same configs). Corection: A500 Approximate speed no cycle exact: 34% CPU in old beta, 100% cpu and blue sound buffer in new beta

A1200 Approximate speed no cycle exact: 100% cpu and blue sound buffer in new AND old beta

[Mad-Matt]

B6 seems to have sorted the issue I mentioned before with rtg and new vsync. However a new issue has arrisen where the emu either crashes or gets very laggy when switching from Fastest Possible to Adjustable cpu/chipset mode. This is the mode my whdload is set to use and it hasnt been an issue before. (It can be reproduced simply switching modes on the fly while on rtg workbench)

This issue also causes the gpu jump to 100% use and starts to cook as the fan ramps up !

[Toni Wilen]

Right, something got broken in non-fastest possible vsync..

[Toni Wilen]

http://www.winuae.net/files/b/winuae_2400b7.zip

Quick fix for broken vsync in non-fastest modes fixed.

Beta 7:

- vsync in non-fastest CPU modes fix (b6)
- Renamed "Include CD/DVD drives.."
- Disable other uaescsi.device CD drives if image mode or drive letter is selected from CD type select menu.

[Ian]

Wow, tremendous slow down with both versions (b6 and b7) with Vsync enabled now, even with vsync turned off it's using (according to the display) 120% CPU time.

Using cycle exact mode 2x a1200 speed although it does the same with normal a1200 speed in RTG mode. None RTG mode seems fine.

Also some crashes, don't know if the crash dump will help you.

Attached logs, 2 crash dumps and config to see if it helps.

[Toni Wilen]

I forgot to handle RTG vsync without fastest possible CPU..

[Ian]

The one time I put everything there to help you and it's something simple that you would've got from the description

[rsn8887]

Originally Posted by Toni Wilen

I forgot to handle RTG vsync without fastest possible CPU..

Non rtg modes tested in games for an hour. CPU usage in directdraw is comparable to direct3d, mayube a couple % faster in ddraw. Only exception is double buffered mode, in which directdraw seems much slower (double buffered directdraw CPU84% double buffered direct3d: CPU30%, all other modes around 30%). Might just be my system...

I switched all my configs to directdraw low latency vsync non-buffered modes. I am also using sound buffer 1 now with portaudio ASIO (!).

Toni, what is the nature of sound degradation when buffer is too small? Is it instantly audible, or a subtle general degradation, like the pitch shifting in directsound I used to hear? I am asking because it sounds pretty much the same to me regardless of buffer settings.

Another thing I noticed playing Leander on A500 low latency no buffering. CPU% light is often exactly at 100 and game runs smooth and fine. Sometimes I see a 101 flicker and it still runs fine. How is this possible, or is it just a coincidence? Shouldn't it start to stutter as soon as it goes slightly above 100?

[Toni Wilen]

Some background information again:

Sound buffer under or overflows or high CPU requirement won't affect new vsync mode nearly as badly as old method, as long as it is short enough.

Traditional vsync (old method) is only designed to prevent tearing, by any means necessarily. The end.
It has following problems if goal is low latency and predictable behavior:
- When asked to wait for vsync, it waits until next vblank, it can't be canceled. If vblank is missed, even by 0.1ms, it waits for next one: frame is lost and sound vs frame timing gets out of sync, which takes time to get back in sync, see below:
- Vsync wait may return immediately or it may block. This depends on display driver and driver configuration. This again causes sound vs frame timing issues, you can't reliably know if vsync wait call returned because new frame started or it was only buffered.. (This causes kind of "rubber-band" effect in timing)
- When it waits for vblank, it busy waits. (This is so stupid)

New vsync method:
- vblank wait can be canceled. If vblank is missed, wait gets canceled and either frame can be shown immediately (some tearing) or skipped (same frame is shown twice, current emulated frame is never shown). No out of sound sync problems, "real" lost frames can't happen unless vblank is missed by about 1/3 of total frame time. (~6ms)
- it is predictable. Reported beam position/vblank active status is current position, not some possible buffered position.

New vsync wait method is simple polling every 1ms (very simplified, uses half of frame time, not 1/3 etc.., pseudo-code):

Query beam pos and vblank status.
if (vblank OR (old_vpos > max_vpos / 2 AND new_vpos < max_vpos / 2)) then vblank detected
sleep(1ms) (1ms is smallest sleep period that can work reliably on Windows)

It looks so simple but was not that simple in practice..

100-101% is normal in fastest possible modes due to non-exact calculation.

[Toni Wilen]

Originally Posted by Ian

The one time I put everything there to help you and it's something simple that you would've got from the description

I probably would have asked for logs anyway, it was needed to confirm what worked correctly, not what didn't work this time

[Toni Wilen]

http://www.winuae.net/files/b/winuae.zip should fix RTG non-fastest cpu mode and fix divide by zero crashes introduced in b6.

[Ian]

Appears to work now, thanks Toni.

[msayed1977]

Please do something for me, Toni.
The emulator still crashes after starting it (even with the latest release).
I have previously attached my configuration file and the dump file.
Please do something for me.
Thanks.

[Toni Wilen]

Originally Posted by msayed1977

Please do something for me, Toni.
The emulator still crashes after starting it (even with the latest release).
I have previously attached my configuration file and the dump file.
Please do something for me.
Thanks.

Check my replies again and post correct dump file.

[msayed1977]

Right. Here is Beta 7 dump file.

[Toni Wilen]

Originally Posted by msayed1977

Right. Here is Beta 7 dump file.

Dump is fine now but I can't find out why it does what it does..

When does it crash? Does it crash if you boot normal WB1.3 disk too?
Does it crash if you switch to windowed mode?
Does it crash if you select "null filter" first?

[msayed1977]

Originally Posted by Toni Wilen

Dump is fine now but I can't find out why it does what it does..

When does it crash? Does it crash if you boot normal WB1.3 disk too?
Does it crash if you switch to windowed mode?
Does it crash if you select "null filter" first?

It crashes before doing anything.
I do not use any filters.(filter is "none").
I have previously attached my config files.

[Toni Wilen]

Originally Posted by msayed1977

It crashes before doing anything.
I do not use any filters.(filter is "none").
I have previously attached my config files.

Yes, I noticed your config file but it works fine here.

Answers still needed:
Does it crash if you switch to windowed mode first?
Does it crash if you select "null filter" first?