mame2003-plus: hundreds of new games, improved input, features, new bugs - now with runahead support
-
aadding the lay format isint in the relm of realistic possibilities to add to our core. It would be easier adding a new core base than adding them changes
-
I agree it makes sense to define pre-LAY codebases as "the realm of possibility" here.
I want to spend some more time looking at AdvanceMAME because they use the same basic MAME artwork engine as 0.78 if I understand correctly.
-
I would just need more info to look into what they are trying to do blinking a few leds isint much info to go on.
-
there are a few drivers with set_led_status
-
i believe one of your artwork examples had leds mark just need to know what the user plans on doing with the data ect
-
@mark looks like code is alread in place for led_state_cb whatever that does
-
@grant2258 The idea is to capture the Mame outputs with a program/daemon like Rgbcommander (users.telenet.be/rgbcommander/) or Mamehooker (dragonking.arcadecontrols.com/static.php?page=aboutmamehooker), which will then act on external leds. For example, the buttons in my arcade stick have leds that are activated according to the actual buttons used by the game/system in use. This is done via Rgbcommander, which monitors the Retroarch core and game executed an has a database of the buttons (and colors) of the original arcade, which are then used to light only the buttons in use.
Rgbcommander is also able to capture de Mame outputs of the game in use and, for example blink the start button when introducing a coin or the coin button when no more coins remain.
The website of Rgbcommander provides some information on how the Mame outputs (in the standard Mame) works and in which versions have been implemented (see the Mame section)
-
@janderclander14 are there any libretro cores that currently work with rgb commander?
edit: I've looked over the site and the answer appears to be "no." The source is closed although the author pledges to open the next version.
The earliest version of mainline MAME that the author has tried is 0.169:
Linux : 0.? <-> 0.169 - Auto detection works fine. Rom dependant blinking LEDs are functional through old communication system.
I don't know for sure but I think that even the "old communication system" is one generation after the code we have from MAME 0.78. If that's the case, it maybe RGB Commander could be made to interface with RetroArch's LED driver eventually assuming that MAME 2003-Plus is able to send data to RA. It would require the participation of the RGB author at that point.
-
MAME hooker (http://dragonking.arcadecontrols.com/static.php?page=aboutmamehooker) seems like a more likely initial target for this due to maturity, open source, and API than RGB Commander. Again this is purely speculative and would require someone to add support for MAME 2003-Plus to that tool if and when LED signaling is working within the core.
All that is to say that this is a little closer to being possible than I first guessed.
-
@markwkidd Thanks for having a look at it. The only thing I can add is that the author of RGBcommander has been quite reactive to requests via email and, so far, is the only software that works on retropie (Mamehooker is Windows only).
-
it isint a problem writing to the pi io in theroy ra has a driver for it. I checked mame thedata is coming through form the drivers that support it. We just need to decide what we want to do with it.
et_led_status num:0 status:0
set_led_status num:1 status:0
set_led_status num:0 status:0
set_led_status num:1 status:0
set_led_status num:0 status:0
set_led_status num:1 status:0
set_led_status num:0 status:4
set_led_status num:1 status:0
led display updated
set_led_status num:0 status:4
set_led_status num:1 status:0
set_led_status num:0 status:0
set_led_status num:1 status:0
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:0
set_led_status num:0 status:0
set_led_status num:1 status:2
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:0
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:2
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:0
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:2
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:0
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:2
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:0
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:2
led display updated
set_led_status num:0 status:0
set_led_status num:1 status:0
led display updatedect
The problem is we need a system wide solution for RA.Writing to the pie gpio ports is very doable by the looks of things what system will you be using?
-
@grant2258 I think it would be better to mimic the general behavior of the mame outputs as in the standard Mame, so that other apps more focused on managing leds/outputs (such as Rgbcommander) can use these outputs. Otherwise lr-mame will be cluttered with led-related options.
In fact, led management usually requires dedicated hardware (such as Ledwiz), due to the Pi's gpio is too limited in the number of leds that can be managed and the current it supports. Rgbcommader supports most of such hardware already so there is no need for Mame to do that, other than provide the outputs.
-
I really dont agree here windows users dont have that option and i have no idea what you mean why you say mimic mame078 just send pulses to numlock and caplock ect
-
here is the windows code for mame078 you want us to flash the numlock keys?
-
@grant2258 Sorry if I wasn't clear. Windows users already employ Mamehooker instead of Rgbcommander to catch Mame outputs and drive leds, counters, etc. Both Windows and linux standard Mames already provide these outputs (and the non-Retroarch linux version provides outputs on the Pi, which can be catched by Rgbcommander, but runs too slow).
The request was whether the Mame output system (as implemented in the standard Mame until version 169) could be ported to the Retroarch core. The link to the Rgbcommander site I included above explains a little how the outputs work through the different Mame versions.
-
ok do me a favor test mame standard 078 see if it hooks the output from what i see in the standard code youll get 3 leds only in mame078
-
@grant2258 I had a look at it and it seems the standard Mame 0.78 doesn't implement the output system, just the keyboard leds. According to Aaron Giles, the output system was introduced in version 107u4 (August 2006). The following link explains how the outputs work.
https://aarongiles.com/old/?p=181
It seems that the ouput system seamlessly redirects keyboard leds and backdrop lights, which have been supported in much earlier versions of Mame, so that third party softwares can use them to light external leds. Obviouly, more complex outputs (like force feedback effects in racing games) are only available in versions after 2006 and newer drivers. The following posts by the developer of Mamehooker provide some info on this:
http://forum.arcadecontrols.com/index.php/topic,100880.msg1066814.html#msg1066814
forum.arcadecontrols.com/index.php/topic,101789.0/all.html
I don't know whether it could be feasible to backport the mame output system from v107u4 to lr-mame so that at least keyboard leds and backdrop lights are offered as outputs. More complex outputs would likely be unfeasible, because they would imply backporting much newer (and less efficient) drivers.
-
backdrop leds already work and the flashing numlock ect is easy enough to add back. To me a flashing numlock and capslock doesnt mean a lot. I there any reason you want random numnlock ect flashing?i would probably vary from game to game but it wouldnt be a big deal to add outputs that arent there to a drivers in some cases. I just dont see how a random blinking led tells you anything.
RA has a led driver for raspberry pi io and and overlay. you just want random things to blink ?
-
im guess what im trying to say is what function do you personally want these led functions to do for you.
If i had some kind of idea of what the end result would do for you and why that would go a long way into understanding what you want to do. Is it just lighting up joystick buttons or something else?
Ra can do things already with the outputs if they are there like in outrun if you crash you could make the joypad rumble to emulate the steering wheel shaking ect. Im sure we can work something out if its to lightup joystick leds
-
@grant2258 Assuming buttons have leds, a basic use would be to blink the start button after inserting a coin or the coin button when no credits have been inserted. In specific games, leds can have specific meanings (as in the original cabinet) such as the braking light in Outrun or the police lights in Chase hq. These can be mapped to unused buttons or to leds in the cabinet marquee. The thing is that these outputs are already there for many mame drivers and led management can be handled by programs such as Rgbcommander (for linux) or Mamehooker (for Windows). What these programs need is to hook to the Mame outputs in other to know when the leds should be lightened when the game runs. Because this infraestructure relies on the standard Mame output protocol, if this protocol can be reproduced in lr-mame, then they will work without having to adapt drivers or to introduce specific code in lr-mame to manage leds. If not, then I think developing an ad hoc system that lights keyboard leds or outputs the gpio will be of no interest, because it is not standard and output management programs will not work.
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.