WinUAE 2.5.0 Beta series (Was 2.4.2)

[Toni Wilen]

2.4.2 beta series.

Nothing special planned, at least not yet..

Quick rules:

Allowed posts in this thread:

- bug reports but make sure bug is NOT in previous offical version. (Old bug -> separate thread)
- comments and suggestion about new features in betas or changed feature in beta. (missing feature or old feature which has not been changed in latest beta series -> separate thread)

Everything else will be deleted, no questions asked. (includes offtopic posts, discussion about pros and cons of public beta testing etc..)

Misc notes:

- "not working" is not a bug report -> instadelete
- always include name of the program. "Everything" or "most games" fail is not a bug report!
- always use quickstart settings. Non-QS setting reports will be ignored unless there is reason why quickstart isn't good idea but still test using quickstart just to confirm! (unless it needs some HD highend config)
- always check logs (both winuaebootlog.txt and winuaelog.txt, don't forget to enable logging in misc-panel) for possible error or warning messages.
- remember to include PC specs + Windows version (if asked)
- graphics error -> include screenshot.
- disk based program -> include CRC32 (mouse over disk history arrow down button will show CRC32) of the image(s) (or SPS ID or full tosec name if from latest set). Plain name of the game is NOT generally enough! (usually there are different cracks, trainers etc..)

As usual, betas may destroy your PC and your sanity

This thread is for general discussion (bad/good/stupid idea/whatever, no trolling or flaming) about public beta testing.

Beta test related PMs or emails will be generally ignored.

[Toni Wilen]

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

Beta 1:

- Autovsync 50/60Hz also accepts 100/120Hz modes if available, supports also refresh rates +-1 from nominal.
- CD32: CD command receive DMA emulation correctly emulated, TOC read hack removed.
- CD32: Repeat each CD TOC packet 3 times (same as real CD TOC format) (Universe title screen CDA)
- CD32: CD audio stopped if multiple play requests were sent very quickly (Universe in-game CDA)
- GUI RTG monitor selection implemented.
- Low latency vsync + fastest possible CPU auto adjustment updates.
- Legacy vsync automatic adjustment implemented, hopefully improves stability. (Remember that legacy vsync is only compatible with approximate/ce CPU modes)
- FPS led background flashes yellow if frame was missed in vsync modes.
- Detect display driver forced vsync, switch to double buffered mode if low latency no buffer mode.
- 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.
- Added auto scale integer scaling method, uses autoscale display size instead of max overscan.
- Integer scale mode filter horizontal and vertical zoom sliders value is now added to native screen size before calculating integer scaling value. (Negative values reduce size of screen = scale to higher multiplier earlier)
- Integer scaling supports non-power of 2 integer upscaling ratios now, downscaling still only supports 1/2, 1/4 and so on to prevent scaling artifacts or blurriness.
- Warp mode now works properly in all vsync modes.
- Most filter modes (autoscale etc..) now fill "invisible" borders with black, for example this removes ugly extra border(s) in autoscale fullscreen or full-window mode when using non-4:3 displays. (In other words anything outside of 4:3 sized window are now blanked in non-4:3 screen/window sizes)
- Low latency vsync displayed blank screen if emulation was restarted using GUI Restart button.
- JIT GUI cache size box was broken.
- Do not return error code if uaehf.device read or write io command has null data pointer and length is also zero.
- Added more Windows error codes to directory filesystem to AmigaDOS error conversion table.

[Mequa]

In response to PMs re: vsync, here's the logs using beta 1 with fastest possible no buffered Vsync + JIT, plus -vsynclog2 command line parameter. This seems to work fine then has occasional tearing and a few missed frames.

This mode without JIT doesn't seem to have any issues this time, JIT using percentage throttling doesn't seem to make much difference to Vsync in this version on my setup.

[Toni Wilen]

Originally Posted by Mequa

In response to PMs re: vsync, here's the logs using beta 1 with fastest possible no buffered Vsync + JIT, plus -vsynclog2 command line parameter. This seems to work fine then has occasional tearing and a few missed frames.

This mode without JIT doesn't seem to have any issues this time, JIT using percentage throttling doesn't seem to make much difference to Vsync in this version on my setup.

Thanks. I am not going to do any changes until I have more reports. It is always possible it is worse in other systems.. (Of course it works fine here but it does not really mean much..)

[bernd roesch]

I dont know what else values should come, when i start winuae with -vsynclog2 and use fastest possible, P96

I get this values. do you get better values ?.they differ 0.2% from real value.(60 hz should be, 59.8251 is

VSync calibrated: 59.987746Hz/1.0=59.987746Hz. MinV=1 MaxV=1079 Un
%
NTSC mode V=59.8251Hz H=15674.1749Hz (227x262+1) IDX=-1 (<?>)
P96FREQ: 262*59.8251 = 15674.1749 / 60.0 = 261
winuae_inactive(0)
winuae_active(0)
D3D9Ex: Present() 88760872 S=1 F=0876 C=0872 (2162) ()

[Toni Wilen]

Originally Posted by bernd roesch

I dont know what else values should come, when i start winuae with -vsynclog2 and use fastest possible, P96

I get this values. do you get better values ?.they differ 0.2% from real value.(60 hz should be, 59.8251 is

It is correct. "NTSC/PAL mode" value is calculated rate from current custom chipset refresh rate parameters. (NTSC/PAL is only state of Agnus PAL/NTSC mode, it does not necessarily mean rate is NTSC or PAL compatible)

Note that NTSC actually is not exactly 60.00Hz on Amiga (Neither is official NTSC rate which is 59.94Hz). Amiga PAL also isn't exactly 50.00Hz.

For example PAL non-laced can have 2 rates (long field = 313 scanlines, short field = 312, depending on state of LOF bit), interlace alternates 313/312/313 which means there can be 3 different refresh rates that are all "PAL".

59.987746Hz is detected real hardware rate for vsync purposes. (Which probably also isn't 100% exactly 60Hz)

[bernd roesch]

Here stand how NTSC work.

My values are 0.3% diffrent. I have H=15674.1749 Hz but spec for NTSC say 15.734 kHz.

http://en.wikipedia.org/wiki/NTSC

NTSC (National Television System Committee) specs are:

Transmission Band UHF/VHF
Lines/Field 525/60
Horizontal Frequency 15.734 kHz
Vertical Frequency 60 Hz
Color Subcarrier Frequency 3.579545 MHz
Video Bandwidth 4.2 MHz
Sound Carrier Frequency 4.5 MHz

on PAL there is a odd and a even frame 1 frame is 312 lines next frame is 313 lines. so line length toggle each frame by 1 to reach 625 lines .On ntsc its same i guess because 525 is not dividiable thru 2.

[Dr.Venom]

Originally Posted by bernd roesch

Here stand how NTSC work.

I don't think you have to explain to Toni how PAL or NTSC works

http://en.wikipedia.org/wiki/NTSC

If you (would have) read the part from your quoted article under the header "color encoding", you'll understand that the NTSC rate for television is 59.94hz. Tables summarising these rates often round the NTSC rate to "60hz" for simplicity.

To make things more difficult for the layman, modern PC's and monitors have a specific PC "60hz" mode, which is PC specific and shouldn't be confused with NTSC. It's this PC "60hz" mode that you are running on your PC which WinUAE correctly detects. So you don't have a "deviation", but you're seeing the real refresh rate of your PC monitor screenmode.

If you're in doubt about that, just download the little Frequency Test tool here: http://www.mediafire.com/?lycrjcm55j37n. This tool will take a minute or so to make the refresh rate reading. Most probably you'll notice that WinUAE's reading is very close.

[Toni Wilen]

I forgot to mention that "PAL/NTSC mode xx.yy blahblah" log line frequency values are mostly informal only.

Values may not be always correct in some situations, calculating correct value in advance isn't that simple, biggest problem being interlace because it is impossible to be sure if current field is interlaced without also checking following field (single field interlace does not exist) which currently means "external" vertical frequency does not correctly change when interlace switches on/off. (~0.16% difference or so, 2*312 vs 625 scanlines or 2 * 313 vs 625 scanlines)

Interlace bit may be modified anytime. Also actually generating interlaced frames does not always match state of interlace bit.

Amiga programs see correct timing but non-vsync mode "real" world timing is still the exact same 49.xx/50.xxHz (VSync of course can't ever change because there is only single 50Hz PC rate)

Confusing, isn't it? Emulated hardware timing is always correct but what you actually see may not be exactly same! Think it as a some kind of time warp between your monitor and emulated universe

(I'll probably move this thread to another thread soon)

[Dr.Venom]

Originally Posted by Toni Wilen

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

Unfortunately I'm encountering an issue with the interlace detection, resulting in the log continuously showing "07-866 [1417 000x000]: Interlaced frame type mismatch 1<>0". The thing is that it seems to be completely random whether the frame detection works or not. After a lot of testing I can't find a way to reproduce a situation in whether it will surely work or not work. It seems to remain random.

Running the same config with the same tests in 2.4.0 always works correctly.

I've attached both config and the logs. For both settings I'm doing the same things: starting the demo "Hardwired" from workbench, quit back to workbench/tinylauncher, start Agony, quit back to workbench, start Agony again. In 2.4.0 this works, in 2.4.2b1 and 2.4.1 this shows the type mismatch loop, seemingly occuring randomly. Meaning that I can start e.g. hardwired or agony from workbench and the detection works, but if I then quit back to workbench and start the exact same demo or game again from workbench it will show the continuous loop of mismatches.

Hopefully the logs provide some clue as to what is happening..

On another note, when running only tinylauncher from workbench (a small tool to launch WHDload stuff easily) the cpu usage seems much higher with this A1200/AGA/CE config for 2.4.1 and 2.4.2b1 compared to 2.4.0. According to the onscreen leds it uses between 60-70% cpu (averaging at about 60% and spiking regurlarly to 70%) on 2.4.1 and 2.4.2b1. That's on a Core I7-920 clocked at 4.2Ghz. On 2.4.0 using the same setting uses between 40%-60%, averaging at about 50%.

[Toni Wilen]

Originally Posted by Dr.Venom

Hopefully the logs provide some clue as to what is happening..

I think it simply means it fails to recover if frames mismatch at least once. Nothing happens if fields match when switching to interlace.

Unfortunately I am not sure when I can test real interlaced modes again. (http://eab.abime.net/showpost.php?p=810833&postcount=11 unless that one supports real interlace. I don't want to mix red and green drivers..)

On another note, when running only tinylauncher from workbench (a small tool to launch WHDload stuff easily) the cpu usage seems much higher with this A1200/AGA/CE config for 2.4.1 and 2.4.2b1 compared to 2.4.0. According to the onscreen leds it uses between 60-70% cpu (averaging at about 60% and spiking regurlarly to 70%) on 2.4.1 and 2.4.2b1. That's on a Core I7-920 clocked at 4.2Ghz. On 2.4.0 using the same setting uses between 40%-60%, averaging at about 50%.

I wouldn't care much about CPU% because method to calculate changes all the time and some waits may have been replaced with busy waits (no buffer = busy waits are usually better. Minimum wait is 1ms, which is very long time)

[Dr.Venom]

Originally Posted by Toni Wilen

I think it simply means it fails to recover if frames mismatch at least once. Nothing happens if fields match when switching to interlace.

Unfortunately I am not sure when I can test real interlaced modes again. (http://eab.abime.net/showpost.php?p=810833&postcount=11 unless that one supports real interlace. I don't want to mix red and green drivers..)

Ah you've taken the green pill . That's a very nice card. Wouldn't know if it supports interlace. It should if you can connect through HDMI (http://www.hdmi.org/learningcenter/glossary.aspx) as that supports interlace (1080i). I tried to replicate it with my ATI through HDMI and I can set my desktop to 1080i interlace mode, by selecting 25hz or 30hz in the windows screen resolution panel.

But if I try to make WinUAE switch between 1080p and 1080i to simulate my CRT config by changing the displaydata lines to:

displaydata=25,t=lace,pal,lace,gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_linemode=double,gfx_refreshrate=25
displaydata=50,t=lof,pal,nlace,gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_linemode=none,gfx_refreshrate=50

then it either returns a black screen after the screenswitch to interlace in D3D, or an error with DirectDraw. But maybe after taking a green pill, this will work?

Possibly as a backup plan, if the above doesn't work (and assuming you also won't be having access to real interlace anytime soon again). Would it be possible to have the interlace code from 2.4.0 brought in behind a commandline switch? As that 2.4.0 code was tuned to work very well with a real CRT..

I wouldn't care much about CPU% because method to calculate changes all the time and some waits may have been replaced with busy waits (no buffer = busy waits are usually better. Minimum wait is 1ms, which is very long time)

Ok, that's understable. I thought I'd mention it, just in case.

[Toni Wilen]

Originally Posted by Dr.Venom

Ah you've taken the green pill . That's a very nice card. Wouldn't know if it supports interlace. It should if you can connect through HDMI (http://www.hdmi.org/learningcenter/glossary.aspx) as that supports interlace (1080i). I tried to replicate it with my ATI through HDMI and I can set my desktop to 1080i interlace mode, by selecting 25hz or 30hz in the windows screen resolution panel.

Right, 1080i does work, even via DVI.

And now I finally found the problem that caused blank screen in D3D mode if mode is interlaced. D3D refuses to show anything if mode is interlaced but ScanLineOrdering = D3DSCANLINEORDERING_PROGRESSIVE. (I thought it was ATI issue but obviously it could not be anymore..) Still not sure why it only causes blank screen, no error codes or anything.

Next beta will also support resolutions that have both progressive and interlace refresh rates. (like 1920x1080)

Still debugging interlace sync problem..

Possibly as a backup plan, if the above doesn't work (and assuming you also won't be having access to real interlace anytime soon again). Would it be possible to have the interlace code from 2.4.0 brought in behind a commandline switch? As that 2.4.0 code was tuned to work very well with a real CRT..

There is no "interlace code". It is part of the vsync stuff that has changed.

[Toni Wilen]

Does http://www.winuae.net/files/b/winuae.zip fix interlace sync problem?

At least it appears to work in 1080i and 576i Direct3D modes.

[Dr.Venom]

Originally Posted by Toni Wilen

Right, 1080i does work, even via DVI.

And now I finally found the problem that caused blank screen in D3D mode if mode is interlaced. D3D refuses to show anything if mode is interlaced but ScanLineOrdering = D3DSCANLINEORDERING_PROGRESSIVE. (I thought it was ATI issue but obviously it could not be anymore..) Still not sure why it only causes blank screen, no error codes or anything.

Next beta will also support resolutions that have both progressive and interlace refresh rates. (like 1920x1080)

That's perfect.

Originally Posted by Toni Wilen

Does http://www.winuae.net/files/b/winuae.zip fix interlace sync problem?

At least it appears to work in 1080i and 576i Direct3D modes.

It does not fix the problems, it sort of randomly works / works not. Logs attached. I tested it with DirectDraw, D3D still gives me a black screen on switch to interlace, switching out of interlace returns non-black/visible screen again.

Edit: tested on my CRT, will try the LED in a moment.

Edit 2: LED 1080 p/i switching gives blackscreen in D3D. Log added.

Edit 3: LED 1080p/i with DD gives the "screenmode does not exist error" (and simply returns the progressive screenmode after that).

56-037 [933 000x000]: set_ddraw: trying 1920x1080, bits=32, refreshrate=25
56-043 [933 000x000]: IDirectDraw7_SetDisplayMode: 80004001 S=1 F=0000 C=4001 (16385) (The function called is not supported at this time)
56-284 [933 000x000]: set_ddraw: failed, trying without forced refresh rate

[bernd roesch]

>If you're in doubt about that, just download the little Frequency Test tool here: >http://www.mediafire.com/?lycrjcm55j37n. This tool will take a minute or so to make the >refresh rate reading. Most probably you'll notice that WinUAE's reading is very close.

intresting tool, but i dont understand the last three values(See screenshot). Should this divide by 2 give the real line frequency ?
For vertical it show 59.999... winuae show me (now test)

VSync calibrated: 60.000003Hz/1.0=60.000003Hz. MinV=1 MaxV=1079 Unit
%
NTSC mode V=59.8251Hz H=15674.1749Hz (227x262+1) IDX=-1 (<?>)
P96FREQ: 262*59.8251 = 15674.1749 / 60.0 = 261
winuae_inactive(0)

the 59.8251 HZ and 15674 hz is a little diffrent. But if that doesnt matter for good timing, i can be silent about that. ;-)
But i thought to get vsyn work well and smooth amiga emu need fit the real PC frequency and not the amiga frequency of real hardware. this is of course that programs need run 0.3% faster to match PC vsync.

[Toni Wilen]

Originally Posted by bernd roesch

But i thought to get vsyn work well and smooth amiga emu need fit the real PC frequency and not the amiga frequency of real hardware. this is of course that programs need run 0.3% faster.

Detected rate does not need to be exactly right (which is impossible without long test), it only needs to be close enough (I'd say +-1% or so is still fine without causing problems)

This value is used to set sound and other internal timing values, vsync is still 100% locked to real hardware sync.

EDIT:

Should this divide by 2 give the real line frequency ?

No, it always reports frame rate, not field rate (x/1 if progressive, x/2 if interlaced)

/1 in the log means rate is used 1:1. /2 would be used if PC rate is 100Hz/120Hz. (=it is shown twice / Amiga field)

[Toni Wilen]

Originally Posted by Dr.Venom

It does not fix the problems, it sort of randomly works / works not.

What about now?

D3D still gives me a black screen on switch to interlace, switching out of interlace returns non-black/visible screen again.

Unfortunately I can't duplicate this anymore. What if you temporarily remove your displaydata config entries?

Edit 3: LED 1080p/i with DD gives the "screenmode does not exist error" (and simply returns the progressive screenmode after that).

I assume this also didn't work previously?

btw, I have noticed interesting difference: some drivers/cards report minimum scan line as line 1, some 40+. It does not seem to have anything to do with used display or connection (I had min line of 40+ with ATI but now it is always 1)

[bernd roesch]

When i boot my system it set always(i do several tests) on first time to 60 hz (NTSC mode V=60.0000Hz). this is more close to real value.later it change then to 59.8251 hz. see log

clipboard initialized
P96FREQ: 312*49.9201 = 15575.0799 / 49.9 = 312
SetSwitch() - Picasso96 1920x1080x32 (1920x1080x32)
winuae_inactive(0)
winuae_active(0)
D3D9Ex: 00000056 ALPHA DYNAMIC
D3D9Ex: PS=3.0 VS=3.0 1920*1080*0 VS=-3 B=1WS 32-bit 0
'E:\amiga\plugins\filtershaders\direct3d\_winuae.fx' mismatched version (2 != 3)

D3D9Ex: pixelshader filter 'E:\amiga\plugins\filtershaders\direct3d\_winuae.fx'
enabled
Buffer size (1920*1080) RTG
D3D9Ex: 1920*1080 working texture allocated, bits per pixel 32
D3D9Ex: 1920*1080 texture allocated, bits per pixel 32
VSync remembered: 60.000003Hz/1.0=60.000003Hz. MinV=1 MaxV=1079 Units=45459 87.0
%
PAL mode V=49.9201Hz H=15575.0799Hz (227x312+1) IDX=-1 (<?>)
BEAMCON0 0020 -> 0000 PC=1fffd2ca
NTSC mode V=60.0000Hz H=15720.0000Hz (227x262+1) IDX=-1 (<?>)
P96FREQ: 262*60.0000 = 15720.0000 / 60.0 = 261
NTSC mode V=59.8251Hz H=15674.1749Hz (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)
winuae_active(0)
winuae_inactive(0)

EDIT: I forget to say, when i use low latency vsync sound crackle happen in hd-rec and without vsync it work better.

[Dr.Venom]

Originally Posted by Toni Wilen

What about now?
...
Unfortunately I can't duplicate this anymore. What if you temporarily remove your displaydata config entries?

Without the displaydata config lines and starting winuae in an interlaced mode made the black screen problem disappear with D3D. Saving that config, I noticed the line "gfx_interlace=true". Adding back the displaydata config lines with the addition of this line now makes the lace screen appear both on my CRT and on my LED, both with D3D!

So displaydata lines for CRT:
displaydata=25,t=lace,pal,lace,gfx_width_fullscreen=742,gfx_height_fullscreen=574,gfx_linemode=double,gfx_refreshrate=25,gfx_interlace=true
displaydata=50,t=lof,pal,nlace,gfx_width_fullscreen=742,gfx_height_fullscreen=287,gfx_linemode=none,gfx_refreshrate=50,gfx_interlace=false

And for the LED:
displaydata=25,t=lace,pal,lace,gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_linemode=double,gfx_refreshrate=25,gfx_interlace=true
displaydata=50,t=lof,pal,nlace,gfx_width_fullscreen=1920,gfx_height_fullscreen=1080,gfx_linemode=double,gfx_refreshrate=50,gfx_interlace=false

I assume this also didn't work previously?

Indeed, that didn't work previously.

BUT, the randomness in the "Interlaced frame type mismatch 0<>1" is still there.

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

btw, I have noticed interesting difference: some drivers/cards report minimum scan line as line 1, some 40+. It does not seem to have anything to do with used display or connection (I had min line of 40+ with ATI but now it is always 1)

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

[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..