WinUAE 2.5.0 Beta series (Was 2.4.2)

[Toni Wilen]

Originally Posted by Dr.Venom

Great, fixed black screen with winuae.zip is confirmed.

Great, back to interlace mismatch issue: Does it still happen in all modes or only in non-fastest modes?

[Dr.Venom]

Originally Posted by Toni Wilen

Great, back to interlace mismatch issue: Does it still happen in all modes or only in non-fastest modes?

It still happens in all modes..

EDIT: tested with default A500CE, Approximate, Fastest Possible, each with the Hollywood Poker Pro "test"

[Toni Wilen]

Originally Posted by bernd roesch

When i stay longer on windows side and go back to winuae the clock run faster to reach the correct time.

Perhaps resume from GUI or pause state should simply call timer.device/TR_SETSYSTIME to fix big clock differences immediately (of course only if syncronize clock is enabled)

[MrX_Cuci]

Don't know if this is the right place to post this, but everytime I set the refresh rate to 50hz (or any other besides 60hz) onder host / display I get an error and WinUAE reverts back to directdraw mode. Seems if I force the HD Radeon driver to 50hz there is no problem using it in direct3D mode. Any work around for this? My display can handle 50hz and 60hz

[Toni Wilen]

Originally Posted by MrX_Cuci

Don't know if this is the right place to post this, but everytime I set the refresh rate to 50hz (or any other besides 60hz) onder host / display I get an error and WinUAE reverts back to directdraw mode. Seems if I force the HD Radeon driver to 50hz there is no problem using it in direct3D mode. Any work around for this? My display can handle 50hz and 60hz

Lets see..

- most likely nothing to do with 2.4.2 betas
- error message not included
- logs not included

[MrX_Cuci]

Ste the Radeon driver settings to default and seems to work now. I have a dmp file though from the crash. Any use for that?

EDIT: error is in the log though
02-659 [0 000x000]: CreateDevice failed, 8876086C S=1 F=0876 C=086C (2156) ()

[Toni Wilen]

Originally Posted by MrX_Cuci

Ste the Radeon driver settings to default and seems to work now. I have a dmp file though from the crash. Any use for that?

EDIT: error is in the log though
02-659 [0 000x000]: CreateDevice failed, 8876086C S=1 F=0876 C=086C (2156) ()

Dump and logs from 2.4.1 in 2.4.2 thread?

Seriously, can you duplicate the crash using latest 2.4.2 beta? Thats the important part.

[kfasheldon]

Hi Toni,

Most confused, Installed last full release and its working fine, just downloaded latest beta to install in a folder, runs but F12 does not bring up menu?

So I have tried copying the folder from Programs(x86) onto desktop , run the latest full release then from the folder on desktop and F12 will not work?

Any ideas, oh if I copy the beta to the installed folder in programs(x86) F12 wont work either ? Confused

[Toni Wilen]

Originally Posted by kfasheldon

Hi Toni,

Most confused, Installed last full release and its working fine, just downloaded latest beta to install in a folder, runs but F12 does not bring up menu?

So I have tried copying the folder from Programs(x86) onto desktop , run the latest full release then from the folder on desktop and F12 will not work?

Any ideas, oh if I copy the beta to the installed folder in programs(x86) F12 wont work either ? Confused

Do you mean F12 does not work even if you don't load any configurations (including configurations/default.uae. DO NOT delete this, keep it safe for debugging purposes it this file causes the problem)?

Which beta introduced the problem?

[Toni Wilen]

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

Beta 6:

- PC raw MFM decoding improved (uaeunp, Amiga/ST/PC multiformat PC images didn't decode properly)
- Interlace flag wasn't set if resolution had "i" flag but refresh rate didn't, caused blank screen in D3D modes.
- Set system time to host time (timer.device/TR_SETSYSTIME) when exiting GUI or unpausing if syncronize clock option is enabled. Only works if at least one directory filesystem is in use. (Shares directory filesystem process to minimize resource usage)
- Interlaced host resolution field matching with emulated interlace rewritten, now simply waits extra field if fields don't match. Can cause small sound glitches if small buffer but this is also much more reliable than old method. (Need tweaking)
- Small non-fastest CPU mode low latency vsync tweaks.
- Ignore CPU writes to DSKDAT. (Useless "DSKDAT: FIFO overflow!" log messages caused by some programs that poke DSKDAT).
- Added -nodirectinput command line parameter that completely disables directinput device enumeration.
- Gayle PCMCIA CF IDE emulation improvements, PCMCIA CF config #2 also supported (PC primary IDE IO addresses)
- GUI position is also saved in fullscreen mode, separate from windowed mode GUI coordinates.
- Some chipset mode on the fly configuration changes also reset RTG internal variables, causing blank screen when returning back to RTG mode. (Very old bug, "SetSwitch() - Picasso96 0x0x0" in log)
- Fullscreen RTG mode refresh rate uses chipset mode refresh rate or rate directly set in Expansions panel. Automatically selects lower available refresh rate if selected rate is unsupported.
- Added option to enable/disable RTG vblank interrupt emulation. Previously it was automatically enabled if Refresh rate option wasn't set to disabled. Moved to separate GUI option because of above new feature and because some games don't like RTG board generated interrupts.
- Direct3D mode RTG OSD only updated when any part of RTG bitmap changed.
- Blank unused displays(s) (opens full screen topmost black window(s)) option added to misc panel.
- Only save minimal CPU context (registers and PC) during native/m68k code switching. Previously it saved lots of unneeded data, including data that can be changed outside of CPU emulator. May also increase performance in some situations. Finally explanation and fix for mysterious copper state corruption.
- CD image mounter: MDS image CD audio tracks didn't play if subchannel data was not included, MDS image data tracks that also included subchannel data returned wrong data.
- Host MMU write protect ROM regions in JIT direct mode because JIT only checks destination address type when generating x86 code for the first time. Badly crashing programs can corrupt loaded ROM image causing repeating red/black screen reset loop. (Another mysterious previously reported problem solved)
- Restructured UAE boot ROM variable locations, ROM part write protected.
- Doubleclicking Input panel Input Source column resets clicked line back to default. (Currently keyboards only)
- Added uae-configuration harddrive attribute modification support:
-- Syntax: uaehfX_Z where X = unit number, Z = attribute name. (for example: "uaehf0_bootpri 10")
-- Attribute names: devicename, volumename, root, bootpri, read-only, filesys, controller.
-- Syntax is write-only. Use plain uaehfX to check current values.
-- Reset required to activate modified settings.

[mark_k]

Were there any changes to keyboard-related code in 2.4.2 beta 6?

I tested beta 6 under Wine 1.5.5, and the Amiga keyboard doesn't work any more. It was fine in b5 and earlier (with the same WinUAE config). I can still press F12 to bring up the settings window, it just seems that no key presses are seen by the emulated Amiga.

[Remember the old "reappearing settings window" bug in Wine? With beta 6 that no longer happens. I'm assuming that's related to the emulated Amiga not seeing key presses, so the Wine bug will probably show up again if/when this issue is fixed.]

I couldn't see any keyboard-related info in the winuae -log output, but I can attach that here if needed.

Edit: I got boot logs from both 2.4.1 and 2.4.2b6. Part of the 2.4.2b6 log:

RawInput enumeration..
RAWINPUT: found 0 devices
Windowsmouse initialization..
Catweasel joymouse initialization..

The corresponding part of the 2.4.1 log:

RawInput enumeration..
RAWINPUT: found 0 devices
DirectInput enumeration.. Keyboards..
I={6F1D2B61-D5A0-11CF-BFC7-444553540000} P={0AB8648A-7735-11D2-8C73-71DF54A96441}
'Wine Keyboard' 'Keyboard' 00000013 [Keyboard]
DirectInput enumeration.. Pointing devices..
I={6F1D2B60-D5A0-11CF-BFC7-444553540000} P={9E573ED8-7734-11D2-8D4A-23903FB6BDF7}
'Wine Mouse' 'Mouse' 00000212 [Mouse]
DirectInput enumeration.. Game controllers..
Windowsmouse initialization..
Catweasel joymouse initialization..

Could the problem be due to this change:
- Added -nodirectinput command line parameter that completely disables directinput device enumeration.

It seems that under Wine at least, beta 6 isn't enumerating DirectInput devices by default. And since rawinput doesn't work under Wine, there's no keyboard.

[Toni Wilen]

Originally Posted by mark_k

Were there any changes to keyboard-related code in 2.4.2 beta 6?

nodirectinput internal variable was accidentally set to true. Will be fixed soon..

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 1:

- Always call D3D SetMaximumFrameLatency(1) if vsync mode (any vsync) to reduce latency, previously was only called when low latency no buffer mode used. (SetMaximumFrameLatency only available on Vista and later) Usually display driver control panel can be also used to override this value.

Is this SetMaximumFrameLatency the same thing as "Flip Queue Size" on ATI/AMD and "Max Frames to Render Ahead" on NVidia?

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 1:

- Always call D3D SetMaximumFrameLatency(1) if vsync mode (any vsync) to reduce latency, previously was only called when low latency no buffer mode used. (SetMaximumFrameLatency only available on Vista and later) Usually display driver control panel can be also used to override this value.

Originally Posted by Dr.Venom

Is this SetMaximumFrameLatency the same thing as "Flip Queue Size" on ATI/AMD and "Max Frames to Render Ahead" on NVidia?

I'm answering my own question, but with a purpose. I looked this up on MSDN and it seems indeed the same as the "Flip Queue size" on AMD and "Max frames to render ahead" on NVidia.

The issue:
Although the D3D "SetMaximumFrameLatency()" function itself doesn't seem to allow a real setting of 0 frames rendered ahead (setting it to "0" will make it reset to "default"), there are certain utils that do enable a real setting of 0, i.e. really having zero frames rendered ahead. A setting of zero is ideal for emulation, as it will give the absolute lowest possible latency.

For ATI/AMD there's the RadeonPro tool (http://www.radeonpro.info/en-US/ ) with which a real setting of zero for Flip Queue Size is possible, and on NVidia this can be done through the NVidia Control Panel (http://www.tweakguides.com/NVFORCE_6.html ), although it's important to note that a real setting of zero for NVidia cards seems to be disabled in the newer drivers. With older drivers it was apparently possible (see: http://www.overclock.net/t/1263509/a...rames-0-option)

For WinUAE I always have the maximumframelatency / flipqueuesize set to 0 through the radeonpro utility, but the message in the Beta 1 release log triggered me to worry about the fact that WinUAE might infact override this real setting of "0" by setting SetMaximumFrameLatency(1). This is because the call by the RadeonPro utility might come before WinUAE calls its function, effectively overriding the zero latency with a one frame buffer, which would mean a 20ms latency loss :-/ ...

I guess I understand why WinUAE sets it to 1; basically because D3D9ex doesn't allow a -real- setting of "0", but has one prerendered frame as the minimum. (Calling "0" in D3D SetMaximumFrameLatency() is actually reserved for setting FrameLatency to driver "default"...). (No news for Toni I'm sure, but for others: http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx )

I'm really not sure why the D3D SetMaximumFramelatency() function call is limited to at least a value of 1. My best guess is that this is to keep compatibility with Windows Vista / 7 Aero vsynced window design (which always seems to use an extra buffer..)?

Toni, would it be possible to have the SetMaximumFrameLatency(1) not be called when the user has a real setting of "0" set?

I'm not sure how you would detect a real setting of "0", but possibly GetMaximumFrameLatency (http://msdn.microsoft.com/en-us/libr...=vs.85%29.aspx ) will report anything sensible when the real value is set to zero?

But if it can't be detected automatically, would it be possible to add a command line option to disable WinUAE calling the SetMaximumFrameLatency(1) option? If I'm right about this, then that would be very useful for ATI/AMD users that have FlipQueueSize set to zero (with RadeonPro utility), where WinuAE might currently override that value.. I'm not sure about NVidia, but possibly it's also useful for NVidia users who are running drivers below version 296.10 and also have set it to a real value of zero (but maybe the NForce setting overwrites the WinUAE call, in which case it would not be a problem)..

[Toni Wilen]

Originally Posted by Dr.Venom

I'm really not sure why the D3D SetMaximumFramelatency() function call is limited to at least a value of 1. My best guess is that this is to keep compatibility with Windows Vista / 7 Aero vsynced window design (which always seems to use an extra buffer..)?

Toni, would it be possible to have the SetMaximumFrameLatency(1) not be called when the user has a real setting of "0" set?

Shouldn't display control panel settings override application settings, including SetMaximumFramelatency() value?

Did you test if setting it to very high value using control panel utility overrides WinUAE's SetMaximumFramelatency(1)?

GetMaximumFrameLatency() is documented to return 1 or higher so I wouldn't trust it either..

EDIT:

I guess calling SetMaximumFramelatency(1) only if GetMaximumFrameLatency() returns value larger than 1 should work fine?

[Dr.Venom]

Originally Posted by Toni Wilen

Shouldn't display control panel settings override application settings, including SetMaximumFramelatency() value?

Hmm.. I'm not sure, but I guess not. Given that a value of "0" in SetMaximumFrameLatency() is reserved to set the frame latency at "Default", which I would guess means "Driver Default" (?), that's probably the only setting where the control panel setting will "override" the SetMaximumFrameLatency?

But I'm really not sure.. MSDN doesn't specify what is meant by "default". It says that it's typically at "3", but it doesn't say that's the default, which leaves open the option that it really is set to some default value, or that it is taking the "default value" that is set by the user in the control panel.. (I wish they would document this stuff somewhat better!)

Did you test if setting it to very high value using control panel utility overrides WinUAE's SetMaximumFramelatency(1)?

I just tested it with a value of "5" (the largest value RadeonPro allows), but this doesn't introduce additional lag. This seems to point that indeed SetMaximumFrameLatency(), for values other than "0", is overriding any config panel (RadeonPro) setting..

GetMaximumFrameLatency() is documented to return 1 or higher so I wouldn't trust it either..

EDIT:

I guess calling SetMaximumFramelatency(1) only if GetMaximumFrameLatency() returns value larger than 1 should work fine?

That would be a perfect solution

Just to be sure, maybe it's good to shortly test with a beta what value is returned by GetMaximumFrameLatency when the FlipQueueSize is set to a real zero render ahead buffer by any tool/config panel? Just to be sure it doesn't return any weird positive value (which would result in getting a false positive with the >1 check..)

[kfasheldon]

Originally Posted by Toni Wilen

Do you mean F12 does not work even if you don't load any configurations (including configurations/default.uae. DO NOT delete this, keep it safe for debugging purposes it this file causes the problem)?

Which beta introduced the problem?

Thanks for reply Toni, sorry it was not 100% report.

Problem fixed now, it would appear that Comodo Internet Security was the cause, odd it does not affect the Amiga Forever versions, nor does it effect latest install version from main site - only the zip only extracted into a directory, seems once you start emulation F12 is prevented from getting sent to the emulator and trapped somehow by Comodo ?. I have install AntiVir and all is well, just as a double check put back Comodo and F12 just does not work with Comodos default settings on Win 7 64bit.

Anyway - looks more the problem with the security software being paranoid rather than WinUAE, keep up great work, cheers Karl

[Toni Wilen]

Originally Posted by kfasheldon

Thanks for reply Toni, sorry it was not 100% report.

Problem fixed now, it would appear that Comodo Internet Security was the cause, odd it does not affect the Amiga Forever versions, nor does it effect latest install version from main site - only the zip only extracted into a directory, seems once you start emulation F12 is prevented from getting sent to the emulator and trapped somehow by Comodo ?. I have install AntiVir and all is well, just as a double check put back Comodo and F12 just does not work with Comodos default settings on Win 7 64bit.

Anyway - looks more the problem with the security software being paranoid rather than WinUAE, keep up great work, cheers Karl

Not the first time keyboard rawinput (combined with winpcap network support) has caused some security programs to block it. AFAIK both are commonly used by malware too..

[Toni Wilen]

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


Beta 7:

- Directory filesystem 64-bit seek (ACTION_CHANGE_FILE_POSITION64) broke in 240b27
- -nodirectinput mode was always enabled. (b6)
- -nodirectinput does not anymore disable mouse/keyboard directinput enumeration if rawinput fails to initialize.
- Syncronize clock enabled and loading new config crashed in some situations (b6)
- Blitter emulation didn't leave correct data in blitter's B data register after linedraw finished, fixes No Way demo by Academy that seems to use wrong minterm that requires correct static value in B data register.
- WASAPI exclusive software volume control support. It seems normal WASAPI volume control does nothing in exclusive mode.
- Added support for unimplemented integer instructions to 68k emulation code generators. Not yet in use. (This is easy part, unimplemented floating point support is very difficult because it requires special FPU stack frame)

**********************

- Experimental memory space rewrite. Now WinUAE reserves address space as much as possible (~1.6G if 64-bit OS, 512M if 32-bit, note that this is only reserved space, actual memory is not yet allocated). Allows more stable on the fly memory size changes. It is not guaranteed that this is safe to use and won't cause side-effects or other bad behavior or loss of performance, please test and report.

**********************

[Toni Wilen]

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

Beta 8:

- 68060 and CPU compatible checkbox ticked: generate unimplemented instruction exceptions instead of emulating instructions that real 68060 don't have. Integer instructions only, 040/060 FPU emulation still supports all 6888x instructions.
- Set FPU FPIAR register (No one shouldn't care, except unimplemented FPU exception handler which isn't supported)
- RTG state restore broke in previous update.
- Save RTG mode palette to statefile (Quite important missing information if dislay mode is 8-bit..)
- More memory space reservation updates.
- "Restart" GUI option improved, shouldn't cause strange errors if new config has 32-bit RAM enabled and old one didn't.
- Savestates with 32-bit RAM configured should now load without need to first load configuration that has same amount (or more) RAM configured.