That’s super to hear! I’ve seen you around a fair bit, so sounds like you know what’s going on. If you find any problems with it, post about it and a fix can be made.
The only things you might want to manually update are the fantastic fixes @hi80482 has provided in the posts above.
Otherwise, I don’t see any new impending releases of the DEOT v2+ family coming out at any time. I’ll be trying to focus my energy more on working on a new image from scratch, using @Joao_Manoel’s minimalistic image as a base.
I’ve gotten my hands on a first gen CPI board with 512MB and no HDMI; but more importantly a R16-J, as opposed to my existing two R16 boards.
So far it seems to run fairly similarly without any major slow downs. I’m not sure if many things really use more than 512MB RAM, besides perhaps some background service adding to the overhead.
I’ll be mucking around with kernel settings, Retroarch, window managers and other optimisations with both processor variants in mind; trying to look for any discernible differences; thus having more universal settings that can be applied to both.
A fresh image from scratch sounds great! I was looking at that minimal image, and think it is a wonderful project, however I don’t do too much with retroarch on my Gameshell so having a menu to select my own projects is crucial. Which is a part of why I’m choosing this image
Though, I’d definitely would be willing to be a Guinea pig in testing out anything you’d want tested in that direction .
One of my biggest issues I’ve had with the “official” image is that updating and doing linux tasks how I’d expect caused the device to just not work … so I’d hope for a more stable linux core experience. But I understand it needs a more custom uboot and all that under the hood.
Thanks again for all your hard work, and to @Joao_Manoel for the image as well!
I’d love to put more effort into this device myself, but with other external factors I’m unfortunately limited on time. But I do want to at least support my project on this board!
Being based on Buster, you should at the very least be able to use and update any stable apps, and not have to worry about back porting, or using deprecated versions etc.
That’s my problem right now with using the current minimal image. it’s based on the SID bullseye, so I’m needing to back port a lot of features to get the stock Gameshell Launcher running.
Potentially look into @r043v’s custom image as well.
I’ll be the first one to mention that this DEOT image is far from being lightweight. This image is more for an OOB experience with everything set up.
Seeing as you’re not really wanting to use it for emulating/playing games, the above mentioned image could be another viable option, with customisable app launchers etc.
I hear you, re: limited time due to external factors!
No idea how I forgot about this one! Will put that on my list of things to try out
I actually use Fedora Rawhide on my raspberry pi, which is where I compiled my project, and which is why it uses libs that are too new for the current image of clockwork os … Though, that makes me wonder if I should give building an image a try I’ve done it a few times for another device following a guide. I believe it would be a similar process for the Gameshell (create partitions, rsync rootfs, copy uboot, profit)
ok, yeah, I’ll have to give it a try, Fedora Minimal. Just to say that I can Though I still think I’ll give this DEOT and the Arch image a try first. Thank you!
The more heads we have making things, the better! One thing leads to another, and we’ll eventually have something ridiculously stable, user friendly, and efficient!
Plus, not going to lie - seeing other people doing things always encourages me to try new things too
I’m super keen to see what you come up with!
On the note of Pico-8, you’ll need to update the /home/cpi/launchger/Menu/GameShell/50_PICO-8/compkginfo.json with this to install the latest version.
{
"GameDir":"/home/cpi/games/PICO-8/",
"InstallDir":"pico-8",
"NotFoundMsg":["Please purchase the PICO-8 \n|None|varela16",
"and copy it to the \"~/games/PICO-8\"|None|varela16"],
"MD5":{"pico-8_0.1.11g_raspi.zip":"a3f2995cf117499f880bd964d6a0e1f2",
"pico-8_0.1.11g_amd64.zip":"6726141c784afd4a41be6b7414c1b932",
"pico-8_0.1.12_raspi.zip":"08eda95570e63089a2b9f5531503431e",
"pico-8_0.1.12c_raspi.zip":"1a62b0d7d4e4be65f89f23ec9757cb66",
"pico-8_0.1.12c2_raspi.zip":"7a878795472fa39304e9a10128c1f712",
"pico-8_0.2.0e_raspi.zip":"085edfecd111c2b195b878b2197afe7a",
"pico-8_0.2.0i_raspi.zip":"be0c708d707fa967c77455512bd456c7",
"pico-8_0.2.1b_raspi.zip":"d72968c56b4de8bc3dda84a6d5b6270e",
"pico-8.zip":"whatever it takes"},
"Post-Up":"bash Post-Up.sh"
}
Ah thank you for the Pico-8 info! That is one of the 3 major things I actually use the Gameshell for
On this note, it makes me wonder if using something like Buildroot would be worth looking into instead of trying to use an already prebuilt linux distro.
I mention that, not out of experience, but due to folks working on R-Cade at https://retro-cone.com/ using it.
Again, thank you so much for the continuation of improvement!
Now here’s the small clincher. I don’t ever use or update via git, preferring to manually look at the commits, and apply them as I see the necessity. Bad practise I know!
I’ve actually got my own internal image that I have been keeping up to date, manually adding in the majority of the recent updates.
It doesn’t however have the updated git hash, and in fact still has updating disabled. The reason for this is, I still prefer to be able to toggle between using the DEOT interface, but still be able to switch back to the default, say for testing purposes. There are also a few other small font discrepancies.
The problem is, my DEOT mode switched exists in the ~/apps directory, whilst the majority of the git updates are within the ~/launcher directory. The switcher writes different values in the ~/launcher directory, making an absolute mess when updating.
Realistically I “should” make git pull requests to include whatever changes I have, but that is something that I get far too caught up and distracted with that it never eventuates. In short, I don’t know how to properly collaborate
The question is: would it be fragmenting information and releases too much if I released this internal image that I have been working on? The only other changes are a potentially faster rebuilt mupen64plus, an apt-get update and upgrade, and once it comes out, potentially Retroarch updated/configured to 1.9.0.
Again, you would need to flash your image, losing everything to try it. Realistically, having all updates possible via git would be best, but due to the reasons above, that’s not possible.
So yeah! Let me know if it’s worth uploading. Pros: you get a bunch of updates pre installed, and an interface switcher. Cons: you won’t be able to do any git pulls from what @hi80482 has recently been updating and maintaining.
I finally got around to installing this, which feels great! I love it so far. Got Pico-8 installed and everything.
One crippling issue though (which may actually have some fix?) is that the screen becomes unusable and glitched. I initially thought it was the gpu driver so I switched to software rendering and it got better. But then I rebooted and again it started happening with software rendering as well. So I switched back to gpu driver and let it sit for a while. Eventually it started being unusable.
No idea what happened I will be digging through this post to see if there are any fixes, because I really want to keep using this image >_<
[Edit]
Never mind, I applied the kernel update (or revert to stock?) and it fixed it
Hah! bingo! It’s something I’m trying to work out myself. I’m guessing it’s the screen flickering. This sounds silly, but try reverting back to the full speed OC’d kernel/clockspeeds, and then apply some light pressure to the back of the gameshell. Does it make a difference? I had “some success” with some extreme screen distortion while deliberately running the gameshell EXTRA hot doing a compile/build. Pushing the back … somehow remedied it. That said, i wouldn’t recommend this as a long term fix.
Just for data sake, could you let me know if you have an R16 or an R16J board?
Also, hold off from transferring all of your roms etc. Later on today/tomorrow, I’m going to upload a new image. It will have a lot of @hi80482 's fantastic optimisations applied, as well as retroarch “hopefully” updated to 1.9.0. It’s not behaving right now, so I wouldn’t recommend updating your retroarch manually just yet. I’ll get that sorted, so that the image can work well for newer users who don’t know how to do it themselves.
After attempting to update Retroarch, I also encountered the problem @shadowsword mentioned in this post.
I have a feeling this was also you? It looks like @guu responded here.
I’m still trying to work out exactly what has gone wrong.
My guess is that something when installed in the latest Retroarch update has been defined to be a part of the group “none”, which hasn’t been defined in the main_screen.py. As to what it is, i’d need to do a bit more digging.
def ReadTheDirIntoPages(self,_dir,pglevel,cur_page):
global commercialsoftware_flag
Cur page in this case is “none”
I’m assuming given the position of the error message, one of the values being concatenated is returning a “none” value:
if FileExists( MySkinManager.GiveIcon( _dir+"/"+ReplaceSuffix(i2,"png"))):
It’s just strange that it only happened after installing/updating something.
@hi80482 - You might have better luck that I! If you want to replicate the problem, run the Retroarch update script. @shadowsword - Whatever your IRC client was doing now appears to be what Retroarch and no doubt other things would do in the future.
I’ve got to go to work, so will just leave my gameshell to do an apt-get update/upgrade, and hope that when I get home, things will have magically fixed themselves. I am fairly sure it won’t, but hey! Worth a try.
I’ll also test to see if this is a problem in the stock 0.5 image, after updating to Retroarch 1.9.0. I haven’t tried the IRC client, so wouldn’t know how that fares.
Good to know I’ll wait until the new image is up before I do any more playing around then. Just in case I run into anything already fixed. Thanks for the heads up! You guys rock
Right. Problem solved! In a nutshell, my RA update script was running from within its launcher directory, leaving trash behind in its wake. Somehow that’s what caused the type error re: str and nonetypes.
It’s strange. I could swear that I have had it run from the home directory in the past. I also had similar problems with Emulation station sometimes running from the location of the shortcut, or sometimes running properly from the location the shortcut is referring to.
Nonetheless, it is fixed. I’ll be uploading a new version of the OS, mainly with the contributions made by @hi80482, an updated Retroarch 1.90 and a clean apt-get update/upgrade.
I would also normally have done an update on all of the installed retroarch cores, but with the recent Retroarch server hack, and destruction of build bot, I’m not too sure if I can still do that.
Consider this the new user friendly OS, with everything that could be tricky to set up done for you. There’s no need to update this if you’re already on the previous version.
One thing to note: Be careful with running the previous retroarch scripted updater! Better yet; don’t use it, and instead do it manually.
The new version I’m releasing should be fixed to not have the same problem.
Just got it installed, and I gotta say I still have the graphical glitches but reverting to Stock kernel in the tools section fixes it just fine so no worries there.
Also got Pico-8 installed easier than ever, so thanks for updating that part!
Argh! Yes, graphical glitches are something that probably need to be sorted out on a kernel side. I’ve got a few CPI boards that I am testing on, and will keep trying to get things working. Meantime, i haven’t got anything productive to report, other than what you’re currently doing.
Glad that the Pico-8 update worked for you!
.
… so I’d hope for a more stable linux core experience. But I understand it needs a more custom uboot and all that under the hood.
… Though, that makes me wonder if I should give building an image a try 
I’ve done it a few times for another device following a guide. I believe it would be a similar process for the Gameshell (create partitions, rsync rootfs, copy uboot, profit)
Though I still think I’ll give this DEOT and the Arch image a try first. Thank you!
instead of trying to use an already prebuilt linux distro.
I will be digging through this post to see if there are any fixes, because I really want to keep using this image >_<
but reverting to Stock kernel in the tools section fixes it just fine