Vamiga: Feud hangs after intro screen

Created on 1 Nov 2019  ·  24Comments  ·  Source: dirkwhoffmann/vAmiga

Feud hangs (kick 1.2 and 1.3) after intro screen:
Feud (1987)(Bulldog).adf.zip

Schermata 2019-11-01 alle 09 20 25

Blitter Bug Game

Most helpful comment

Excuse me, but I have read this:
Musashi is a Motorola 68000, 68010, 68EC020, 68020 and 68040 emulator written
in C. This emulator was written with two goals in mind: portability and
speed.

Why cannot you add the 68010, 68020 and 68040 selection CPU ?
...than the 68040 has the fpu for @PAKKUNKINOPPI...

All 24 comments

I didn't manage to launch it in UAE, too.

Do I have to press special key? The image doesn't say anything 🤔.

I managed to run the game in AmigaForever. Maybe I simply didn't wait long enough in UAE:

Bildschirmfoto 2019-11-01 um 15 15 30

When the disk drive turns off, pressing the mouse starts the game.

Just looked up a lets play gamer video of feud on YouTube. An old guy told me that the most emulators dont play audio. what about vAmiga. And be aware of the guy in the red robe. Its your brother and he wants to kill you. At least they said that in the video. 🙄

I know Alessandro has a faible for these sort of games.

In vAmiga, the game seems to hang in the following loop:

Bildschirmfoto 2019-11-01 um 14 27 55

Paula panel shows that VERTB interrupts are enabled:

Bildschirmfoto 2019-11-01 um 14 33 51
Register dff01e is INTREQR and the AND mask $20 tests for the VSYNC IRQ bit.

This might be an interrupt timing problem:

Hypothesis:

  • if the VERTB bit is set in INTREQ, an IRQ is issued immediately
  • The VERTB bit is cleared in the IRQ handler. Hence, the CPU never sees the bit being 1

TODO: Write a vAmigaTS test case for this scenario.

that the most emulators dont play audio

No audio in vAmiga 😢.

And be aware of the guy in the red robe.

This guy usually shows up on Christmas, only. This time, I promise to keep the door locked.

The good: I can confirm that this bug is indeed due to interrupt timing.

Bildschirmfoto 2019-11-02 um 14 49 35

The bad: The bug is most likely caused by the Musashi CPU which hasn’t been designed to be as timing-accurate as we need it to be in this case. Freud is only running, because I hacked vAmiga. I simply delayed the change of the CPU’s interrupt level pins by 25 DMA cycles.

The ugly: I compensated the inaccuracy of the CPU by adding another inaccuracy which is a bad idea in the long run.

Maybe I can patch the Musashi core directly… we’ll see…

If somebody wants to spend time on it: It would be interesting to know the exact impact of the MAME config option. Maybe the MAME team run into similar issues with the core...

Hi dirk. Musashi core had recently received pull requests which port over mame related patches to it. Particulary interesting for Feud is maybe the mention of interrupts on pr35 https://github.com/kstenerud/Musashi/pull/35

Yes, I need to update the Musashi core first. I wasn't aware of the fact that the recent "massive" pull request was really so massive.

https://github.com/kstenerud/Musashi/commit/0a75e6e85ec3a16e09e50928f6d25200e34f8704

For us particulary interesting whether this commit solves the feud crashing.

For us particulary interesting whether this commit solves the feud crashing.

Yes, it'll be interesting to see. I'll try asap.

However, my feeling is that it won't solve it (just a guess of course. I hope I am wrong).

Here is the thing: When the IRQ level goes up on the CPU level pins, Musashi interrupts immediately (if IRQs are enabled for the detected level). However, the real CPU seems to react with a considerable delay (i.e., it seems to execute a few more commands before execution is interrupted). Right now, I don't know where this delays comes from. It could come from Paula (unlikely from a hardware-perspective), it could be an internal delay of the 68000 or it could be caused by prefetching. Maybe all prefetched commands are completed until the IRQ triggers (just a guess).

However, the real CPU seems to react with a considerable delay (i.e., it seems to execute a few more commands before execution is interrupted).

What you are suspecting seems to match what @zerlurker wrote in pr35

I am not sure about the one changing the interrupts so that they don't execute until you run some cycles, I had a crash because of this while doing my testing, but it's not hard to fix anyway, just run a minimum number of cycles after the interrupt and you are done, and it's probably the right thing to do.

Excuse me, but I have read this:
Musashi is a Motorola 68000, 68010, 68EC020, 68020 and 68040 emulator written
in C. This emulator was written with two goals in mind: portability and
speed.

Why cannot you add the 68010, 68020 and 68040 selection CPU ?
...than the 68040 has the fpu for @PAKKUNKINOPPI...

Wow again someone with a logic analyzer😄
I have to read about this. Toni also wrote that he used one. Interesting stuff.

Sesam street game... 😜 Very interesting... Have too read that article carefully.

Probably your "wait 25 DMA cycles" patch is still unreal (too quick) according to the article the CPU is 44 cycles minimum busy when interrupt happens? But maybe CPU cycles are not DMA cycles?🤔

Why cannot you add the 68010, 68020 and 68040 selection CPU ?

I'm not claiming it's not possible. I think it's just too early to add such features at the moment. The priority for now should be to emulate the real Amigas (A500 😎, A1000 😎, and A2000 😎) with an accuracy hight enough to justify a "public beta" v0.9 release.

Wow again someone with a logic analyzer 😄

The logic analyzer seems to be the magic weapon for emulator makers 🤔. Unfortunately, only electrical engineers are able to operate them. I'm only a computer scientist. I would probably hurt myself with such a thing 🤓.

BTW, does anybody remember this cool device?

images

Doom became much easier once I discovered this "logic analyzer" in one of the secret chambers.

Massive issues with the latest Musashi core on macOS:

Bildschirmfoto 2019-11-03 um 09 27 17

  • Warnings about uninitialised variables in the new fpu code 🤭.
  • Lots of linker errors 😲. Something has changed in a way that I can no longer integrate the C core in my C++ code as I did before. I don't understand the details yet.
  • In some files, I needed to add include statements manually, because otherwise, it didn't recognised some self-defined symbols 😳.

I'll revert back to the old version (with it's very very high code quality ❤️ ). The latest code feels beta.

Yes I remember. BFG 9000🤤. The abbreviation BFG stands for "Big F**ing Gun” no? A Brute Force Logic Analyzer. I think it should be named BFLA instead which would not be so rude. 😇

But maybe CPU cycles are not DMA cycles?🤔

Agnus runs at 3.55 MHz. Thus, 1 DMA cycle equals 2 CPU cycles.

It's known that you can execute at least one instruction after enabling VINT in the VDP with a pending VINT.

Never heard about that in my life 🙄. Anyway, I patched vAmiga such that it delays IRQs by one instruction. This is not perfect, but it makes Feud to run.

Emulating this is required to make Sesame Street Counting Cafe to work.

"Sesame Street Counting Cafe" is Sega only. There is no Amiga port 😢.

I have found another derivate of musashi here. It has been ported to C++.

https://github.com/mamedev/mame/tree/master/src/devices/cpu/m68000

According to the history of the file mame/src/devices/cpu/m68000/m68kcpu.cpp it is frequently developed by various people until today. If you still have energy, maybe you can give that one a last try ?

I succeed in starting Feud only if Blitter Accuracy is set to 0, with accuracy 1 or 2 it hangs

Schermata 2019-11-04 alle 22 50 43

Works only with blitter accuracy 0.

Seems to work in v0.49 with Blitter accuracy 2. Please reopen if I am wrong.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

dirkwhoffmann picture dirkwhoffmann  ·  4Comments

dirkwhoffmann picture dirkwhoffmann  ·  3Comments

dirkwhoffmann picture dirkwhoffmann  ·  3Comments

KenDFish picture KenDFish  ·  3Comments

Gianmarco72 picture Gianmarco72  ·  4Comments