WinUAE 2.5.0 Beta series (Was 2.4.2)

[Toni Wilen]

Originally Posted by Dr.Venom

New better testcase: Run a plain vanilla A500 cycle exact config with the game "Hollywood Poker Pro". After loading and clicking away the title screen it wants to load from disk 2 and starts to flash a "Insert Disk 2". While doing this the game switches continually between a non-lace (when the blinking "Insert..." appears) and a lace screen. Here you'll notice how random the interlaced frame type mismatch is. See attached config and logs. This might be a good case which you can replicate..

This is very good test case

That's interesting indeed. Does it affect the current vsync code?

It can cause issues (probably not visible) if time between 0 and 1 is longer than 1 to 2. (=there is "hidden" vertical blank period and 0 to 40-something jump would be actually more correct)

Same problem if 0 to 40-something jump is shorter than for example 100 to 140.

VSync code estimates previous real vsync position (this is used to calculate when next vsync is supposed to happen) by getting current scanline position (must be 1 or larger) and substracting <current scanline> * <time units in one field> / <total scanlines> from current time value.

[Dr.Venom]

Originally Posted by Toni Wilen

This is very good test case

That's good

It can cause issues (probably not visible) if time between 0 and 1 is longer than 1 to 2. (=there is "hidden" vertical blank period and 0 to 40-something jump would be actually more correct)

Same problem if 0 to 40-something jump is shorter than for example 100 to 140.

I guess such differences shouldn't occur normally. From my understanding pixeltime is determined by the pixelclock rate of the videocard, which is a constant for each screenmode. So both pixels and whole scanlines (even the "scanlines" in the blanking areas) should always take the same time. But that's the theory..

VSync code estimates previous real vsync position (this is used to calculate when next vsync is supposed to happen) by getting current scanline position (must be 1 or larger) and substracting <current scanline> * <time units in one field> / <total scanlines> from current time value.

OK. I can imagine you would get estimates that are a bit off when you can't rely on the timing of the scanlines anymore. (Hopefully that's not the case.)

[Toni Wilen]

Originally Posted by Dr.Venom

OK. I can imagine you would get estimates that are a bit off when you can't rely on the timing of the scanlines anymore. (Hopefully that's not the case.)

I timed how long it takes from vblank to line 1. It takes much longer than any other normal line (about ~25x). I guess it was not properly documented long time ago and someone thought it means first visible line and someone else that it means second "real" line.

This will be compensated in next beta. Also value is logged (Adj=xx)

btw, interlace sync won't be fixed in next beta.

[Toni Wilen]

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

Beta 2:

- Missing harddrive in harddrive dialog if any device returned "too short STORAGE_DEVICE_DESCRIPTOR only x bytes". (2.4.0)
- D3D crashed if Vista or newer and D3D9Ex couldn't be used (shaders didn't load for reason for example) (2.3.something)
- Vsync dynamic adjustment algoritm updated.
- Added vsync debugging command line options:
- -vsync_min_delay <val>: val is value from 1 to 90, minimum guaranteed extra time left for display rendering. Automatic dynamic adjustment system can still use higher values if needed.
- -vsync_forced_delay <val>: val is forced extra time, dynamic adjustment is disabled. <val> is percentage of total frame time, the bigger the value, the less chance for tearing and slower CPU emulation performance (if fastest possible mode).
Above Parameters work in low latency no buffer mode and in all legacy vsync modes.
- -vsynclog shows frame counts (total, missed, errors, time waited for frame relative to total frame, average of previous value, current frame time difference) Low latency only parameter.
- -vsynclog2 starts logging current adjustment parameters. Mostly undocumented values except last 4: current adjustment value, time/scanline, total frame time, adjustment percentage value.
Note that time unit is internal PC time counter (Rate can be seen in winuaebootlog.txt)
- Added -rtg_blitter <val> command line option (0 = disable native RTG blitter acceleration code)
- Show more correct vertical and horizontal frequency in display mode change log line.
- Added -bsdlog command line parameter, enables full bsdsocket emulation logging. (This was previously compile-time option)
- Support PC screen resolutions that have both progressive and interlaced modes.
- PC interlaced modes work in D3D mode, fixes blank screen.
- Added 50i/60i switching support to autovsync.
- Added timing compensation to low latency vsync for some drivers (nvidia only?) that don't count any lines inside vblank period. (MinV=1 in the log)
- IOCTL 32-bit overflow fix, CDFS DVD read error when accessing data outside of first 2G.
- Built-in CD image mounter 32-bit image size restrictions removed.

[Dr.Venom]

Originally Posted by Toni Wilen

I timed how long it takes from vblank to line 1. It takes much longer than any other normal line (about ~25x). I guess it was not properly documented long time ago and someone thought it means first visible line and someone else that it means second "real" line.

I'm not sure if I fully understand the "from vblank to line 1". Do you mean from end of vblank to line 1 or from start of vblank to line 1?

Normally the vblank takes much longer than 1 scanline, including front and back porch signal it would take about 25-26 lines for a normal PAL signal. This seems like close to the ~25x longer you mention. So I guess what you're actually measuring is the time from start of field blanking to the first visible line? See this page halfway down http://martin.hinner.info/vga/pal.html. The letter "j" in the Field Synchronization of PAL System represents the Field-blanking interval, and takes about 25 lines. From what I understand these synchronization blanking times are valid for LED monitors also, because of compatibility reasons. But maybe we're talking about two completely different things here?

Page 39 (png_039) of the Agnus specification sheet shows a comparable picture with regards to the blanking time btw (they're still a bit different though..). It's taking about 26 lines for the whole field blanking.

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 2:

Not sure if this was an explicit update or improvement, but this beta improves the sound stability in Wasapi-ex mode even further for me (quite significantly even). I like it .

[Toni Wilen]

Originally Posted by Dr.Venom

I'm not sure if I fully understand the "from vblank to line 1". Do you mean from end of vblank to line 1 or from start of vblank to line 1?

Start of vblank to line 1.

Note that PAL/NTSC (and all(?) old computers that have PAL/NTSC video out) count those "invisible lines" during vblank which makes first visible line 20+, not 1.

I guess vblank period length does not make much sense with digital outputs anymore which probably explains the difference.

[Dr.Venom]

Originally Posted by Toni Wilen

Start of vblank to line 1.

OK, that makes sense.

Note that PAL/NTSC (and all(?) old computers that have PAL/NTSC video out) count those "invisible lines" during vblank which makes first visible line 20+, not 1.

I guess vblank period length does not make much sense with digital outputs anymore which probably explains the difference.

I guess so too. Good to find out about any of these differences though..

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 2:

- -vsynclog shows frame counts (total, missed, errors, time waited for frame relative to total frame, average of previous value, current frame time difference) Low latency only parameter.

Could you elaborate a bit on what "time waited for frame relative to total frame" means? For example if this value hovers around 90%, what does it mean?

[Mequa]

Originally Posted by Toni Wilen

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

Beta 2:

- Vsync dynamic adjustment algoritm updated.
....
- Added timing compensation to low latency vsync for some drivers (nvidia only?) that don't count any lines inside vblank period. (MinV=1 in the log)

The behaviour seems to change on my system with every new release. Now with fastest possible no-buffer vsync it runs smoothly with no tearing for most of the time, except every 5-10 seconds or so there is a "jerk" or judder (not sure if actual missed frame or just tearing)...

Any suggestions of specific options to test for this new build? (I'm mostly interested in JIT-enabled fastest possible no-buffer vsync... last stable one on my system is 2.4.1 beta 14, not release 2.4.1.)

[Dr.Venom]

Originally Posted by Mequa

The behaviour seems to change on my system with every new release. Now with fastest possible no-buffer vsync it runs smoothly with no tearing for most of the time, except every 5-10 seconds or so there is a "jerk" or judder (not sure if actual missed frame or just tearing)...

Are you running Windows Vista or 7 and running WinUAE in a window? The symptom you describe might be an issue where WinUAE conflicts with the Windows Desktop compositor (Aero), which has its own vsync.

You could try disabling the desktop composition for WinUAE: http://www.sevenforums.com/tutorials...e-program.html

It will also do away with an extra buffering layer, so input latency will improve when you're running in windowed mode.

[Toni Wilen]

Originally Posted by Dr.Venom

Could you elaborate a bit on what "time waited for frame relative to total frame" means? For example if this value hovers around 90%, what does it mean?

It is basically idle time. 90% = 90% of frame time was polling for next vblank, 10% of frame time was used for hardware emulation.

Originally Posted by Mequa

The behaviour seems to change on my system with every new release. Now with fastest possible no-buffer vsync it runs smoothly with no tearing for most of the time, except every 5-10 seconds or so there is a "jerk" or judder (not sure if actual missed frame or just tearing)...

Any suggestions of specific options to test for this new build? (I'm mostly interested in JIT-enabled fastest possible no-buffer vsync... last stable one on my system is 2.4.1 beta 14, not release 2.4.1.)

I don't know anymore.. No one else still haven't said anything and it has always worked fine on all my 3 test systems..

-vsynclog will show if it is missed frame (You would need second display to see the log properly..). -vsynclog2 log may also help.

EDIT: So wildly changing results may point to some power saving feature that gets confused. (Like nvidia on my work laptop with "adaptive powersomething" enabled. It is not always CPU or OS level power saving = OS power saving options have no effect!)

[Dr.Venom]

Originally Posted by Toni Wilen

It is basically idle time. 90% = 90% of frame time was polling for next vblank, 10% of frame time was used for hardware emulation.

OK, great that the hardware emulation is taking only that small a fraction. The 90% idle time seems quite consistent for me when running in A500 cycle exact, low latency vsync mode. It only occasionaly dips to 80%-85%. Does that also mean that the "-extraframewait" option should be working quite well, or does the new code work in a different way? I tried with a setting of 10 milliseconds (50% of frametime to be on the safe side), but it somehow bogs down the emulation right from the start.

[Toni Wilen]

Originally Posted by Dr.Venom

OK, great that the hardware emulation is taking only that small a fraction. The 90% idle time seems quite consistent for me when running in A500 cycle exact, low latency vsync mode. It only occasionaly dips to 80%-85%. Does that also mean that the "-extraframewait" option should be working quite well, or does the new code work in a different way? I tried with a setting of 10 milliseconds (50% of frametime to be on the safe side), but it somehow bogs down the emulation right from the start.

Try some demo or games that actually do something nice with copper if you want higher cpu usage

-extraframewait is not compatible with feature that subdivides frame to multiple emulation chunks (currently 3). First chunk emulates first 1/3th of scanlines, then wait, next emulate following 1/3 of scanlines and so on. This makes sound more stable (sound buffer can be smaller than 1 frame without guaranteed underflow)

I think it is possible to adjust -extraframewait so that extra value is substracted from total wait, "pushing" start of frame emulation forward and also shortening the wait between chunks. (instead of pushing whole frame to next vblank period)

[Dr.Venom]

Originally Posted by Toni Wilen

EDIT: So wildly changing results may point to some power saving feature that gets confused. (Like nvidia on my work laptop with "adaptive powersomething" enabled. It is not always CPU or OS level power saving = OS power saving options have no effect!)

Ugh, these gfx card power saving features can be a real pain. I ran into this when I got unexplainable frame rate interruptions with the PCSX2 emulator. That was on my I7-920 system with Radeon 6870. It sort of drove me crazy at first, not being able to trace the cause. I finally traced it back to the ATI Powerplay feature on the GFX card, which reduces the coreclock rate seemingly random in the midst of running the Playstation 2 emulation. And stupidly ATI/AMD don't have a preference setting on Desktop systems for turning it off/on.

For ATI owners the solution is to create a custom profile in which the "idle" (power saving) settings for ATI Powerplay are set to the normal coreclock target values. This profile (and thus the Powerplay feature) can then be activated/de-activated by the user. For people with ATI/AMD cards who suspect this might be causing trouble, if you look for "disable ATI Powerplay" on google you might find a few guides. One of them is http://forums.guru3d.com/showthread.php?t=334513 , which explains the basics to create such a profile.

[Dr.Venom]

Originally Posted by Toni Wilen

Try some demo or games that actually do something nice with copper if you want higher cpu usage

I'll try a few to see what it does

-extraframewait is not compatible with feature that subdivides frame to multiple emulation chunks (currently 3). First chunk emulates first 1/3th of scanlines, then wait, next emulate following 1/3 of scanlines and so on. This makes sound more stable (sound buffer can be smaller than 1 frame without guaranteed underflow)

OK, that explains it. Sound is definately more stable than before, and being able to have a buffer shorter than 1 frame is also quite cool so that shouldn't be lost..

I think it is possible to adjust -extraframewait so that extra value is substracted from total wait, "pushing" start of frame emulation forward and also shortening the wait between chunks. (instead of pushing whole frame to next vblank period)

That sounds like a great idea. I definately hope that could work, being able to shorten input latency to the max while keeping the benefits of the more stable sound buffer.

[bernd roesch]

with b2 i get now output in green the framerate 60 on P96 screen. with a pal screen it is not green(only when i use not vsync it is green too). happen if i use vsync or not on P96. always green. whats wrong ?. Do you need any log ?

I notice no diffrence in timing to older versions

EDIT: This are values i get with -vsynclog

VSync remembered: 60.021029Hz/1.0=60.021029Hz. MinV=1 MaxV=1079 Adj=1856 Units=4
5443 87.0%
PAL mode V=60.0195Hz H=15625.0881Hz (227x312+1) IDX=-1 (<?>)
BEAMCON0 0020 -> 0000 PC=1fffd1e6
NTSC mode V=59.8859Hz H=15590.7473Hz (227x262+1) IDX=-1 (<?>)
P96FREQ: 262*59.8859 = 15690.1141 / 60.0 = 261
NTSC mode V=59.8251Hz H=15590.7473Hz (227x262+1) IDX=-1 (<?>)
P96FREQ: 262*59.8251 = 15674.1749 / 60.0 = 261
POS (0 0 1920 1080) - (0 0 1920 1080)[1920,1080] (0 0)
winuae_inactive(0) 8 E: 0 99% ( 99%) 1590
winuae_active(0) 8 E: 0 99% ( 99%) 977
D3D9Ex: Present() 88760872 S=1 F=0876 C=0872 (2162) ()
winuae_inactive(0)289 E: 0 99% ( 99%) 2120
winuae_active(0) 3289 E: 0 99% ( 99%) 6556
D3D9Ex: Present() 88760872 S=1 F=0876 C=0872 (2162) ()
winuae_inactive(0)397 E: 0 99% ( 99%) 1829
F: 1187 M: 3401 E: 0 99% ( 99%) -17914

[Toni Wilen]

Originally Posted by bernd roesch

with b2 i get now output in green the framerate 60 on P96 screen. with a pal screen it is not green(only when i use not vsync it is green too).

It is a bug, if you mean FPS "led" having yellow background.

[Toni Wilen]

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

Beta 3:

- FPS led was always yellow in most non low latency vsync modes.
- Custom input event toggle didn't work (3rd and 4th slots), (2.4.1)
- Custom input event non-toggle mode with qualifiers didn't work correctly.
- Allow D3D RTG hardware sprite if non-power of 2 textures are supported, do not require shader support.
- Do not override currently selected CD image when loading statefile if new CD path does not exist.
- Do not report CD not present state if restoring CD32 statefile that was created with inserted CD. It would usually cause immediate reboot to CD32 title screen and most CD32 shovelware ports won't care about the CD after game has been loaded. This has been broken previously many times..
- Any active breakpoint stopped all interrupts in some situations if 68020 cycle-exact mode.
- "ALT-TAB or middle mouse button untraps mouse - F12 opens settings" window title was missing.
- Uncapture mouse when entering debugger.
- Fixed blank screen in directdraw + no filter mode. (b1)
- Do not move directories or empty files to Windows recycle bin (if recycle bin option enabled).

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 3:

Just to provide some feedback. This Beta 3 is running very well for me:

- A500 cycle-exact + D3D low latency vsync + wasapi-ex (soundbufffer 1): excellent . Smooth video and sound, stable buffer.
- A1200 cycle-exact (CPU 2x) + D3D low latency vsync + wasapi-ex (soundbuffer 1): excellent. It runs at about 70% CPU utilisation with this mode. Smooth video and sound, stable buffer.
- A1200 fastest-possible + D3D low latency vsync + wasapi-ex (soundbuffer 1): very good. Runs at pretty consistent 100% CPU utilisation, smooth video and sound, stable buffer. There's only one thing in that the fastest possible mode in one of the earlier betas seemed more compatible with some AGA demos, while it still provided the needed CPU boost for these demos. Throttling the CPU speed to any level doesn't seem to make a difference for compatibility with this beta and these specific demos, so this maybe has to do with the current implementation of FP mode?

Originally Posted by Toni Wilen

btw, interlace sync won't be fixed in next beta.

This one I'm still looking forward to. Hopefully you can fix it in one of the coming betas..