Weird problem with Another World WHDLoad in WinUAE 5.1.0 (but not 5.0.0)

[xaind]

Apologies if this has already been reported somewhere and I missed it.

When I try to run Another World from a WHDLoad install in WinUAE 5.1.0 I just get a black screen. The emulator hasn't hung though as I can still press the WHDLoad quit key to exit the game.

If I use WinUAE 5.0.0 though the game works fine.

I'm using WHDLoad version 18.9.6601.

The problem occurs with Another World slave versions 2.7 and 2.8, but it works fine if I use slave version 2.4.

My config is set up to mimic an A1200, so 68020 with 24-bit addressing, Kickstart 3.1, AGA, Cycle-exact, 2MB Chip RAM, 4MB Z2 Fast RAM.

This isn't really that big of a problem I guess, since there's nothing in the later slave versions that I really need, so I can just stick with slave 2.4.. still I thought it might be worthwhile to report it.

(Note: A full install of the game with slave version 2.4 is on whdownload.com. Version 2.8 of the slave can be downloaded from whdload.de)

[Velociraptor5]

Originally Posted by xaind

Apologies if this has already been reported somewhere and I missed it.

When I try to run Another World from a WHDLoad install in WinUAE 5.1.0 I just get a black screen. The emulator hasn't hung though as I can still press the WHDLoad quit key to exit the game.

If I use WinUAE 5.0.0 though the game works fine.

I'm using WHDLoad version 18.9.6601.

The problem occurs with Another World slave versions 2.7 and 2.8, but it works fine if I use slave version 2.4.

My config is set up to mimic an A1200, so 68020 with 24-bit addressing, Kickstart 3.1, AGA, Cycle-exact, 2MB Chip RAM, 4MB Z2 Fast RAM.

This isn't really that big of a problem I guess, since there's nothing in the later slave versions that I really need, so I can just stick with slave 2.4.. still I thought it might be worthwhile to report it.

(Note: A full install of the game with slave version 2.4 is on whdownload.com. Version 2.8 of the slave can be downloaded from whdload.de)

You are right, the same here. Try your "Cycle exact" but with "fastest possible" or untick only "Cycle exact (full)" and the game should work. Unfortunately, It's normal, sometime CE configuration works in older version of WinUAE and in latest version doesn't work (and viceversa). You'll find much more such examples like your Another World. But absolute majority of games work correctly under Cycle exact-full.
P.S. Don't use games from "whdownload.com", it's obsolete. The original source is Retroplay. Look here in EAB:
https://eab.abime.net/showthread.php?t=61028

[Toni Wilen]

Does 5.2 beta (see above in this forum) fix this? It has a fix that might help.

[xaind]

Originally Posted by Toni Wilen

Does 5.2 beta (see above in this forum) fix this? It has a fix that might help.

No, unfortunately, it doesn't work with 5.2b1 either - but note that Velociraptor5's suggestion of unticking "Cycle-exact (Full)" fixes the problem in both 5.1.0 and 5.2b1.

[Toni Wilen]

This is probably the most common hang reason (at least 3 different cases seen so far), program being doing bad things and poll vblank bit in INTREQR while vblank interrupt is active. Even on real HW this can introduce "unspecified" delay until polling detects the interrupt. (Especially if 68000 where it is emulated 100% accurately)

This probably needs some hack to work around...

[ross]

Originally Posted by Toni Wilen

This probably needs some hack to work around...

imo, much better would be a patch in the slave than a hack in WinUAE..

[Toni Wilen]

Originally Posted by ross

imo, much better would be a patch in the slave than a hack in WinUAE..

Yes but I am quite sure this is not whdload specific bug.

[ross]

Originally Posted by Toni Wilen

Yes but I am quite sure this is not whdload specific bug.

Yep, that's the reason I referred to the slave, not to whdload itself

Problem is in slave/"ReadJoyPad.s" (and that's probably why it only appeared from a certain version onwards, it wasn't supported before).

.wvbl:
	; wait for VBL
	lea	$DFF000,a0
	move.w	#$7FFF,intreq(a0)
.wait
	move.w	intreqr(a0),d0
	btst	#5,d0
	beq.b	.wait
	rts

This piece of code of course cannot work well if INTENA/VERTB is active (as you rightly said in your message).

Jotd can definitely fix it in a short time by updating the slave

[xaind]

Originally Posted by ross

Problem is in slave/"ReadJoyPad.s" (and that's probably why it only appeared from a certain version onwards, it wasn't supported before).

.wvbl:
    ; wait for VBL
    lea    $DFF000,a0
    move.w    #$7FFF,intreq(a0)
.wait
    move.w    intreqr(a0),d0
    btst    #5,d0
    beq.b    .wait
    rts

This piece of code of course cannot work well if INTENA/VERTB is active (as you rightly said in your message).

Jotd can definitely fix it in a short time by updating the slave

Confirmed. I replaced the code above with the following (shamelessly stolen from Stingray's mini startup code):

.wvbl:
    ; wait for VBL
    move.l    d0,-(a7)
.loop
    move.l    $dff004,d0
    and.l     #$1ff00,d0
    cmp.l     #303<<8,d0
    bne.b     .loop
    move.l    (a7)+,d0
    rts

and after that the game works fine in WinUAE 5.0.0, 5.1.0, and 5.2b1 with "Cycle-exact (full)" still ticked.

Note: I haven't checked if this change breaks the controller detection code that calls this routine, since I don't have a controller. If anyone else would like to give it a try I'll attach the modified .slave file.

[Toni Wilen]

Above hangs if screenmode is NTSC. This is nasty situation because active interrupt can also "steal scanlines" (and amount of lines can be "random") which makes single line comparison also bad/unstable choice. Only guaranteed working method is to set some flag in vblank interrupt or to disable interrupt during the wait. Or maybe STOP instruction

[jotd]

the real fix is to disable interrupts then enable them. I have done that in more recent slaves where the problem occurred. But at the time it worked with Another World.

Will fix.