@zoltan45, it seems like Mame2003-plus is working 100%, hopefully this is all I really need to enjoy the games until a possible later Mame revision if someone chooses to work on it. Thanks for the information.
Mortal Kombat 2 Plus Beta 2 and Ultimate Mortal Kombat 3 Plus Beta 1 have been officially added to mame2003 and mame2003-plus. Update these emulators from source to play these along with many other enhancements made daily. Now bootstrapped to fix low volume and CMOS errors at boot.
Pretty cool. I just set these up with both MAME 2003 (as .7z) and FB-Neo (as .7z). Best of both worlds.
@F4CEpa1m looks good :) unfortunately retroarch haven't really defined the "official" arcade layout for their cores.
for mame2003 we used your layout
Y X L
B A R
but following a looong discussion with libretro devs, we decided that this layout was probably a better standard to reflect how "modern" (since the late 90s) fighting games have used fight sticks, etc.
Y X R1
B A R2
although really you need both layouts so that 6 button arcade setups can play 6 button consoles (SNES).
so the bottom line is, either layout should be an option in a established cores. i know they are in FBA/N... no idea about the various mame cores.
Does anyone have any idea why the mapping for the up motion on joystick would be different for player 1 than player 2? This problem only occurs on ultimate mortal kombat. I'm sure the joysticks are wired properly.
You don't really need a ton of custom video modes, since the resolution stays the same, and you only have seven or so different refresh rates at maximum to deal with. Two config lines like "lcd_native_res=1920x1080" and "lcd_range=50-60" or whatever the monitor supports would cover it.
on groovymame, sure, but raspberry pi only understands discreet videomodes. you have to tell it when you want to use a new videomode. in retropie, using the runcommand, you would have to add each videomode to the list, and when selected they would have to call the api command i linked above (since these aren't videomodes in the raspberry pi's limited list of videomodes)
I'm afraid that the whole 'snap to the closest available refresh rate once the native ROM refresh is detected' part is best handled by the emulator itself, as well.
agreed, but for that to happen someone woudl have to update CRT switchres (or something similar) in retroarch such that it can communicate with the pi's custom videocore API calls (see the link above).