WinUAE 2.5.0 Beta series (Was 2.4.2)

[Toni Wilen]

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

Beta 4:

- Custom input event autofire wasn't always canceled when shortcut included qualifier(s).
- Do not crash if 7zip unpacking fails because out of memory or process address space. (Big compressed CD images and 32-bit Windows)
- Log also RDB dostype in text format.
- Replaced misc panel checkboxes with scrolling checkbox list view. Now there is unlimited space for all kinds of on/off options that I previously refused to add because of lack of GUI space.
- Added disable notification icon option.
- Loading statefile using GUI now remembers statefile filename, allowing to save configuration files with statefile (running configuration file will automatically load the statefile). This required manual config file editing previously. Statefile path and checkbox that "forgets" stored path added to GUI.
- Ignore vendor specific USB usage pages (Do not list for example some Logitech USB mouse/keyboard receiver dongles)
- Z2 RTG + 68EC020 fixed, RTG requires memory mapping. (Memory mapping was originally JIT only and 68EC020 is not JIT compatible)

[Toni Wilen]

Originally Posted by Dr.Venom

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?

What does "seems to be more compatible" mean? I don't think this really means anything useful

Something like "version x did this when running that but following version y does does this when running same program using same settings" is much better (but note that fastest possible = nothing is guaranteed, especially compatibility)

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

I am still not sure how to do this without causing other side-effects. "Problem" is new dynamic adjustment that detects sync attempt (finish current frame asap and start following one without framewait to sync fields) as a problem (too fast or slow frame) and attempts to readjust causing sort of feedback loop..

[Dr.Venom]

Originally Posted by Toni Wilen

What does "seems to be more compatible" mean? I don't think this really means anything useful

Something like "version x did this when running that but following version y does does this when running same program using same settings" is much better (but note that fastest possible = nothing is guaranteed, especially compatibility)

You're right, I'll get a more specific example. (Need to retrace the specific versions/betas in which it worked previously first..)

I am still not sure how to do this without causing other side-effects. "Problem" is new dynamic adjustment that detects sync attempt (finish current frame asap and start following one without framewait to sync fields) as a problem (too fast or slow frame) and attempts to readjust causing sort of feedback loop..

OK. If there's anything I could test, just let me know. Hopefully you can come up with a way, as it's making the emulation on CRT that bit closer to the real thing..

[Dr.Venom]

Originally Posted by Toni Wilen

What does "seems to be more compatible" mean? I don't think this really means anything useful

Something like "version x did this when running that but following version y does does this when running same program using same settings" is much better (but note that fastest possible = nothing is guaranteed, especially compatibility)

OK, I've retraced one of the demo issues to be related to using low latency vsync or not when in fastest possible mode. Somehow there was a previous beta, where it did work with low latency vsync, but I can't retrace that anymore.

With Beta 4, the issue is quite apparent. When running the WHDLoad demo "Big Time Sensuality" by Axis (started from a plain vanilla 3.1 workbench) in fastest possible mode -and- low latency vsync, then after some seconds of running, the demo quits back to workbench with the message "WHDLoad has detected that a previous call to 'resload_Diskload' has been interrupted. The actual call to 'resload_FlushCache' can therefore not been processed."

If I run this demo with the exact same config, but only disable vsync, then it works without problems. Configs, logs and screenshot attached.

[Mequa]

As of beta 4 (perhaps some earlier betas too), almost all of the tearing issues on my hardware are gone. Only using HQ4X (software or D3D) has noticeable tearing, as well as some other D3D filters. (Does anyone else have any issues with D3D filters on this beta series?)

Software HQ3X is rock solid though, even at 1920x1080 (fullscreen and fullwindow) with fastest-possible JIT + no-buffer vsync. Windowed mode works well too (with Aero disabled).

[ancalimon]

I can't make WinUAE create winuaelog.txt by turning it on from the miscellaneous part of the gui.

[Toni Wilen]

Originally Posted by Dr.Venom

"WHDLoad has detected that a previous call to 'resload_Diskload' has been interrupted. The actual call to 'resload_FlushCache' can therefore not been processed."

Demo or slave timing bug.

Originally Posted by ancalimon

I can't make WinUAE create winuaelog.txt by turning it on from the miscellaneous part of the gui.

Check winuaebootlog.txt for path information.

[Dr.Venom]

Originally Posted by Toni Wilen

Demo or slave timing bug.

It might be, but I'm not fully sure yet.. I have some additional testresult. Running it with exact same config but instead of low latency vsync, use legacy vsync instead, the demo works.

So (with the config earlier attached, only changing between vsyncs):
- Fastest possible without vsync: works
- Fastest possible & legacy vsync: works
- Fastest possible & low latency vsync: doesn't work

It strikes me as a bit odd that that the first two work, and the third doesn't. If it's a timing issue than why is low latency vsync the only one suffering from it (even with having tried the various CPU throttle settings with it, which should also affect timing?)

Any idea?

[Toni Wilen]

Originally Posted by Dr.Venom

It might be, but I'm not fully sure yet..

Vsync can change how CPU time is "distributed" a lot and HD access runs in separate thread which can make HD access timing very different. (Error seems to have something to do with OS HD access)

Does it do the same when running from ram disk or hdf? (instead of directory)

[Dr.Venom]

Originally Posted by Toni Wilen

Vsync can change how CPU time is "distributed" a lot and HD access runs in separate thread which can make HD access timing very different. (Error seems to have something to do with OS HD access)

Does it do the same when running from ram disk or hdf? (instead of directory)

Yes it does the same when running from ram disk (in all tests the demo is run from hdf already)

I found something interesting additionally. Running the demo from floppy with the exact same fastest possible & low latency vsync config, the demo does work.

There is a small bug though when running from floppy. In the beginning of the demo it doesn't show the zooming routine with the "Axis - Anno Domini 1994" text, but it only shows the text when the zoom finishes. (Same happens with A1200 cycle exact config.) Interestingly the end of this "non-working" zooming routing on the floppy version is also the exact same spot where the whdload version crashes: whdload does properly show the zooming, but at the end when the text is fully zoomed it quits back with the reported error.

I think it's a safe bet to say that the whdload version has that zooming routine patched, possibly in a bit "hackerish" fashion, causing the demo to be very timing sensitive at that point? So I'm not sure if it explains it as truely being a whdload patch/timing issue (it could still coincide with e.g. a "load from disk" event), but it does seem to make it more probable..?

[ancalimon]

Originally Posted by Toni Wilen

Demo or slave timing bug.



Check winuaebootlog.txt for path information.

It worked after a reboot. I have no idea why.

[Dr.Venom]

Originally Posted by Toni Wilen

Demo or slave timing bug.

I've been testing some more and found that my earlier conclusion on the Axis demo compatibility in fastest possible and low latency vsync (see posts here and here) wasn't fully correct; the CPU Speed throttle does have influence. This would point to it plainly being a demo or slave timing issue, but hang on..

Using earlier attached A1200+fastestpossible+lowlatencyvsync config (see here), and varying CPU speed:

CPU Speed set to -90%,-80%,-70%: demo works
CPU Speed set to -60% or less: demo "crashes" with the earlier reported error.

So adding to the earlier reported results:

• Fastest possible without vsync: works
• Fastest possible & legacy vsync: works
• Fastest possible & low latency vsync
  • CPU Speed -90% to -70%: works
  • CPU Speed -60% to +0%: doesn't work

What still strikes me as a bit odd though is that the whdload demo in low latency seems only sensitive to "too high a speed". With that result one would expect the demo also to crash when running fastest possible without vsync at full CPU speed (+0%), but then it works.. This could be a pointer that there's still something in the fastest possible and low latency algorithm that's causing some instability/incompatability.

Maybe it can be of help, so I've gone back to the 2.4.1 beta series (again using the same config) and found that with 2.4.1 beta 1 to beta 6 this demo did work in fastest possible mode at full speed and low latency vsync. Since 2.4.1 beta 7 and onwards it doesn't work anymore. Hopefully this provides a clue as to whether this is indeed a pure slave timing issue, or whether there's an identifiable issue with the current fastest possible low latency implementation, that keeps it from having the same level of compatibility as fastest possible mode with no vsync / legacy vsync.

Originally Posted by Toni Wilen

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

Beta 7:

- DirectDraw full-window mode on non-primary monitor was blank.
- Adjusted (again) fastest possible CPU mode extra CPU time scheduling, trying to find balance between better timing syncronization and not causing unnecessary slowdowns on some systems..
- OCS Denise bug emulation update, PAL STREQU counts are 8 (short field) or 9 (long field) lines, not static 9 lines. (Probably no program cares)
- F11 in gameports/input test mode shows next page (if list is longer than visible area).
- Manual display positioning X coordinate offset fixed (Filter panel or gfx_center_horizontal_position) Origin should be hardware position 0 (same as sprites), not first possible visible position.
- Fastest possible low latency vsync should work better again (b2), plus some other adjustments done, CPU throttling supported.
- Autoresolution worked badly in some situations.
- Removed USB_DEVICE_ID_RETRO_ADAPTER from USB "quirks" list, apparently it is working correctly according to firmware sources. (Perhaps older version was wrong, not exactly sure why it was included in Linux HID quirks list)
- Save also selected monitor name (gfx_display_name) to config file because order of displays can change when removing or adding monitors or replacing display cards.

[Dr.Venom]

Originally Posted by Toni Wilen

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

Beta 4:

With regard to the interlace sync issue. I don't know why I didn't notice this before, but the interlace frame type matching works perfectly fine when using WinUAE in "fastest possible" mode. It's only when using either cycle-exact or approximate A500/A1200 that the interlace syncing issue with the looping "interlaced frame type mismatch 1<>0" pops up (also see earlier post). Any idea why it's working in fastest possible and not in cycle exact?

I've been experimenting a bit with the shaders and having a scaled image on my LED screen, and noticed that the "integer scaling" option in filters only scales in steps of 2, i.e. 2,4,6,8. As such it's missing the 3X scaling, and I was wondering if you could add these to the integer scaling options?

I'm asking because in my experience a 4x scaled image (or 2x with double line mode enabled), fills the whole 1080p height, but pixels look too pixelated/blocky. A 2x scaled image (or 1x with double line mode) looks closer to CRT, but the image on screen is too small (filling only half of the 1080p height). The sweetspot as such would be 3X scaling (or 1.5X with double line mode enabled), finding a good balance between filling enough screensize and pixels not becoming too blocky or pixelated. That way when applying a (modified) scanline/CRT filter makes it look closely to what a 14inch CRT is looking like. As such, hopefully it's possible to have the 3X and 1.5X scaling options added. (Or is there maybe something code-wise standing in the way it?)

Lastly, when experimenting a bit with the WinUAE.fx shader code I noticed that the built-in bi-lineair filtering option in WinUAE seems to get applied after the shader filter has done its job. I was wondering if this could be the other way around, so have the filter shader manipulating the source image -after- it has been bi-lineair filtered, or maybe have a flag in the .fx file where you can set whether the filtering is coming before or after the shader? Hopefully something is possible here..

[Toni Wilen]

Originally Posted by Dr.Venom

What still strikes me as a bit odd though is that the whdload demo in low latency seems only sensitive to "too high a speed". With that result one would expect the demo also to crash when running fastest possible without vsync at full CPU speed (+0%), but then it works.. This could be a pointer that there's still something in the fastest possible and low latency algorithm that's causing some instability/incompatability.

Anything is possible. It may be just single instruction in specific position that causes the difference.

Originally Posted by Dr.Venom

With regard to the interlace sync issue. I don't know why I didn't notice this before, but the interlace frame type matching works perfectly fine when using WinUAE in "fastest possible" mode. It's only when using either cycle-exact or approximate A500/A1200 that the interlace syncing issue with the looping "interlaced frame type mismatch 1<>0" pops up (also see earlier post). Any idea why it's working in fastest possible and not in cycle exact?

At least Big Time Sensuality whd in approximate mode seems to work fine in interlaced (only single mismatch line or none)

EDIT: winuae.zip updated, perhaps I "accidentally" fixed it

I've been experimenting a bit with the shaders and having a scaled image on my LED screen, and noticed that the "integer scaling" option in filters only scales in steps of 2, i.e. 2,4,6,8. As such it's missing the 3X scaling, and I was wondering if you could add these to the integer scaling options?

It was added in beta 1 and works fine here.

Lastly, when experimenting a bit with the WinUAE.fx shader code I noticed that the built-in bi-lineair filtering option in WinUAE seems to get applied after the shader filter has done its job.

It is basic D3D flag, it is always done after shaders automatically. Only way to do it earlier is to "emulate" it in shaders.

[Toni Wilen]

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

Beta 5:

- More custom input event fixes.
- Replaced custom event single line string dialog with larger multiline dialog, increased allowed custom event string length.
- Autoresolution didn't detect interlaced mode in some situations.
- Added "Internal events" input device category. Currently it only contains two events: "CPU reset" and "Keyboard reset". It can be used to customize what happens when emulated Amiga is reset. For example: set CPU mode back to fastest possible, eject or insert disks, quit emulator, etc..
- Added 68020 prefetch CPU core. Emulates instruction prefetch without cycle-exact. "More compatible" option enables this mode (Previously it did nothing in 68020 mode)
- A1200/CD32 Quickstart compatibility slider changed: cycle-exact/prefetch/fastest possible without JIT/JIT
- ASPI support removed.

[Dr.Venom]

Originally Posted by Toni Wilen

At least Big Time Sensuality whd in approximate mode seems to work fine in interlaced (only single mismatch line or none)

EDIT: winuae.zip updated, perhaps I "accidentally" fixed it

I still have issues with it here.. I'm getting a bit confused by it now as I've tested numerous different configurations on both LED and CRT to see what works and what not. I will focus only on A500 cycle exact below, otherwise it gets too confusing (in Holland we have a saying "Then you can't see the forest through the trees anymore", i.e. it gets confusing.. )

The bad news: it will not work in any configuration that uses LED 1080i as display output. It will always give the frame type mismatch.

The good news: there is a specific configuration with CRT 574i in which interlace -always- seems to work. See the attached A500 configs and logs.

The weird thing though is that:

1. A500.uae: this gives the frame type mismatch, always.

Changing only -one- setting in above config, setting the default screenmode to start in 742x574i instead of 742x287:
2. A500-lace-(default refresh).uae: interlace will -always- work without any frame type mismatch

Why does 2 work and 1 not? Does this still point to an issue with screenmode enumeration, or something?

To make it even more confusing, setting the refresh rate to 25hz (instead of "default") in config 2, will cause it to break again and always result in the frame type mismatch.

Unfortunately whatever I try to replicate this behaviour with LED 1080i doesn't work, there it will always give the frame type mismatch....

It was added in beta 1 and works fine here.

For me the 3x scaling only works when resolution setting is "Lores", it will not work when it is set at "Hires(normal)", then it will scale 1x,2x,4x, omitting the 3x scaling..

It is basic D3D flag, it is always done after shaders automatically. Only way to do it earlier is to "emulate" it in shaders.

OK, thanks for pointing that out..

[Toni Wilen]

Originally Posted by Dr.Venom

I still have issues with it here.. I'm getting a bit confused by it now as I've tested numerous different configurations on both LED and CRT to see what works and what not.

You should have included logs (EDIT: from so called "working" case) earlier because winuae does not attempt to autodetect interlace anymore, Windows must have interlace flag set for selected mode or mode is considered progressive. "i" in vsync calibration = interlaced = frame matching enabled.

EDIT: for some reason calibration adjustement value is lost after mode is "remembered" again. Checking.. (Nothing wrong, it does not matter if minv=1)

EDIT2: Do you mean it only "works" if you select screen mode that does not show "i" in calibration log message?

[Dr.Venom]

Originally Posted by Toni Wilen

You should have included logs (EDIT: from so called "working" case) earlier because winuae does not attempt to autodetect interlace anymore, Windows must have interlace flag set for selected mode or mode is considered progressive. "i" in vsync calibration = interlaced = frame matching enabled.

EDIT: for some reason calibration adjustement value is lost after mode is "remembered" again. Checking.. (Nothing wrong, it does not matter if minv=1)

EDIT2: Do you mean it only "works" if you select screen mode that does not show "i" in calibration log message?

Yes, it only "works" with the CRT 742x574 interlaced mode, which WinuAE classifies as 574i in the GUI and being able to display at 25hz, but it doesn't show the "i" in the log.

What makes it tricky is that this mode easily results in a black screen. Currently it only seems to work when the screenmode is triggered from displaydata (like in earlier attached configs and quote below).

1. Removing the "gfx_interlace=true" in the first line will result in a black screen, or
2. Setting the gfx_refreshrate=0 in the first line to gfx_refreshrate=25 results in a black screen

EDIT:
3. The default screenmode in WINUAE must also be set to 742x574 interlace in combination with the displaydata, otherwise the displaydata trigger will result in a black screen on switch to interlace

displaydata=25.000000,t=lace,pal,lace,gfx_width_fullscreen=742,gfx_height_fullscreen=574,gfx_linemode=double,gfx_refreshrate=0,gfx_interlace=true
displaydata=50.000000,t=lof,pal,nlace,gfx_width_fullscreen=742,gfx_height_fullscreen=287,gfx_linemode=none,gfx_refreshrate=50,gfx_interlace=false

[Toni Wilen]

Originally Posted by Dr.Venom

Yes, it only "works" with the CRT 742x574 interlaced mode, which WinuAE classifies as 574i in the GUI and being able to display at 25hz, but it doesn't show the "i" in the log.

Include both logs this time. (winuaebootlog and winuaelog)

What makes it tricky is that this mode easily results in a black screen.

Didn't we discuss this some time ago? D3D shows black screen if mode is interlaced but D3D is configured for progressive mode. gfx_interlace=false will clear the flag = black screen.

[Dr.Venom]

Originally Posted by Toni Wilen

Include both logs this time. (winuaebootlog and winuaelog)

See attached logs.

2. A500-lace-(default refresh).UAE --> interlace "WORKS"

1. Only changes default 742x574 interlace screenmode to 742x287 (displaydata untouched)--> mismatch
3. Only changes default 742x574 interlace "default refresh" to "25hz" (displaydata untouched) --> mismatch

Didn't we discuss this some time ago? D3D shows black screen if mode is interlaced but D3D is configured for progressive mode. gfx_interlace=false will clear the flag = black screen.

Ah yes, I remember. What confuses me is that when not using displaydata at all, and manually adding gfx_interlace=true to a plain config that has the 742x574 interlace mode as default, it still results in a black screen. This while triggering this displaymode from displaydata (as in previous post) does work.