WinUAE 2.5.0 Beta series (Was 2.4.2)

[Toni Wilen]

Originally Posted by Dr.Venom

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.

Which log does this?

[Dr.Venom]

Originally Posted by Toni Wilen

Which log does this?

None of them (they all contain displaydata).

Starting from the earlier "working" interlace config (A500-lace-(default refresh).uae), in attached config I've removed the displaydata, it has default screenmode 742x574 and manually added gfx_interlace=true parameter. This should show the problem I described, but... it doesn't do so anymore now. I'm quite certain I had the exact same test showing me a black screen earlier, hmm, anyway.. The screen normally opens. As should be expected given what you said earlier.

This config does however run into the problem with mismatching frame types. It does seem to do something differentlty though, in that it either is showing a row of the "0<>1" mismatch or a row of the "1<>0", but is not "mixing" them, as happens in the previous "non working" configs.

[Toni Wilen]

Originally Posted by Dr.Venom

This config does however run into the problem with mismatching frame types. It does seem to do something differentlty though, in that it either is showing a row of the "0<>1" mismatch or a row of the "1<>0", but is not "mixing" them, as happens in the previous "non working" configs.

I don't think this mode is interlaced because it does not switch between 0<>1 and 1<>0. Can you check if it is really interlaced using monitor's OSD or if you can notice the interlace scanline flickering?

[Dr.Venom]

Originally Posted by Toni Wilen

I don't think this mode is interlaced because it does not switch between 0<>1 and 1<>0. Can you check if it is really interlaced using monitor's OSD or if you can notice the interlace scanline flickering?

It is 100% interlaced. I can notice easily by the onscreen leds, as they are squashed to half in vertical size and the thin white lines around them flickering quite badly .

Do note that this test is running the lace switching test of Hollywood Poker Pro, where it asks for disk 2, continually switching between Amiga side LOF and LACE mode when the "Change Disk!" appears. (When "Change Disk!" appears screen is normally LOF, when it flips to black for a second, screen is normally lace).

I ran the test again and let it run for a longer while, see attached log. Further in the log it starts showing the "mixed" frame type mismatches again.

For completeness sake, loading from disk 1 happens until the following point in the log:

52-239 [936 000=000]:

After this point the only thing happening is the continuous blinking of the "Change Disk!", as described above. You'll notice that both monotonically 0<>1 and 1<>0 periods are followed by periods where they are getting mixed..

[Toni Wilen]

Originally Posted by Dr.Venom

It is 100% interlaced. I can notice easily by the onscreen leds, as they are squashed to half in vertical size and the thin white lines around them flickering quite badly .

It looks like D3D thinks it is progressive but driver sets it to interlaced. D3D probably ignores interlace when using default (0) refresh rate.

[Dr.Venom]

Originally Posted by Toni Wilen

It looks like D3D thinks it is progressive but driver sets it to interlaced. D3D probably ignores interlace when using default (0) refresh rate.

I just tested the same config with DirectDraw and that seems to give more robust results. When it starts switching modes (blinking "Change Disk", starting at about 42-680 [1576 065-109] in the log), the frame type matching is nicely alternating in the way of 0<>1, 1<>0.

It also seems to be more consistent in that each period of matching is of comparable lenght (same number of lines where it shows the alternating 1<>0), where my impression is that in the D3D log they are quite different, sometimes taking only a few mismatches, sometimes a lot. See attached log for DirectDraw results.

Does this mean that D3D isn't really reliable for using with real interlace screenmodes, and that for interlace in WinUAE the focus should be on using DirectDraw only?

[Toni Wilen]

Originally Posted by Dr.Venom

Does this mean that D3D isn't really reliable for using with real interlace screenmodes, and that for interlace in WinUAE the focus should be on using DirectDraw only?

I don't think so. It only means it is more difficult because D3D does more than DD internally.

Also don't use "default" refresh rate selection to prevent black screens

[SaphirJD]

So far, so nice.. Winuae gets better and better for watching amiga Demos

But with the latest few Betas i have experienced some heavy sound stuttering in combination with Filters like Supereagle, Super2xSaI or hq4x - have quite some powerful hardware here, i tried with Winuae Settings hires normal in combination with buffers off, Line Mode normal - Guess a recent computer should be able to handle that, but in combination with that settings also that stuffering appeared.

It even got worse if i was setting Superhires, Line Mode Double and the same already mentioned filters.

[Dr.Venom]

Originally Posted by Toni Wilen

I don't think so. It only means it is more difficult because D3D does more than DD internally.

OK.

Also don't use "default" refresh rate selection to prevent black screens

I guess I should report that kind of stuff right away

With regards to refresh rate selection. The earlier DirectDraw config when set to 25Hz instead of "default" shows the interlace screen properly. (With D3D it shows the black screen).

Is there anything else I could test that would help you out with finding what is causing the interlace issue? Would it be helpful if I retrace from which 2.4.1 beta (I suspect) the frame type matching stopped working?

Btw, did you have the chance to create a computer setup with a CRT monitor again, or is that not going to happen since you've taken the green pill..

[Toni Wilen]

Originally Posted by SaphirJD

So far, so nice.. Winuae gets better and better for watching amiga Demos

But with the latest few Betas i have experienced some heavy sound stuttering in combination with Filters like Supereagle, Super2xSaI or hq4x - have quite some powerful hardware here, i tried with Winuae Settings hires normal in combination with buffers off, Line Mode normal - Guess a recent computer should be able to handle that, but in combination with that settings also that stuffering appeared.

It even got worse if i was setting Superhires, Line Mode Double and the same already mentioned filters.

Nothing to do with this beta and there is nothing to fix, those software filters are not meant for high resolutions (>320). Use D3D shader filters.

[bernd roesch]

To save CPU power and lower cooler noise(the 10% CPU load with idle slider full right increase power need by 15 Watt and cooler is louder) i use synchronize clock now and i enable when inactive "pause emulation".

When i stay longer on windows side and go back to winuae the clock run faster to reach the correct time. But during this time no double click work. is it possible that the clock is increase faster, (maybe 10*) so the wait before a double click can do is shorter.

Or maybe when winuae is inactive the CPU idle full right do longer sleep phase, so CPU can sleep longer and get not so hot.

[Dr.Venom]

Originally Posted by Dr.Venom

Would it be helpful if I retrace from which 2.4.1 beta (I suspect) the frame type matching stopped working?

Couldn't resist to try to track it back to some previous beta. Tried the 2.4.1 betas back to the 2.4.0 betas and I'm getting unsure whether this specific Hollywood Poker Pro test, running on the previously discussed single interlace screen config (i.e. not using LOF/LACE displaydata) has worked properly before (tested with DirectDraw only). At least I can't get it to work with the current beta's or the previous ones (tested 17 different betas back to 2.4.0 beta 14). All result one way or the other in the continuous frame type mismatch messages.

So either this specific test hasn't worked before (if I recall correctly I only stumbled upon this test when we were in 2.4.2. betas already), and/or maybe there's a video driver issue at play here, which messes with the reliability of the interlace syncing. I've been installing new video drivers since the 2.4.0 series, so the possibility of unreliable video drivers is there.

Originally Posted by Toni Wilen

Nothing to do with this beta and there is nothing to fix, those software filters are not meant for high resolutions (>320). Use D3D shader filters.

You could possibly consider a mouseover "balloon" in the GUI with above message, as it seems to be one of the more frequent returning questions..

[Toni Wilen]

Originally Posted by Dr.Venom

Couldn't resist to try to track it back to some previous beta.

I already said sometime ago that it is rewritten, not much in common with old versions.

btw, you still haven't included configuration + logs that has black screen with D3D but works with older version..

You could possibly consider a mouseover "balloon" in the GUI with above message, as it seems to be one of the more frequent returning questions..

No one reads those

[Ian]

Beg to differ, if theres a new option I always mouse over unless it's completely obvious what it does.

[Mclane]

Originally Posted by Ian

Beg to differ, if theres a new option I always mouse over unless it's completely obvious what it does.

So its you who looks at them

We all wondered who it was

[Dr.Venom]

Originally Posted by Toni Wilen

I already said sometime ago that it is rewritten, not much in common with old versions.

I guess the most important point I was making is that the Hollywood Poker Pro test most probably has never worked before (which was opposite to my earlier impression). I gathered you might find that interesting to know, but anyway..

btw, you still haven't included configuration + logs that has black screen with D3D but works with older version..

I thought I had already answered that one (quote below taken from this post), but let me know if you meant something else..

Originally Posted by Dr.Venom

[...] This should show the problem I described, but... it doesn't do so anymore now. I'm quite certain I had the exact same test showing me a black screen earlier, hmm, anyway.. The screen normally opens. As should be expected given what you said earlier.

No one reads those

I wouldn't agree, I read them myself even . Seriously, and my guess is that less experienced users might appreciate the little titbits of info even more..

[Toni Wilen]

Originally Posted by Dr.Venom

I thought I had already answered that one (quote below taken from this post), but let me know if you meant something else..

"This should show the problem I described, but... it doesn't do so anymore now" so is there D3D black screen problem or not? This needs to be fixed first before interlace sync problems.

[Dr.Venom]

Originally Posted by Toni Wilen

"This should show the problem I described, but... it doesn't do so anymore now" so is there D3D black screen problem or not? This needs to be fixed first before interlace sync problems.

I need to be more clear.

There is a black screen problem when config defines D3D and screen 742x574i (25hz) ==> WinUAE does not open interlace, but shows black screen. F12 -> GUI is shown on non-lace black screen. (see attached Config 1 and logs)

Solution: MANUALLY add "gfx_interlace=true" to config file. ==> WinUAE nicely opens interlaced screen. (See attached Config 2 and logs).

To solve this problem WinUAE should by default save the "gfx_interlace=true" parameter for these type of (CRT) "i" modes.

[Toni Wilen]

Originally Posted by Dr.Venom

ITo solve this problem WinUAE should by default save the "gfx_interlace=true" parameter for these type of (CRT) "i" modes.

Now I noticed the difference, you have modes that have "i" after resolution but there is no "i" after refresh rate.

32: 742x480i, 16-bit (30)
33: 742x480i, 32-bit (30)
34: 742x574i, 16-bit (25)
35: 742x574i, 32-bit (25)

38: 800x600i, 16-bit (25)
39: 800x600i, 32-bit (25)

These don't set interlace flag correctly, will be fixed..

It seems enumerated refresh rates don't always "inherit" interlace status from "parent" resolution.

EDIT: should be fixed in today's winuae.zip.

[Dr.Venom]

Originally Posted by Toni Wilen

It seems enumerated refresh rates don't always "inherit" interlace status from "parent" resolution.

EDIT: should be fixed in today's winuae.zip.

Great, fixed black screen with winuae.zip is confirmed.