Vamiga: no firebutton detection in gods?

Created on 10 Nov 2019  路  14Comments  路  Source: dirkwhoffmann/vAmiga

Bildschirmfoto 2019-11-10 um 09 03 01

Pressing fire on the controller should make the hero throwing swords. But it is not happen. I pressed with the buttons of the controller, with the keyset1 and keyset2 and mouse but nothing. Interestingly I can move the guy back and forth so it is not a general problem of the connection...

In FS-UAE the same setup works as intended e.g. it throws swords.

Also I discovered when I climb the ladder then no further input is taken from input that is the my character freezes but not the enemies ...

Also in the beginning there comes a game menu which lets you choose to begin at start or at a later level. Interestingly the choice is made automatically that means vAmiga recognizes a "false" button press (false positive).

Bug Game

Most helpful comment

What was it ? Was it a misbehaving CIA ?

No, it was the POTGO register. I completely misunderstood how that register worked until I found the logic circuitry in the HRM:

8-6

In hardware it's really simple. Just a capacitor and a counter which is triggered by the hsync signal and guarded by a Schmitt trigger.

It's now emulated accurately.

All 14 comments

I think the missed button presses are just a symptom of another bug.

I played up to the point where the main character freezes. In the inspector panel, it can be seen that joystick movements and button presses are still translated correctly:

Bildschirmfoto 2019-11-10 um 14 49 52

Bildschirmfoto 2019-11-10 um 14 50 14

馃槳the dev branch already stucks after intro ... while loading the game. I think it is due to Moira which is still in its infancy and don't care about old games at all ...

馃檵when you plan to separate Moira into its own repo than you could include/reference it in vAmiga via the git built in submodules feature ...

I think it is due to Moira

Yet, Moira ignores completely if the bus is free. She just runs. Therefore, it only makes sense to run vAmiga in Blitter level 0 at the moment if Moira is used (Fast Blitter). My plan is to proceed as follows:

  • Clean up Moira, setup a repo
  • Remove Musashi from vAmiga
  • Implement bus access from scratch, clean and solid

via the git built in submodules feature

馃 Do you know how to set this up in Xcode?

The idea of these git submodule thing is like a package manager. That is first you tell your project which package (e.g. submodule) it depends on. You do it with "git submodule add". Later when you freshly clone your vAmiga somewhere, it knows the dependency and you just get those needed 'packages' (in git language 'submodules') with the "git submodule init" and "git submodule update" command. Or you can have that with a single command only, when you type "git clone --recursive https://github.com/dirkwhoffmann/vAmiga.git", it then clones vAmiga and all the submodules.

basicly you have to add Moira into vAmiga which resides in its own Repo only once on cmd line with the following (to tell git about the dependency)...

git submodule add https://github.com/dirkwhoffmann/Moira.git Amiga/Computer/Moira

git then clones Moira into the dir "Amiga/Computer/Moira", it also creates a ".gitmodules" file in root of vAmiga where it describes the meta information of the submodule...

you can also let it stick to a certain branch with
git submodule add -b tags/v0.49 https://github.com/dirkwhoffmann/Moira.git Amiga/Computer/Moira

I am not sure wether XCode supports the "git submodule" feature per its GUI. But on command line it works fine. There is a blog of ray wenderlich (https://www.raywenderlich.com/690-dependency-management-using-git-submodules) which describes how to deal with XCode. I have not read it, but I read some other tutorials of him which in general where great. There are tons of other tutorials about this out there...

On the other hand, 馃maybe it is wise to save the separation of Moira and vAmiga for a later time?! Because I think the separation of the codebase into separate repositories really pays of when

  1. there are at least two projects which depend on Moira (currently only vAmiga)
    and
  2. when Moira is more or less stable (e.g. expected coding frequency on the submodule is relatively low)

Unless you have fun and don't care about the overhead in investigating and organisation which comes with the separation at the current state of Moira, it could be a wise step to still leave it maybe for some time in the vAmiga repository, no ?

How do you think about it ?

At the moment, Moira is kept in a private repo on Github. I need to have it in a separate repo, because of the "test runner" which is the testing framework that runs Moira against Musashi in an infinite loop.

I've also spend some thoughts on the git submodule approach. It's cool technology, but I think I can't use it in my case. The reason is that all vAmiga classes need to inherit from some special vAmiga base classes that provide an API for taking snapshots and for managing the lifecycle state of the component (powered on, powered on, running, paused etc.) As a consequence, I need to maintain two Moira versions in future:

  • A general version kept in a separate repo. This version includes the test runner as demo app and will come with a standard Makefile instead of an Xcode project file. This version of Moira will be compile on other architectures, too, such as Linux.
  • A tailored vAmiga version that supports the vAmiga snapshot API and the vAmiga lifecycle API.

The overhead of keeping the Moira core in sync between the (yet private) Moira repo and the vAmiga repo isn't that big. It just means to copy a few files from the core CPU code back and forth.

At the moment, I am working on porting breakpoint support from vAmiga back into Moira. I think it also makes sense to add watchpoint support (which means to halt the CPU when certain memory locations are accessed). In contrast to conditional breakpoints (which I never used), watchpoints could be really helpful in real-life debugging. E.g., it would be possible then to set a watchpoint on a certain OCS register which causes the CPU to halt the first time this register is accessed.

As a consequence, I need to maintain two Moira versions in future:

I like your two Moira versions approach. One can think of it as two different branches of the Moira project. And when you copy changes over to the other version this is like a git merge. We don't share the same git commit comments though, which is a slight disadvantage. But we don't have to tackle with the special command line git commands for submodules, slight advantage.

it would be possible then to set a watchpoint on a certain OCS register which causes the CPU to halt the first time this register is accessed

Cool feature 馃槑

The old breakpoint manager is history. Now breakpoints are supported natively by Moira as well as watchpoints 馃槑:

Bildschirmfoto 2020-01-09 um 14 54 54

BTW, did I talk about Moira's ultimate killer feature yet? Running the disassembler in upper case mode 馃槑. Impressive, isn't it? No? 馃槷

Bildschirmfoto 2020-01-09 um 15 03 57

Update: Replacing Musashi by Moira didn't fix this issue (but other stuff has improved a lot).

I think, it's not related to the CPU.

Fixed in v0.60

Bildschirmfoto 2020-02-19 um 16 26 48

Very cool stuff. OMG 馃槺 unbelievable... Just building the new master. What was it ? Was it a misbehaving CIA ? Hang on a second v0.6 launches just now ...

It plays very good now. I can spot nothing odd anymore. 馃憤馃徏 This vAmiga project has already become so accurate by now. It emulates all great games I know. Ok I don't know so many...

What was it ? Was it a misbehaving CIA ?

No, it was the POTGO register. I completely misunderstood how that register worked until I found the logic circuitry in the HRM:

8-6

In hardware it's really simple. Just a capacitor and a counter which is triggered by the hsync signal and guarded by a Schmitt trigger.

It's now emulated accurately.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

KenDFish picture KenDFish  路  3Comments

dirkwhoffmann picture dirkwhoffmann  路  3Comments

dirkwhoffmann picture dirkwhoffmann  路  4Comments

dirkwhoffmann picture dirkwhoffmann  路  4Comments

dirkwhoffmann picture dirkwhoffmann  路  3Comments