could you try the arch port or only the kernel about this issue ? i also got a r16j revision
@jmfaker Interesting. So 5.4.6 is also flickering. This was a kernel that was originally included in the stock 0.5, but not enabled due to compatibility reasons and indiscrepancies between boards. This must be the problem encountered. It just seems to be further exacerbated with newer releases.
@r043v Iām not sure how much good me testing the kernels on different images would work, seeing as I donāt have any problems with any of them as it stands.
For the record though, the last time I used your image, it worked fine with no flickering. I will try and apply some different kernels to it to see what happens, but Iām assuming it will also be fine.
Iāve only got R16 Gameshells. Also for the record, the entry in the poll of āI have a R16-J and it worksā - that was me accidentally voting for something. Pretend that single result isnāt there. Itās such a small sample size, but at least there is a slight trend pointing to a correlation between the R15-J board and the flickering.
I donāt think itās a matter of trying to write in to the clockwork crew demanding a new board. Officially nothing theyāve released is, OS wise is faulty. Nor are you really missing out on anything by not having the latest bleeding edge kernel. Itās up to us to find a kernel that fits the boards; even if that means having to have two separate kernels. It should be easy enough to just have a switch to do this, as already demonstrates.
I compiled the kernels on my gameshell itself, assuming that the gameshell has enough grunt to not need to rely on a cross compiler. This could possibly be the reason behind my gameshells being fine, but other peopleās flickering. I guess once my R16-J board comes in the mail, weāll find out then!
Also hosted on my EU link now 
Thanks for all your efforts !
1 Like
Thank you so much again @wizz! I was going to DM you! You beat me to it! Much appreciated
yet i got this post as draft for so long time, sorry for delay
The problem for me was, knowing exactly what people have done when asking for help. Having things done in a ready made image was just easier, and let me know exactly the place where people started experiencing problems.
but now you are the only one maintainer for all the content and have an āobligationā of support, cannot really be tenable in the long run,
have external packages mean have different packagers
it also mean easy evolution without any new release, i just need package drastic or n64 emu to give them enable in my initial image
I could/should package the files into upgradeable packages, but like you said itās not trivial
itās more easy as you think, yet it need some rigor and could depend from the compilation process but itās not hard
arch got the easiest package creation tool from far with makepkg tool, there exist 3rd party makedeb scripts who allow debian to do the same way
and Iād have to start again from scratch, using the 0.5 image as a base.
in my mind better way will be use bare vanilla debian armhf without any manually changed files,
we know how setup uboot, how create kernel with proper options & drivers, how compile & configure the gfx stack (mesa & x server)
what does we need else to have a full working system ? thatās what i done for porting arch
Maintaining a server to have current updated files for me is a fair bit of work, since itās not something I usually do. Iād have to learn to do it essentially. If someone could assist in doing so, that would be great!
i got a running ppa server dedicated to the gs, thatās was one of my entry at the first compo along with a dedicated apt client (where full apt code still reside in fantasti without been used)
yet that wasnāt fun as a cat on roomba but the server is still alive and configured, off course itās one of my personal server so if i down it down, a mirror more wonāt be bad
The only thing I wouldnāt be able to change is the first boot screen.
uboot is the last part whoās not community builded, there are a repo with config for uboot, we need a try, the boot picture is show by uboot, but does we really need show a splashscreen and augment boot time for that ? fancy vs usability 
Iām not sure how much good me testing the kernels on different images would work, seeing as I donāt have any problems with any of them as it stands.
yet i was asked @jimfaker who got a problematic unit
my kernel differ from your one in some ways, the config is totally different, the patchs were split from months and maintained aside from your branch, kernel source is latest one 5.6.rc7 with an manually included lima 1.1 who must come with future 5.7 kernel
so knowing if it flicker too could be great and could give benefit to the twice kernels
Iāve only got R16 Gameshells
my initial one from first batch where a J revision, my screen ribbon was broken and i lost the keypad cross so i bought an used unit, whoās also a J revision but with 1GB ram this time
this flicker screen effect is pretty strange, we must debug it.
I guess once my R16-J board comes in the mail, weāll find out then!
you may request @guu to make some test if he got time to find a faultly board, but i donāt think itās a J revision issue, maybe a batch is more tolerant than other one yet but i think itās a software issue
when you compiled the kernel, was you sure the patch forced the tclock divider to the correct value (6) ? kernel was changed the way to set the divider two time these months, patch must be fixed too
1 Like
Haha I kept on seeing you about to post, then vanishing. That explains it!
I would really like to do something like this. Long term, itās something I will do. Looking at the thread you linked, Iām imagining I will get a lot of similar responses, with people having small user input errors, ultimately ending up with more questions on how to fix a hosed installation.
I try to help as much as I can on these forums, but sometimes itās easier to just say, go and download this custom image with all of your questions answered. Itās always a last resort, after things get too convoluted to try and explain over forum messages.
I guess not having 100% full control over when and where something may or may not stay stable is whatās stopping me using anyoneās external servers for now. I will always need some for mod contingency plan.
If I start from a complete scratch Debian armhf image, it would be super clean and very much user content controllable. However, Iām sure that the majority of the community are using the stock 0.5 image. I have tried to make this as similar to that structural, that anyone can install anything mentioned in the forums without too much intervention or changes for compatibility.
I just know that I will end up forgetting one or two dependencies in a stock image, causing a headache for people down the line. Sure thatās easily fixable, giving instructions on how to fix it, but following up on that in the long run will be a lot of work.
I am so very much wanting to do what you are suggesting, but it will be a lot of work and a long term investment. Iām just one guy, and only come from a a hobby coding background. So much new knowledge will have to be learned from scratch - which I am willing to do! Youāve been super helpful with assisting with that @r043v, having taken your advice so much!
In short, you are 100% correct in every way! What I am doing is essentially constantly doing a bandaid maintenance method, and not tackling the problem at its core. Instructions are excellent, however I will need to release a beta release, alongside the standard ones, as no doubt I will break something in my first attempts. That would require a lot of testers.
Iām just wondering how many people would want to spend time arduously putting an image together from scratch, vs. conveniently having one all put together and readily made. I know that a lot of people would love simple upgrade scripts to avoid having to format their system on each upgrade.
As for the kernel, the 5.3.6 that people are having success is the same as the stock one, just recompiled with a different stock image.
5.4.6 is an untouched stock kernel, just for testing. Ie the one included in clockwork os 0.5 but not enabled.
5.4.21 and 5.4.24 are both the work of @shell, just like the 5.3.6 and 5.4.6. They have only been modified changing the boot splash, and compiled using the exact instructions as the kernel config maintainer.
The 5.5.9 kernel is the only one Iāve poked my finger in to change things up. This is the one Iām testing the most, and have as my main day to day kernel. Itās mashed on @joao_manoel ās kernel, with a few tweaks here and there. I applied the tclock divider change according to what you mentioned earlier. But again, since itās working for me, I donāt know where the problem lies.
@r043v Can you possibly provide a patch that I could try applying to this monthās batches of kernel releases for the modification to the tclock divider? There no doubt could be user error with me inputting it incorrectly. Iāll try again and see where it takes me.
I still wonder whether or not compiling something yourself on whatever revision board you have will have any affect on stability. Another thing could also be cable and build quality/integrity, ie looking at your experiences re having to get a second hand gameshell.
I do remember when I let me gameshell compile using 4 cores maxxed out at 1.4GHz, I got some major screen fuzziness. I pushed down on the mainboard, and it seemed to fix the problem. Definitely not the best option I know. I just noticed that when I poked the back to feel how hot it was, I saw a change in the screen. It could even be pushing the screen itself, bringing me to also believe there could be a difference in screen quality and builds coming from different batches.
So many factors. At least being modular, we can test them!
Oh and haha. That trivial initial boot screen that augments the image boot time. I agree. It is trivial. But I wrote this image initially targeted at helping people who bought a DEOT gameshell, and were put out by the fact that the stock DEOT v1 0.4 image didnāt really get updated ever. My initial work got a few comments saying that it wasnāt 100% the same as the stock DEOT image, so I made my best attempt in rectifying that.
I tested the boot time against a stock image with a stock first boot screen, and it didnāt prove to add any additional overhead. That said, having no boot screens at all would be an even faster option, but thatās what Iād apply if I were just going for pure function. A high priority of this custom image is form and maintaining a certain aesthetic.
1 Like
Iām imagining I will get a lot of similar responses, with people having small user input errors
on this time gs menu file structure was get some location variation between os release,
real problem is launcher could break and hang on a tiny thing, having a āno failure modeā by pushing a key at boot by example would have been help a lot
also as i initially tried to launch a debate around the package setup vs hard writed link into the menu, this problem is still here, install a package may not put link into the menu, thatās must be a 3rd software to do this and just linking things to the menu from a common setup location.
sometimes itās easier to just say, go and download this custom image with all of your questions answered. Itās always a last resort, after things get too convoluted to try and explain over forum messages
yes and no, thatās true as all must be manually setup & configured, itās easy to break the system, but as the releases advance it got bigger and bigger with some new things to support aside
off course you release a clean and usable full image, flash and play, that would be the perfect solution for average users, and in fact if itās work upgrade is useless.
but having a nice menu to setup on a second a program is also pretty accessible to any user, like warehouse done
I guess not having 100% full control over when and where something may or may not stay stable is whatās stopping me using anyoneās external servers for now. I will always need some for mod contingency plan.
thatās a reason i setup my own %) but not all user can do that 
having one or two mirror more
would set sufficient stability, also a web interface to upload packages update could be done
also, have a server is not an obligation, release deb files for a manual install is much easy than recompile et setup things at hand, and deb files could easily (if not too big) be placed into a git repo
If I start from a complete scratch Debian armhf image, it would be super clean and very much user content controllable. However, Iām sure that the majority of the community are using the stock 0.5 image. I have tried to make this as similar to that structural, that anyone can install anything mentioned in the forums without too much intervention or changes for compatibility.
actually maybe 90% of the forum posts are now obsolete in a way or another, there was some variation of structure on os & launcher
having the requirement for compatibility is not as hard, in arch i faked the /home/cpi in fact linked to /home/gs and i pre-setup all the python requirement for the launcher, it run fine, i yet removed it from release as it make a take over around the screen, keeping himself in front of all (as pico 8 do too, but pico 8 can be closed)
also yet, what does really need to be here to keep a near full compatibility ? retroarch folders location ? menu location ? thatās near all, maybe user system files but some could be keep xinitrc xmodmap etc ā¦
I just know that I will end up forgetting one or two dependencies in a stock image, causing a headache for people down the line. Sure thatās easily fixable, giving instructions on how to fix it, but following up on that in the long run will be a lot of work.
donāt miss deb files can specifies dependency each package just install if need the missing packages, also upgrade a package is more easier than redistribute an os, for you and for the users
an example is the bluetooth support who was not work at the time of the release, now a package is dedicated to this without having to touch my base image
off course it will need a new base image soon or later, i changed tiny location etc ā¦ but nothing critical, itās more to reupgrade all to not let user download 2Gb of upgrade after initial flash
Iām just wondering how many people would want to spend time arduously putting an image together from scratch, vs. conveniently having one all put together and readily made. I know that a lot of people would love simple upgrade scripts to avoid having to format their system on each upgrade.
from now two users was want create a bare clean debian image, @Joao_Manoel and @duckyvirus, also iām sure @guu could help as he can
Can you possibly provide a patch that I could try applying
basically all my process to patch & compile kernel reside in only one file GameShell-PKGBUILDs/linux-gameshell/PKGBUILD at master Ā· r043v/GameShell-PKGBUILDs Ā· GitHub
for the tclock itās only a sed but itās apply to recent source, you may have to check file history to compile an old revision
all files (sources or patch) implied are here GameShell-PKGBUILDs/linux-gameshell at master Ā· r043v/GameShell-PKGBUILDs Ā· GitHub
itās work fine with latest source (5.6.rc7 at kernel.org)
I still wonder whether or not compiling something yourself on whatever revision board you have will have any affect on stability.
i donāt think i may have any issue, thatās why i still think using arch kernel on debian will work, and debian one on arch too
bringing me to also believe there could be a difference in screen quality and builds coming from different batches
thatās possible ! +1, flicker could also come from here
for the screen issue while compiling, i nearly always have backlight near minimal, never have for now your symptom, having a cooling mod would be great
I tested the boot time against a stock image with a stock first boot screen, and it didnāt prove to add any additional overhead.
thatās possible each just wait two seconds to show the boot logo %)
if you want two logo you could use kernel logo, why not use a 3rd tool to change background after initial kernel init, and desktop bg ^^
1 Like
What if comes down to is the fact that some users know how to deal with problems when they arise; knowing how to debug and install dependencies as needed etc.
I donāt know what percentage of users this would be, but I have noticed that there are a lot of users who just want to do a quick copy paste of commands, but donāt necessarily understand the syntax, leading to potential problems.
This is definitely not an image built up from scratch at all, so I guess if I wanted to go ahead and provide individual packages, I would need to follow suit and start again. Not difficult at all, just time consuming.
As for what needs to be in place, itās more knowing what people havenāt done. Often, people would install things the incorrect way, not have correct file permissions/modes or may have different versions of files, causing a compatibility problem.
Folder structure is probably the easiest thing to fix, seeing as like you said 90% of the posts on the forums are now out of date and require doctoring. Thatās essentially what Iāve done with a lot of the things in this image; taken the out of date things people desire, and bringing them up to date. Iāve provided instructions on the way; albeit not in the respective threads all the time, but within the DEOT Custom threads.
Since Iām actually basically a travelling bard by trade, I donāt have a means to have a fixed server to use as a repository. Money is always tight so paying for an online hosting service is probably not worth it for a temporary pet project.
Iām just making excuses at this stage. Iām not a coder by trade; just a musician. Iāll definitely try to learn as much as I can about how to package every individual module/component, and start from scratch. As it stands, I probably would prefer to spend more time with loved ones while they are working at home in these trying times.
Eventually though. I will have a look into it. Your information youāve provided is most invaluable and I will definitely refer to your post when I get around to it.
1 Like
I just want to say Thank You to Javelinface. I had no idea that the Gameshell was capable of playing Drastic and Mupen64 to such a high degree of performance. Iām basically a hack that just copies and pastes commands, and Iāve got a MicroSD that Iāve built up with my own preferences, but I always flash an extra 16gb card with your next release to see what can be done.
The only thing I want to figure out is how to remap the controls for mupen64, Iād prefer the d-pad to be a d-pad so I could play the AKI wrestling games.
2 Likes
No worries!!! Thanks for the comment! It keeps me smiling and motivated.
And ha we all gotta start somewhere!
Iām eventually going to make individual modules people can install with each change Iāve made, so you can install individual components without having to reflash your entire card. For now, hereās a link to a mupen script to get things running on your main card:
As for the dpad reconfiguration, the mupen config file is located in ~/.config/mupen64plus/mupen64plus.cfg
There will be a place you can scroll down to change the keybindings under āinput player 1ā
As for what to put in, youāll possibly need to know the keycodes. I uploaded them all somewhere but canāt seem to find it! Never fear! You can get them yourself. Hereās how.
- SSH into your gameshell.
- Type
export DISPLAY=:0 - Type
xev - Push the buttons that you want to get the key codes of, and make a note of it.
- Exit by pushing āctrl + cā
- Edit the config file accordingly.
Oh haha I just realised. I would have already had the Gameshell dpad keycodes mapped! You could have just cut and paste them to wherever you want! Haha. Ah well, itās also a good thing to know, so you can edit the rest of your keys.
There should be a way to make an individual script/action to load a specific config file for a specific game. Useful for times such as this. Either that, or a script to toggle different mupen configurations; similar time what I did with the kernel/clockspeed switch.
While Iām here! I want to also point out another thing I noticed re: some standalone emulators. Some of them now run ATROCIOUSLY! In particular, FCEUX and gpsp. Both of them have really janky v-sync and frame rates. FCEUX has audio sync problems. This is using 5.5.9 and 1400MHz. Possibly a clock sync issue. The audio issue was fixed just changing the audio quality down to 0 in FCEUX.
I didnāt notice these at first, since I usually use Retroarch. Likewise with PCSX, the Retroarch core handles scaling of text better than the PCSX standalone. But thatās just personal opinion. I actually prefer using Retroarch, where everything runs buttery smooth, but I know that many users insist on using standalones. Theyāre there for you to try out and fiddle with settings to make work better.
And please do! There are far too many games to test and too little time to do it in. It would be great if people could post and changes they have made to make things run smoother etc. Iām always testing and trying new things, and often overlook simple things.
1 Like
Just caught wind of another potential thing to fix. It was via Discord. (Iām lettuceleaf)
For now, unless you really want the custom volume/brightness, deactivate the DEOT settings via the script in utils.
I havenāt tested it yet myself, as I am at work, but will report back as soon as I do!
1 Like
Indeed it freezes itā¦but I like the looks of the deot menu, so I will not deactivate the DEOT settings until I have to access the warehouse
1 Like
At least Iāve isolated it down to the skin_manager.py being the culprit behind the warehouse breaking.
The only thing added to it were references to additional fonts that theoretically shouldnāt have altered anything unless called upon. The stock font references were untouched.
Unlessā¦ surely itās not the changes the the settings pages? They shouldnāt be referenced in the warehouse. Surely?
Yay another thing to add to the mystery bag to sort out.
After work, Iāll just try commenting off each line one by one.
#!/bin/bash
sudo cp -r /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.deot/Settings/Brightness/ /home/cpi/launcher/Menu/GameShell/10_Settings/
sudo cp -r /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.deot/Settings/Sound/ /home/cpi/launcher/Menu/GameShell/10_Settings/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.deot/Settings/list_page.py /home/cpi/launcher/Menu/GameShell/10_Settings/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.deot/UI/scroller.py /home/cpi/launcher/sys.py/UI/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.deot/UI/skin_manager.py /home/cpi/launcher/sys.py/UI/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.deot/UI/slider.py /home/cpi/launcher/sys.py/UI/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.deot/.gameshell_skin /home/cpi/
sudo rebootOn another note!
Iām looking into getting Mesen running. A NES emulator that supposedly supports advanced audio features from some famicom games. Eg Akumajou Densetsu/Castlevania 3. The Retroarch core doesnāt perform well on the gameshell, so was going to try and compile the standalone. It would be something to replace FCEUX, that is currently suffering from terrible V-Sync issues.
1 Like
thank you for the update. it is very helpful
1 Like
Welcome to the forums @kate_smith !
Glad that itās helpful!
1 Like
Iāll be including the LowResNX fantasy console in the next release.
Hereās an icon that has been āDEOT-ifiedā if you decide to install it now yourself.
or
In other news, Iāve gotten the warehouse working in DEOT mode. Yay!
Iāve also put on standby the DEOT style settings pages for storage and airplane, in case anyone else wants to try their hand at making it work. Theyāre currently commended out in the activation script.
I also fiddled with a few other icons too. Nothing major, just the DEOT mode (de)activation, and the retroarch update script. Iāve touched up the wonderswan icon. The colour just isnāt quite right!
I added another script to retroarch, serving as a config file recovery; just so you donāt need to SSH in if you change something that makes it not start up properly, or just want to start over.
Experimentally have included an action.config for the BeetleVB Virtual Boy Retroarch core.
Iāve also included an installation of mednafen that seems to work much better for virtual boy.
It also supports NES and Wonderswan.
I havenāt included it, but if you want to install Brutal doom, you can do so with this script.
The post has been updated with some new information to have better mod management.
Iāll get it uploaded tomorrow. Itās 2am, and I probably should sleep.
1 Like
Hello again! I wonder, is it possible to perform an overclock at stock 0.5 OS? Letās say, I want 1200MHz, what I need to do?
Thanks in advance.
I tried to search in this thread but, couldnāt find itā¦
Hello! You can apply the overclock to whatever kernel you want. Itās more, you may want to have an updated governor in an updated kernel to get the most out of it, re throttling etc.
The stock 0.5 image has the stock kernel, so could potentially lead to battery life being less.
Although are you specifically wanting to have 1200mHz and not 1400mHz?
You will need to replace the .dtb file in the boot partition.
Have a look here for more info.
1 Like
I want to take a try and compare with original frequency, 1200 looks logic to me, but I can try 1400 also.
Thank you for showing me what I was looking for!
1 Like
1200 is what the gameshell is advertised as having funnily enough! Theyāre not wrong; itās just that all the official OS releases have it set to 1008.
Most things donāt have that much difference. Thatās why I made it a toggled option. Itās certain games in Mame/FBA that really benefit from it. Usually when the audio gets out of sync, and has major buffer problems. Mupen64 just has slightly better performance, and less micro stuttering.
Compiling is faster, but it gets stupidly hot, so I probably would wait that 50% extra time.
Overall though, Itās not worth having overclocked all the time. Just turn it on when you need it.
That said, another user recently posted that while using the DEOT image, they canāt get their SNES emulator running well, unless overclocked. This is very strange. I have no problems with SNES on stock clock speeds. Did I just get lucky and get two really good CPI boards? Not likely.
Anyway, let me know how you go. Iām curious to see how others feel the overclock works.