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)

Just for comparison, here are the two stock window managers side by side. Left one is DWM and right one is TWM.

You can see how they are comparatively. TWM is smooth, whereas DWM is snappy.
I do recall that DWM is painfully slow via HDMI. I’ll try it out later, comparing the two. Hopefully TWM is faster.
Potentially, I could even have one window manager for handheld and one for HDMI.
The next question is: who actually uses HDMI with the Gameshell often? I only use it when playing PokeMMO personally.

Just reposting this poll in case it was missed:


it doesn’t make sense, the wm just place window on the screen, arrange their size and read events

dwm is pretty minimalist, like monsterwm
twm else is more for a desktop use, can showing title bar & co

so dwm must be the fastest, but any of them must be invisible in performance

100% Agreed. It would be next to negligible given the resolution, and the inability to really have multiple windows.

The main thing that gets affected are things like Retroarch that can specify to be run in a window mode, vs full screen. That presented a problem using TWM, even specifying a windows size. I had to revert to fullscreen.

The only reason I can see for running TWM as the default over DWM is for HDMI use, and to have less redundant apps, if having both. As mentioned above, DWM performs terribly over HDMI for some reason.

One thing I have noticed since switching to TWM is Retroarch having a visible mouse cursor now; even in handheld mode. Useful, especially if using the mouse mod flashed to the arduino.

This is mainly a reflection of what is covered here:
If this indeed is going to be what is standardised in the future, tackling it early, and giving feedback can be a good way to test it before implementing it; using the modified DEOT OS.

1 Like

@javelinface I am experiencing a booting loop with the latest version on startup that eventually results in a blank white screen.
My gameshell resets at the clockwork logo continuously. I tried plugging it into power.

I thought this might be the partition expanding onto the 32gb card but I have now bricked two SD’s (oops)
I have tried reformatting them with command prompt and a Mac computer but no luck. They remain corrupted and/or inaccessible.

I don’t think this is your image I think the download or flashing process might have had issues.
I will try updating etcher tomorrow and downloading the image again before flashing it.

I am using the Kickstarter edition of the GS if this would cause issues

Interesting. The Kickstarter one may have been a generation 1 CPI.
Can you confirm whether or not it has an HDMI output on it?
One thing you could possibly try is changing the kernel of the image.
I’ve got a link to a compressed archive with two folders; one with the stock kernel (0.5) and one of the older stock DEOT kernel (0.4)
The older kernel was before change were made to make the GPU Drivers work. See if this helps.
You’ll need to plug your SD card into your computer, mount the Boot partition (it should by default) and then replace the contents with what is in the DEOT kernel folder.

Is this a problem you’ve got with the stock 0.5 image too? And when you say bricked SD card, can you not write to it anymore? I’ve had some cards entering a state where you cannot write to it, no format it; entering a protected mode. This happens especially with my old GO PRO 3+ when it runs out of power, and abruptly interrupts the writing of data. Something similar could have happened here.

FWIW, with my Sandisk cards, I’ve contacted their RMA dept. they are aware of this happening and generally ship out a replacement card for free, no questions asked, after you send in your faulty one. No receipts were needed even. Who keeps receipts for SD cards?

This leads to another thing that could be happening if you have a kickstarter edition is your battery could be on its way out. I know my older gameshell sometimes has trouble starting up, unless it has the power plugged in. It will sometimes just turn off as well, even though it reports 40% power is left. Batteries are just a consumable part of electronics these days, just like phones and laptop batteries.

Yes it is generation 1 CPI, there’s no HDMI just a micro USB.

I try a stock 0.5 image tomorrow. If that works I’ll replace it with yours and try again.

Exactly like you say the SD’s are unreadable and refuse to be read or written to despite me trying several command processes and workarounds.
It seems the gameshell is repowering continuously because windows made beeps every ten seconds when it turned back on.

The system works fine with my original OS on the SD that came with the unit. Battery life is about five hours emulating SNES.

It sounds very much like a write protect fallback, after an erratic power problem. Might be worth starting a new thread over it, regarding how to recover from it. What I can offer for now I this:

But the more pressing and important issue at hand is the fact that there may be other users out there with a kickstarter first gen CPI. I just assumed most people would have upgraded to the new board when they offered free postage etc. I’ve never owned a first gen cpi to test on so honestly can’t say either way how things would run.

When you say your original OS that came with the unit, that would have been … gosh, 0.2??? Or 0.1 even? You’ve been here since the beginning I take it? If you ever upgrade to the 3.1 board, you’ll be in for a world of difference!

Perhaps for now, try a 0.3 or 0.4 image. I have a feelin the kernel is behaving. 0.5 comes with 5.3.6 stock, but also has 5.4.6 tucked away ready to be renamed and used. It isn’t used by default, due to some compatibility problems with different batches of soc.

I have the Kickstarter board (no hdmi and half the ram) and the stock 0.5 runs fine.

1 Like

Phew! You saved me having to write a disclaimer!
I guess that rules out having to use an older kernel for the older board.

It could just be an old card, which has been written too many times, with bad sectors over the threshold amount.

If it’s using the current DEOT 200128 build, that one doesn’t do the automatic resizing, re: any concerns about partition etc. Besides that, it is basically a stock 0.5 image, just with a few things updated and fixed up. None of them should affect any of the core functionality or startup of the image relative to stock.

You’re right it’s an error somewhere on my end.

The second SD I tried it on was brand new.

I will try the stock 0.5 OS on a new SD and redownload your image in case something went wrong there.

In the meantime I’ll probably purchase the new CPI also.

1 Like

@javelinface do you recommend the full DEOT Gameshell for this project?

I could upgrade my CPI but I note the DEOT has a better battery.

And a pretty badass appearance.

1 Like

Oh??? Is the battery actually better??? I actually thought they were the same! Now I need to check!
That said, it seems you can’t get official batteries from the store now, so I guess if you like the look of the DEOT (I realty do), it’s a good excuse. That said, having two Gameshells is expensive! But hey! It’s certainly served you well!

My two cents would be at the black theme :joy:

Battery savings from using a dark theme with OLED screens are drastic: Google saw battery life savings between 15% and 60% when it moved from YouTube’s default white background to the dark mode.

1 Like

Agreed! The contrast is better too, so for just menu use, you can dim down the screen; plus it’s easier on the eyes!

Ok so I redownloaded the image last night and updated Balena etcher to the latest version.
The problem was still there, so I reflashed with the stock 0.5 OS.

Same issue. The gameshell perpetually restarts when turned on.

It still works fine with the original OS.

What can you do…? I will just have to save up and wait for the newer units to go on sale. :grin:

I have had this exact problem before, and basically did what I mentioned re unplugging for long periods.

Check out this thread. Sounds like a similar problem to yours.

A thought.
It only really charges when the logic board tells it to. Use the old image that works to fully charge your battery perhaps.

It’s strange that it’s only the new image that is affecting things.
Just try this for now. Replace the contents of the boot partition with the files in the here. That’s the only thing I can think about.

Hi Javelinface,

I just flashed the deot_v2+ 200128 img and noticed that RetroArch is not in a good shape. UI elements are overlapping/overlaying each other when moving in the menu, sometimes hangs the device.

I was wondering if you can tell if you have time and plan to roll out a new release soon with the fixes mentioned above?

Thanks in advance

This is just the XMB menu. It was excluded in the stock release, possibly for this very reason. I included it for people who use the Gameshell in HDMI mode; something I do a lot. It becomes a lot more readable on a big screen. Although did you mention overlapping menu components? That sounds like the assets haven’t been downloaded for some reason. You can redownload the assets in the online updater page in Retroarch. It also shouldn’t be hanging the device. Are you using the Lima graphics mode?
You can change it to the regular rgui mode by going into the drivers setting page in Retroarch, and changing the menu driver to rgui. That should be less taxing on the Gameshell, but less of a standalone GUI for loading and arranging Roms. I made a screen shot in this post
I have an image that is ready to go, but haven’t uploaded it yet, since it only has minor hot fixes here and there. I’ve provided instructions on how to apply the fixes in the most recent posts above. This is due to a lot of people not wanting to have to wipe their images just to apply a small change. Are these the fixes you are referring to? Or just the ones from your own post?
I’ll upload it today, and have the release notes written up shortly after.

DEOT v2+ Build 200224
24th of February 2020

Current changes:

  1. xbindkeys installed to allow key shortcuts to exit/kill apps that don’t have easy termination processes. eg, sampler box and scummvm.
  2. Samplerbox shortcut in utilities. (Exit it using menu key) thanks @edward
  3. Scummvm shortcut made in Retro Games. (Exit using shift+A+B+X+Y) You will still need to sudo apt-get install scummvm. I have omitted from doing this on this release, as you will not be able to use this unless you’ve installed the mouse mod to the arduino. Unfortunately, I can’t do this from the image end.
  4. Slightly modified .xinitrc that uses twmrc in HDMI mode, but sticks with dwm-mod in handheld mode. There were no benefits in hand held mode, and it only made the interface slower. We’ll see how the mainline image tackles it in the future, and go with whatever is chosen then. I personally don’t have this on my day to day image, but I know that people will complain about the slower menu speeds.
  5. Cleaned up and optimised mupen configuration, and action.config to reflect using a /usr/local/bin file location.
  6. Quake 2 shortcut removed.
  7. Returned freedoom part 1 and 2 - I previously deleted, while culling all games.
  8. DEOT Skin settings items modified to have the appearance of stock, with the colour of the DEOT interface. I still can’t get the modified items to work. I believe it’s a font issue or something else referenced in the file.
  9. The OP-1 theme has been returned, and adequately doctored to reflect the new file structure of 0.5. Likewise, Canisminor has been included with similar fixes.
  10. Fixed the vertical justification of the /etc/motd file so that the welcome splash message better reflects the stock DEOT OS.

Previously mentioned updates reiterated, with links to initial post:

  1. Tweaked retroarch config to try and have more of a focus on vsync and screen tearing issues, than audio timing/skewing. It seems that most people care about visuals more, than actual frames and audio quality. On my day to day image, I personally prefer to have Vsync off, and just have audio sync, since it gives more reliable frame rates, and better audio. But screen tearing is what people see, so lets see how this goes. see here
  2. Font overlap fixed
  3. DEOT Apps cleaned up
  4. Cleaned up some of the retroarch directory structure
  5. The initial tweak to the .xinitrc reference to the window manager

Things I haven’t done:

  1. Installed Emulationstation. It’s just not reliable/stable enough yet.
  2. Installed Brutal doom. Not everyone will want this.

It is being compressed and uploaded as we speak. For now, it’s on google drive, just so I can set it and forget it while I go to work. I’ll provide a mega link later.
It might also just fail uploading, because I live in Australia, and we have terrible internet.
The link will be the same one in the original post


It may be worth considering changing to Ozone for the interface as it appears that will now be the default in Retroarch. I haven’t tried it on Gameshell, but if the main development effort is there, it might be a good default to use if it’s stable/working on Gameshell.

Also, sorry I kind of disappeared. Haven’t had the time to completely move my stuff over from the old broken card, and set up the dev environment stuff again. I need to just take a whole day and do that :frowning:

1 Like

Oh haha, I also disappeared! My last update was a month ago! Life is… it is hard! :smiley:
I actually did initially use the Ozone interface, but that was WAAAY back before Lima was working, and well, basically, you couldn’t tell what was highlighted with the half done drivers.
The good news is, Ozone menu UI capabilities are also installed with this retroarch build, so you CAN in fact change to it. I’ll just need to tweak it a bunch to make it fit the 320x240 screen. As it is now, it barely fits!
I just mentioned rgui above, since the user was mentioning lagging menu problems and freezing. Rgui is about as bare bones as it comes - and looks absolutely horrible!
I fully agree with the move to Ozone.

Well this is annoying. Even changing to menu_scale_factor = "0.200000" doesn’t appear to make ozone’s scaling change. This is meant to be the official way to change the dpi scaling. Although, this is probably assuming more that people want to scale it to fit their larger 4k displays; not the opposite.

I’m going to investigate more to see what can be done.

The only ozone specific parameters are:

ozone_collapse_sidebar = "false"
ozone_menu_color_theme = "1"
ozone_scroll_content_metadata = "false"
ozone_truncate_playlist_name = "true"

Not much to work with. @adcockm See if you have any better luck.

1 Like