English Amiga Board


Go Back   English Amiga Board > Support > support.WinUAE

 
 
Thread Tools
Old 24 June 2012, 19:45   #81
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by Dr.Venom View Post
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?
Toni Wilen is offline  
Old 24 June 2012, 20:09   #82
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 400
Quote:
Originally Posted by Toni Wilen View Post
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"
Dr.Venom is offline  
Old 25 June 2012, 12:51   #83
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by bernd roesch View Post
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)
Toni Wilen is offline  
Old 26 June 2012, 21:35   #84
MrX_Cuci
Registered User
 
Join Date: May 2006
Location: The Netherlands
Age: 39
Posts: 186
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
MrX_Cuci is offline  
Old 26 June 2012, 22:00   #85
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by MrX_Cuci View Post
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
Toni Wilen is offline  
Old 26 June 2012, 22:12   #86
MrX_Cuci
Registered User
 
Join Date: May 2006
Location: The Netherlands
Age: 39
Posts: 186
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) ()
Attached Files
File Type: txt winuaebootlog.txt (12.0 KB, 183 views)
File Type: txt winuaelog.txt (9.4 KB, 170 views)
File Type: dmp winuae_241_20120626_195844.dmp (52.8 KB, 160 views)

Last edited by MrX_Cuci; 26 June 2012 at 22:59.
MrX_Cuci is offline  
Old 27 June 2012, 10:01   #87
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by MrX_Cuci View Post
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.
Toni Wilen is offline  
Old 09 July 2012, 01:30   #88
kfasheldon
Registered User
 
Join Date: Oct 2006
Location: Ottawa, Canada
Posts: 32
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
kfasheldon is offline  
Old 09 July 2012, 11:11   #89
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by kfasheldon View Post
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 is offline  
Old 10 July 2012, 13:48   #90
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
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.
Toni Wilen is offline  
Old 12 July 2012, 14:35   #91
mark_k
Registered User
 
Join Date: Aug 2004
Location:
Posts: 2,966
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:
Code:
RawInput enumeration..
RAWINPUT: found 0 devices
Windowsmouse initialization..
Catweasel joymouse initialization..
The corresponding part of the 2.4.1 log:
Code:
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.

Last edited by mark_k; 12 July 2012 at 15:38.
mark_k is offline  
Old 12 July 2012, 16:55   #92
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by mark_k View Post
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..
Toni Wilen is offline  
Old 14 July 2012, 17:07   #93
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 400
Quote:
Originally Posted by Toni Wilen View Post
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 is offline  
Old 14 July 2012, 19:53   #94
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 400
Disable SetMaximumFrameLatency(1) in certain situation

Quote:
Originally Posted by Toni Wilen View Post
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.
Quote:
Originally Posted by Dr.Venom View Post
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)..
Dr.Venom is offline  
Old 15 July 2012, 13:15   #95
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by Dr.Venom View Post
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?

Last edited by Toni Wilen; 15 July 2012 at 14:46.
Toni Wilen is offline  
Old 15 July 2012, 15:36   #96
Dr.Venom
Registered User
 
Join Date: Jul 2008
Location: Netherlands
Posts: 400
Quote:
Originally Posted by Toni Wilen View Post
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!)

Quote:
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..

Quote:
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..)
Dr.Venom is offline  
Old 19 July 2012, 01:00   #97
kfasheldon
Registered User
 
Join Date: Oct 2006
Location: Ottawa, Canada
Posts: 32
F12 broken

Quote:
Originally Posted by Toni Wilen View Post
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
kfasheldon is offline  
Old 19 July 2012, 12:02   #98
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
Quote:
Originally Posted by kfasheldon View Post
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 is offline  
Old 20 July 2012, 18:19   #99
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
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 is offline  
Old 22 July 2012, 18:59   #100
Toni Wilen
WinUAE developer
 
Join Date: Aug 2001
Location: Hämeenlinna/Finland
Age: 43
Posts: 22,105
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.
Toni Wilen is offline  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
WinUAE 2.5.1 beta series Toni Wilen support.WinUAE 69 22 December 2012 11:22
WinUAE 2.3.3 beta series Toni Wilen support.WinUAE 124 17 September 2011 16:48
WinUAE 2.3.2 beta series Toni Wilen support.WinUAE 79 31 May 2011 20:39
WinUAE 2.3.0 beta series (was 2.2.1) Toni Wilen support.WinUAE 229 22 September 2010 20:20

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 08:40.


Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2018, vBulletin Solutions Inc.
Page generated in 0.11444 seconds with 14 queries