Tks for details, I mean the color of icon and text are not the same. But it is just my point of view, and I have zero exp in UI/UX 
Anyway, I can get used to it, as I donât stay at home menu for long, itâs very very minor
Again, thanks for your work, this build is so far so good. Iâll have my beloved Pokemon game backed up and play it to sleep 
Oh! I gotcha! I was having thoughts on that, re: text colour. Initially, if I kept it the same as the dark theme, the text would have been blue/green, and almost unreadable against the white. Thatâs why I changed it. Itâs particularly painful, when trying to navigate the menus in the settings, and file names etc.
Haha a random thought. Make a UI based on the Pokemon UI. Seems like a lot of people are using their Gameshells for Pokemon.
If itâs of any interest, I started some work on getting PokeMMO working on the Gameshell. I havenât looked at it in a while, but hey! If youâre interested, the instructions are there.
Or potentially harder
on windows, sure it will be !
release two version must not be really hard and could be automated, one with only os partition for update, other with full image
This would however fragment a lot of the tutorials reference things. Although just making everything use symbolic links would make most things work. However that would just be for things that I define in the image.
a good solution will be to set other partition as /home,
but menu is in /home and near all what is setup more are also in home folder,
in a way this is perfect, only update core os and let all user settings & additional binary in place
but if menu contain additional programs who are setup in the real classic way (/usr/bin /usr/local/bin âŚ) the menu will get fucked up entry
in this case not follow good method is a valuable point %)
also, with fstab (like for /boot), mounting /home could be automatic, just transparent for users and all existing tutorials
.
in arch i follow an only package way, letting all update to the classic system way, not needing new os release
got an only os partition release is more or less an in the middle solution
each modification you done you release a new revision, you made a fantastic work,
but users cannot follow you as fast, in fact they may reformat only if real issue is get out or if they fucked up their system,
also you provide as you can information to update without formatting but as release advance it cannot be followed step by step, for users and also for you
I fear I will need to be here forever
thatâs the point ^^
you made an awesome job but cannot be forever the full support
re standardising things that will be prevalent from now on.
So perhaps setting a new standard starts here with us, the users.
thatâs i was originally try to set up long time ago, full white page with community choice before all extend too much ^^
externalize data partition with fstab mount could be transparent, easy to setup without major changes, just create the 3rd partition, and tell extend script to work on this one instead
one issue would be it will limit in size the system partition, needing let sufficient free space into for the future
but yet, does the game is worth the candle ?
Hey I just updated D. E. O. T. And tried to play one of my roms but it isnât showing up I am not sure I put it in the right folder or not. However, I did read your post set up notes and checked the files for roms under the directory games and placed them in the appropriate folders (gbc With gbc etc.) But none show up did I skip a step or something?
Hey, which rom are you trying to play, and with which emulator?
If itâs not showing up, possibly it hasnât been sent properly. Have a look at this post. (Note itâs from the previous DEOT thread; donât get mixed up with info!
Each emulator has an action.config file that recognised a set of extension. To the best of my knowledge, Iâve added all of the missing extensions, along with .zip and .7z, frequently found in rom sets. I mainly use Nintendo emulators however, and am less familiar with say, Sega, lynx, colecovision etc. If the game youâre trying to run is in a format thatâs not listed, it wonât be detected.
Another thing. If youâve got your gameshell on, and transfer the files over, they wonât appear unless you go into the list and push the X button to refresh the list. Refreshing the launcher by running a program and then exiting can also work. That and restarting.
This image should run exactly the same as a stock 0.5 image, just with better support. Did the game you are trying to run work on a vanilla 0.5 image? If it did, then I am super curious to know which one it is youâre trying to run. My guess is that itâs in a compressed archive such as a .rar and isnât recognised. Either that, or the game could be corrupted.
See how you go! 
Partitions would definitely be the most logical approach, but I figure, if a user has trouble following the incremental steps Iâve written to perform small updates themselves, Iâm going to assume that they would find it even harder to follow instructions on writing an individual partition.
It would be a tech support nightmare, worse than the initial official 0.4 â 0.5 upgrade patch. It was an amazing concept in theory, just not the most âregularâ user friendly.
Youâve probably noticed that Iâm also primarily using the classic /usr/local/bin and /usr/bin file locations. Most of the config information ends up in ~/.config, which would no doubt need to reside on the system partition. This would make overwriting the partitions wipe any custom settings.
On top of that, most apps that are in ~/apps/emulators also store their config files, save states, screenshots and save files in this directory, and would also be in the system partition. Essentially, Iâd also need to make a custom script to back up all of these files, taking into account every file extension that could possibly exist, and then returning them to the correct place.
Just backing up the entire ~/apps/emulators directory would be an easy approach, however thatâs where the majority of my updates end up going. Essentially the process would involve a lot of user manual intervention, which would result in âregularâ users making mistakes - something Iâd need to personally spend even more time trying to answer people getting frustrated.
Itâs funny! I actually wanted to do this back in my DEOT v1+ image!
So youâre definitely right on the money for what I want. Itâs just a matter of delivering it in the easiest way for a non Linux user to be able to execute. I was going to go the two release path, ie one image with a partition and one without, but doing upkeep on that would be a lot of work. Itâs already enough using my current workflow setup.
Iâd need to multiply that by two, which is going to be a lot of work. Ideally it would be good to have a team who could work on things together. That would actually be an interesting proposition, although if that were to be a thing, it would probably be better to use an image such as your archlinux as a base and make it an entirely community driven collaboration from scratch.
As much as I would love to have it based on the official image, I simply donât know how to get in contact with the official devs who are in charge of official releases. Guu has been extremely helpful, but it does sound like he needs to answer to powers above him, following guidelines that they have in place.
Back on topic, another thought I had was to have ALL of the contents of non user contents tarballed up, and have users transfer a massive file over to their gameshell, and run a script to essentially manually replace the contents of ~/apps, ~/launcher and /usr. Theyâd lose the config files and customisation etc I mentioned above, but would keep all of the contents of ~/games and ~/music.
It would also take a ridiculously long time to do, and would be plagued with user errors breaking the system. The amount of trouble and time it takes would make if worthwhile to just have users backup their files. Unless theyâve got a Linux system, this takes an eternity over Ethernet or wifi.
Likewise if I have everything in a .deb file, I need to be able to trust that a user can follow instructions perfectly. Another thought I had was to simply make my own warehouse repository, with scripts people can run to incrementally build up their stock OS to include whatever features exist on the forum. Think a Debian/Ubuntu style GUI installer.
Iâll be honest. I get scared of commitment, and thrive on instant gratification of user happiness. I just feel that the amount of work to do any of this would be so much, for so little reward. I am 100% on board with what youâre saying and suggesting. I just donât want to be reinventing the wheel, and fragmenting the community more than it already is.
If anything, Iâm hoping this thread will bring people together, and get the attention of the official devs. If that means they release an official image with partition support, I would be on board. Of course if we do a good job of implementing it here, it could do exactly that, and they could use what we have done as a base. Eg, look at how Lima was fixed up in the DEOT v1 thread. My fear is that Iâd spend the time doing it, then officially they release something that effectively does the same thing, but does it using a different method/file structure.
Iâd also realty want to work with you, using your arch Linux OS as a base, and making it much more of a user friendly experience. It is so powerful and clean, that it would be easy to work with. The clockwork OS is kinda all over the place, almost held together with sticky tape. Itâs hard for users to know how to easily edit things.
So! In short. I want to have a separate data partition SO badly! But I have many fears.
being a kid of the 90âs its mostly GBC and GBA games i belive the eemulators are all there and updated but it doesnât see the files,i mainly used the mGBA or Gpsp to play gba roms.
Great. Can you tell me the exact name of the Roms, including the extension, exactly where youâre putting them, and exactly which emulator youâre using? Eg, mgba in my build is specifically there to play GB and GBC and doesnât search for GBA Roms. GPSP is what I have designated as the GBA player. Likewise, GPSP is not currently set up to to play GB/GBC.
Oh also. Try pushing left and/or right while in the menu. You may have navigates away from the main list to the favourites list, which if you just wrote your image, would currently be empty.
Okay so the directory is as followed /home/CPI/games/GBA
And letâs just take for example The legend of Zelda the minish Cap.zip when I unzip the file all it registers is GBA file under type even on name it doesnât classify the it as anything different
Okay! So is it specifically GBA or gba - capitalisation makes a difference! If itâs not lower case, it wonât even see it. Try changing it to zelda.gba instead of zelda.GBA. Iâll possibly update the file associations to include upper and lower cases of everything, if this continues to be a problem.
speaking of GBA, from yesterday, I had some (2 or 3 times) of random freezed then reboot when playing with RetroArch.
It happened on several ROMs, with both mGBA and gpSP core.
I donât remember exactly but I was not overclocking.
Now Iâm enabling logging for RetroArch to see if it happen again 
OH?? Which kernel were you using? Iâve pretty much switched to using 5.5.9, and have had smooth sailing. I used to have freezes on earlier kernels. But like we discovered earlier, some people have a screen flicker issue with anything other than stock 5.3.6.
On top of that, the 5.5.9 has also got a modification to allow you to push the power button to force a proper safe shut down, even when the system is unresponsive.
I use this a lot when troubleshooting. Saves having to hold the power for 10 seconds, and hope the system is being shut down properly.
If youâre one of the lucky few who can use a newer kernel, give that a try and see if that improves your stability in retroarch.
Also, regarding overclocking, I havenât found that it affects stability at all. The only thing I really notice is a higher temperature, but thatâs only when Iâm using all 4 cores to compile code. For gaming, I havenât noticed a real difference; but then again, I havenât exactly been methodically monitoring. The main thing is, there hasnât been any thermal throttling noticed, or sudden drops in frame rates. That should mean that itâs running cool and within specs.
I wonder if we can properly overclock it, removing the thermal throttling. This is a terrible idea I know, since if it is getting that hot, youâre probably going to melt plastic haha! The fact that it doesnât means that stability shouldnât be compromised by an overclock. I think people just get scared of the word âOverclockâ and associate with the word âVoid warrantyâ. Of course I canât guarantee anything, but thatâs just my experience. I donât have it on all the time, since honestly, most things donât need it. Itâs when I know I need it I will crank it up.
Another thing - Try a general core update within retroarch via the online updater. There was a pretty big overhaul of cores recently. I deliberately avoided doing it, in case it would break something, but hey! If youâre having stability issues as it is, give updating them a shot. Whatâs the worst that can happen? (famous last words)
Hi! Well for me, to have it them separated, I just created a copy of some menu emulators:
And the ones with the gbc are the ones where I use for GBC, here is the action.config, I just changed the directory, GBC
âROM=/home/cpi/games/GBC
ROM_SO=/home/cpi/.config/retroarch/cores/mgba_libretro.so
EXT=gb,gbc,gba,gbx,7z,zip
LAUNCHER=retroarch -L
TITLE=MGBA Roms
SO_URL=https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/mgba_libretro.so.zipâ
And the normal one for GB only:
âROM=/home/cpi/games/GB
ROM_SO=/home/cpi/.config/retroarch/cores/mgba_libretro.so
EXT=gb,gbc,gba,gbx,7z,zip
LAUNCHER=retroarch -L
TITLE=MGBA Roms
SO_URL=https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/mgba_libretro.so.zipâ
And for GBA, the same, to use mGBA or GPSP.
Oh god, um, donât restart! You canât have two 30_NAME files. Make the numbers change, otherwise the order will get messed up!! Do that before restarting, otherwise it possibly wonât start! Also, you will need to make a duplicated icon in the skin file.
So maybe something like,
30_MGBA
31_MGBAgbc
32_Ohboy+
33_OhboyCBC+
And hope that the next numbers arenât occupied. That is how the ordering of the icons is done, via numbers. And clashes with numbers/names is how launcher hangs happen.
Well I didnât have a problem with those names, but as you say, I will change the numbers hehehe
Yes, for the skin, I didnât bother to ask, doesnt matter, but I will look in to it 
Okay. So depending on if youâre in the full DEOT mode, or in the mode that lets you change skins, you can find the skin files in different places.
DEOT Full mode: /home/cpi/launcher/skin/DEOT
Skin mode: /home/cpi/skins/DEOT
Once youâre in the skin folder, go into DEOT/Menu/GameShell/20_Retro Games/ and duplicate the file MGBA.png, and rename it MGBAgbc.png. (thereâs also an alternative MGBAalt.png file that you could use/rename)
Basically, just make the .png mirror the naming structure of your new action files.
Do the same with the OhboyCBC+. Note: you donât need to have the number prefacing the file name for it to recognise which icon needs to be skinned.
You can optimise it further if you want
ROM=/home/cpi/games/GBC
ROM_SO=/home/cpi/.config/retroarch/cores/mgba_libretro.so
EXT=gb,gbc,7z,zip
LAUNCHER=retroarch -L
TITLE=Gameboy Color Roms
SO_URL=https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/mgba_libretro.so.zipUnder EXT, I changed the extensions list to only contain gb and gbc extensions. If you donât use zip or 7z files, you can get rid of those too. As it initially was, it was able to read all gameboy, gameboy color and gameboy advance roms, in case someone decided to say, put all the pokemon games in one directory.
Under TITLE, you can change it to whatever you want. I had it initially as the name of the emulator.
Now the question is, was there any reason for choosing to use MGBA over gpsp for GBA games? From my experience, gpsp ran faster for GBA in every way, whereas MGBA ran better for GBC and Super Gameboy, integrating better colour palettes and borders. I switch to the gpsp+ standalone for games that need a bit more grunt to play faster. The downside is that it uses more power.
Ohboy was included mainly for old school gameboy games, and better palette selection. It also has nicer borders to simulate physical gameboy consoles. The downside compared to mgba is that it doesnât support retroarch achievements, and other features.
I havenât made as many individual iterations to keep the menu from being too cluttered.
The reason Iâm asking is I havenât tried every possible game, and emulator combination. If there are specific scenarios where one emulator works better than another, I may consider removing superfluous emulators in future. For example, it doesnât seem like youâre using any of the gpsp emulators.
No no, I use them as you said, I mean, I got mGBA for GB and GBC, and the same for OhBoy. I know, both for the same, but as you said, there are different and so I can choose hehe.
And for GBA, yes I use the gPSP+ for those. So donât think otherwise 
But I also keep mGBA to some extent as it is known for accuracy not for speed, butâŚwell, I donât want to loose it.
So for me most of it is: GB and GBC with mGBA and GBA with GPSP+
Thanks for those tips to optimise those action.config
Haha phew! Yeah, thatâs exactly my thinking re: having them all!
But yeah, definitely is good to be flexible to be able to use any and all of them as you see fit.
I shall definitely keep them all! I was getting worried that perhaps no one was using gpsp and/or ohboy.
@javelinface could you please attach your RetroArch config. Iâve messed up again when trying to get rid of sound glitches in some of my fav games 