Wings of death get stuck

[Darasco]

I'd like to report that "Wings of death" game (ipf format) gets stuck when loading after changing the second disc. This happes using winuae 5.1.0 (x64), but not with 5.0.0 version (x64).Thks for the great work.

[alexh]

If you wanted to see if it was a WinUAE<->SoftPres plugin issue I have an eADF (made by Dflrsilver from the official softpres 3022 IPFs) on my website.

http://thalion.exotica.org.uk/games/...a/wod_eadf.lha

[Darasco]

thanks alexh, but with the adf version it gets stuck the same. Winuae 5.0.0 works, but 5.1.0 get a black screen. The SoftPres plugin does not seem to be the problem.

[alexh]

Please post your WinUAE configuration / Save All.

Thalion games, because they are traditionally ported from the Atari ST, regularly contain left-over code that reads/writes to Atari ST HW registers that don't exist. On the A500 OCS/ECS these accesses are normally benign but perhaps these accesses are now causing an issue?

[dlfrsilver]

Originally Posted by alexh

Please post your WinUAE configuration / Save All.

Thalion games, because they are traditionally ported from the Atari ST, regularly contain left-over code that reads/writes to Atari ST HW registers that don't exist. On the A500 OCS/ECS these accesses are normally benign but perhaps these accesses are now causing an issue?

For me, it's either configuration or a regression on the winuae side.

[Darasco]

My config file. Could it be a config file error using diferent winuae versions?

[paraj]

Reproducible w/ a500 "most common" quickstart (best compatibility) and SPS 3022 disks. Stuck on track 77, but I think loading is done. Haven't looked but maybe copy protection failed and/or stupid code, but could be WinUAE issue.

[Zarnal]

Confirmed. Quickstart A500/Best compatibility.

Here are the logs ( WinUae 5.1 and WinUae 5.2 beta 6 ).

[paraj]

Tried to bisect, but there are many commits I can't build, but found that:

ce63da96cdbe647f5f34729025284bfff1872815 works
1102b028b135243bf8b21c8b26aacef021de296f (5100b1) does not

[kremiso]

the game seems to switch to an (hybrid?) 60Hz mode at the end of that loading;
the screen stays black, but you can somewhat re-activate the video enabling 'ntsc' in the WinUAE menu

seems a resolution or fake ntsc (like bckid) issue perhaps? not a loading problem imo

[alexh]

Originally Posted by kremiso

the game seems to switch to 60Hz mode at the end of that loading; the screen stays black

Yes after the loading disk b comes the main menu which switches to 60Hz that doesn't seem to work anymore. Works on release 5.0 doesn't work on 5.1

Definitely works on real PAL HW (Although all my Amiga's have AGA or ECS Agnus)

Originally Posted by kremiso

you can somewhat re-activate the video enabling 'ntsc' in the WinUAE menu

Confirmed. It also works 100% correctly if you select NTSC Amiga from Quickstart.

For testing you can press "s" on the title screen (Dragon) to skip the intro.

[Waccoon]

Confirmed 5.1.0 b1 is the first version with issues, since some significant updates were made to the chipset emulation to support more programmed sync modes.

The game is doing some weird custom programmed mode but apparently isn't using the copper to do it, at least for the frame setup. In pure PAL mode there's too many lines for the display. It's not necessary to switch to NTSC to get the display to show up -- any fiddling with chipset settings in the GUI and returning to emulation will force a redraw and the game will show up.

When I switched to NTSC mode while the game was running, the visual debugger went berserk and is trying to draw lines that don't exist and shows all kinds of DMA conflicts. This is with the OCS chipset selected, and I don't think it's possible for OCS to use that many vertical lines.

[alexh]

The WHDload installer says

- Illegal writes to bitplane pointers fixed
- Bplcon0 color bit fixes (x5)
- Uninitialised copperlists fixed (x2)

I don't know if this can help narrow it down?

[Toni Wilen]

Probably something simple. There is nothing special here.

CPU writing to V(H)POSW is the only way to change refresh rate on OCS because custom address less than $dff040 are always unavailable for the copper. (ECS allows it). All "fake 60Hz" NTSC modes that works on OCS Agnus do it this way.

You can move display vertical and horizontal anywhere you want by writing to VPOSW. >312 lines are possible, even with OCS. DMA debugger don't like these modes.

[ross]

Originally Posted by Waccoon

The game is doing some weird custom programmed mode but apparently isn't using the copper to do it

It doesn't use Copper because in OCS only the CPU can be used for this 60Hz trick on PAL, only from ECS onwards it could use Copper, but at that point it makes no sense because the BEAMCON0 register exists

When I switched to NTSC mode while the game was running, the visual debugger went berserk and is trying to draw lines that don't exist and shows all kinds of DMA conflicts. This is with the OCS chipset selected, and I don't think it's possible for OCS to use that many vertical lines.

Problem here is that you cannot use the trick values in NTSC because the fixed comparator for end of frame is passed.
So the Agnus y counter wraps and you have a stop at 'next' frame (generating too many video lines).
Moral: do not switch on the fly from PAL to NTSC when this trick is in use, start the game in NTSC mode from boot time.

However: to overcome the problem in version 5.1 (but it will certainly be fixed by Toni in version 5.2) go to the Host/Display settings menu and set Overscan:Overscan+ as the mode.

EDIT: oops.. I didn't see that Toni had already posted

[alexh]

Fixed in WinUAE 5.2.0