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