WinUAE 5.0.0 beta series (was 4.10.2)

[Waccoon]

I just noticed that autofire support for input devices seems to not be working anymore. Was working fine in beta 7, not working as of beta 8.

It's likely that commit 09a06c4 is the culprit. Config file values for autofire are correct for all devices, and the GUI drop-down menus can be selected, but autofire has no effect under emulation for any input device.

It's really late so I'm off to bed. I'll look closer into this tomorrow night.

[hexaae]

Originally Posted by Toni Wilen

I can't duplicate. Both CD32 version (Big6 collection) and WHDLoad version works fine.
EDIT: if you can duplicate it, does winuae.7z do same?


EDIT2: Can you also duplicate this: https://eab.abime.net/showpost.php?p...postcount=1153
I fixed related issue but there might be other bug too if it still happens. If it does, which was first beta that introduced it?

Yes, I can replicate also BTS "all green" bug (tested BTS AGA 1.5 WHDLoad).
Tested up to b6 and was still reproducible (can't find lower betas with Error 404).
EDIT: ah was named winuae_41020b<1 to 5>.7z let me try...
EDIT2: was reproducible since https://download.abime.net/winuae/fi...uae_41020b1.7z. Not reproducible with 4.9.1


EDIT3: 4.10.1 final public is also affected.

[hexaae]

Tested some more old betas... BTS and Fantastic Dizzy AGA all green bug... It all started with 4.10.1b4. Up to 4.10.1b3 they were ok.

[Waccoon]

Originally Posted by hexaae

Tested some more old betas... BTS and Fantastic Dizzy AGA all green bug... It all started with 4.10.1b4. Up to 4.10.1b3 they were ok.

I found out some things about the green screen bug.

I've found that this is related to the compiler optimizations. The "Whole Program Optimization" (/GL flag) seems to be solely responsible for triggering the green screen bug. Debug builds don't have this issue, and almost all optimizations (O1/O2) changes nothing. Just disabling whole program optimization in the FullRelease build resolves the issue.

It's apparently a DX9/DX11 issue, and it happens in both software and hardware mode. GDI does not have this problem. The visual debugger also goes green. If you switch between DX9/DX11 mode or software/hardware mode on-the-fly, the display is partially resolved, but there is still something internal that is messed up sooner or later the green comes back.

When the screen goes green, I can see all kinds of packed-pixel garbage and chunks of the display moving all over, so it appears to be some kind of DirectX buffer corruption going on and it's definitely not a problem on the Amiga side. The BTS demo triggers it when a particular AGA video state with 8 planes is enabled. I'll see if I can isolate that code, but I'm out of time for today.

[Zosite]

Hello there!

First the first, thank you Toni for all the work you've been investing in such a milestone as 68000 cycle-accuracy is when it comes to proper Amiga emulation. It's been a long journey, indeed!

Now, I'd like to report a couple issues I've been noticing as of late. I'm using 5.0.0 RC4 right now:

1.) Intro screens in 'Agony' OCS/ECS appear completely distorted under ECS Agnus (or Full ECS combining Agnus and Denise). OCS and AGA work OK. Always using QuickStart profiles, of course.
Regression is 4.9.1 where it doesn't happen at all.

2.) 'Lionheart' main menu appears corrupt when using 'remove interlace artifacts' display option to get rid of interlace hell both there and in main game background effects.
Regression goes as back as 4.4.0, the last release where such an useful setting doesn't produce this effect.

Thinking about it now, it might be that being both regressions back to versions older than 5.0.0 beta/RC cycle they may not belong to this particular thread; if that's the case please accept my apologies and tell me about so I can replicate this post into the main support forum.

And once again, thank you so much and all the best for WinUAE 5!

[Toni Wilen]

Originally Posted by Waccoon

I found out some things about the green screen bug.

I am quite sure it is caused by sprite buffer overflow (again). (64-bit build + address sanitizer detects it). winuae.7z/winuae64.7z has yet another possible fix.

[Toni Wilen]

Originally Posted by Zosite

1.) Intro screens in 'Agony' OCS/ECS appear completely distorted under ECS Agnus (or Full ECS combining Agnus and Denise). OCS and AGA work OK. Always using QuickStart profiles, of course.
Regression is 4.9.1 where it doesn't happen at all.

Fixed, thanks.

2.) 'Lionheart' main menu appears corrupt when using 'remove interlace artifacts' display option to get rid of interlace hell both there and in main game background effects.
Regression goes as back as 4.4.0, the last release where such an useful setting doesn't produce this effect.

Did it even work in pre-4.4.0? It is difficult to say because nothing moves in main menu screens, can't see if there are usual interlace artifacts or not.

[Zosite]

Did it even work in pre-4.4.0? It is difficult to say because nothing moves in main menu screens, can't see if there are usual interlace artifacts or not.

Yes, it does, and also in 4.4.0 but 4.9.0 breaks it. You can tell in that menu by moving your chosen item selector which highlights the text. Interlace artifacts (fading horizontal lines) are normally there when text is highlighted or goes back to non-chosen shade, but 'remove interlace artifacts' manage to get rid of them.

Within the changelog of 4.9.0 there's an interesting “Remove interlace artifacts” last line flickering workaround fix. entry. Could this issue be related to that particular fix? Just guessing...

And thanks a lot for that other fix, Toni. See, due to its 1992 state-of-the-art (IMHO) nature I'm always testing new WinUAE versions against 'Agony'.

[freddy]

Toni could you create an another entry for the translation of this options.
Thanks

[hexaae]

Originally Posted by Zosite

2.) 'Lionheart' main menu appears corrupt when using 'remove interlace artifacts' display option to get rid of interlace hell both there and in main game background effects.
Regression goes as back as 4.4.0, the last release where such an useful setting doesn't produce this effect.

FYI, I can run Lionheart (WHD) without issues also in menus with these settings I use from tooltypes:

for WinUAE 4.9.1:

ExecuteStartup=
ExecutePostDisk=uae-configuration cachesize 0 cpu_compatible false cpu_cycle_exact true immediate_blits true cpu_throttle -600

for WinUAE 5.0.x:

ExecuteStartup=
ExecutePostDisk=uae-configuration cachesize 128 cpu_speed real cpu_throttle -420 cpu_memory_cycle_exact true cpu_multiplier 2 immediate_blits true

So I wonder if it's just a matter of different timings and inner WinUAE changes...
The strange thing is that using "4.9.1 cfg" on 5.0.0 the game often takes a lot to load with black screen and other issues, that's why I created another cfg.

EDIT: this is interesting... After I run Lionheart with last winuae64.7z mouse and screen positioning goes wrong with other games like Colonization AGA (run from WB, no WHD: it closes WB screen automatically to save chipmem). Moreover Lionheart WHD itself (just load and Start the game without changing Options) puts Valdyn not in the center of the screen but on the right side and scrolling is also broken (= badly centered). No problem with WinUAE 4.9.1.

EDIT2: Attached log with Colonization AGA with windows out of focus (i.e. cursor clicks are moved on the right and not right under the pointer). To reproduce it I ran: DeluxeGalaga AGA, then Lionheart WHD (using WinUAE 5.0 ExecutePostDisk as above), and finally Colonization AGA. Possibly something related to Filter/Overscan settings and recent changes...
Log: https://paste.sh/gDwFv61U#ilpEd1isBEwMREeCJEEhpc7o

[Toni Wilen]

Originally Posted by hexaae

FYI, I can run Lionheart (WHD) without issues also in menus with these settings I use from tooltypes:

That was A500 config only problem. It won't happen in any 68010+ config.

Moreover Lionheart WHD itself (just load and Start the game without changing Options) puts Valdyn not in the center of the screen but on the right side and scrolling is also broken (= badly centered). No problem with WinUAE 4.9.1.

Can't duplicate, not even with your config and setup.

Just a random guess: get rid of these lines:

gfx_center_horizontal_position=0
gfx_center_vertical_position=0
gfx_center_horizontal_size=0
gfx_center_vertical_size=0

I am 99.9% sure you don't want those or you will get strange display positioning in some filter modes.

EDIT2: Attached log with Colonization AGA with windows out of focus (i.e. cursor clicks are moved on the right and not right under the pointer). To reproduce it I ran: DeluxeGalaga AGA, then Lionheart WHD (using WinUAE 5.0 ExecutePostDisk as above), and finally Colonization AGA.
Log: https://paste.sh/gDwFv61U#ilpEd1isBEwMREeCJEEhpc7o

Don't make this more complex, please. Get rid of uae-configuration lines first, don't use cpu_throttle). It is impossible to debug when there are far too many variables.

Screenshot please.

[Toni Wilen]

Originally Posted by freddy

Toni could you create an another entry for the translation of this options.
Thanks

Done (+few others). "Built-in expansions" (and other items in same menu) is already supported (IDS_EXPANSION_CATEGORY).

[Toni Wilen]

https://download.abime.net/winuae/fi...uae_5000b13.7z
https://download.abime.net/winuae/fi...e64_5000b13.7z

Beta 13: (RC5)

- Sprite buffer overflow was still possible. Adjusted buffer size again and added limit check, if it is still going to overflow, sprite emulation is skipped until next frame. Problem with this buffer is that it is static, it needs to be as big as max supported programmed display mode which is waste of memory when emulating normal PAL/NTSC modes. It needs to be dynamically allocated. But it is too late now. ("Green" Big Time Sensuality / Axis)
- Game ports panel autofire options didn't do anything (b8)
- b8 "Allow moving vertical position backwards (VPOSW/VHPOSW writes) if current vpos is out of range" only handled VHPOSW writes. Agony interlace title screen swapped odd/even fields if accurate A500 ECS 68000 mode (CLR.W $DFF02A..)
- Added Striker Manager dongle emulation.

[Toni Wilen]

Originally Posted by Zosite

Yes, it does, and also in 4.4.0 but 4.9.0 breaks it

winuae.7z has fix that should fix it but it also can cause other side-effects. Not in latest beta because it still needs some work. ("doubled" line also rerun blitter cycles in some situations..)

[Zosite]

Originally Posted by Toni Wilen

- b8 &quot;Allow moving vertical position backwards (VPOSW/VHPOSW writes) if current vpos is out of range&quot; only handled VHPOSW writes. Agony interlace title screen swapped odd/even fields if accurate A500 ECS 68000 mode (CLR.W $DFF02A..)

Originally Posted by Toni Wilen

winuae.7z has fix that should fix it but it also can cause other side-effects.

It is with great pleasure, Toni, that I can confirm both fixes seem to be working perfectly and I didn't notice any side effects to the 'remove interlace artifacts' fix... yet... better to make sure it won't do more harm than good, just my two cents. on the matter. Thank you so much and keep up the good work!

[freddy]

Originally Posted by Toni Wilen

Done (+few others). "Built-in expansions" (and other items in same menu) is already supported (IDS_EXPANSION_CATEGORY).

I did not find an entry for these 3 cases

[Toni Wilen]

Originally Posted by freddy

I did not find an entry for these 3 cases

Only last will be updated before 5.0. Other ones won't be changed until 5.0 is out.

[Toni Wilen]

https://download.abime.net/winuae/fi...uae_5000b14.7z
https://download.abime.net/winuae/fi...e64_5000b14.7z

This should finally fix remaining reported bugs. Random refresh conflict sprite offset was very nasty one.

Beta 14: (RC6).

- "Remove interlace artifacts" + accurate modes: some blitter cycles were also rerun during "scandoubled" line.
- Added Multi-Player Soccer Manager dongle emulation. This is very similar to Striker Manager dongle.
- On the fly switch from AGA to OCS/ECS and then back didn't restore original AGA background color until running program wrote different value to COLOR0 register.
- In some situations refresh conflict (even if it was harmless single cycle conflict due to bitplane DMA being enabled with "bad" position) left sprites in always on horizontal "conflict offset" state. (4.9.9+)
- Added jit_inhibit config entry, can be used to force disable JIT temporarily even if uae-configuration/custom event is used to enable JIT. When you really want JIT disabled but don't want to modify anything else.

[hexaae]

Great work!

[Mclane]

Incredible work as always, Toni.

May you wake up to sunshine and happiness every day!