Are these the graphical glitches you’re referencing?
Quite annoying as they persist in game and occur regardless of theme.
EDIT: that GIF turned out to be HORRIBLE quality. View this to see what I mean
1 Like
No it is actually much worse than that for me. Like full on glitchy to the point where eventually it becomes impossible to read the top/bottom menu text, and games are unplayable bad quality.
For me using the Tools menu and selecting the Stock Kernel option makes it work like normal 
1 Like
Interesting. There is no combination for me that actually resolves it, although sometimes it partially goes away (or at least isn’t as noticeable) after exiting a game.
1 Like
I am super curious. Has anyone who has been experiencing the screen flickering perhaps tried building a kernel from scratch for themselves, perhaps using a premade defconfig file?
I mean, it shouldn’t make a differences, but that’s one thing I can think of that would make a difference.
I’ve tried on two R16 boards with 1GB of Ram and a single R16-J board with 512MB ram. Both board revisions function without any screen flickering. Another thing I also do whenever using the gameshell is activate airplane mode. I do it for the sake of saving power, since mostly when out and about i don’t need wireless functionality. Give that a shot perhaps.
There could be two other variables.
I’m using a Sandisk 128GB card as my daily driver, and for the sake of published images, using a 16GB Sandisk card. I have the exact makes of them somewhere if anyone wants to know. Perhaps it could be down to the brand of card used?
The next variable could be the physical build conditions of the Gameshell. I am personally extremely meticulous, using essentially, my Gunpla tools and experience to assemble the plastic portions; while also having a background in dealing with electronics, soldering, PC building etc.
Not to question the handiwork of others, but potentially could the integrity of the build be something that could come into play?
@shwifty - Could you let me know which revision of the board you are using? ie, R16 or R16J? It would help a lot!
This was one of the first things I wondered about, if I had potentially messed up something when retrieving and reinserting the card, but on further inspection it all seems normal, and that wouldn’t get fixed by changing the kernel to Stock I’d imagine 
I didn’t even think about trying this. I’ll give it a go and see how it works 
- entered flight mode
- changed power mode to performance
- switched kernel to 5700
- gpu driver is still LIMA
upon reboot, the graphical glitches returned in painful full force
1 Like
Am I doing something wrong if the screen flickering is still occuring? Just loaded version 200903 onto my GS and its not usable at all. reverting to version 2000626 now. I’ve read the forums for a while now, just haven’t created a username so…nice to meet you all! Hehehe…
…
Thanks for all the hardwork and helpful tips you guys post!
3 Likes
Hey! Welcome!
Before putting in the time to revert, I suggest trying to go to Tools > Kernel > Stock and then (maybe after a restart) it might work.
This worked for me after 2 images of D.E.O.T
2 Likes
Ok! Will do, I’ll post later if I continue to have issues.
2 Likes
Ok, I’ve selected the 5509 Kernel and it seems to be working. I will try and load some games on it to test out performance.
2 Likes
How would I go about compiling the kernel myself?
Also where do I look to see the board revision?
EDIT: I hate being such a rookie 
1 Like
Possibly the best instruction for kernel compilation has been written by @Joao_Manoel, but it’s still not for the faint hearted:
(Skip to the kernel 5.7 section)
If you really want to try and are having difficulty, I could put aside some time on discord or something to walk you through the process.
As for checking your board, turn your Gameshell so it’s screen is facing down, and look at the CPI board casing. There should be a big black chip with either R16 or R16J written on it. That will tell you which version. Although theoretically, it shouldn’t actually make a difference. I’m just asking for the sake of my own data collection, to find any kind of correlation.
@dessysGS welcome to the forums! good to see a voice. Also, it’s a good way to actually get things working if in doubt.
Glad you got it sorted trying a different kernel/governor combination.
I might actually try exactly that - build the same kernel using a different governor. I was meaning go do that a while ago to potentially solve some micro stutter issues with gpsp standalone I was having.
By default, the stock image uses the performance governor, which is basically running at full throttle all the time, even if the app only demands 10% of its grunt. This isn’t the best thing for saving battery power, but may be the cause of some of the problems.
The kernels that change the clock speed on demand and provide extra sleep functions, and more stable wifi are the ones made by @Joao_Manoel; just modified by myself to include the DEOT splash screen. That alone could also be a potential cause, but shouldn’t be.
It’s just mind boggling that the problem is present with some users, but not all. I need to try and work out the factor that is causing this.
Back in the day, wifi was something that worked “when it decided to”, sometimes requiring multiple startups, until the correct drivers actually loaded. This has been addressed in this kernel, having them built into the kernel instead. Perhaps there is something else’s that is temperamental. We may need to have some deep startup log analysis on people whose consoles exhibit the screen flickering.
That might be something for another thread; pure data gathering. If anyone has any other factors they can think of, let me know!
In fact. I am potentially willing to do a 1 for one trade of one of my functional CPI boards, complete with a flashed SD card that I have working, for another user’s non functional screen flickering Gameshell. I can’t cover postage, since I’m just one guy. But I am willing to do this for free. The problem is, I’m from Australia. Although, @Shwifty; I seem to recall you are too? Or am I getting mixed up with someone else.
Anyway, the offer is there! For Science!
1 Like
I can relate. I’m also a rookie but I’ve learned through you guys and I really enjoy the GameShell…let’s be noobs together…how about it?! 
3 Likes
I actually own a “regular” GameShell and the DEOT version. The DEOT is my daily player and it has an R16 chip inside. I’ve tried switching to the “Stock” Kernel and it might have solved the issue…I’m testing it a bit now…
UPDATE 9:09pmEST
It’s working on the Stock Kernel now. Will upload games to test now.
UPDATE9:16pmEST
Cannot connect to the GS through SSH (PuTTy or Wi-Fi).
GS looks to have a strong enough and active Wi-Fi signal with access to RetroArch’s online downloader which seems to work correctly when the GS gets around this next thing. It will not boot to DEOT screen without a charging cable plugged in. Using DEOT settings turned off now and will try this mode to see what happens.
1 Like
I’m guessing I have the R16 board. Switching kernel doesn’t change anything at all for me, the glitchy screen continues.
@javelinface you are correct, I am also in Australia (Melbourne).
2 Likes
i have an R16 board and i don’t have those glitchy errors, so it must be something else that’s up with it
1 Like
Tried the 5700 kernel, with governed clockspeed, seems to mostly get rid of the glitches, but they still randomly pop in. Will edit with video shortly
EDIT: Here we go
1 Like
@dessysGS haha! Same scenario here! DEOT Gameshell = every day driver and regular Gameshell = over night compiled abuse machine.
The battery is basically SHOT in that one from the number of hours used it just compiling.
I would say that your problems with booting up only with a power cable plugged in are battery related.
Unfortunately it’s a consumable part of the Gameshell, although supposedly there a few options, such as the Nokia BL5C battery for older phones, or even a 3DS battery. There are a few threads you can search up using. Here’s one that could be helpful.
I’ve only tried an aftermarket NOS BL5C battery, and unfortunately it doesn’t give much better performance Than the stock Gameshell battery. Then again, I didn’t actually try to fiddle with it enough. Maybe I just need to get a few cycles in to remind it how much capacity it has.
Mmm the wifi is extremely hit an miss at the best of times. I have wifi repeaters in basically every room of my house, and at least that usually works. When it doesn’t, I just reset ALL of the modems (ie I turn of my entire house’s mains powers lol) then everything works.
I will normally just do anything requiring connectivity with Ethernet over USB. You just need a USB micro cable, ie the same one that you use to charge it. Just be careful when searching things up regarding this. A few people have tried using ANCIENT threads from 2 years ago, where information is no longer valid.
In fact in general, check the date before trying to follow any information. If in doubt, post in the thread, and ask if the information contained is still valid before attempting anything. Either myself or someone else would no doubt chime in and report.
As for updating and Retroarch, I’ve taken the liberties of updating all of the assets, cores, shaders and whatever else you could possibly need on the same day as the build of the image. Likewise with an apt-get update && upgrade. So unless you’re installing anything extra, you should be set. I’ve also change the default buildbot URL to one that uses NEON instructions, so potentially you could be using better optimised emulators already over the stock image.
I actually made mention of what the kernel changers do in the first post of this thread. Theoretically, the stock Gameshell image runs at 1008MHz, which is under locked. This is the stock speed according to the image, even though the gameshell is advertised at running at 1.2GHz. Perhaps in the earlier days, it wasn’t stable any faster. Or as we are finding now, some people experience graphical artefacts. I’m reminded of my days overclocking my computer’s GPU, opening up pipelines in the registry, discovering my lesser card is just a higher end card that didn’t quite pass the QC, and was badged as a lower spec card.
@Shwifty - try the underclocked clock speed profile. It uses the 5306 kernel. Failing that, also try the 5406 kernel. That has worked for some people. You’ve got the same revision R16 board as me. I guess, let me know if you want to do a direct “swap” to see if it works. Plus I would love to get my hands on one of the units that doesn’t seem to behave.
@Metonym - glad to hear that someone else out there is also running their system fault free. I was worried I was alone!
Also note, in the kernel section, only the scripts with the numbers independently change the kernel. Stock changes the kernel to stock AND the clock speed go underclocked, ie stock settings. Overclocked changes it to the newer kernel that allowed dynamically governed clockspeeds, and has a silent boot screen. Suspend is the most recent kernel, with the ability to suspend the system, and has a more verbose startup display. It also has the wifi drivers built into the kernel, which should give it more stability than the other two. This is primarily the work of @Joao_Manoel, so all credit should go his way.
The DEOT mode disabling essentially reverts a bunch of files in the ~/launcher/sys.py/UI/ directory to stock, so that you can run any skins etc intended for the stock 0.5 image. I had to change quite a lot to get the exact DEOT look; so much that trying to use a regular skin would cause the machine to hang. It shouldn’t affect anything that runs upon startup. If it does appear to make a difference, try restarting with it enabled again. You may have just gotten lucky with a “good boot up” process, while it’s disabled.
Anyway, I am working on it on and off, trying to find a solution! The more data I have, the more troubleshooting I can do. Keep me updated with what works, and what doesn’t.
Edit: @Shwifty! AH! I just noticed! There is a USB cable plugged into your console, no doubt providing power!
Now. I’m not sure if this is related, but potentially the cable itself could be causing some kind of interference if say, it’s not shielded. This could be in conjunction with the clockspeed varying as you are changing from idle time in the launcher, to using cycles when scrolling.
Try a different cable if you need tethered power. Or even, try no power cable at all.
I do remember for older 2.5” HDD caddies, certain cables didn’t provide enough current, or rather had good much resistance, resulting in failure with HDD spin ups, and detection. The one kind of cable that worked ridiculously well was the one that came with my PS4 and/or PS4. Usually digital cameras come with decent cables too, including a ferrite core; usually to prevent surges etc. The build quality in general from a reputable brand should be sufficient, especially if it’s a heavily gauged cord.
I have a R16J and the screen have flickering lines on the top and bottom of the screen. This issue appears for the latest two releases, before those I did not observe this issue.
1 Like
This is EXTREMELY useful information! First, the fact that the location of the flickering seems to vary between users, but also regardless of which revision of board people are using, they are experiencing flickers. I have got 2x R16, and one R16J which don’t display any flickering. I do however only have 2 Gameshell units.
This leads me to believe that perhaps it’s not the board that’s the culprit here, but instead possibly:
- The screen
- The ribbon from the CPI to the screen
- A problem with a USB cable providing power
- A problem with the power coming from the battery
Again, this could come down to how the user has build the system, but realistically, the plugs are pretty fool proof. Unless you’ve completely bent and cracked a ribbon cable, or have tugged at the battery connector so much it’s being held by a hair thread of copper, there’s not much that can go wrong.
If it is indeed a problem with the power coming from the USB cable, it could be another case of a damaged surface mounted USB header on the CPI board. There are so many factors. So it sounds like I won’t be able to just test out problems with a CPI board alone. I’d need to physically check another person’s entire build to make sure everything is in order.
All this could be moot, if it has been noticed that the flickering only happened in the last two versions.
In build 200620, I included the 5.7 kernel, but didn’t enable it by default, instead using a more “failsafe” default option. You can restore this kernel using the “stock” kernel script that also sets the clock speed to an under clocked static 1008MHz, which is the fail safe option I spoke of and what the gameshells used to all come running at on the stock OS.
In build 200626, I added a few scripts to re-enable the sleep scripts, which were seemingly removed from the original Gameshell OS, due to not having a feasible way to perform an adequate sleep back in the day. To make sure the sleep function actually works, I left the kernel on 5.7 by default, because it seemed like it was getting a lot of active development and attention, and didn’t have any reports of having problems.
In the current build 200903, I have certainly kept it as kernel 5.7 by default, and since I haven’t changed off of that kernel for at least a few months of regular use, I almost forgot that I used to change the kernel to stock before publishing new builds. It also uses the on demand governor, meaning that even though it can potentially reach 1400MHz, it will only do so if it’s demanded; meaning that sometimes the clock rates can get much lower, running at lower voltages etc. The Underclocked one actually could be more taxing at the end of the day, since it uses a performance governor, essentially running at 1008MHz constantly, regardless of load.
Anyway, I am probably repeating myself a lot here. If anyone else has noticed any of the flickering etc happening in an earlier build, check the first post of this thread, and check the change logs to see what else has changed, and hopefully we can get to the bottom of this.
You are correct, it can be a hardware or cable issue. First I will install gameshell os v0.5 to a separate sd card, and check all the cableing.
1 Like