WinUAE 2.4.0 beta series

[Toni Wilen]

Originally Posted by Dr.Venom

Unfortunately the switching between two monitors (native <-> RTG) through displaydata got broken somewhere between beta 8 (release 2011.12.27) and public beta 9. In beta 9 the switch doesn't occur. Both native and RTG stay displayed on the same monitor.

Hmm.. There was a stupid logic problem.. RTG driver only got modes from monitor which was current active monitor when driver started.

DirectDraw enumeration (which was originally used): "Primary Display" always listed both monitors' modes for some reason.
EnumDisplayDevices enumeration (new method): up to b8 also "raw modes" were listed in RTG (modes that may not be supported by monitor or something like that, in your case this included standard modes)
B9 disabled raw modes which meant you lost all standard modes from the list because your active monitor is the one that only list some small "strange" resolutions.

RTG needs to list all modes from all enabled monitors.

winuae.zip should restore original behavior.

[Dr.Venom]

Originally Posted by Toni Wilen

Hmm.. There was a stupid logic problem.. RTG driver only got modes from monitor which was current active monitor when driver started.

DirectDraw enumeration (which was originally used): "Primary Display" always listed both monitors' modes for some reason.
EnumDisplayDevices enumeration (new method): up to b8 also "raw modes" were listed in RTG (modes that may not be supported by monitor or something like that, in your case this included standard modes)
B9 disabled raw modes which meant you lost all standard modes from the list because your active monitor is the one that only list some small "strange" resolutions.

RTG needs to list all modes from all enabled monitors.

winuae.zip should restore original behavior.

Thanks, works perfect again

[Mequa]

I tried my AMOS-3D game "Operation Gigabyte" (from its adf using built-in AROS ROM), which achieves a frame rate of up to 60FPS in parts with Fastest Possible CPU+JIT+Immediate Blitter, without Vsync. When using the new Vsync (hoping to get smooth performance at last), the frame rate drops to around 12-16FPS on the same machine, barely faster than without JIT.

I was expecting some CPU performance drop with the new Vsync, but not quite this dramatic. Is CPU performance with Fastest Possible CPU+JIT+Vsync likely to improve as this build is developed, or is this the likely overhead we'll see using the new Vsync?

Does anyone else report such a dramatic hit for CPU-heavy software and games? If anyone wishes to test - how does benchmarking software such as AIBB report the drop on CPU speed with the above combination when enabling the new Vsync?

[Toni Wilen]

Originally Posted by Mequa

I tried my AMOS-3D game "Operation Gigabyte" (from its adf using built-in AROS ROM), which achieves a frame rate of up to 60FPS in parts with Fastest Possible CPU+JIT+Immediate Blitter, without Vsync. When using the new Vsync (hoping to get smooth performance at last), the frame rate drops to around 12-16FPS on the same machine, barely faster than without JIT.

I was expecting some CPU performance drop with the new Vsync, but not quite this dramatic. Is CPU performance with Fastest Possible CPU+JIT+Vsync likely to improve as this build is developed, or is this the likely overhead we'll see using the new Vsync?

Does anyone else report such a dramatic hit for CPU-heavy software and games? If anyone wishes to test - how does benchmarking software such as AIBB report the drop on CPU speed with the above combination when enabling the new Vsync?

This is quite close to "it is not working" type report.. Logs are also missing.
(Use of vsync with programs that are not synced to frame rate does not make much point anyway)

Step 1: Test a500 mode new vsync. Stop here if it isn't working. Use program that runs stable 50Hz to confirm it, not some slow 3d stuff.
Step 2: Run same program using fastest possible mode. WHDLoad game or demo is good test.
Step 3: Finally test something else

Ignore benchmark programs, they don't really show anything useful in these kinds of situations.

[Mequa]

This 3D program is sync'd to the frame rate ("Wait Vbl" in AMOS loop), and does reach a full 50FPS (PAL) / 60FPS (NTSC) in less busy parts with fastest possible JIT + immediate blitter.

I suppose the real question is whether we can realistically expect to get fast 68060-level performance with the new Vsync on (say) a 2GHz Core2Duo, when this new Vsync is working.

I don't have time to fully test it now, but I added a zipped .adf to the Zone (works with AROS ROM).

[Toni Wilen]

Originally Posted by Mequa

This 3D program is sync'd to the frame rate ("Wait Vbl" in AMOS loop), and does reach a full 50FPS (PAL) / 60FPS (NTSC) in less busy parts with fastest possible JIT + immediate blitter.

I suppose the real question is whether we can realistically expect to get fast 68060-level performance with the new Vsync on (say) a 2GHz Core2Duo, when this new Vsync is working.

I don't have time to fully test it now, but I added a zipped .adf to the Zone (works with AROS ROM).

Whole point is to test if it works on YOUR PC (Obviously it does not or config is bad because it shouldn't slow down emulator's FPS). It has nothing to do with the Amiga program.

[Toni Wilen]

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

Beta 10:

- RTG mode list should always list all monitors' supported resolutions.
- PAL filter display positioning is now same as other filters.
- Removed obsolete right control key hack, Amiga does not have right control key, it was only originally needed to handle keyboard layout B in old UAE versions.
- Cycle-exact mode and very heavy interrupt activity caused lost internal interrupt event in some very rare situations, bug introduced long time ago. (Guardian Dragon II / Kefrens random hang, probably others too)
- In non-vsync modes only triple buffering enables vsynced page flipping, other modes flip instantly for better performance (and possibly introduces tearing but it is better than bad performance)
- Log more complete RDB dump when mounting RDB hardfile or real harddrive using UAE controller.
- bsdsocket emulation tweaks. SocketBaseTagList() more compatible with AmiTCP (emulate weird behavior of breaking tag list processing if unknown tag detected, some programs actually don't even have a TAG_END..), get/setsockopt more compatible ("Unknown optlen (1)" log error messages) Convert SO_SNDTIMEO and SO_RCVTIMEO time values between milliseconds and struct timeval.
- HID input stuck button fixed if multiple buttons were kept pressed while releasing another button.
- HID input configuration loading didn't always match devices correctly

[Toni Wilen]

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

Beta 11:

- SocketBaseTagList() must not report unknown tag error unless tag is really unknown, not just unsupported. SBTC_LOGx tags are now "supported" because some programs sets them and they also do not want to get any errors.
- bsdsocket.library SBTC_IOERRNOSTRPTR, SBTC_S2ERRNOSTRPTR and SBTC_S2WERRNOSTRPTR implemented.
- bsdsocket.library SBTC_FDCALLBACK implemented. Should fix (SAS-C compiled only?) Unix ports that use both socket and plain file FDs.
- Multiple bsdsocket emulation thread safety fixes. Should finally fix all YAM hangs.
- Directory filesystem internal file size access update, previously Examine() and friends returned old file size if file size changed (either inside or outside of emulation) until file was closed. (fixes Subversion bad request 400 error)
- Built-in zip unarchiver utf-8 encoded file name support implemented
- Vertical centering and small enough display size: vertical positioning was really wrong.

[Toni Wilen]

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

Beta 12:

- Quick beta update: blitter cycle-exact mode was not cycle-exact in b10 and b11 release builds.

[Dr.Venom]

Originally Posted by Toni Wilen

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

Not sure about this, but is 'fastest possible' mode with vsync supposed to be working reliably by now, or is it still in progress? For me there's the issue that no matter what vsync or buffering I use, upon starting a whdload game or demo from RTG workbench the sound crackles for about 20 seconds.

Originally Posted by Toni Wilen

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

Beta 6:

New vsync should finally work in all modes.

- Low latency vsync keeps list of modes that have already been calibrated, switching back to remembered mode uses stored calibration value.

Are these remembered calibration values stored in a user accessible file somewhere, or are they only stored per session in memory?

[Toni Wilen]

Originally Posted by Dr.Venom

Not sure about this, but is 'fastest possible' mode with vsync supposed to be working reliably by now, or is it still in progress? For me there's the issue that no matter what vsync or buffering I use, upon starting a whdload game or demo from RTG workbench the sound crackles for about 20 seconds.

I wanted to do something else for few weeks. Vsync changes will still be done..

Are these remembered calibration values stored in a user accessible file somewhere, or are they only stored per session in memory?

Per session only. I don't want to cache too much because updated display drivers, use of display mode adjustment programs etc.. can change refresh rates.

[rsn8887]

Toni, shouldn't A1200 fastest possible always have 100% CPU meter? I just noticed that in beta 9,10 and 11, my CPU% is changing between 92-93%. In beta 8 it is 100% constant, like I would expect.

Config file and logs are attached...

[Dr.Venom]

Originally Posted by Toni Wilen

I wanted to do something else for few weeks. Vsync changes will still be done..

OK, then I can rest assured...

Per session only. I don't want to cache too much because updated display drivers, use of display mode adjustment programs etc.. can change refresh rates.

That's clear, thanks.

[Toni Wilen]

Originally Posted by rsn8887

Toni, shouldn't A1200 fastest possible always have 100% CPU meter? I just noticed that in beta 9,10 and 11, my CPU% is changing between 92-93%. In beta 8 it is 100% constant, like I would expect.

Config file and logs are attached...

Do you notice any other problems? New vsync system may have changed some things.. Does it show 100% if you disable sound? Does SND% show strange values?

[rsn8887]

Originally Posted by Toni Wilen

Do you notice any other problems? New vsync system may have changed some things.. Does it show 100% if you disable sound? Does SND% show strange values?

Still shows 93% even when I completely disable sound. Tried DirectDraw/Direct3D, and above normal/normal priority too but is always 93% or 94%. Haven't found anything else that's strange apart from CPU% indicator.

[Dr.Venom]

Originally Posted by rsn8887

Toni, shouldn't A1200 fastest possible always have 100% CPU meter? I just noticed that in beta 9,10 and 11, my CPU% is changing between 92-93%. In beta 8 it is 100% constant, like I would expect.

Config file and logs are attached...

Originally Posted by Toni Wilen

Do you notice any other problems? New vsync system may have changed some things.. Does it show 100% if you disable sound? Does SND% show strange values?

I can also confirm this behaviour. Beta 8 was the latest beta showing 100% constant CPU in A1200 fastest possible mode, while in betas 9 to 12 the CPU usage changes between 92%-98%. Disabling sound doesn't make a difference, SND% doens't show strange values.

[Toni Wilen]

Originally Posted by Dr.Venom

I can also confirm this behaviour. Beta 8 was the latest beta showing 100% constant CPU in A1200 fastest possible mode, while in betas 9 to 12 the CPU usage changes between 92%-98%. Disabling sound doesn't make a difference, SND% doens't show strange values.

It is confirmed normal, reporting was only changed, behavior is same. Previously this small wait was counted as "emulated cpu busy" which was wrong. (It may be possible to get rid of this wait and improve cpu speed slightly in vsync fastest possible modes. Later, much later..)

[Dr.Venom]

Originally Posted by Toni Wilen

It is confirmed normal, reporting was only changed, behavior is same. Previously this small wait was counted as "emulated cpu busy" which was wrong. (It may be possible to get rid of this wait and improve cpu speed slightly in vsync fastest possible modes. Later, much later..)

Thanks for verifying it. Good to know that it's normal/intended behaviour. And until it's much later, I guess fast is fast enough

[Toni Wilen]

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

Beta 13:

- bsdsocket emulation: use SOCK_DGRAM if requesting IPPROTO_UDP + SOCK_RAW. Raw sockets require admin privileges and have restrictions (introduced in XP SP 2 / Vista). This partially fixes Genesis traceroute, UDP packets are now transmitted (Wireshark detects it) but for some reason it is not possible to receive ICMP packets using winsock anymore (but ping that both sends and receives ICMP packets do work fine, so it seems you can only receive replies to your own packets)
- bsdsocket emulation WaitSelect() incorrectly cleared break mask signals, this caused programs like traceroute to not exit with CTRL+C.
- Swallow raw input mouse middle mouse button presses if middle mouse button is set to untrap mouse.
- WinUAE Windows dialogs (not GUI or file dialogs) may have been invisible in some situations in fullscreen D3D mode.
- Some on the fly config changes caused side-effects if new vsync mode was enabled, for example JIT on<>off or fastest possible<>approximate caused graphics corruption.
- Switching on the fly to/from fastest possible CPU to approximate or cycle-exact mode in low latency vsync didn't switch to correct internal vblank detection mode.
- It was possible to enable both JIT and cycle-exact using uae-configuration which froze the emulation until GUI was entered and exited (which fixed the bad configuration). Now this conflicting configuration is detected and JIT is automatically disabled.
- Built-in CDFS crashed if CD was unreadable (empty CD-R).
- Input panel custom event configuration changes didn't trigger until some other config entry changed or GUI was entered.

TODO: sound sync still needs work.

[Toni Wilen]

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

Beta 14:

- Input panel qualifier key/button support. I think this was requested many many years ago.
(I didn't originally plan to do this now but someone reminded me few days ago..)
* - Any key or button can be configured as a qualifier (like a shift or control key that modifies behavior of other keys)
* - Any Input Target can be configured to require qualifiers. Input Target only triggers if it's Input Source and all configured qualifiers are active at the same time.
* - If multiple slots are configured, only slot(s) that have matching qualifier will be triggered, for example if slot 1 has qualifier and slot 2 has none: Only slot 2 triggers if Input Source matches without qualifier active and only slot 1 if Input Source matches with active qualifier.
* - Same qualifer code (1-8) can be configured to more than one key/button.
* - Qualifier(s) set to any other types than keys or buttons is currently undefined.
* - End ("*" in GUI), Shift, Alt and Control keys are mapped to built-in qualifiers.
* - Most previously hardwired key mappings (END+F1 etc..) are now implemented using Input qualifier system
* -- Exceptions: F12 so that there is no way for users to accidentally disable GUI access. END+<number> and END+<numpad number> disk swapper and statefile shortcuts, I didn't want to add 30+ new mostly pointless input targets.. Disabled if END-key's qualifier flag is removed.
* - Qualifiers and custom events: slots 1 to 4 and 5 to 8 can have different qualifiers.

- Doubled number of input target slots (4 to 8)
- "Copy from"-button corrupted memory.
- Added keyboard default options to "Copy from"-button. Can select either Amiga or PC default mapping.
- TODO: restore only single input target to default.

- Less than 35Hz vsync display refresh rate: show only every other frame.
- Workaround for strange Windows feature or a bug. First call raw input RegisterRawInputDevices() to unregister HID devices and then immediately call to register them again: Windows randomly stops reporting HID events.
- Windows to Amiga clipboard sharing wrong string size if string contained cr/lf line endings.
- Low latency VSync screen mode switch fixes and updates.
- Native code execution (winlauch.alib etc..) is not anymore allowed by default. Option in misc panel.