@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

@quicksilver thanks. Looks like it's relatively recent and has got some attention, I guess that's promising in terms of it getting fixed soon.

@k-bit said in Raphnet Dual N64 usb adapter with RetriPie:

I tried to create the udev role, but that didn't worked for me and i actually dont know why it has to be this specific file name for the rules.

Please add some info about your setup, as detailed in https://retropie.org.uk/forum/topic/3/read-this-first.

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 ?

@ringus please provide some info about your setup, as asked in https://retropie.org.uk/forum/topic/3/read-this-first.

@Markeno you too, provide the same info in a new topic, please.

@hawkes_84 thanks man

@retropieuser555

I would love to, but, I can't seem to get the save file to work between mupen64plus and lr-mupen.

Lr-mupen saves data as a .SRA file, mupen64plus saves it as .SRM . I have been unable to convert the srm to sra.

Any ideas on how to accomplish this? I've tried pj64tosrm and other utilities, carefully checked the directories and names, etc.

@ancapgamer said in How do N64 Hi-Res Textures work now?:

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?

Standalone instructions https://github.com/mupen64plus/mupen64plus-video-rice or the docs page, libretro core(s) https://docs.libretro.com/library/mupen64plus/#hires-textures. The N64 opt page (here) has even a video linked with instructions for standalone Mupen64Plus (not the libretro core).

I agree that documentation could be more explicit, but should get you started. Maybe give more details on what have you tried so far and it's not working?

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 ?

@mitu
Thank you!
I don't know why it was Glcore. I changed it to Gl as you suggested and the shaders are now enabled!
Thanks so much for the help!

@unknown nah the memory is emulated, don't think a proper emulator could read the data from a real memory card; that would be cool though.

@stevenrice please fill out https://retropie.org.uk/forum/topic/3/read-this-first

but again note that it doesn't support .zip files. the behaviour that you're seeing can be caused by incompatible file types. if you're using .zip, extract the files.

@breadpie said in N64 on a Pi 3B+:

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.

@alinktotao said in Anyone know how to set up N64 raphnet adapter with the "raphnetraw plugin" on RetroPie??:

@mitu said in Anyone know how to set up N64 raphnet adapter with the "raphnetraw plugin" on RetroPie??:

Looks like the input plugin is detected and loaded, but the plugin errors out while opening the controller:

... Opening device path: '/dev/hidraw2' Input Error: Could not open gcn64 device serial '109634'. Skipping it. Input Error: No adapters detected

Maybe there's a permission error ? Check if the /dev/hidraw* devices are available to the pi user, by running the command:

ls -l /dev/hidraw*

pi@retropie:~ $ ls -l /dev/hidraw*
crw------- 1 root root 244, 0 Aug 7 18:58 /dev/hidraw0
crw------- 1 root root 244, 1 Aug 7 18:58 /dev/hidraw1
crw------- 1 root root 244, 2 Aug 7 18:58 /dev/hidraw2
crw------- 1 root root 244, 3 Aug 7 18:56 /dev/hidraw3
crw------- 1 root root 244, 4 Aug 7 18:56 /dev/hidraw4
crw------- 1 root root 244, 5 Aug 7 18:56 /dev/hidraw5
crw------- 1 root root 244, 6 Aug 7 18:56 /dev/hidraw6
crw------- 1 root root 244, 7 Aug 7 18:56 /dev/hidraw7

OH MY GOOODNESS!! THAT DID IT! THANK YOU SOOOO MUCH!!!

@mitu said in N64 Controller Setup - Inconsistent Documentation:

@busywait said in N64 Controller Setup - Inconsistent Documentation:

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 :)

Could find the solution on my own.

The correct syntax is J0B4/H0VX
where the "X" is set to be 1(up) 2(right) 4(down) or 8(left) depending on the direction.

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.

@omission229 No, sorry, otherwise I would have said so.