Another World (The Company) freezes

[dirkwhoffmann]

This is a follow up from issue vAmigaWeb/vAmigaWeb#254 opened in the vAmigaWeb repo. The demo TheCompany_AnotherWorld.hdf.zip freezes after a couple of seconds.

Seems to be a race condition to me. It depends on when exactly the VERTB bit is set during the execution of the BTST instruction. Interestingly, entering the debugger in vAmiga often makes the demo continue. It seems like suspending / pausing the emulator brings Agnus and the CPU slightly out of sync. This lets the demo continue, but shouldn't be the case, obviously.

Regarding the first issue (why does the demo freeze), the following should be done first:

• Add more CPU tests for the BTST instruction in the vAmigaTS repo. I.e.,
  • add an IPL2 style test (directory CPU/IPL2)
  • add timing tests that read from the background color register (directories CPU/Timing, CPU/Timing2).

The second issue has to be tackled separately.

[dirkwhoffmann]

Second issue solved (why does the demo continue when entering the debugger in RetroShell?).

Here is the thing: I've entered the debugger by pressing Shift+Return. When RetroShell is open, all key events are intercepted and routed into the shell rather than the emulator. However, the interception check was missing for flag-changing keys such as Shift. As a result, pressing Shift+Return in RetroShell routed the Shift key into the Amiga (in addition to the shell). Pressing a key brings the CPU and Agnus a bit out of sync which lets the BTST instruction recognize VERTB and the demo continues.

I bet something similar will happen on the real machine. Pressing a key is likely to continue the demo...

[mras0]

Here's my attempt at a testcase: btst_ipl.zip

It uses this sequence before the btst loop to check various cycle "alignments" (d0)

        stop    #$2000
        lsr.w   d0,d1
.loop

With the vblank handler active the "stop" instruction should retire at the same point during the frame regardless of what happened before.

The output is the number of times the VERT bit was observed outside the interrupt. You may find that vAmiga already matches for this test in which case it's just a subtle timing difference in the time it takes to reach the loop start (probably not worth trying to track down as you can see being even a single CCK off matters).

[dirkwhoffmann]

Cool test. I'll run this on my real A500 when I am back from vacation. As an aside, it revealed another bug in my latest beta. v3.0b1 didn't accept EXE files any more (🙈). That was easy to fix, though.