@AlphaBetaPie I see no such message in genplus-gx code so i suppose those messages are handled by the frontend (retroarch). FWIW, Kronos and yabause are using the newer libretro api for disc control, while genplus-gx seems to still be using the older disc control api, if i had to guess the difference is probably related to that. Nothing i can do about. Are you sure your retroarch is up-to-date ?

Here are some NEC TurboExpress Bezels

TurboExpress (1).png

TurboExpress (2).png

TurboExpress (3).png

TurboExpress (4).png

TurboExpress (5).png

TurboExpress (6).png

@jdoc never mind. I just switched the USB ports and they work as expected now.

@dankcushions I provided the information of my raspberry unit to the best of my ability in the posts above.

I tried reinstalling. After reinstalling had to imput login information at the boot screen. Even after the update the ps1 emulator doss not respond to button presses.

@mitu ah yeah, my bad. Guess I'll have to wait for the next version for source to be 1.8.5, or I'll have to modify the setup script.

@dirkomatic said in Retroarch Config File for ROM Does Not Work:

I figured it out from the documentation on overrides and saving game specific overrides. Specifically, going into the Quick Menu->Overrides->Save Game Specific Override after making the correct setting change.

You added the edit before I saw the notification email and came here. I started re-reading the thread from scratch and, at first, didn't remember it, but then it started making sense to me. Yes, just what you said - the info was in the documentation, including in the link provided for help.

@mitu Never used Reset, at least that I know of. But thanks for that tip. I'll be sure to avoid it.

I don't think there's a RetroArch's option to fix what it looks like an overclocking issue - your overclock may not be stable.
Try removing your overclock and try one of the other N64 emulators - mupen64plus, the standalone N64 emulator, or lr-mupen64plus-nx , the newer version of the libretro N64 emulator core.

@mitu Ah well, thanks anyway - I posted it as an issue in github to see if the retroarch - developers can help
https://github.com/libretro/RetroArch/pull/10114

@mitu said in Are Multiple Mice Supported or Was That Feature Trashed?:

You can check by looking at the RetroArch's debug log and by running cat /proc/bus/input/devices.
Remembering your first RetroArch debug log, my guess is that RetroArch counts twice a mouse device as both /dev/input/mouseX and /dev/input/eventY. You can check this theory by adding a mouse (so you have 3 devices) and using indexes 0, 2 and 4 to see if each device is detected and working.

Okay. I can see that now, with access to the computer again. (Remember, it's in a different place than my desktop, that I use for posting.) Thanks!

Now I have the primary Mini PAC set in Keyboard Mode and I see that it recognizes the Mini PACs as devices, but also recognizes the devices on them separately. It looks like keyboard in the Mini PAC gets an event node. Interestingly, the Ultimarc SpinTrak (the spinner) gets Event 5, not 6. When I test with cat /dev/input/event6 I get input from the spinner and I don't with event5.

But this shows me that some of the devices are broken down into multiple devices and explains why something else is "in between" the trackball and the spinner.

As a side note, even though this is a built in function for RetroArch, I've now done what the manufacturer claims can't be done. Xtensions claims that, in D Input Mode, you can only have one mouse device, so you can have the trackball (somehow that always ends up as the one to take priority) but not the spinner in that mode. I'll be writing them about that!

When I have all my questions worked out, I'm going to either write up a few blog pages or make a few videos for others with the same issues. I'm hoping that they will use the so their other customers can get this working, too.

I'm using the following setup:

Raspberry Pi 3 Model B
RetroPI: 4.5.1
Retroarch: 1.7.6

@soge73

Thanks for posting - this helped me with lr-vice as well!

@rsn8887 we can't control were RetroPie users will open issues - they're welcomed to open them here and we'll help them as far as we can. As for releasing an image, that's a work in progress - but users can always update from their packages from an existing installation.

I made an ARM64 build of dosbox-core:

https://github.com/realnc/dosbox-core/releases/tag/latest_build_linux_arm

I don't actually know if it runs, since I don't have an ARM machine. In theory, it should run fine on RPi 4 since it's built on arm64v8 Ubuntu 16.04.

I've not tested on my odroid xu for some weeks. May be a recent change broke something. I'll check when I next get a chance.

May be a retroarch issue.. you could try rolling back the RetroPie-Setup script and building the previous version. I don't have time now however to give instructions to do this sorry.

I went through config files and even used the rp-dist in /opt/retropie/configs/mame-libretro to replace the modified one in the retroarch.cfg in that directory. Still no luck.

But I've come upon a frustrating issue that does not seem to fit in with the situation. It's so different from what I'm dealing with, I started a new thread and went into long and careful detail of what I did and what's going on. It's here.

@hawkes_84 No problem, glad you got it sorted. Yeah, a you can see there is no single best solution for ZX, but Retroarch offers lots of ways to deal with it. And you figured out why Q & W don't work, congrats, this has annoyed me to no end back in the day.

@Thorr69 Sure is Ir-Fba Alpha, Ir-Nestopia, Ir- Snes9x 2010

Thank you for the reply. Before I saw you replied I tried reinstalling the drivers using the method you so happened to post in the thread I linked at the top. That worked for me. I will say I installed drivers 340 instead of 440 so that could of been my issue.

For anyone that runs into this problem in the future here is a guide to install Nvidia drivers the way mitu recommended in this thread.