clockworkpi

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.8.9, Mupen64+ plus more! (Current build: 200626)

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

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 :slight_smile: 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 :slight_smile:

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 :slight_smile:

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 :smiley: 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 https://github.com/r043v/GameShell-PKGBUILDs/blob/master/linux-gameshell/PKGBUILD#L82-L126

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 https://github.com/r043v/GameShell-PKGBUILDs/tree/master/linux-gameshell

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 :slight_smile:

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