@ShmashBroJoe with N64 the "A" is the normal spot for the "B" , which is the south of the controller. The "B" is the normal spot for the "Y" which is the west of the controller. It is set up the same directions as the original N64
The filename's extension is important since this is how udev recognizes it as a configuration file. The name itself doesn't matter, as long as it's in the right folder and having the correct extension.
What error are you getting when you're trying to create the file ?
Also, they seem to be written primarily for the "mupen64plus" core - which as of the most recent time that I updated my pi4 is no longer available, having been replaced by the "lr-mupen64plus" and "lr-mupen64plus-next" cores.
lr-mupen64plus is the mupen64pus core (now superseded by lr-mupen64plus-next, I think you're confusing it with standalone emulator (which is named mupen64plus).
Multiple google searches have actually yielded a truly distressing lack of documentation. I haven't found anything remotely resembling a set of useful instructions. Does anyone know how you're supposed to get Hi-Res Texture Packs working now?
It's working okay now all things considered. I'm surprised at how well the scaling works as on the raspbian + retropie the text is harder to see and the borders are a bit off even in the terminal. I should try to copy retropie's font to my other sd cards with raspbian + retropie on them to make the console more visible
Glad you got it sorted out, actually RetroPie is using Raspbian (RPI OS) Lite underneath, so there's no specific font that's included in RetroPie.
Maybe the borders' position have something to do with the Overscan settings for the display ? Or you may try to increase the font size from the Setup script, as explained here ?
I have my Pi 4 (which is great), but I also have an older Pi 3B+ where the microSD became corrupted and I finally got around to putting in a fresh one. I grabbed the download from the retropie website, put it on a new card, etc. But, I noticed two things: 1) that mupen64plus (not lr-mupen64plus, and not lr-mupen64plus-next which wasn't installed by default) is the default for N64; and 2) that updates were available for mupen64plus. The stock build seems to have mupen64plus current as of Oct 2020, if I recall correctly. Normally I would update a package reflexively, but I also remember concerns about regressions with an N64 update from around last year. So, my questions, specifically for a Pi 3B+:
Should mupen64plus stay as default?
yes. standalone is fastest and most compatible. lr-mupen64plus (NOT -next) or mupen64plus-gles2n64 or even lr-mupen64plus-parallel may be faster in some scenarios, but the best balance is mupen64plus-auto (which i believe is the default for pi3), which selects the appropriate video plugin for mupen64plus-standalone, per game.
Is there any potential downside to installing the latest updates (since the most recent stock install) to these emulators on a 3B+?
not that i'm aware of, but as always, always back up before any updates. do note that n64 emulation is probably only going to get slower with updates, as emulation gets more accurate, compatible, etc.
If you don't have a 'retropad A' button defined, of course it's not going to work in the menu . My remark was:
How the button is mapped to the underlying core doesn't matter for the menu (RGUI or otherwise).
I agree, but the reason that I don't have a retropad A button defined is because the core doesn't use it for it's logical function in the mapping. I could have had both [N64 "A" and RGUI "A"] if the core used different bindings.
Obviously this is a minority problem for people trying to use pads without the full set of retroarch inputs, and I can still navigate the RGUI using a keyboard in my case :)
Well, you guys are awesome. Once I figured out where to change input settings in Retroarch..and then how to save my configuration...I got it working. The mappings for the left analog stick were blank, somehow. Note: I edited the main RetroArch config, and not Core configs. Both were blank, but I wanted it to correct every N64 rom.
I assume that means the Dpad was working, and it just wasn't being needed by Mario64, which I was testing on.
The mappings for N64 are described in the emulators doc page - https://retropie.org.uk/docs/Nintendo-64/. If you wish to change it, you can either use RetroArch's input remapping for the lr-mupen64/lr-mupen64-next emulators or editing the InputAutoCfg.ini for the standalone mupen64plus emulator.