Interesting, well I take it back, somehow I am still on 5.3.6 per the about page, so the stock kernel, even though I selected verbose, the clock speed is 1400 so it is “overclocked” but now no matter what I do I cannot change the kernel or stock, anything I select after it does its thing I check back and it shows the stock 5.3.6 and 1400 oc.
Update: Correction, very weird before after a internal reboot it would change the kernel and stock without turning it off and on manually, but after doing so it changed. I am going to keep it OC but change it to every kernel I can and see what happens for each and report back.
asking for a little more help on the pico8 (since that is my reason of dusting off the gameshell again)
from the desktop version, I was able to download a few carts (example picohot-0.p8.png)
now, on the gameshell, I am putting them under the directoy of /home/cpi/.lexaloffle/pico-8/carts
is this how to take carts and use them on another machine? if yes, then after doing this how do i use them?
also, does it matter that carts from pc to be put on gameshell? I mean, on pc it says press “x” and “c” buttons etc… which on gameshell is different buttons. are the carts the same version on all hardware or should I somehow get the gameshell version of carts (for compatibility, etc?)
What is weird is that anything switched away from stock needed a manual reboot, but when switching back to the stock it would do a hard reboot and would ultimately work. Not sure if that means anything but was interesting. The other things is that when moving to any other kernel it would keep the oc speed of 1400 Mhz, but when switching back to the stock it would revert it back to 1008 Mhz which is the stock clockspeed and I had to change it back to 1400 Mhz after.
The gameshell uses an arduino “keyboard” programmed for certain keys to be mapped a certain way. Since the pico-8 is a “fantasy” console with a defined pair of action buttons and a D-pad, the gameshell “version” has been mapped to follow this convention. In short, it should just work without needing a special gameshell version.
Try putting it in /home/cpi/.lexaloffle/pico-8/carts/, see if it works, and then if it doesn’t, put it in /home/cpi/.lexaloffle/pico-8/bbs/
That’s where you can find the majority of files. One of them is a cache, but it doesn’t actually ever flush. My guess is that it’s for where the games stores using the online are held.
Anyway, I’m just one guy, and not an expert on Pico-8. I didn’t write the installer for Pico-8, and to be honest, haven’t actually used it too much recently. I can provide help, but ultimately it might be better to start a new thread to get more help. Not everyone will be able to help out if it’s a reply to this custom OS’s thread.
@ajbrensike Hello! All of what you posted makes sense. The problem is, the stock kernel wasn’t written to go up to the higher speeds. It basically has a defined set of clock speeds if has under different loads. From memory, the stock one was an all or nothing affair of 1008MHz for everything. The other ones has tiered clock speeds. If you let the game she’ll sit idle for say 5 mins on one of the “custom” kernels, then do a clockspeed check, you will notice it’s lower.
I “thought” I put in a “sudo reboot” in my scripts, but I could be mistaken! I know for my own use, I removed it, so I can do multiple changes to my choices re: kernel/dtb and then reboot. I don’t actually ever use stock, so that could be why it still had the hard coded reboot present. There’s a chance it may have snuck into the final release the same way. Either way, whether it’s done automatically or not, the Gameshell needs to reboot before the kernel change is applied. That could be why it’s reporting as 5.3.6.
If you want to, you can read the contents of my script file. Is a super simple copy paste affair. I didn’t do any actual on screen menu selectors, since I didn’t expect people to really use it that often, and thought of it as a quick remedy for a few people having problem. I could potentially make one, similar to this:
But ideally, it would be better actually have a kernel that works for everyone that doesn’t need to have switching.
Ideally, just set it to one that gives you the most enjoyment and leave it. 1400MHz is nice, but realistically not many things make use of the full clockspeed, and you’ll enjoy the gameshell just as much without it.
Work has gone back for me, and I’m full on. I’m a musician, so it’s been teaching 7am-4pm, rehearsing/gigging 6pm-10pm on Mon-Fri, then weekend concert/recordings weekends. I’ll see what I can do in my spare time, and I’ll post something here if I come up with a better solution. If anything it will just be a replacement 5.7.0 kernel with the dclock patch applied.
Basically, I’ll be adding this before making the kernel:
sed -i 's/tcon->dclk_min_div = tcon->quirks->dclk_min_div/tcon->dclk_min_div = 6/' ./drivers/gpu/drm/sun4i/sun4i_tcon.c
This is from @r043v 's suggestion above. Eh, I’ll just do it now. I’ll start compiling now and post in an hour or so. See if it helps!
NOTE: THIS IS FOR TESTING! THIS IS FOR ADDRESSING FLICKERING ISSUES!
Okay, try this at your own risk. Backup before trying this. Or wait for someone else to do it and report back.
As mentioned above, I added the sed -i 's/tcon->dclk_min_div = tcon->quirks->dclk_min_div/tcon->dclk_min_div = 6/' ./drivers/gpu/drm/sun4i/sun4i_tcon.c patch, and applied it to the 5.7.0 kernel; making new dtb files while I was at it.
I’ve tested it on my own Gameshell, and well. It boots, and works. Ie, it shouldn’t prevent your system from working.
(this problem was fixed - but I'll keep it here, in case anyone still has the problem)
HOWEVER I’ve tested Mupen and Retroarch Snes9x and they don’t appear to be running. Other standalone do work. I’ll try rebuilding mupen and Retroarch to see if it addresses things. But if you do have the flickering, please try out the standalone emulators that work, and see if it flickers.
The TEST script changes both the kernel AND the generated dtb files. It seems to be the newer dtb files that causes things to stop working. For now, you can restore functionality using one of the “clock speed settings”, such as “governed” or “overclocked”. Both of them will make Mupen and Retroarch run again. Whether or not the flickering gets resolved, I have no idea since I don’t have this problem. (See below for a small hot fix to the “overclocked” clock speed script.)
Mainly try this out to see if it addresses the flickering issues. If you accidentally try this, and some things stop working, you should be able to return to normal using one of the existing kernel changing scripts.
It makes an entry called “Test” in the utilities>kernel section of the launcher. (Oh, I made the translation file change “utilities” to “tools” to be in line with the stock DEOT OS, so look in “Tools>Kernel”)
If you want to go back to the other combinations, they should all still be there.
To install the update, SSH into your gameshell, then just copy paste everything into your session command line. If you do the last line as well, it should run the script, which includes restarting your gameshell with the new kernel applied.
IMPORTANT!! ENSURE THAT THE GAMESHELL IS CONNECTED TO THE INTERNET SO IT CAN DOWNLOAD ALL OF THE NEEDED FILES! IT WILL NOT BOOT UP IF YOU FAIL TO DO THIS! (Thanks @DJC4 for pointing this out!)
(this probably isn't a problem - and something I only noticed on my "day to day" machine. It wasn't present in my "deployment" machine, so probably isn't in the uploaded images. Again, i'll leave it here, just incase.)
While I’m here, I just noticed a typo in the “Overclocked” script!
sudo mount /dev/mmcblk0p1 /boot
sudo cp /home/cpi/apps/Menu/60_Utils/07_Clockspeed/Governed /boot/sun8i-r16-clockworkpi-cpi3.dtb
and should be
sudo mount /dev/mmcblk0p1 /boot
sudo cp /home/cpi/apps/Menu/60_Utils/07_Clockspeed/1400 /boot/sun8i-r16-clockworkpi-cpi3.dtb
I’ve toyed with the idea of completely replacing the current launcher with Emulationstation, or at least having the option to change between them, kind of like “bean” in the utilities.
I’m posting it here, only because it’s reflective of the directory structure of this custom OS.
Start by following the script, as per the above thread to install the launcher/frontend:
Reload the launcher, or restart the Gameshell. There should be a new entry in Utilities. Run it to test out Emulationstation. To enter the EmulationStation menu, push start.
It is currently set up to primarily use Retroarch emulators. This is to reflect a possible candidate for a slimline OS, say using @Joao_Manoel 's minimal image. If you would prefer to include EVERY emulator on the gameshell, run this:
It will display A LOT of doubled up systems, and generally be quite a mess. Eventually, it would be good to use this: Launch emulator script - #2 by Dowdheur
To revert it to retroarch only, run this again:
Oh my, I forgot to reply to your post!
The kernels are for the most part using the defconfs of the specific author’s work. I’ve mentioned who made which one in the OP.
The only thing added was the tcon patch mentioned above, and manually adding the wifi module after the kernel was compiled.
Here’s the main kernels I’m using. I’m not cross compiling, but using the gameshell itself to compile.
Re: ZRAM, I uses to run into some problems using -j4 when building or making binaries. I believe that was possibly due to a lack of a swap file. I’m guessing that’s what you’re thinking, re enabling ZRAM. I actually included a few scripts for enabling, setting and deactivating the swap file space. I used that for times when I needed it. You should be able to find it in utilities/tools.
Of course there’s also the controversy of running a swap file on SD flash memory, and potentially having the benefits being less than the degradation of life. Realistically unless I’m compiling, I’ve rarely found RAM to be the bottleneck of the system.
Otherwise, it should be a simple case of running [make menuconfig] and enabling zram as you see fit; and any other changes to the config. The only other thing I’ve altered was the including of a custom splash screen. I just substitutes the stock one with my own. Since we didn’t have the source code, I just imported images from media coverage, formatted the file to the required standard and put it in the arch/drivers/video/logo directory. Here’s some more info.
Hopefully this is somewhat helpful. Again, sorry for overlooking your post! Life got busy!!
On the topic of flickering, no one’s reported back re: the update I posted two posts up.
I’m just going to tag a few people who have mentioned flickering, and hopefully this can fix everyone’s problems. If you could post your results, that would be great. I can’t tell if it changes anything, since I don’t get flickers. @ajbrensike@Lambdanaut@CommanderKitler@ghostronaut@Lix@Shwifty@DJC4
Was it possibly not clear how to do it? You need to SSH into your Gameshell, then basically copy paste everything in the code box into your session.
@javelinface I have replaced my battery and will inform you if that gets rid of my flickering for good after a few days of use. I will then tell you my results. In the event of the battery replacement not fixing the flickering I will back up my files and try the above solution and report that too.
Theoretically, it should be safe enough to do without backing up. But of course, Murphy’s law dictates that if something can go wrong, it will go wrong!
Perhaps test it out on a spare SD Card, testing the process; then when you’re confident, and see if it works, apply it to your main SD card.
Thanks for getting back to test the above. I’m fairly confident that the kernel change will do the trick, and you won’t need to mess around with changing the battery. Although, it’s probably a good idea to do it anyway, since the battery is a consumable item that degrades over time.
Okay, I found that the battery replacement did indeed not fix the flickering (although it does provide slight stabilization). I tried the fix above and and It fixed the flickering. I would like if you could an explanation of the root problem and how you fixed it @javelinface.
For future viewers: If you do the linked fix without internet the links won’t download and upon the restart and execution command the Gameshell will freeze and you will need to re-flash.
Oh my goodness I completely forgot to mention that!! Ahh I just assumed that it would be known, via the wget command. But forget that there may be an off chance that people are just copy pasting blindly!
The commands I provided merely downloaded a compiled set of kernels and boot images, set the permissions, and provides a script for add to the rest of the pile to switch the kernel/boot img at will. It does so by mounting the boot partition, and copying the downloaded kernel/images to the appropriate directory, and overwriting the existing files with renames copies of the patches ones. This is how all of the kernel changing scripts work. You can open the script file to see for yourself. It’s far from elegant, and much cleaner solutions exist. I just did something super rough to get quick changed out to people as soon as possible.
Anyway, keep testing it out, and report back any problem (if any) you encounter that weren’t present in the original one. If there aren’t any, we may well have just solved the flickering problem once and for all! I’d still rather have a larger test sample before deeming it a success. Thanks again!
Oh wait what??? Are you using it on the latest DEOT specific image? This is very interesting news!
Try using the script to change back to one of the other kernels and see if it helps.
In fact before that, as silly as it sounds; just try restarting it. And try restarting your modem.
The one thing I may have forgotten to do was run make modules_install after compiling the kernel. But the fact that it’s working on my image makes me think that I did do it.
I haven’t had many people report back after trying this hot fix, so fingers crossed it’s an isolated incident. You shouldn’t have to reflash, as it’s only adding an extra kernel option. Like I said above, you should be able to just switch back, and everything will be back to normal.
If you’re still having problems with the new kernel active, I’ll try recompiling the kernel again and upload it.
I’m not in the latest version of your deot image, may be 3 versions back.
Well changing to another kernel from TEST goes back to flickering and got back my wifi, here more detailed:
5306 - No flicker, wifi works
5406 - Flicker, wifi works
5421 - Flicker, wifi works
5424 - Flicker, wifi works
5509 - Flicker, wifi works
If I go back to TEST, wifi does not come back and no flicker.
Maybe I should flash your last deot image and do the flicker fix and see if the same happens.