WinUAE 4.9.0 beta series (Was 4.5.0)

[AMIGASYSTEM]

Originally Posted by hexaae

What RTG do you use?
Here is very unstable (black screen and emu quits) with RTG UAE-Z3 (I use P96 with AmigaOS) after it quits from WHDLoad games and has to go back to RTG WB.

With Beta 24 I tested ShadowOfTheBeast on UaeGFX Screen, and i had no problem, tested with 4 RTG systems: OS 3.1 RTG, OS3.9 BB4 RTG, OS 3.2 RTG and AfA One RTG

Usually the black screen followed by Guru happens when using a recent version of WHDLoad with an old Key.

[hexaae]

Ok, I think I've found the problem with some of my WHDLoad installed games vs beta24: some of them in the icon tooltypes use 'uae-configuration' to change some emulator settings on the fly and fix glitches (my WB boots in RTG P96 + 060 emu etc. hi-end Amiga emulation...) and I've found that some commands in particular cause this black-screen issue right after quitting WHD games.

For example for Shadow of the Beast WHD I use:

...
ExecuteStartup=
ExecutePostDisk=uae-configuration cachesize 0 cpu_speed real cpu_throttle -800 cpu_memory_cycle_exact true immediate_blits true
...

This causes black-screen issue when I quit back to my RTG WB with WHD exit key... but removing just the "cpu_memory_cycle_exact true" part solves the issue and WinUAE is stable again.
BTW, on exit, WHDLoad automatically runs my S:WHDLoad_cleanup script where I revert back emu to "cachesize 8192 cpu_speed max etc." to re-enable JIT etc. Renaming the script though didn't solve the problems... so it's not the exit script the problem.

In short: some emu 'uae-configuration' options from within emulation I use for some WHDLoad games, seem to cause strange instability effects with latest beta24, when it switches Native mode <-> RTG WB soon after.
Was rock stable at least up to b16.

[rutra80]

On unofficial beta I get floating pointer garbage instead of display when Remove interlace artifacts is enabled and I switch WB to PAL laced modes.

[Viceroy]

Originally Posted by hexaae

What RTG do you use?
Here is very unstable (black screen and emu quits) with RTG UAE-Z3 (I use P96 with AmigaOS) after it quits from WHDLoad games and has to go back to RTG WB.

This is interesting: I tried also non-WHD games (opening their own NTSC or PAL screen) and they work fine instead all the time after I quit and go back to RTG WB. Seems to affect WHDLoad games only... mmmh

rtgmaster_user.lha version 42.0

[Tomislav]

Originally Posted by rutra80

On unofficial beta I get floating pointer garbage instead of display when Remove interlace artifacts is enabled and I switch WB to PAL laced modes.

From Beta 18 "Remove interlace artifacts" Display panel option is not supported. It must be disabled.

[jotd]

I get systematic crashes when uniconifying winuae after a resume from a windows sleep mode

zoned the dumps I got those days.

[Toni Wilen]

Originally Posted by jotd

I get systematic crashes when uniconifying winuae after a resume from a windows sleep mode

zoned the dumps I got those days.

Has same cause as above Picasso96 crashes.

[Toni Wilen]

https://download.abime.net/winuae/fi...uae_4900b25.7z

Last missing "weird programmed mode" feature was implemented (I hope, unless someone who does not need to be mentioned finds even more interesting programmed mode undocumented features )

Next step: bug fixes and optimizations.

Beta 25:

- On the fly PAL/NTSC switch (VPOSW trick or BEAMCON0) incorrectly adjusted screen width in some situations. Height is now adjusted relative to total vertical lines, some games use VPOSW trick to generate 56Hz mode which was previously scaled as NTSC.
- Programmed mode (BEAMCON0 bit 7 set) with PAL/NTSC like parameters are not anymore considered as VGA-like.
- Hardwired vblank end line was 1 too late.
- Fixed repeating autoresize.
- Yet another HBLANK related undocumented feature: HBLANK start enables border. If HBLANK start is moved to visible area and bitplanes are active during HBLANK: border gets re-activated and bitplane re-starts when next BPL1DAT write happens. This probably can't be used for anything useful because display's black level detection will get confused (weird colors, wrong black level etc) if HSYNC period is not blanked.
- And another undocumented feature: if horizontal display window was closed due to HBLANK and next BPL1DAT access is close enough (and after HBLANK end in visible region, so probably can only happen in bitplane overun condition, normally shift registers empty and only background color is shown), display window opens 1.5 lores pixel early, showing previous BPL1DAT loaded pixel pattern.
- Horizontal diw now works correctly even if display horizontally "wraps around" due to (much) larger than normal HSYNC position.
- Light gun/pen fix.
- Partial fix to cycle-exact + MMU emulation (but could also happen without MMU) weird copper behavior. Internal cycle counter was not always guaranteed to be chipset cycle aligned.
- GUI lists (for example Hardware info) column DPI support.
- Fixed D3D11 OSD led crash (D3D9 worked) if display moved monitors and they had different DPI.
- Fixed RTG unexpected display size/scaling, introduces few betas ago.
- Fixed RTG related crash when switching fullscreen modes (possibly also in other modes).
- Fixed chipset emulation buffer overflow in some programmed modes, buffers need to be slightly larger now that vertical "overrun" is supported.

[Viceroy]

Well done Toni you are on a mission!

[hexaae]

Originally Posted by Toni Wilen

https://download.abime.net/winuae/fi...uae_4900b25.7z

Last missing "weird programmed mode" feature was implemented (I hope, unless someone who does not need to be mentioned finds even more interesting programmed mode undocumented features )

Next step: bug fixes and optimizations.

Beta 25

Stable again!
Well... almost, got a crash Will try to reproduce...

[goldmomo]

Originally Posted by Toni Wilen

- Partial fix to cycle-exact + MMU emulation (but could also happen without MMU) weird copper behavior. Internal cycle counter was not always guaranteed to be chipset cycle aligned.
.

Thanks Toni, great work

[falken]

Recently I have observed that in the latest betas (from beta 18 to 25), the image does not fit well with respect to the previous betas. The last one that fitted well is beta 17, as seen in the attached image. In both cases the same configuration file is being used.


Beta 25 on the left. / Beta 17 on the right

[DZh]

Originally Posted by falken

Recently I have observed that in the latest betas (from beta 18 to 25), the image does not fit well with respect to the previous betas. The last one that fitted well is beta 17, as seen in the attached image. In both cases the same configuration file is being used.


Beta 25 on the left. / Beta 17 on the right

Need just correction this in 'Filter' panel. Perhaps this features of the new graphics emulation. (?)

[falken]

Originally Posted by DZh

Need just correction this in 'Filter' panel. Perhaps this features of the new graphics emulation. (?)

You mean this?

[DZh]

Yes, I changed these parameters.

[falken]

Originally Posted by DZh

Yes, I changed these parameters.

Ok, i´ll try that. Do you know what's new in graphics emulation?

[DZh]

See post #559 - "Display emulation rewrite".

[falken]

Originally Posted by DZh

See post #559 - "Display emulation rewrite".

Nice, thank you!

[Toni Wilen]

Originally Posted by falken

Recently I have observed that in the latest betas (from beta 18 to 25), the image does not fit well with respect to the previous betas. The last one that fitted well is beta 17, as seen in the attached image. In both cases the same configuration file is being used.


Beta 25 on the left. / Beta 17 on the right

Right side had one extra pixel, fixed in next beta. Bottom should be correct, it is usually line that is black but can be have other colors too but not graphics. This was not fully emulated previously.

btw, don't scale screenshots..

[R-TEAM]

Hi,
dont know if this known ...
Filters (shaders) dont work in actual (25) Beta ... in DX11 - in DX9 it works.

Regards