New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

luaengine: expose device state entries #100

Merged
merged 3 commits into from Jan 11, 2015

Conversation

Projects
None yet
3 participants
@lucab
Contributor

lucab commented Jan 11, 2015

These commits expose device_state_entry to LUA, providing methods
to enumerate available states for a device object, as well as getting
and setting their values. Mostly usefull to inspect and manipulate registers content.

Signed-off-by: Luca Bruno lucab@debian.org

lucab added some commits Jan 11, 2015

luaengine: fix name/tag confusion
Don't mix names and tags when exposing devices to LUA.
While at it, also provide the shortname.

Signed-off-by: Luca Bruno <lucab@debian.org>
luaengine: luabridge Stack<UINT64> specialization
Provide a Stack<UINT64> specialization for luabridge, later
needed by some APIs.

Signed-off-by: Luca Bruno <lucab@debian.org>
luaengine: expose device state entries
This commit exposes device_state_entry to LUA, providing methods
to enumerate available states for a device object, as well as getting
and setting their values.
It is mostly usefull to inspect and manipulate registers content.

Signed-off-by: Luca Bruno <lucab@debian.org>

mmicko added a commit that referenced this pull request Jan 11, 2015

Merge pull request #100 from lucab/lucab/mame-lua/devstate
luaengine: expose device state entries

@mmicko mmicko merged commit bad1ab3 into mamedev:master Jan 11, 2015

@galibert

This comment has been minimized.

Member

galibert commented Jan 11, 2015

It's buggy though. You need to call the pre- methods before reading state,
and the post- methods after changing it.

OG.

On Sun, Jan 11, 2015 at 10:43 AM, Miodrag Milanović <
notifications@github.com> wrote:

Merged #100 #100.


Reply to this email directly or view it on GitHub
#100 (comment).

@lucab

This comment has been minimized.

Contributor

lucab commented Jan 11, 2015

@galibert sorry, I'm still getting used to mame core and may miss some details here and there. Thanks for patiently checking my PRs.

I have some doubts after your last comment:

  • Should I go up to device_t::pre_save/post_load (notify all interface?) or are device_state_interface::interface_pre_save/interface_post_load (notify state interface?) enough?
  • What's their relation with `device_state_entry::state_import/state_export``? Should I care here?
  • I don't see how to link a device_state_entry to its parent device_state_interface? Is there a way to retrieve it that I'm not seeing? If not, should I add an upward pointer in the child?
  • Should I also take care of these notification mechanisms when dealing with address_space memory I/O?
  • A posteriori, I suspect that friend-ing lua_engine to device_state_entry is a big no-no
@galibert

This comment has been minimized.

Member

galibert commented Jan 11, 2015

Don't worry, I don't understand all of it either. And I wrote the original
version of the save state subsystem :-)

For presave, you need to extract the pre-save part of
save_manager::write_file in its own method. I mean the "for
(state_callback *func = m_presave_list.first(); func != NULL; func =
func->next()) func->m_func();" part. Save for post_load, of course.

I'm in the process of adding the device to the state_entry structure, and
also making it public. It's essentially for the same use case as you,
except it's access from the debugger. So don't worry about the friend
thingy, it'll be fixable better later.

As for state_import/export it's used for the display and modification of
registers in the debugger, so no worry there.

Best,

OG.

On Sun, Jan 11, 2015 at 5:23 PM, Luca Bruno notifications@github.com
wrote:

@galibert https://github.com/galibert sorry, I'm still getting used to
mame core and may miss some details here and there. Thanks for patiently
checking my PRs.

I have some doubts after your last comment:

  • Should I go up to device_t::pre_save/post_load (notify all
    interface?) or are
    device_state_interface::interface_pre_save/interface_post_load (notify
    state interface?) enough?
  • What's their relation with
    device_state_entry::state_import/state_export`? Should I care here?
  • I don't see how to link a device_state_entry to its parent
    device_state_interface? Is there a way to retrieve it that I'm not
    seeing? If not, should I add an upward pointer in the child?
  • Should I also take care of these notification mechanisms when
    dealing with address_space memory I/O?
  • A posteriori, I suspect that friend-ing lua_engine to
    device_state_entry is a big no-no


Reply to this email directly or view it on GitHub
#100 (comment).

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment