Chipset AGA option trashed gfx

[hexaae]

I use for Shadow of The Beast WHDLoad the option "uae-configuration … chipset ecs_denise" to remove the trashed tree sprite in parallax main menu.

When I run first a true AGA game like f.e. Virocop AGA WHDLoad and THEN I run Shadow of The Beast WHDLoad with "chipset ecs_denise" there is visible trashed gfx…
E.g. (Virocop AGA WHD and then Lionheart with "uae-configuration … chispet ecs_denise" to avoid line in the middle of the screen when scrolling up/down):


This in general happens whenever I run an AGA game first and then I force a game in ECS mode using "uae-configuration … chipset ecs_denise". Never happens if I run the game without "chipset ecs_denise".

Is this a bug in WinUAE 4.2.1 when switching chipset modes, WHDLoad, or simply expected behaviour due to dirty registers?

[DamienD]

From a quick read of your post; why do you force "ECS Denise" when you are running WHDLoad games that are optimised / hacked for AGA and being run on that system?

[hexaae]

Unfortunately some WHDLoad games are still not fully patched against some minor glitches when not degraded to ECS (Lionheart = horizontal line when scrolling up/down, Beast = trashed tree sprite in main menu)…
I already opened WHDLoad appropriate reports.

[Hewitson]

I'd say you're probably asking for trouble by switching chipsets on-the-fly.

[hexaae]

Yes, the problem happens because of that but I'd like to understand if it's a WinUAE issue (not clearing some registers etc. when switching) or is a mere consequence using this 'hack' feature of WinUAE...

[jotd]

We're not going to fix issues in whdload slaves related to hacking in winuae.

For instance all that's JIT-related is very difficult to solve because JIT has a cache capacity way more important than the 060... if I can do it I do it but it's too much work to make all slaves work properly with JIT. I use a script to turn off/on JIT when starting a slave => done.

custom chips are even more tricky because the programmers often optimized the copperlists/etc... not worth it.

I already fixed some self-modifying code issues that were happening only on winuae because it _could_ happen on other CPUs, but this is going a little too far and - added - those kind of fixes (custom chip stuff) are not particularly easy to do (maybe for others but me I'm not doing it, sorry)

[hexaae]

@jotd
I already opened a WHDLoad report about this glitch in Lionheart…

On AGA machines there's a known gfx glitch showing an horizontal line "unaligned" in the middle of the screen (at the bottom of mountains parallax scrolling), but forcing OCS ("ECS Denise" mode from WinUAE) the issue disappears.
I suppose also on real Amiga HW degrading it to OCS from boot manager could solve the glitch.

This and Beast tree sprite glitch ( http://eab.abime.net/showthread.php?t=18371 and http://codetapper.com/amiga/sprite-t...-of-the-beast/ ) are the only reason for me to use that WinUAE 'hack' switching chipset mode runtime…

[ross]

Hi hexaae, I used for the first time uae-configuration, both as a tooltype and from the command line, and it does nothing
(in fact if I check the options in the GUI they are exactly as before).
Probably I do something wrong..
However, if I change the chipset realtime from the GUI everything works as it should (no problem whatsoever).

About Beast I've never looked in code for the tree sprite glitch but I suppose can be corrected.
For Lionheart you already know the answer

[Toni Wilen]

Shadow of the beast fix:

Zero following addresses: 464bb and 46d2b. (Second byte of SPRxCTL, game for some reason set vertical end bit 9 which is ECS only)

Chipset on the fly is mostly supported. I'll check what happens, probably some AGA sprite feature gets stuck in wrong state or something.

[ross]

Just checked Beast. A little addition to what Toni wrote.
You also need to zero 4681b, there is a wrong 35ns delay for sprite 3, visible as an empty vertical line in the big parallax tree when subpixel emulation (or real AGA) active.
Considering these incorrect settings in the sprite lists it is perhaps a good idea to check the others carefully.

[Toni Wilen]

Originally Posted by hexaae

I use for Shadow of The Beast WHDLoad the option "uae-configuration … chipset ecs_denise" to remove the trashed tree sprite in parallax main menu.

How do you change it? Using whdload prefs (attach whdload prefs file) or manually?

btw, ECS Denise option is OCS Agnus + ECS Denise which is quite unsupported configuration, for example KS 3.1 with this config has some graphics issues because it assumes ECS Agnus if ECS Denise is found.

Better select OCS option.

[hexaae]

I use a specific WHDLoad tooltype to run command/script after disk loading right before WHDLoad starts the game:

Name: lionheart
Type: OS3.5 Icon
SS: 18384
IT: Project
BP: 2,2
SZ: x= 64, y= 16, w= 46, h= 46
DT: (YES) WHDLoad
CI -Width : 82
CI -Height : 93
CI -Borderless : NO
CI -NumImages : 2
CI1-Transparent: 0
CI1-NumColors : 194
CI2-Transparent: NO
CI2-NumColors : 16511570
TT: (YES)
SLAVE=lionheart.slave
PRELOAD
QUITKEY=$5D
ExecuteStartup=
ExecutePostDisk=uae-configuration cachesize 0 cpu_speed real immediate_blits true cpu_multiplier 4 cpu_throttle -500 cpu_memory_cycle_exact true gfx_filter_vert_offsetf 8 chipset ecs
Custom4=0
PreloadSize=4199508

P.S.
Tried Beast with chipset ocs but does NOT fix the tree sprite issue, only chipset ecs_denise hack works

[Toni Wilen]

OCS does fix it (switch it using GUI to confirm, obviously it had to work with OCS A500).

You probably have something else going on too, always test with as simplified config as possible. There are too many unknown variables that can cause side-effects.

Use approximate CPU config and get rid of all other uae-configuration entries from the tool type. Does it now work correctly?

--

Attach also both games icon files (if they contain custom stuff, as binary files, it must be 100% identical), your whdload.prefs and your config file.

[hexaae]

For Beast… Yes, once the game is already running I can actually set OCS from the GUI without side effects, but if I use these tooltypes instead:

Name: Work:Games/HDInstalled/Beast/Copy_of_Beast
Type: NewIcon
SS: 23432
IT: Project
BP: 1,0
SZ: NOPOS, NOPOS, w= 8, h= 8
DT: (YES) whdload
TT: (YES, NEWICON)
SLAVE=ShadowOfTheBeast.slave
PRELOAD
Custom1=1
Config=C1:B:Skip intro;
ExecuteStartup=
ExecutePostDisk=uae-configuration cachesize 0 cpu_speed real chipset ocs
NoCache
PreloadSize=1864417

I have trashed sprites (shrinked) in the upper panel. In other words, if you switch to OCS (from GUI or with uae-configuration) BEFORE you launch the WHDLoad game version it will show trashed sprites in the upper panel. This won't happen using chipset ecs_denise for some reason…

Files:
WinUAE cfg: https://1drv.ms/t/s!ApMUGr0cuN39gcA4...JE9bA?e=osVywd
WHDLoad.prefs: https://1drv.ms/t/s!ApMUGr0cuN39gcBr...QYKwA?e=HVlB3K
WHDLoad_start (ignored when you have the tooltype "ExecuteStartup="): https://1drv.ms/t/s!ApMUGr0cuN39gcBs...M-caw?e=mrgT67
For the icon tooltypes just copy & paste from above ProcessIcon output starting from "SLAVE..."

[Toni Wilen]

winuae.7z should fix it. Not all AGA-only register were reset to OCS/ECS defaults when doing on the fly chipset changes.

[hexaae]

Fixed Beast but introduced some problems with this version:
when I run VirocopAGA, start a new game and quit back to WB
and then run Lionheart I see strange corrput sprites and the screen is set to PAL but 60Hz (?!) with stretched video.

My Lionheart WHDLoad: https://1drv.ms/u/s!ApMUGr0cuN39gcBu...vnwZw?e=yrEpVC
My VirocopAGA WHDLoad: https://1drv.ms/u/s!ApMUGr0cuN39gcBt...y44zg?e=rXASHl
(will remove the files in a couple of days)

Sometimes I have to run VirocopAGA + Lionheart more than once to start see the issue...

[Toni Wilen]

Redownload (make sure exe has changed, sometimes cached copy is returned), enable logging and when it happens, include log, thanks.

[hexaae]

No more PAL 60Hz but still sprite corruption running first Virocop AGA WHD and then Lionheart WHD from the archives above ("chipset ECS" for Lionheart slave)…
I'll proceed with logging in next editing to this msg.

EDIT:
Log: https://1drv.ms/t/s!ApMUGr0cuN39gcBz...SG01A?e=g0jfbb

[Toni Wilen]

Does it disappear if you enter and exit gui? If not, does it disappear if you switch between windowed and fullscreen mode? If still not, does it disappear if you change chipset using GUI?

Remove everything unneeded (extra partitions, expansions etc). If you save state when the corruption is visible, does it still appear when restored?

[hexaae]

No change switching gui on/off, windowed/fullscreen. Switching to OCS from GUI once Lionheart/Beast WHDLoad is already running causes no corruption, but setting OCS before running the game causes corrupt sprites.
Of course running Lionheart/Beast WHDLoad without "chipset ocs" causes no issues.