Pi4 MAME2010 crashing on Tab menu > Inputs
-
Interesting - you get this log when accessing the tab menu?
The offending line is
tag = owner->subtag(tempstring, TOKEN_GET_STRING(tokens));
and seems to be that the object
owner
is null. But that object reads as a member of thegame _driver
object. Does that also happen for other games?Regardless of whether it happens when you open the menu, maybe that is the root cause of this crash down the line.
By the way, Chase HQ - one of my favorites since the ZX Spectrum.
-
well with asan the emulation doesnt start it drops out happens during the initial executeGame(char*) src/osd/retro/retromain.c:1470 happend during the parsing of the command line might be worth checking that string thats sending. Keep in mind this is the effect not necessarily the cause.
-
ok well there was two issues going on here my plus zips where corrupted on my ole hard drive so go them fixed need to look into it not handling zip failures so well at some point. Took a while to trace it! He is the info you will need this is for input this game. it still runs on linux btw but there is issues there.
c/emu/mconfig.c:128:61: runtime error: member call on null pointer of type 'const struct device_config' pal16l8b-b52-124.ic180 NO GOOD DUMP KNOWN WARNING: the game might not run correctly. src/emu/memory.c:3154:127: runtime error: signed integer overflow: 2122219134 * 4096 cannot be represented in type 'int' src/emu/uimenu.c:1736:16: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ src/emu/uimenu.c:1737:20: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 40 1c 0f 00 40 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ src/emu/uimenu.c:1738:16: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 40 1c 0f 00 40 61 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ src/emu/uimenu.c:1739:19: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 40 1c 0f 00 40 61 00 00 00 00 00 00 20 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1740:22: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 40 1c 0f 00 40 61 00 00 00 00 00 00 20 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1741:17: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 40 1c 0f 00 40 61 00 00 00 00 00 00 20 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1742:17: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 40 1c 0f 00 40 61 00 00 00 00 00 00 20 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1743:17: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 40 1c 0f 00 40 61 00 00 00 00 00 00 20 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1747:16: runtime error: member access within misaligned address 0x63100395882d for type 'struct input_item_data', which requires 8 byte alignment 0x63100395882d: note: pointer points here 65 6e 75 00 00 00 00 00 00 00 00 00 40 1c 0f 00 40 61 00 00 00 00 00 00 20 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1913:43: runtime error: member access within misaligned address 0x631003958ddd for type 'struct input_item_data', which requires 8 byte alignment 0x631003958ddd: note: pointer points here 00 00 00 00 6d 8d 95 03 10 63 00 00 40 26 0d 00 40 61 00 00 00 00 00 00 4c 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1919:24: runtime error: store to misaligned address 0x631003958e4d for type 'struct input_item_data *', which requires 8 byte alignment 0x631003958e4d: note: pointer points here 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ^ src/emu/uimenu.c:1918:56: runtime error: member access within misaligned address 0x631003958ddd for type 'struct input_item_data', which requires 8 byte alignment 0x631003958ddd: note: pointer points here 00 00 00 00 6d 8d 95 03 10 63 00 00 40 26 0d 00 40 61 00 00 00 00 00 00 4c 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1884:7: runtime error: load of misaligned address 0x631003958e55 for type 'const struct input_item_data *', which requires 8 byte alignment 0x631003958e55: note: pointer points here 10 63 00 00 6d 8d 95 03 10 63 00 00 fd 8c 95 03 10 63 00 00 8d 8c 95 03 10 63 00 00 1d 8c 95 03 ^ src/emu/uimenu.c:1884:16: runtime error: member access within misaligned address 0x631003958d6d for type 'const struct input_item_data', which requires 8 byte alignment 0x631003958d6d: note: pointer points here 00 00 00 00 fd 8c 95 03 10 63 00 00 40 28 0d 00 40 61 00 00 00 00 00 00 4b 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1884:29: runtime error: load of misaligned address 0x631003958e5d for type 'const struct input_item_data *', which requires 8 byte alignment 0x631003958e5d: note: pointer points here 10 63 00 00 fd 8c 95 03 10 63 00 00 8d 8c 95 03 10 63 00 00 1d 8c 95 03 10 63 00 00 ad 8b 95 03 ^ src/emu/uimenu.c:1884:38: runtime error: member access within misaligned address 0x631003958cfd for type 'const struct input_item_data', which requires 8 byte alignment 0x631003958cfd: note: pointer points here 00 00 00 00 8d 8c 95 03 10 63 00 00 40 2a 0d 00 40 61 00 00 02 00 00 00 4b 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1886:7: runtime error: load of misaligned address 0x631003958e4d for type 'const struct input_item_data *', which requires 8 byte alignment 0x631003958e4d: note: pointer points here 00 00 00 00 dd 8d 95 03 10 63 00 00 6d 8d 95 03 10 63 00 00 fd 8c 95 03 10 63 00 00 8d 8c 95 03 ^ src/emu/uimenu.c:1886:16: runtime error: member access within misaligned address 0x631003958ddd for type 'const struct input_item_data', which requires 8 byte alignment 0x631003958ddd: note: pointer points here 00 00 00 00 6d 8d 95 03 10 63 00 00 40 26 0d 00 40 61 00 00 00 00 00 00 4c 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1886:29: runtime error: load of misaligned address 0x631003958e55 for type 'const struct input_item_data *', which requires 8 byte alignment 0x631003958e55: note: pointer points here 10 63 00 00 6d 8d 95 03 10 63 00 00 fd 8c 95 03 10 63 00 00 8d 8c 95 03 10 63 00 00 1d 8c 95 03 ^ src/emu/uimenu.c:1886:38: runtime error: member access within misaligned address 0x631003958d6d for type 'const struct input_item_data', which requires 8 byte alignment 0x631003958d6d: note: pointer points here 00 00 00 00 fd 8c 95 03 10 63 00 00 40 28 0d 00 40 61 00 00 00 00 00 00 4b 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1930:8: runtime error: load of misaligned address 0x631003958e4d for type 'struct input_item_data *', which requires 8 byte alignment 0x631003958e4d: note: pointer points here 00 00 00 00 cd 8a 95 03 10 63 00 00 2d 88 95 03 10 63 00 00 9d 88 95 03 10 63 00 00 0d 89 95 03 ^ src/emu/uimenu.c:1932:14: runtime error: member access within misaligned address 0x631003958acd for type 'struct input_item_data', which requires 8 byte alignment 0x631003958acd: note: pointer points here 00 00 00 00 5d 8a 95 03 10 63 00 00 40 0a 0f 00 40 61 00 00 00 00 00 00 1c 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1932:32: runtime error: member access within misaligned address 0x631003958acd for type 'struct input_item_data', which requires 8 byte alignment 0x631003958acd: note: pointer points here 00 00 00 00 5d 8a 95 03 10 63 00 00 40 0a 0f 00 40 61 00 00 00 00 00 00 1c 00 01 01 03 00 00 80 ^ src/emu/uimenu.c:1935:38: runtime error: member access within misaligned address 0x631003958acd for type 'struct input_item_data', which requires 8 byte alignment 0x631003958acd: note: pointer points here 00 00 00 00 5d 8a 95 03 10 63 00 00 40 0a 0f 00 40 61 00 00 00 00 00 00 1c 00 01 01 03 00 00 80 ^ src/emu/inputseq.c:416:88: runtime error: member access within misaligned address 0x631003958ae1 for type 'const struct input_seq', which requires 4 byte alignment 0x631003958ae1: note: pointer points here 00 00 00 00 1c 00 01 01 03 00 00 80 86 00 01 04 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ^ src/emu/inputseq.c:418:14: runtime error: member access within misaligned address 0x631003958ae1 for type 'const struct input_seq', which requires 4 byte alignment 0x631003958ae1: note: pointer points here 00 00 00 00 1c 00 01 01 03 00 00 80 86 00 01 04 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ^ src/emu/uimenu.c:1945:26: runtime error: member access within misaligned address 0x631003958acd for type 'struct input_item_data', which requires 8 byte alignment 0x631003958acd: note: pointer points here 00 00 00 00 5d 8a 95 03 10 63 00 00 40 0a 0f 00 40 61 00 00 00 00 00 00 1c 00 01 01 03 00 00 80 ^ src/emu/inputseq.h:171:25: runtime error: member access within misaligned address 0x631003958ae1 for type 'const struct input_seq', which requires 4 byte alignment 0x631003958ae1: note: pointer points here 00 00 00 00 1c 00 01 01 03 00 00 80 86 00 01 04 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ^ src/emu/inputseq.h:173:25: runtime error: member access within misaligned address 0x631003958ae1 for type 'const struct input_seq', which requires 4 byte alignment 0x631003958ae1: note: pointer points here 00 00 00 00 1c 00 01 01 03 00 00 80 86 00 01 04 00 00 00 80 00 00 00 00 00 00 00 00 00 00 00 00 ^ ^[[A^[[A^CAverage speed: 99.99% (25 seconds)
-
@grant2258 Thanks - that's quite a bit to digest. I'll try to look into it in the coming days and report back if I end up tracking anything down.
-
ok have a soluton for you that should work until you do any patch work you want to do.
add
#pragma pack(1)
to src/emu/uimenu.c after the includes your input settings should work again on the pi4
pi4 bin compiled for you to test.
wget https://github.com/grant2258/mame2010-libretro/blob/input/pi4_mame.zip?raw=true
please let me know if the pi 4 improves games much over the pi 3 would love to know this
-
@grant2258 Thanks for the binary - actually I just compiled it myself before the binary and it does work!
I am technically intrigued by the "why" of it - or even more, how you got to that solution - but the fact is that yes, it does solve the crash :) I take it it was a deduction based on the "member access within misaligned address" error messages and even "signed integer overflow: 2122219134 * 4096 cannot be represented in type 'int'" suggesting that there's some potentially less zealous pointer handling going on there or what? Just for my own education, really.
The improvement of the games is always a relative thing to do - I imagine you're asking about MAME2010 specifically. In my case, there were a few games I had been running the PSX versions for that right now I can run on MAME and that for the most part perform well - meaning, with minor frame drops, if any.
The key games, as you can infer from my command line, were CPZN1 and CPZN2 ones - specifically Street Fighter EX, Street Fighter EX2, Rival Schools and Strider 2. Strider 2 runs 100%, no frameskip. Same with the Street Fighters. Rival Schools runs slower - I believe it also uses a different resolution, and that's probably the case. This one with frameskip can hover around high-50s for the most part, but on very intense animations will drop to 40s which is underwhelming. I can also run Chaos Heat at 50-55fps with minor frameskip if needed (the game is not properly emulated though). Any game in specific you'd have in mind?
@dankcushions has been experimenting with the actual MAME emulator and his feedback is quite positive - seeming to suggest that the performance is "almost there", but he can elaborate on the tests and games he's been looking into more closely.
From my end, I'm fairly happy with the results so far - honestly, Dreamcast/NAOMI/Atomiswave emulation on the Pi4 is awesome and brings a whole set of arcade games to the Pi. Not only speed, but the actual rendering is improved - games that would render with obnoxious black areas or missing polygons are rendered properly on the Pi4. Flycast and Redream do a great job.
Saturn is a bit hit or miss - emulation is a bit preliminary so far, lr-yabasanshiro is a good start compared to the performance of lr-yabause but it's still on the 50fps range in many cases. We've failed to compile the actual non-libretro yabasanshiro core so far, but I'm hoping that when we get there we can perhaps get to Saturn running nicely on the Pi4.
PSP emulation (especially on PPSSPP, the non-LR core) works well as well, though it's not really my cup of tea for an arcade setup. I have an old PSP lying around for those games. Still, it's good to use it for OutRun Coast to Coast, as I don't imagine being able to play OutRun 2 on the Pi4 in any other way.
So yeah, I've been migrating my Pi3B setup to the Pi4 now that the RetroPie team has done a tremendous job in getting it in a solid state for it - even with the current caveats of in-progress drivers, and some emulators having some quirks.
I don't quite yet know how to dive into this, but I'll take a peek during the coming days and see if anything strikes me as obviously suspicious - my development setup is purely Sublime Text editor, SSH, and testing on the Pi these days as I haven't done any serious development for over a decade. :)
Thanks so much!
-
you dont have to worry about all these errors sometimes emulators to thing intentionally that will flag errors. As for the structure pack it just takes any extra padding away the compiler might add. Some platforms are more forgiving that others when it comes to things like this. I only thinking mame the the gpu wont really come into it. Im mostly play 80s and 90s games i would imagine most of them will run fine. Ill tidy some things up at somepoint to add the mapping back in.
-
@grant2258
I am having great success with mame 2010 on pi4 but also have the problem if I goto mame menu input general, user interface it crashes back to es.I'm not sure how to fix from your post above can you please give more detail.
All I want to do is change the tab menu which is currently set to right thumbstick
To pressing both left and right thumbstick
To prevent accidental menu accessI'm using from binary install
Thanks
Sim -
Im actually in the process of updating a few things for the input so all buttons are map-able and work like they should just bear with me until i finish up and ill post instructions how to compile it. The input system as is lacking in a very bad way.
-
@Simrose different problem specifically - to prevent that from happening, go to the RetroArch menu, Controls menu, Player 1 and change the assignment from R3 to "Enter UI Menu" or something.
If you'd want to fix it, you'd need to compile from source, and between checking the code out and compiling it you'd need to edit the
src/emu/uimenu.c
so that after the includes you'd include#pragma pack(1)
.Alternatively you can overwrite your MAME binary with the one @grant2258 provided:
wget https://github.com/grant2258/mame2010-libretro/blob/input/pi4_mame.zip?raw=true
Download it and overwrite the file on
/opt/retropie/libretrocores/lr-mame2010
if I recall correctly. -
@grant2258 One remark for a conversation we had earlier in the thread:
@grant2258 said in Pi4 MAME2010 crashing on Tab menu > Inputs:
In plain english you would need to set up down left right to dpad even in current mame.
I'm not sure that is true, at least with the emulators that get installed by default (and perhaps - or in spite of - inputs being somewhat broken) the up/down/left/right are mapped to P1/P2 JOY UP/DOWN/LEFT/RIGHT, which end up being mapped by default to the RetroPie buttons as well. Once again, not sure if because - or in spite - of the inputs being broken. LR-MAME 2003, 2010, 2015, 2016 work out of the box as far as I remember.
The fact that we now change the inputs to P1/P2 JOY HAT UP/DOWN/LEFT/RIGHT makes it so that they are not recognized by default. That's the main change that I wanted to highlight that may or may not be useful for the code you're looking at right now.
Thanks!
-
@pjft load mame current stand alone you can see you have to map the digital hat as per default. I can look into adding it to input defautls like i did with mame2003-plus at some point. The truth is the core lacked any analog controls at all for mame so only digital was used.
-
@grant2258 true for standalone, correct. I was referring to the libretro cores, that was my remark. And you're right, there was no analog support.
-
ill try come up with something suitable my good man as i use a barcade myself so i will get round to it just want to hook everything up first. Most libretro cores dont support analog at all.
-
@grant2258 no issues whatsoever - just sharing that note as it could be helpful:)
Best of luck with the barcade setup!
-
I wont be using this on a pi 3 to be honest just want to get it usable fror a pi4 if people want to use it.
Ok the updating is done there is one fix in here for the pi 4. Its a one line paragma and the rest of the updates are for the input that never worked right so it applies to all platforms. I only updated this because there might be a need for it to be usable.
There is a core option to enable auto mapping this will set selected games to automap its off by default you need to restart the core when you enable/disable this setting.
how to compile for pi4
git clone https://github.com/grant2258/mame2010-libretro.git git checkout input make platform=rpi4 -j8 sudo cp mame2010_libretro.so /opt/retropie/libretrocores/lr-mame2010/
you can also patch the official repo with this
wget https://github.com/grant2258/mame2010-libretro/commit/eb1d80d0625c5ecd493c9e001a5e9f3a1fd8ec18.diff git apply eb1d80d0625c5ecd493c9e001a5e9f3a1fd8ec18.diff
@pjft let me know if you find any issues i will look out for sensible way to add the digital hats at some point!
-
@grant2258 Oh my, I did not get notified of these changes/edits to your post, so only now did I come back to update this.
I ended up digging into the actual issue there - thank to yours and @mitu's guidance - and came up with a smaller fix for the crash on the Pi4, on the actual
struct
that was causing the problems. There might be more memory leaks or wrong accesses, but at least from what I tested nothing is crashing for the moment.https://github.com/pjft/mame2010-libretro/commit/5b689b6351b602102967dd953237fb85fbb59244
I am just running a final test on compiling from scratch and then if it works well I'll submit it upstream.
I'll test out your patch tomorrow or weekend the latest, for sure.
For the actual compilation scripts, I'd love to get other (definitely more knowledgeable) people's inputs on those -- @mitu being clearly one of them. :)
Thanks for these - they'll make the lr-mame2010 experience a lot better for 2 player games and for customizing the inputs!
-
the only fix needed for the pi4 crash is #pragma i sent you. The rest of the updates is fixing the input thats badly broke and not finished
-
@grant2258 Correct - I ended up just narrowing it down to what was the exact struct that was being accessed incorrectly, and apply the __packed qualifier to it only, in case the repository maintainers would object to applying it to the entire file for some reason.
Thanks for putting these together!
-
I have one more check on the code and noticed a little boo boo the latest updates will be in the input branch if you want them it works like it should now. If you find any issues let me know. Ill check the code over in the next few days and play some games. I dont think there is any maintainers. The defaults are stored in src/emu/inpttype.h if you want to have a look at changing them. In my experience this is the hardest part to deal with there is always going to be someone that doesnt like your changes.
Ive looked at this there is two ways to do the dpad you can set it up as a button and map it in the .h file you would for digital you would need to map the dpad to all alalog controls dial,xaxis,yaxis,paddle ect. This basically means you would loose the extra buttons on the dpad because they are already mapped and you really need it for games like hard driving ect.
I think a better way of doing this would be use of a controller file if the code for that hasnt been ripped out it wil basically do the same as above but you could have a core option to enable it or not of course a restart would be required.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.