CruiseForACorpse.hdf

[dirkwhoffmann]

Load CruiseForACorpse.hdf with Kick 2.04 + 8MB FastRam. After a few seconds, the screen becomes black and the loading process stalls. The CPU is unable to exit the following loop (breakpoint at RTS is never reached):

Register DFF01E is INTREQR and bit 5 is VERTB.

[mras0]

Extra info: It works with same config in WinUAE 4.9.1. Tried it in my own emulator, and I see the same thing. Issue seems to be classic game bug: It also has level 3 interrupt enabled that clears VERTB from INTREQ. Meaning the loop syncs up in way that it never see INTB_VERTB set.

Possible causes (not exhaustive):

• IPL timing (played around a bit with this, and doesn't seem to be case, but not conclusive)
• Timing on something that happened earlier means alignment of cycles is different (TODO: check if WinUAE enters the loop with different V/HPOS values)

[dirkwhoffmann]

In vAmiga, the interrupt seems to always hit in after the BEQ command.

This is a little too early. It it hit in after the MOVE command, the loop would be exited.

As an experiment, I've removed IPL polling from the BEQ instruction by applying the following temporary change:

Moira::execBcc(u16 opcode)
{
    ....
    // Take branch
    reg.pc = newpc;
    // fullPrefetch<POLLIPL>();   <-- old code
    fullPrefetch();               <-- faked code
    ....
}

Using the fake CPU, the game starts:

Of course your second hypothesis might also be correct. Maybe the loop is executed with a different cycle pattern on the real machine and UAE.

TODO: Double-check IPL polling tests for Bxx instructions.

[dirkwhoffmann]

Update: I've written a new (second) test for checking IPL timing for the BEQ instruction: https://github.com/dirkwhoffmann/vAmigaTS/tree/master/IPL/B/BEQ2

The test passes in vAmiga with the current IPL polling code and fails when the IPL polling cycle is altered. Hence, I am pretty confident that we are not facing an IPL polling issue.

[mras0]

Yeah, I also managed to get WinUAE stuck in that loop now (I think I forgot to enable cycle exact mode yesterday). It won't exit it until I press a key (disturbing the timing). If I run my emulator at 14MHz+ or with 1.5 slow RAM instead it doesn't get stuck.

I think it's likely it's a real problem that just wasn't noticed because 7MHz 68000 + fast ram isn't a very common configuration. Since system is kept alive (OS interrupt routines run) it probably also depends on exact setup. In WinUAE it only gets stuck if I'm careful not to press any keys during the loading screen (like shift+f12 to enter the debugger... ) so instead I add a breakpoint on the BEQ.W instruction with fi 6700 fff4 and the start the game.

[dirkwhoffmann]

Same here:

• Pressing a key disturbs timing and causes the loop to exit.
• Using 2MB Chip Ram instead of Fast Ram fixes the issue (vAmiga doesn't support more than 512KB Slow Ram).

So I think this can be closed.