And then:
These are from the instructions I linked above. There are more descriptive instruction there.
Was the linked post not working/not viewable? Or perhaps are those instructions not clear? Let me know and I’ll do my best to make it work for you. 
Haha this is not letting me post, saying the body is too similar to what I already posted. So I guess, try reading what I posted again. I’m just adding this last paragraph to make it “different.”
Version 1.25
Ok, I did everything and it doesn’t work. I have Mupen in the menu with “Super Mario 64 (U) [!].n64”
I downloaded they files to it and placed everything in the right place.
There’s a mupen file in Home/cpi , it has a zip and source in it.
I have the mupen config in Home/cpi/.config
I have it’s action.config in Menu.
Mupen64plus in home/cpi/apps/emulators
What am I doing wrong or missing?
Thanks
Aha good! Sounds like you’re making progress.
Did you manage to change the permissions, and run that script? It will take a very VERY long time. Like half an hour maybe?
Ah unfortunately, the version number of the launcher hasn’t been updated or changed in a long time. Even if you do update it via the launcher’s settings menu, the launcher version doesn’t change. It’s kind of useless right now, unless you’re using my custom image, which does contain the build number.
What would be the most useful to know is what the kernel version is. That should be enough information to go by in order to tell you of mupen64plus will be able to run well. You should be able to find it on the same screen that you saw the version number. Either that or potentially the OS IMAGE version could be useful, although I haven’t really paid much attention in the past.
Im not sure which file you’re talking about re: the mupen Zip file, but you won’t need that. A lot of the time, we can get precompiled binaries, and just run them from wherever. This isn’t the case with mupen64plus. You need dependencies.
Are you talking about the mupen.sh file that I linked? That’s the one that you put in ‘/home/cpi/‘ and what you need to run in order to install the dependencies. It also installs the mupen binaries to ‘/usr/local/binaries/‘ which is reportedly makes it run faster for some games.
There is one that the Gameshell automatically tries to install to ‘/home/apps/emulators/‘
This is the one that downloads when you put a rom into the ‘/home/cpi/games/n64/‘ directory and try to run it. It downloads a zip file and then decompressed it, leaving the zip file behind.
This is determined by the action.config file. It also tries to reference the mupen64plus file in the ‘/home/apps/emulators/‘ directory.
We aren’t using that one anymore, if you want it to run well, so we should should delete both the mupen64plus binary in the ‘/home/apps/emulators/‘ , the zip file that you mentioned, and overwrite the old action.config file with the one provided. In fact, you shouldn’t even need the mupen64plus binary that I have provided, since it’s now installed to ‘/usr/local/bin/‘, just like Retroarch.
I think you have the action.config file sorted, if you have overwritten the existing one with mine.
Very close! This config file will need to be placed in ‘/home/cpi/.config/mupen64plus/‘ making a note of capitalisation.
I probably could write up an entire script to automate the entire process. In fact I was going to once upon a time, but ended up just making up an entire custom OS with it pre-installed. I guess the problem was, I was having so much difficulty trying to convey how to get mupen64plus set up with a couple of users in particular, that I just gave up on trying to make a mupen specific script.
Let me know if you would like me to, and I can give it a bash.
Ah, sorry I just gave a generic location for it. I’m just saying it from memory. It may have been in /usr/local/games/, or /usr/bin/. Although looking at your screen shots, you’re still searching within the /home/ directory. Either way, it should have been defined in the action.config. I’ll double check it. I might not have updated it to reflect what I updated in my custom image.
Edit! Ah! I just reread my last replay! Ha I accidentally said “binaries” instead of “bin” when saying the location!! Haha, saying literally what the word stands for instead of the abbreviation. So sorry! This is the difference between things working and getting confused. My belated apologies!
ROM=/home/cpi/games/mupen64
ROM_SO=/home/cpi/apps/emulators/mupen64plus --plugindir /usr/local/lib/mupen64plus/ --gfx mupen64plus-video-rice.so --fullscreen
EXT=z64,n64,zip,7z,v64
LAUNCHER=mupen64plus --gfx mupen64plus-video-rice.so --fullscreen
TITLE=mupen64 Roms
SO_URL=https://raw.githubusercontent.com/cuu/emulators/master/mupen64plus.zip
Aha that action.config I provided was assuming that we were running the mupen64plus binary from ‘/home/cpi/apps/emulators/‘
I’ve optimised it since, seeing as the script installs it to ‘/usr/local/bin/‘ which I have confirmed to be the actual location.
I’ve cleaned it up here, getting rid of redundant fields.
Replace the contents with this.
ROM=/home/cpi/games/mupen64
ROM_SO=
EXT=z64,n64,zip,7z,v64
LAUNCHER=mupen64plus --fullscreen
TITLE=mupen64 Roms
SO_URL=The old code was using the pre compiled binary I linked initially. You don’t need it anymore.
I’ll look into it more when I get home from work.
Nothing changed sadly, It loads goes black and then back to the menu.
I’m posting the location of all the files.
Thank you
This is extremely helpful, and possibly the easiest I have ever had to deal with solving this problem!
Thanks for the screen captures. Everything seems to be in order.
Could you confirm which Kernel you’re using?
For now, try and run it via SSH.
(rename your rom to Mario64.n64, just so we don’t have to worry about dealing with parenthesis and spaces)
export DISPLAY=:0
mupen64plus /home/cpi/games/mupen64/Mario.n64I’ll post up my most recent config file when I get home. I don’t think it’s changed for a while very much, but just to be sure, we’ll check everything.
If that works, try and run it again via the gameshell, let it do its thing where it goes black and puts you back to the launcher, then run this, and copy the log printout.
cat /tmp/x.logAnother thought. The rom could be corrupt or a bad dump. I doubt this is the case, but try another just in case. It sounds like you are fairly competent re: how to use a computer so I assume that you’ve already tried restarting the gameshell after running the above scripts.
This is what I got when I put the command in.
cpi@clockworkpi:~$ mupen64plus /home/cpi/games/mupen64/Mario64.n64
| / |_ _ _ __ ___ _ __ / /_ | || | | _ | |_ _ ___
| |/| | | | | '_ \ / _ \ '_ | '_ | || || |) | | | | / |
| | | | || | |) | / | | | (_) | | __/| | || __
|| ||_,| ./ _|| ||_/ || || ||_,|_/
|| https://mupen64plus.org/
Mupen64Plus Console User-Interface Version 2.5.9
UI-Console: attached to core library ‘Mupen64Plus Core’ version 2.5.9
UI-Console: Includes support for Dynamic Recompiler.
Core: Using full mem base
Core: Goodname: Super Mario 64 (U) [o1]
Core: Name: SUPER MARIO 64
Core: MD5: AED29A731056F34B79E6B996BDBAFB63
Core: CRC: 635A2BFF 8B022326
Core: Imagetype: .z64 (native)
Core: Rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
Core: Version: 1444
Core: Manufacturer: Nintendo
Core: Country: USA
UI-Console Status: Cheat codes disabled.
UI-Console: using Video plugin: ‘Mupen64Plus OpenGL Video Plugin by Rice’ v2.5.9
UI-Console: using Audio plugin: ‘Mupen64Plus SDL Audio Plugin’ v2.5.9
UI-Console: using Input plugin: ‘Mupen64Plus SDL Input Plugin’ v2.5.9
UI-Console: using RSP plugin: ‘Hacktarux/Azimer High-Level Emulation RSP Plugin’ v2.5.9
Core: input plugin did not specify a render callback; there will be no on screen display by the input plugin.
Input: 0 SDL joysticks were found.
Input: N64 Controller #1: Using manual config with no SDL joystick (keyboard/mouse only)
Input: 1 controller(s) found, 1 plugged in and usable in the emulator
Input Warning: Couldn’t open rumble support for joystick #1
Input Warning: Couldn’t open rumble support for joystick #2
Input Warning: Couldn’t open rumble support for joystick #3
Input Warning: Couldn’t open rumble support for joystick #4
Input: Mupen64Plus SDL Input Plugin version 2.5.9 initialized.
RSP: RSP Fallback disabled !
Core: Using video capture backend: dummy
Core: Game controller 0 (Standard controller) has a Memory pak plugged in
Core: Game controller 1 (Standard controller) has a Memory pak plugged in
Core: Game controller 2 (Standard controller) has a Memory pak plugged in
Core: Game controller 3 (Standard controller) has a Memory pak plugged in
Core: Using CIC type X102
Video: Disabled SSE processing.
Video: Found ROM ‘SUPER MARIO 64’, CRC ff2b5a632623028b-45
Video: Initializing OpenGL Device Context.
Core Error: SDL video subsystem init failed: No available video device
Core Status: Rom closed.
cpi@clockworkpi:~$
And here’s the print out.
cpi@clockworkpi:~$ cat /tmp/x.log
X.Org X Server 1.19.2
Release Date: 2017-03-02
X Protocol Version 11, Revision 0
Build Operating System: Linux 4.9.0-8-armmp-lpae armv7l Debian
Current Operating System: Linux clockworkpi 5.2.0-rc4-clockworkpi-cpi3-00001-gac0d4e8 #1 SMP Mon Jun 17 18:02:55 CST 2019 armv7l
Kernel command line: console=ttyS0,115200n8 earlyprintk no_console_suspend root=/dev/mmcblk0p2 rootfstype=ext4 rootwait init=/sbin/init noinitrd panic=10
Build Date: 03 November 2018 05:53:43AM
xorg-server 2:1.19.2-1+deb9u5 (https://www.debian.org/support)
Current version of pixman: 0.34.0
Before reporting problems, check http://wiki.x.org
to make sure that you have the latest version.
Markers: (–) probed, (**) from config file, (==) default setting,
(++) from command line, (!!) notice, (II) informational,
(WW) warning, (EE) error, (NI) not implemented, (??) unknown.
(==) Log file: “/home/cpi/.local/share/xorg/Xorg.0.log”, Time: Tue Jun 30 02:18:22 2020
(==) Using system config directory “/usr/share/X11/xorg.conf.d”
/home/cpi/launcher/sys.py/gsnotify
— request header —
GET /jsonrpc HTTP/1.1
Upgrade: websocket
Connection: Upgrade
Host: localhost:6800
Origin: http://localhost:6800
Sec-WebSocket-Key: rNyXAUOCnQmQkDpH/ElG/g==
Sec-WebSocket-Version: 13
no skin config.ini file to read
no skin config.ini file to read
(‘CheckBluetooth:no bluetooth’, (0, ‘’))
state
dbus.UInt32(1L)
Trash:
[‘wireless’, ‘NETGEAR43’]
libpng warning: iCCP: known incorrect sRGB profile
1280
4
21
x11info: 12582919
| / |_ _ _ __ ___ _ __ / /_ | || | | _ | |_ _ ___
| |/| | | | | '_ \ / _ \ '_ | '_ | || || |) | | | | / |
| | | | || | |) | / | | | (_) | | __/| | || __
|| ||_,| ./ _|| ||_/ || || ||_,|_/
|| https://mupen64plus.org/
Mupen64Plus Console User-Interface Version 2.5.9
UI-Console: attached to core library ‘Mupen64Plus Core’ version 2.5.9
UI-Console: Includes support for Dynamic Recompiler.
Core: Using full mem base
Core: Goodname: Super Mario 64 (U) [o1]
Core: Name: SUPER MARIO 64
Core: MD5: AED29A731056F34B79E6B996BDBAFB63
Core: CRC: 635A2BFF 8B022326
Core: Imagetype: .z64 (native)
Core: Rom size: 33554432 bytes (or 32 Mb or 256 Megabits)
Core: Version: 1444
Core: Manufacturer: Nintendo
Core: Country: USA
UI-Console Status: Cheat codes disabled.
UI-Console: using Video plugin: ‘Mupen64Plus OpenGL Video Plugin by Rice’ v2.5.9
UI-Console: using Audio plugin: ‘Mupen64Plus SDL Audio Plugin’ v2.5.9
UI-Console: using Input plugin: ‘Mupen64Plus SDL Input Plugin’ v2.5.9
UI-Console: using RSP plugin: ‘Hacktarux/Azimer High-Level Emulation RSP Plugin’ v2.5.9
Core: input plugin did not specify a render callback; there will be no on screen display by the input plugin.
Input: 0 SDL joysticks were found.
Input: N64 Controller #1: Using manual config with no SDL joystick (keyboard/mouse only)
Input: 1 controller(s) found, 1 plugged in and usable in the emulator
Input Warning: Couldn’t open rumble support for joystick #1
Input Warning: Couldn’t open rumble support for joystick #2
Input Warning: Couldn’t open rumble support for joystick #3
Input Warning: Couldn’t open rumble support for joystick #4
Input: Mupen64Plus SDL Input Plugin version 2.5.9 initialized.
RSP: RSP Fallback disabled !
Core: Using video capture backend: dummy
Core: Game controller 0 (Standard controller) has a Memory pak plugged in
Core: Game controller 1 (Standard controller) has a Memory pak plugged in
Core: Game controller 2 (Standard controller) has a Memory pak plugged in
Core: Game controller 3 (Standard controller) has a Memory pak plugged in
Core: Using CIC type X102
Video: Disabled SSE processing.
Video: Found ROM ‘SUPER MARIO 64’, CRC ff2b5a632623028b-45
Video: Initializing OpenGL Device Context.
Core: Setting 32-bit video mode: 320x240
Core Error: SDL swap interval (VSync) set failed: That operation is not supported
Video Error: Failed to set 32-bit video mode: 320x240
Core Status: Rom closed.
no skin config.ini file to read
no skin config.ini file to read
wifi is connected
60
state
dbus.UInt32(2L)
Trash:
[‘192.168.1.14’, ‘NETGEAR43’, ‘60’, ‘3’, ‘21.6 Mb/s’]
libpng warning: iCCP: known incorrect sRGB profile
cpi@clockworkpi:~$
Thank for the screen caps. Any details on which version of the OS you’re using; as opposed to the launcher?
If you know the kernel as well, that would be even better.
Check to see if you’re using the Lima drivers as well.
Actually, just double checking. When you put in the command, did you first put in export DISPLAY=:0
That would possibly explain why there was no display detected.
Just for the sake of testing, make a new file with the name, “mario64.sh”, place it in ‘/home/cpi/Menu/‘ and put this into the file:
#!/bin/sh
mupen64plus /home/cpi/games/mupen64/Mario64.n64Then change the mode, giving the executable bit, the same way you did it to the mupen.sh script. Eg.
sudo chmod +x /home/cpi/Menu/mario64.shReload the launcher, and the new file should appear in your launcher’s root menu. Run it, and see what happens.
It does appear as though everything has been installed correctly.
Just for reference, here is my current mupen config file I am running on my gameshell.
Uh oh. I just noticed something. I see in the Linux version “5.2.0”
I have a suspicion that this might very well be your kernel version. In which case, you’re running clockwork OS 0.4 or earlier. Only after 0.5 was released earlier this year did the Lima drivers really start to be worth using and stable. This newer OS had the Linux kernel 5.3.6. Without at least version 0.5, even if you get mupen64plus working, there will be a lot of graphical artefact problems, speed issues, and it will generally not be a good experience. But do check in the about page, and confirm the clockwork OS version and kernel.
If you are running an older version of the OS, I strongly recommend you cut your losses, and just format your card with either the official 0.5 image, or one of the images I linked earlier. There is technically a 0.4 -> 0.5 update that you can use, however there have been many reports of it not working for some users. I worked for me when I tried it, so I don’t know if it is just a user error. Either way, you might end up having even more problems trying to trouble shoot the update process.
Fwiw, the Gameshell OS 0.4 came out July 2019. Any posts and information written prior to this would have been based on Gameshell OS 0.3. A lot of older things intended for the older OS will break the installation if you try to apply it to OS 0.4 or 0.5. Afaik, OS 0.4 is what comes with Gameshells by default. I don’t know the difference between 0.3 and 0.4, since I only got my gameshell around the time 0.4 came out.
Gameshell OS 0.5 came out December 2019. Thus came with an option to update OS 0.4 with an update script, however as mentioned above, had mixed results for some users. It’s basically the same as OS 0.4, with an updated kernel, graphic drivers and the introduction of the warehouse system. Most content on the forums written from July 2019 and onwards should be applicable to both version 0.4 and 0.5. It’s just a matter of stability and compatibility with certain graphic intensive applications that improves with 0.5. There is absolutely not reason not to upgrade to 0.5.
The option to update the gameshell via the launcher’s setting menu only updates the launcher, and not the entire OS. This is just doing a git pull and only will only update files within ‘/home/cpi/launcher/‘ and its subdirectories. So you can see how the contents of ‘/home/cpi/apps/‘ , ‘/home/cpi/.config/‘ or anything within ‘/usr/‘ would not get touched, hence why Mupen64plus and all of its dependencies won’t work without manually building the files yourself.
Ok, so I am on version 5.2.0 and Launcher 1.25 and OS Image v0.4.
You’re right, I am cutting my losses and installing your OS.
I installed your OS!
I didn’t get the post installation because everything was already in place.
Nes & Snes game has some sound crackling that didn’t go away until I enabled every overclock & gpu setting.
Mario64.n64 works, but Smash Bros 64 and Banjo 64 didn’t.
Also the roms I put into the MegaDrive don’t show up on the PicoDrive, where do I put them?
Overall it’s really good, but I’m frying an egg on my gameshell right now.
Never mind on Smash and Banjo, I just needed to extract them from 7z.
Oh, can you explain the controls and how to do save states.
Fixed Sega, it only takes .gen & .bin
Not .md
Don’t forget there’s an edit button 
Those instructions were more for people who wanted to restore their save rams, save states, and/or bios collections; specifically for PlayStation, as the location of these files has moved since 0.4, and isn’t well documented anywhere. Since the save state is tied to which bios you use for pcsx, it’s important to know where to put your bios as well. A lot of people put it in the wrong location in the past. Other things like mupen just put the save files into weird places.
This is something that happens with standalone emulators; namely PocketSNES and FCEUX. I want to remove them completely personally, but kept them to retain some kind of stock feel to the image. People might complain if I did. If you use the Retroarch cores instead, it doesn’t have the crackling and generally has less tearing in the graphics.
Smash bros runs, but not very well. Banjo Kazooie runs nicely, however banjo tooie has some slow downs. Glad you worked out you need to decompress the 7z file.
That would probably just be the demands of mupen64plus, and not to do with the image. In fact, just a stock image produces just as much heat. I haven’t seen anyone else do it yet, but I have personally had my rear cpi shell melted slightly, doing an extensive overnight compile. I reiterate, this was using the stock 1008MHz and 5.3.6 kernel. Entirely my fault, ie I had the unit in a small bag with no ventilation.
If anything, the 5.7.7 kernel with the 1200MHz governed clockspeed actually runs cooler, and thus uses less power and lasts longer. I made a shortcut to this combination called “Governed”. Note that it still does go up to 1400 if the demands get higher. This is the only combination that allowed suspend, and due to the way the governor changes the clockspeed/voltage depending on load, is the most energy efficient.
The 5.5.9 + 1400MHz has a shortcut called “Overclocked”, and maintains the 1400MHz Overclock/voltage. Use this to do things that don’t like being cpu throttles. Strangely however, some things like the gpsp standalone emulator seems to have strange stuttering using this combination; whereas the gpsp core in Retroarch runs perfectly fine. If you want gpsp standalone to work, switch to the shortcut called “Underclocked” to basically make things run as they would on a stock image, ie 5.3.6 + 1008MHz. From memory, both of these just remain at their specified clockspeeds.
The three named “shortcuts” I mentioned above are just combinations that I found myself switching to a lot. It’s to save you having to wait while each individual script runs to go to the same combination again and again. That said, mix and match as you see fit between the kernels and clockspeeds if something doesn’t work. Different game’s and emulators work differently, and have different requirements/demands.
To do a state save in my mupen config, you push shift and select. To load, push shift and start. To do turbo, hold menu. To exit, push shift and menu. This unfortunately also conflicts with volume down and up respectively. I didn’t see it as too much of a problem as I only use a single state save to basically resume where I was when I last played. I don’t use it for trying to save scum etc. Unfortunately there’s not enough buttons to cater for all of the N64 controller’s buttons, and change state save slots.
The controls, from memory are (assuming you have your gameshell assembled like a SNES)
Dpad=Analogue stick
Y=B
B=A
X=Z
A=R
Start=Start
Select=L
Menu=Turbo
Holding shift:
Y=C left
B=C down
X=C up
A=C right
(These correspond to the light keys)
Start=State load (and volume up)
Select=State save (and volume down)
Menu=Close mupen64plus
Note: I have configured it assuming that people don’t have a light bar attached. I personally don’t use it, not wanting to have extra bulk. It would be worthwhile editing the mupen64plus config to use a different binding if you did use the light bar. Kind of.
The way the C buttons work on the N64 to essentially be a camera control make having a NSEW cardinally orientated configuration ideal, and unfortunately the light bar shoulder buttons merely mirror these.
It’s probably worthwhile to flash the arduino to use the shift+L/R buttons as the standard registered input. I think I might have also registered the spare shift + L/L2/R/R2 buttons as some combination of the dpad buttons to complete the N64 controller inputs, but never use the Dpad anyway.
Potentially I could use the arduino mouse mod update to simulate more of an analogue stick movement. But realistically, using a Dpad as a mouse, which is then simulating a joystick is kind of counterintuitive. The only problems I have are with games that get you to try and draw a circle. It ends up looking like an etchasketch.
Alright, thank you very much for your help! 