awesome, thanks for the test 
so it may come from the tcon value set at 6, patch could be easily done on others OS
let me know if you had any issue on arch, it still the initial image but some things are now backported into dedicated packages, maybe tiny manual fix could be necessary.
How would I change the tcon value, what should it be changed to? At least if I can change it myself I can experiment with a number that works for me (unless that is potentially dangerous?)
Theoretically, changing to āunderclockedā should set it to stock. Stock is 1008Mhz. It should also set it to kernel 5.3.6 which is also stock.
Otherwise, using the stock os0.5 image, insert it into your computer. A drive called ābootā should appear. Copy the entire contents of this directory to your computer.
The DEOT image doesnāt mount the same way, due to how the header has been imported/stripped from the stock DEOT image to have the special boot screen.
While booted into the DEOT OS, ssh to the utility directory for the kernel and clockspeed switchers, and find the files that correspond to clockspeed and kernel; which should be 1008 and 5360 or something to that effect.
Rename them to 1008.bak and 5360.bak to have a backup of the files, then rename the files you got from the stock 0.5 card to the original names here. Youāll need to rename sunsomethingetx.dtb to 1008 and boot.img to 5360. Put them in the same directory as the DEOT utilityās files.
Sorry for the broad vagueness of this response - itās just from memory, and a quick post before I go to work! Thereās an easier way to do it, just mounting the boot directory, then su copying the files directly. In fact, thatās the way the switched script works. Open the script to find out.
I can be more specific if you want. But more importantly, I think @r043v might be bang on the money, and have a solution for those with the flickers. If it solves all the problems, then we wonāt need to get down to why some boards are affected, and some arenāt. I still put it down to user build factors, but thereās no way of really knowing without holding a unit in my hands.
@Shwifty - youāll need to know how to compile/cross compile your own kernel. Itās not that daunting a task, but does require a lot of fiddly files, and command line know how. If you go to @Joao_Manoelās GitHub page for his kernel, you can see his excellent tutorial there.
On a side note, @r043v and @Joao_Manoel have images that are slim line, efficient and built for the user to build on top of, with what they want without any bloat.
The DEOT is the opposite of this, bloated like a beluga whale, but with all of the āhard to installā modification and UI fanciness that Iāve seen people have trouble with. Ie, for the beginner. I recommend that people check out the other two custom images, and consider them the way forward.
Yeah, would love to know how to change this, and what to change it to to see if it helps
Probably gonna have to hard pass on that. I donāt know any command line, but if there was a tutorial for teh exact kernel/settings I would need to compile then Iād give it a shot
compile kernel in arch is pretty easy, arch package build system is near entirely automatized
also convert arch kernel format (zImage) to other OS kernel (uImage) is pretty easy, a single command :
mkimage -A arm -O linux -T kernel -C none -a 0x40008000 -e 0x40008000 -n āLinux kernelā -d zImage uImage
i do it for you and up result here > http://gs.dread.fr/gs.kernel.5.6.3.tar.xz
just extract uImage into first partition, and others files into second partition of deot OS, or all into unique partition of debian image
. . .
to recompile kernel from arch here is the step onto your gs by ssh :
mkdir ~/dev && cd ~/dev
git clone --depth 1 GitHub - r043v/GameShell-PKGBUILDs: pingu repository - PKGBUILDs collection dedicated to GameShell Arch Linux ARM port - http://gs.dread.fr/arch/armv7h/ && cd GameShell-PKGBUILDs/linux-gameshell/
makepkg -i
-i mean direct install after compile & package generation, download/patch/compile time will be ~45mn
plug your gs to ac and set it to maximum performance will be better
in arch all package generation steps are resumed into a single file, PKGBUILD
current one could be found here > GameShell-PKGBUILDs/linux-gameshell/PKGBUILD at master Ā· r043v/GameShell-PKGBUILDs Ā· GitHub
in line 122 of the file you could view how tcon divider value is patched to 6 :
ie, just calling sed command to substitute original line with value 6 into kernel source file ā/drivers/gpu/drm/sun4i/sun4i_tcon.cā
if you want try other values, you will found a āsrcā folder into ā~/dev/GameShell-PKGBUILDs/linux-gameshellā where you could found kernel source who where downloaded & patched by the makepkg command,
you can directly change kernel source (using vim or whatever) to change the tcon value, after that, to recompile only necessary and not spend 45mn more call makepkg again with -e (no extract source & run prepare function whoās patch source) and -f (force package regeneration)
so :
cd ~/dev/GameShell-PKGBUILDs/linux-gameshell
makepkg -e -f -i
it must recompile changed files and generate the package, and finally install it, after that just reboot to test
when all is ok, you can call the mkimage command in front of this post to create uImage file from the zImage one if need
here is makepkg command manual > makepkg(8)
I get very weird and persistent screen flickering with this image. The whole screen. I have a first batch gameshell. Iām going to try to revert to a the official to check if thatās the issue, but connections seem solid.
For now, go into the utilities folder, then the clockspeed folder. Choose the under clicked option. Underclocked is actually what the stock settings are. This is the stock clockspeed and kernel of the stock image.
The problem is being worked on, when Iāve got some free time. Itās super busy this time!! Meantime, try the suggestions mentioned above.
Itās super hard for me to know whatās going to work, since three of my CPI boards simply donāt exhibit the problem.
Iāll collaborate with someone down the track, or get my hands on a unit that has the flickers.
Meantime, scroll up in this thread. Thereās a lot of discussion regarding the flickering.
I added nohup to the load.sh to avoid stalling if you use longer mp3 boot sounds.
I donāt really know where to contribute to this build so I made a pull request there.
@javelinface let me know whatās best!
i reflashed to the newest version online 903 version, and my gameshell has been stuck at the welcome engineer screen for about 15 min with the folowing message
32.496382] dc1sw: disablingg
running a 3.1 board with R16 CPU
Also noticed the music player hangs the system and you have to force a reboot
Can you try clearing your play lists? See if that works. I managed to force a freeze by deliberately breaking the play lists, adding a redundant reference to a file that doesnāt exist, but that was outside of normal use. Your play list could be out of sync.
Perhaps when copying your music over, a stray corrupt track also got copied over. It MPD could be trying to play something that refuses to do so; thus hanging your system.
Try copying batches of music files at a time until you find the culprit, and if you do, please post what it was so we can know for the future.
I recall in the past, you had troubles with file transfers. Perhaps the files didnāt get transferred completely, and you have partial files that lack any headers. That would cause the MPD to hang. How are you transferring files these days?
Check your file names for potential āillegalā characters. Eg, if youāre playing lots of Phantasy Star MP3ās, some of them may contain Katakana/Kanji characters that may not be readable. Also check for extraneously long file/directory names. Try not having subdirectories, and just have the music in the ~/music/ directory.
If itās still freezing, paste the last few entries of ~/.mpd/mpd.log
As for your other problem re: hanging, depending on how youāre transferring files etc, you may possibly be forgetting to unmount your card if youāre using a Linux system fo transfer files, thus causing file system corruption. If you can SSH info your gameshell when it hangs, try cat /tmp/x.log and paste your findings.
Another thing that causes hangs upon booting is having the SD card filled to the brim. How much free space do you have? Did you and jam every last bit of space with music files?
Iām personally not experiencing any of the problems mentioned, but I also donāt have the exact same music files as you. Nor do I know how you use your card re: file transfers, the contents of your card, and potentially anything else you may have done.
Try the above suggestions, and if none of them solve things, try to provide a bit more information.
Just wanted to chime in. Iām having the screen flickering issue with a DEOT install, no settings change. If I change the GPU driver to software rendering, it works fine. If I change the kernel to 5700, it works fine. Changing the clockspeed did nothing.
I am using a kickstarter unit (512mb ram).
Yup! Clock speed shouldnāt do anything. Itās just the kernel. That said, possibly only some kernels will use proper governors. Thereās too many combinations to list every iteration.
Thanks for mentioning that 5700 is stable and flicked free @Qiangong2. I have no idea what to ever recommend since all three of mine (including a first gen Kickstarter model) work without the flickers.
Javelinface, Iāve really loved all of your work on updating the Gameshell over the last couple of years, especially now that Iāve figured out how to write my own config file for mupen64plusā¦ ive got all the AKI N64 wrestling games running perfectly. Its amazing. I just have one issue with your latest release though. MAME doesnāt seem to work, and there is a lot of slowdown in FBA for Konami beatem ups like X-Men and Turtles in Time. Ive tried updating the cores in RetroArch and using different coresā¦ but no good.
Its especially weird since I have no issues with the same games on my other SD card with older firmware (0.3 i think)
Any advice would be greatly appreciated.
Aha!! Try using a different kernel combination. Itās super strange.
I remember at one stage having an absolute nightmare of a time with getting any arcade things running without ridiculous stuttering audio.
Another thing. Iām not sure if itās itās some kind of initialisation problems of some parameters in the config, but certain changes to the config made it slow down. Changing it back didnāt fix anything. It was at that stage that I made a config from scratch.
In the utilities, thereās a Retroarch recovery shortcut. All that does is restore the Retroarch config with a clean backed up copy. Just in case something was changed.
Which game was if exactly? Do you know if it was specifically from the romset thatās compatible with FBA? Possibly try mame2003 too. Iāll give it a try myself, if I have if that is! Itās funny.
I was actually playing turtles in time just the other day; one of my childhood favourites. It has no problem. But another side scroller; super ninja Batman - or something like that; the audio just runs crappy, but the gameplay is fine.
I used to have problems with other games like Gunbird, but they now work. Try them out too, just to see if youāre experiencing my initial problems.
Perfect! Thanks for the advice, I was able to play around with the Kernel and Overclocking settings in the DEOT Utilities folder, I also downloaded brand new romsets for my favorite games. (The zips Iād been using have been passed around from device to device for years) Then I used Retroarch to scan the directory and build a playlist. That allowed me to read the details of each rom better to choose the one I wanted to play. Itās running great now!
@javelinface, first off, thanks for the amazing image. Been using it for a while, and have very much enjoyed it. Your default configs are always a pleasure to use.
Whatās your kernel compilation setup look like? Iād like to build my own (mainly to add zram support) but I always end up with no wifi/sound. Are there drivers I have to get somewhere?
Ah! Re: wifi, I knows exactly what youāre talking about! Have a look at this:
As for the config Iām using when compiling, itās dependent on the kernel. Usually Iām using the config of the original author, which I have defined in the first post of this thread. The only modification Iāve done is an adjustment to the boot splash image, and in some cases adding a few additional governors. Iāve left a few of them at completely stock, for people with flickering/compatibility.
I just use the gameshell itself to compile the kernel, just so I donāt need to worry about any cross compiler compatibility problems. Iām fairly sure I still have the necessary tools still installed on the custom image.
I have no idea re: sound not working. Iāll dig around my configs etc and post up what Iām using when I have a bit of time.
hello @javelinface
I have my gameshell since I backed the campaign during Kickstarter and always found the stock OS very clunky and not user friendly.
Recently, I thought to use the console again since my new found love in PICO8.
Browsing the forums I came across your threads and your custom images.
I know youāve been doing this a long time (I went through all 500 replies on this thread), but I have only now come across your work.
Iād really like to thank you very, very much for all the work youāve been doing and developing the CFW long after the original gameshell company devs have moved onto their new console; it really is a Godsend!
PICO-8 has recently upgraded their version- pico-8_0.2.2_raspi.zip
I changed the config to this:
{
ā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.2.2_raspi.zipā:āe2dba152bf507d337459e9316061411dā,
ā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ā
}
Submitted a pull request to the main repo here:
Do you maintain a copy/fork, too? Will submit a PR there, as well then.
I think I found your repo, submitted PR:
I do have a quesion:
So a weird thing happened, flashed 200903 on my 64GB micro, everything went perfectly fine, but during boot and after that point the screen shakes non-stop like it is glitching. At first, I thought it was part of it initializing as the booting process looked cool so it gave it an interesting effect, but then it kept doing it no matter what I did on the main menu. Any ideas why? Already flashed it a second time and the same thing happened.
Update: I have tried both etcher and rufus to flash the drive and it still has the screen shake, I put back in my 16gb with the normal OS and everything is running smoothly no screen shake so I know it is not the screen. The drive was working fins before this and had no issues nor did i get any error when flashing on either softwareā¦still stuckā¦
Update2: Even tried an older build, same problem, going to try a different download source over google and see if that fixes it, if not then ill try a new driveā¦
Update3: While waiting for the new download source to complete as it is taking longer than expected, I tried to install the most up to date google drive file to a different micro usb drive and sure enough same shaky screen resultā¦the other dl of file is almost done, will try that before heading to bed and if that does not work I am lostā¦
Update4: Alright I also downloaded the mega file and still get the shaky screenā¦I have troubleshooted as much as I possibly can, hopefully I am missing something simple but any and all help is appreciatedā¦please and thank youā¦
Hello @7thking and welcome to the forums! Iām surprised you hadnāt come here, being an early adopter!
This really means a lot, saying that my image has been useful! Thank you so much!! Seriously!
Since they have moved on, Iām thinking that this will probably be the most complete version of the official image.
I have considered making another image, based on @Joao_Manoelās custom image from the ground up. I just encountered some compatibility problems, being based on a newer version of Debian; at least using the official gameshell launcher installation.
I have also been meaning to make an OS using a fork of Retropie, or at the very least, a custom Emulationstation front end. Iāve got it already running on my day to day machine. Itās just a matter of making it the primary ālauncherā on boot.
Thanks for the heads up re: Pico-8. Sounds like you found the repository for the image. Mind you; I commented out being able to update the launcher from the menu as a safeguard against people accidentally updating and hosing their system. You can re-enable if, simply by removing the commented line in the settings page python file. Or just manually perform a git push yourself. I figured if you knew how to do this, you werenāt at risk of ruining your OS.
Usually if people have issues, you can either just rename the file to a previous version, or even just
āpico-8.zipā. If the former, just ignore the hash check. Calling it the latter shouldnāt need a MD5 check.
I ended up just releasing entire images every time I did any major updates, opting not to really maintain the fork and/or changes. Ultimately, I made this as an out of box experience, with as little things that could go wrong as possible. I considered just running a diff on my image, but never actually got around to it.
From trying to help people on the forums, I discovered that following instructions can be difficult for some, and at the end of the day, I would have had to have done more trouble shooting in undoing problems people have encountered trying to update something that they themselves have modified beyond recognition.
As for the location of Pico-8 carts, check here:
~/.lexaloffle/pico-8/bbs/and
~/.lexaloffle/pico-8/carts/Theyāre in ā.p8.pngā formats (confusing since itās a similar extension to the image files), and may use a BBS binary as their respective names.
Hello to you too @ajbrensike! Welcome to the forums.
Ahhh the notorious āflickeringā problem. If you search up āflickeringā on the forums, youāll find a handful of entries. As for downloading different versions, check the MD5 hash for integrity. Iām pretty sure I provided one in the first post? Although I may have forgotten! Either way, they āshouldā all be the same.
Itās a weird thing that seems to be a hit and miss scenario where some get the flickers, and some donāt. Iāve got 3 CPI boards, (a R16, a R16-J and a first gen kickstarter 512MB board) and two sets of game shells. I cannot replicate the flickering on either of them! Iāve used a considerable number of configuration permutations between the gear; mainly switching out the mainboard and display. I havenāt done every cord, speaker, arduino, keys and case since they shouldnāt be contributing to the problem.
I have actually experienced some crazy glitching ONCE on my main machine. It was while doing a apt-get full upgrade (or maybe I was updating retroarch, or compiling a kernel? I forget) while overclocking the unit to 1800MHz, using a performance governor, and running -j4 four jobs at once. It over heated like mad, and the screen went crazy! Strangely, the flickering lessened when I applied āpressureā to the machine. Hopefully itās not an overheating issue, causing the ball grid array to dissociate on on of the pcb. Or haha hopefully Iām not immune to the issue BECAUSE I overheated my unit, forcing a reflow of the solder. Haha. Doubtful.
I initially thought that perhaps it could have been cable integrity, assembly cleanliness, or batches of LCD. But then I remembered that the one thing that I have replaced on all of my units is the battery. It could possibly be related to battery health! On a simply scale. as internal resistance increases, the output current drops. Of course with modern batteries this shouldnāt be a thing, but Iām willing to guess anything at this stage.
The kernel Iām using by default is @Joao_Manoelās work, with many benefits, including a functional sleep mode, over clocked (or rather not underclocked) cpu, and better governors for power efficiency. This is what causes some people some problems. Of course, the ones with problems are the ones who speak up and check the forums. There may be more people without the problem than have reported here.
First and simplest solution is to turn the Gameshell on, then simply restart it from the launcher. This solves it for some people. Mind you, it does mean you need to double boot it every time, but if youāre using the suspend function, technically you could just let it sleep, and charge it when it gets low; never turning it off.
The second most effective solution is to change the kernel. I have provided scripts to do this in the utility folder. Check the first post of this thread for info on what each option does. You will lose some features, but you will remedy the flickering problem. This is also a way to get around any other āglitchesā that may happen. There is a stock kernel included, if you want to see how a āvanillaā os 0.5 would run.
If you can get your hands on a BL-5C battery, try and replace your existing one. Iām curious to see whether or not this is actually the cause of all the problems.
Hopefully that solved your problems with the shaky glitching screen!