Custom D.E.O.T. V2.0+/Clockwork OS v0.5 image - With customised DEOT interface, Kernel 5.7, Optional 1400MHz OC, Debian 10 Buster, Retroarch 1.9.0, Mupen64+ plus more! (Current build: 200903)

I’m so glad it’s all working now! This would no doubt be a problem anyone wanting to play Blood would have if they updated their Debian to Buster, ie the current stable release. I actually haven’t played Blood yet, so this will be a great time for me to try it!

Also another thing. Re: your initial thoughts on copying a file to your PC, renaming it, then copying it back; be very careful with doing that in general, even for other apps. You could potentially lose permissions etc during the move process. You’re always better off doing most renaming/copying/moving processes via a command line.

As for how to check your clock speed, go into settings, scroll down to the about page. You’ll see both your clock speed and your kernel. That’s the easiest way. There are other ways to also check via the command line.

You don’t need to worry about changing it every time. What the script is doing is copying different .dtb files to the boot partition, setting the clock speed on boot. I’d probably mainly recommend turning it off when compiling big files. Sure it compiles faster, but if you’re using all four cores, boy does it get HOT!

@ghostronaut It’s definitely something that’s a part of the whole visual package, and my whole initial reason for making this custom image. I can’t take credit for the skin, since it’s just a special version for the DEOT edition Gameshells.

Now I see why they disabled the skin chooser in the original DEOT release!

That said, I will definitely be making some kind of switch script to allow standard skins to be used. I’ll probably also need to have another script to enable/disable the skins page from the settings menu, depending on which mode you’re in. I’ve posted the original files in that Post I linked you above if you wanted to try your hand at it.

At the end of the day, all of that trouble is simply to have a brightness and volume page that’s slightly different. Perhaps it’s not worth sacrificing being able to use different skins over this.

Speaking of which, thanks for reminding me - I need go standardise some applications to have their icon file only in the skin directory, and not in the source directory. Eventually I’ll run out of things to do with the image! :slight_smile:

Also!! If you ever do change your skin, and it refuses to boot, it’s actually just the launcher that’s locking up. You can still SSH to your gameshell to change things back. You’ll want to edit the contents of ~/.gameshell_skin (it’s a hidden file)
Just change the name of the skin you’re using to DEOT, then reboot with sudo reboot or just reload the launcher.

2 Likes

@ghostronaut
I’ve just made a small utility script to change from the DEOT customised skin_manager.py (for additional fonts) to the stock one, along with returning the stock pages to normal.

The activate script also temporarily disables the skin changing page in settings, since changing the skin in this mode will result in a frozen launcher. It also automatically activates the DEOT theme. (You will need to have the DEOT theme in the skin folder - I have provided an updated DEOT skin, just with an extra icon for the script)
Theoretically, if there is ever an official launcher update, it would overwrite the custom changes and anything else in the launcher directory. This can be a way to return some things back to the DEOT form, if it ever happens.

The deactivation script returns the skin manager to normal, and re-enables the skin manager page. It will also default the sound and brightness pages to their original form.
I’ve also included the OP-1 and canisminor theme I previously removed in the compressed archive, so you can edit your existing installation to be up to date with what the new build will have. No doubt I will have this as the default choice, so that people can have more initial freedom to choose whatever skin they want.

What's in the scripts

Here’s the activation script:

#!/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 reboot

And this is the deactivation script:

#!/bin/bash

sudo cp -r /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.stock/Settings/Brightness/ /home/cpi/launcher/Menu/GameShell/10_Settings/
sudo cp -r /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.stock/Settings/Sound/ /home/cpi/launcher/Menu/GameShell/10_Settings/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.stock/Settings/list_page.py /home/cpi/launcher/Menu/GameShell/10_Settings/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.stock/UI/scroller.py /home/cpi/launcher/sys.py/UI/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.stock/UI/skin_manager.py /home/cpi/launcher/sys.py/UI/
sudo cp /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/.stock/UI/slider.py /home/cpi/launcher/sys.py/UI/
sudo reboot

The files referenced are included in the compressed archive.

So in summary, and as a reminder to myself, the recent changes that will come in the next release:

  1. Update to retroarch 1.8.5, and update to assets/shaders etc.
  2. Retroarch update script
  3. Swapfile script
  4. DEOT custom settings toggle script
  5. DEOT theme moved to /home/cpi/launcher/skin, and only activatable now via above script
  6. XDO tools installed
  7. SCUMMVM modified to have a F5 key remap
  8. Small shuffles and cleanups to app icons
  9. PCSX Retroarch action.config and core added
  10. OP-1 and canisminor themes restored, and greey added
  11. 5.4.6 Vanilla 0.5 kernel selector added, in case you really want to change to the stock white boot splash screen

N.B. The skin toggle switch will be slightly modified from the above, changing to the default white 0.5 theme when deactivating, and moving the DEOT theme file to a different location. It’s just if you want to have things 100% the same as what I’m doing. I don’t think it’s important enough for me to re-upload the script, as functionally it does exactly the same thing - just makes it a bit more foolproof and less prone to having user error/breaking.

Thank you for taking the time! I have tried deactivating and then switching to a different skin, but it still results in the system getting stuck on the “Projecting…” screen for some reason? I tried with the “Greey” theme. Thanks for the tip about changing back the skin via command line, managed to un-brick it that way :wink:

(Just checked, the theme manager is still available in settings even after running the activation-script)

Ah, I forgot to explicitly mention - you will need to chmod +x each of the scripts!

So,

chmod +x /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/activate.sh
chmod +x /home/cpi/apps/Menu/60_Utils/11_DEOT\ Settings/deactivate.sh

You need to put it exactly in the directory mentioned above for the script to work, since it assumes that path.

Thanks, I did assume I could just run them from the folder on the GS :wink:
So I ran the activate script via ssh (it doesn’t output anyting, I assume that is correct?) then did a reboot of the system. It did something, as the background brightness has been reset. But the theme manager is still visible in the settings.
I then ran the deactivate script and switched to a different theme; default works. But both on canisminor and the “greey” theme the system still freezes for me.

Ah yes! It’s a huge assumption. The change of the mode to give it the executable bit (chmod +x) is kinda like, giving someone a car, but forgetting to tell them that you need to have a key.

Did you transfer the entire “11_DEOT Settings” folder? There are two hidden directories that could have been missed. Also, are did you copy it to the “60_Utils” folder?

There isn’t any verbose output, because well… I was lazy, and just made a simple script.

So to clarify, the activate script will activate the DEOT exclusive mode, thus removing the theme chooser, and activating the custom volume and sound pages.
The deactivate will re-enable the theme chooser, and disable the custom volume and sound pages.

Just for now, try an switch to the default theme, and then immediately change to another theme. It’s strange, because it’s working for mine, and we should be on practically the same image.

I’ll probably get around to uploading the current custom image tomorrow, if you’re having trouble getting it to work. That said, I do try and provide instructions for people to do things themselves, so they don’t have to constantly start from scratch.

I just read something from your previous post:

You shouldn’t have needed to do a restart, since a reboot is actually included in the script. If it didn’t reboot, then something is possibly amiss!

Possibly try and run each line manually, and see where the error is. See this post, and expand the details:

I’m fairly sure that the problem lies in the source files not being in the expected directory; be it either that they didn’t get transferred, or they were placed in the wrong directory.

Also, you should just be able to run the scripts from the launcher. Although the fact that there was no output running them from an SSH session means that there wasn’t any error, so it ran correctly. The plot thickens! I’ll get back to you tomorrow. It’s midnight and sleep beckons me!

Sorry if it came across wrong regarding my assumption – the fact that I assumed I could run it just like that simply stems from the fact that I have very little knowledge about command lines, linux or anything really, haha. Just winging it :slight_smile:

So, the 11_Deot Settings folder is definitely in the correct spot, the hidden subfolders also have been copied over.

Anyways, no rush :wink: Have a good night!

Edit
Ah, now it works from inside the launcher. Previously it didn’t work because I had moved the 11_Deot Settings folder to the wrong spot. After I fixed that I only tried via the command line with chmod +x which didn’t work, as I described. But now I tried it again from the launcher and now it works.

1 Like

PHEW! I was worried I messed up somewhere!! Mm I probably should provide clearer instructions on how and where to install the scripts.
I just assumed that anyone wanting to do them by themselves instead of waiting for the next release have a background using Linux. Thank you so very much for letting me know what to do in future! :slight_smile:

Also, for the record, the chmod is just a means to change the mode of the file. It doesn’t actually run if. If you want to run something, you type ./activate.sh
If the file you’re trying to run has the permissions set to execute, the file will run. :slight_smile:

It’s great the you’re using the gameshell as a means to learn how to use Linux. For the record, I just do this for fun. I’m nowhere near as good as the people here who actually know what they’re doing! But hey, I’m happy to help out where I can! We all gotta start somewhere. :slight_smile:

Having no after work extra curricular activities means I get stuff done.
Apologies for having new releases every 4 days. I just kept on finding new things that could be improved upon/fixed, and updates that could be applied.
Now that I’ve got most of the recently discovered kinks ironed out, this next build should be one that will sit for a while, unless something major surfaces.

If you were waiting for a relatively stable release to come out that will be staying for a while, now is the time to try out using the image.
That said, now that I’ve said this, more people will probably try this and find more things that can be fixed!

DEOT v2+ Build 200327
27th of March 2020

  1. Update to retroarch 1.8.5, and update to assets/shaders etc.
  2. Retroarch update script
  3. Swapfile script
  4. DEOT custom settings toggle script
  5. DEOT theme moved to /home/cpi/launcher/skin, and only activatable now via above script
  6. XDO tools installed
  7. SCUMMVM modified to have a F5 key remap
  8. Small shuffles and cleanups to app icons
  9. PCSX Retroarch action.config and core added
  10. OP-1 and canisminor themes restored, and greey added
  11. 5.4.6 Vanilla 0.5 kernel selector added, in case you really want to change to the stock white boot splash screen

As usual, you can find the links to the download in the first post of this thread.

Please stay safe everyone, and enjoy playing your Gameshell in the comfort of your own home. :slight_smile:

1 Like

thanks for your update, but I think 50_PicoDrive and 45_Wswan’s action.config are not correctly. The PicoDrive is being set to GPSP core, and Wswan is labeled ‘PCSX Roms’ :smiley:

1 Like

Thank you so much for thoroughly checking this! These are things I honestly overlooked!
Lets see. So one at a time. I checked the Wswan action.config. Thank goodness, it’s just the title that was wrong. An easy fix. I copy pasted the action.config from the GBA as a template. Haha you’ve seen through my lazy ways!

Here’s a fix:

ROM=/home/cpi/games/WSWAN
ROM_SO=/home/cpi/.config/retroarch/cores/mednafen_wswan_libretro.so
EXT=wsc,zip,7z
LAUNCHER=retroarch -L
TITLE=Wonderswan Roms
SO_URL=https://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/mednafen_wswan_libretro.so.zip

And ha! While making the PCSX Retroarch core, I used the PicoDrive action.config as my template, but evidently got mixed up which one was the source and destination! That would explain why it happened like that!

Here’s a fix:

ROM=/home/cpi/games/MegaDrive
ROM_SO=/home/cpi/.config/retroarch/cores/picodrive_libretro.so
EXT=bin,zip,gen,32x,smd,iso,7z
LAUNCHER=retroarch -L 
TITLE=PicoDrive Roms 
SO_URL=ttps://buildbot.libretro.com/nightly/linux/armv7-neon-hf/latest/picodrive_libretro.so.zip

Thanks for testing it thoroughly to find these! I’ll upload a new version to include these changes. Let me know if you need any assistance with replacing the contents of the action.config files. I’m assuming by the sound of things, you know how the action.config works. :slight_smile:

Edit: Aaaaand it’s uploaded. It’s the same build number, since it’s just a slight revision of something that is trivial to fix.
I’m about to upload a mega link. Watch this space!

3 Likes

yep, after finding these problem, I was abled to fix it myself, lucky me :smiley:
Ah, one more thing, and it seems to appear in your previous builds too. The chocolate-doom key binding, I can’t ‘Fire’ with any of GameShell key.
I had a look at .chocolate-doom configurations but just too lazy to learn about keycode. I don’t play Doom, but, just in case anyone has same issue like me. Could you please take a look?

Thanks, anyway, believe it or not, I keep watching your post everyday and looking for improvements you made. Great work, man :slight_smile:

Thanks to you actually! I’ve honesty wanted to have someone who’s willing to help me test out everything. You’re doing me a huge favour doing this! It means a lot that you keep checking every day!

As for the fire key, I have currently mapped it to “snes X”, ie the North action key.
This is to have something useable on a gameshell without a lightbar setup. At least that’s how I thought I had it set up.
Oh my goodness. Somewhere along the line it got wiped! Possibly, while doing the buster update!
To be honest, I’ve actually been using zdoom to run most of my WADS lately, so didn’t actually check to see if it was working. I’ll need to write an older image to a spare card to extract my previous config files and post them up. Thanks for finding this out!

My testing involves 3 gameshell images: Card1: a 32GB card that I mess around with test things and break things to find things that work (it gets wiped a lot), Card 2: a stock 16GB card that I apply the findings I make on Card 1 and base all of my clean images on, and ensure works, and Card 3: a 128GB day to day image filled with test roms, to ensure that most games run, and that incremental updates can be successfully applied.

Sometimes, things I do in one card get lost along the way, going between them. So having someone who can help spot when I make silly mistakes is greatly appreciated! It happens. A lot!

On another note, you can edit the doom/heretic/hexen/strife config on the gameshell, executing the configs via the dinguxcommander in utilities. It’s located in:

/usr/games/chocolate-doom-setup
/usr/games/chocolate-heretic-setup
/usr/games/chocolate-hexen-setup
/usr/games/chocolate-strife-setup

You can input each key one at a time till you have something that works. No need to work out key codes/hex values, or editing of the config files. The config file is located in /home/cpi/.chocolate-doom/ if you ever wanted to back it up or anything.

Here’s some super rough configs I just whipped up.

Copy them to /home/cpi/

I’ll include this with the next release.

cant wait for release~! :crazy_face:

1 Like

And done! Build 200328 is exactly the same as 200327, just providing a tiny hot fix to include a config file for the chocolate doom/heretic/hexen/strife wrappers.

Since it’s identical to the file posted above, if you’ve already downloaded and installed build 200327, you can just update if with that file.

It’s not actually essential at all, since you can just configure it yourself. You might not even like my config, since I have it set to a gameshell without a light bar.

In a nutshell, here’s what it is.

D-Pad = WASD FPS style movement.
Shift Up/Down = look up/down
Y/A(east/west) = turn left/right
X(north) = Fire
B(south) = Jump (if available) or centre view
Start = activate/confirm (yes)
Select = use item
Shift Y/A = scroll weapons left/right
Shift Select/Start = scroll items left/right
Shift Menu = map

In Hexen, once you get the ability to fly, you will probably need the light bar, since we’ve run out of keys fo fly up and down.

Any more hot fixes I make I will provide instructions and files for fixing them yourself, in addition to uploading a new image that has the hot fixes applied. You can consider the 200327 to be a solid check point to work from. I should really change my versioning naming convention. Eh. Dates make it easy.

As usual, the custom image can be found in the first post of this thread.

Let me know if you find any more things that need fixing.

1 Like

I create two link for cn user, u can post it :wink:

https://mega.nz/#!pMpATKiB!VfsJSGyg0F12shpIFZU7UFM2RRoDEmgaTr1V7hQe5tM

https://www.multcloud.com/share/8947b1fc-653e-4254-ab5c-5c62d257a0f7

1 Like

Thank you so much! It definitely helps a lot! I usually do a mega upload myself. I just keep forgetting to put up the link! Haha!
Anything to help make it easy to download is good thing! More people to test things out, and improve upon the image. :slight_smile:

2 Likes

If it helps at all, the 5.4.6 kernel with your latest image is the highest i can run without screen flickering. great job doing these!

1 Like

Thank you very much! :slight_smile:
This is some useful information. I need some data, so I’ll try and run a poll. To check what SoC you have, look at the CPI mainboard. You don’t even need to take it out. The big black square will have R16 or R16-J written on it.

I have the …

  • R16 and it flickers with kernels 5.4.21 and above
  • R16-J and it flickers with kernels 5.4.21 and above
  • R16 and it doesn’t flicker with kernels 5.4.21 and above
  • R16-J and it doesn’t flicker with kernels 5.4.21 and above

0 voters

I personally have a Beige stock R16 board from June last year and a DEOT R16 board from February this year. Both of them behave nicely. I only got some slight flickering after trying to build Retroarch using 4 cores on the 5.5.9 kernel overclocking to 1.4GHz. It got ridiculously hot. I wonder if that’s it; heat tolerances.

I’m in the process of getting a R16-J board to test, although theoretically there should be no difference between the R16 and R16-J. If anyone can think of any other discernible manufacturing discrepancies between boards, let me know!

For me the only one that is not flickering is 5.3.6…i’m in a R16-J and I tried all the other without the overclocking

1 Like