Hello, I installed the most recent image about 15 minutes ago. I figure this was unintentional, but it would seem a copy of Megaman 3 was left in the NES folder.
1 Like
I tried to flash the image 5 times now but my GameShell refuse to boot…
Tried image from Guu link and Javelinface link.
I am using a 256gb card that was working before.
1 Like
Thank you so much for letting me know! I hate it when I leave files behind like this. It was meant to be cleared out!! I’ll get onto sorting this out ASAP, legality wise.
For @lix and those that are having trouble making an image, can you let me know what program you’re using? @develroo when you burnt the image the second time, was the boot partition still empty? Sounds like it could be a hit or miss thing in that regard depending on the flashing process. Also apologies re: control inputs!! I ran a poll a bunch of posts up asking which control interface people use, and the SNES interface came out on top. Hopefully you got it sorted. You can change it in the settings.
@Petrakis Basically, the edits made were the ones made by @guu a few posts up. He zeroed the empty space to make the image smaller, and added an expand_rootfs script. Custom D.E.O.T. V1.0+/Clockwork OS v0.4 image - With Updated Kernel 5.3.6, Latest Lima Drivers, RA1.8.1, Mupen64+ and much more! (Current version: 191122)
The only edit I would add would be adding something as you said in the form of an echo display prompt to say that it’s expanding. Also, I’d get rid of the mega man 3 rom haha. I’m only using VMs and USB boot sticks, and since my initial image is 16GB, I’ll need to make a larger environment to properly edit the images, since the expand_rootfs automatically culls itself upon execution. I’ll look into it later, but if you’re happy to help out, that would be great! For now, I’ve just provided an alternative file without the modification above applied.
Yeah… I ddrescue it in the end and fsck’d it after just to make sure. Seemed too work ok. So maybe just bad luck first time.
Otherwise seems to work ok. Just not sure what the whole extra things are. The Manual and all the apps are in Chinese so no idea what they are referring to. Is it just an effect or something ? Is there an English translation for it ?
1 Like
Ah sorry, I forgot to reply to that part. Yeah, they’re all just “for fun” and to add to the cyber edge lord hacker appeal. It was a part of the whole DEOT experience in the last game jam, and matches up with the DEOT edition of the gameshell. It literally stands for Dimension Engineering Operation Terminal.
You can pretty much just ignore them, and not worry about translating them. For all intents and purposes, having them in a foreign language (Chinese) adds to the whole mysterious appeal of having acquired a cyber punk hacking device.
So yeah, it’s just an effect really. As for a translation I believe they are all written in Love, so you will need to know how to write in that language to make any translations. They’re all images from what I can gather, so it wouldn’t be a quick copy paste of a text file. If anyone wants to translate it, that would be great!
1 Like
Thank you so much for letting me know! I hate it when I leave files behind like this. It was meant to be cleared out!! I’ll get onto sorting this out ASAP, legality wise.
Also check the GBA, MGBA and mupen64 folders if you haven’t yet. There seem to be a couple of roms left behind.
Great firmware image otherwise, good work.
1 Like
What… ohhhh no. I was using an image I was individually testing Roms with, after doing the Lima driver update. I must have been way too excited after seeing how well it worked, and rushed out the release. Right.
I’ll have to wait till the weekend when I have a bit of free time. For now… just… ignore it.
Hopefully pico-8 isn’t installed, since that’s something you can buy and pay for today. Thank you soo much for letting me know!
I’m guessing Megaman 3 NES, Banjo Kazooie N64 and Mother 3 GBA?
yup. MegaMan3 Banjo Kazooie and Mother 3. No pico-8 installed.
I played around with the image a bit and it mostly seems to work great but there seems to be a weird thing with the lima driver where under certain conditions it becomes broken and it will use fbdev even when switching to lima in the settings menu. It happened to me 3 times now and I couldn’t recover from that and had to reflash the image:
- when running an apt upgrade and rebooting
- when trying to enable vsync in quake (through quakespasm)
- when switching to fbdev/fbturbo and trying to switch back to lima
It seems to impact retroarch which slows down to a crawl becoming completely unusable and quake, which also slows down to 2 FPS in the menu while htop shows 100% cpu load.
Other emulators like gpSP still seem to work just with slightly worse performance.
dmesg and journalctl don’t show any errors so I couldn’t figure out what the problem is.
1 Like
Yup, that sounds like what @guu said, re installing the drivers in the user directory, and it being just a temporary means to test out the Lima drivers. An apt upgrade will end up breaking it.
Earlier, there was a post from @shell, mentioning how the driver works. That should hopefully shed some light on what was happening re: driver changing problems.
As for Retroarch slowing to a crawl, definitely sounds like it’s due to a lack of Lima drivers caused by the above problems. I’ve got the config set to the XMB interface that only really behaves with Lima. A solution temporarily is to change to the rgui menu driver.
Re: quake and gpsp not working well, is this just on a clean image, or after doing an apt upgrade and/or switching drivers?
Definitely worthy of knowing, bug testing wise re: things that will just not behave. I’m fairly sure these problems would occur, even if you applied the kernel/Lima driver update on a vanilla 0.4 image. While I’m here, also a reminder to not change to the other two launchers for now. I had problems with booting after doing this. It’s not an important feature for now, so I haven’t looked into it, but definitely will when I do the other tweaks.
Thank you so much for testing the image so thoroughly!!
why don’t you simply use my custom apt repository and provide .deb packages for mesa-lima and others ?
this would throw away all your apt-get update issues and remove all the self user compiling part
As for Retroarch slowing to a crawl, definitely sounds like it’s due to a lack of Lima drivers caused by the above problems. I’ve got the config set to the XMB interface that only really behaves with Lima. A solution temporarily is to change to the rgui menu driver.
The image I downloaded seems to use rgui by default. but even that becomes unusable. Anyway, I just got to wait til the lima driver is more stable before I can get Quake working. (I haven’t tried recompiling mesa and lima after using apt. maybe recompiling against the updated libraries fixes it?)
That would be possible, but is easier said than done. Someone would have to maintain the packages and recompile against newer libraries. Let’s just hope that lima keeps on making progress and the CPI kernel changes will be merged into linux-mainline. That would open up the device to a ton of customization as you could easily run other distributions on the device and update using the package manager that comes with the distribution without breaking things.
2 Likes
You took the words right out of my mouth.
With the current Lima updates installed in the user directory, I don’t believe it would an easy push. I’m intending on waiting for the devs to base a new 0.5 version or later using some of the recent finds.
@r043v If you’re keen to look into using your custom apt repository, that would be great. For now, it’s also a problem with doing an apt (I don’t use apt-get personally since it’s technically older than apt - but that’s just a personal choice and a topic for another day) updating the dynamic library, but not currently being compatible with the current driver configuration. It’s not technically a hard thing to do, but will also need to be done before using a custom repository.
If you can provide a link to your custom repository, that would be great.
@CommanderKitler I’ll try an apt upgrade, then recompiling things. Thing is, with buster as the stable release now, I’d have to really test the craziness out of it to make sure nothing else breaks. I released the image as it is now, since @guu tested his findings on my image; so I wanted to keep as many variables the same as possible.
Previously when I installed buster a few months back, before it got moved to the stable release, switching drivers broke, no doubt due to the dynamic library no longer being correct as mentioned above. There were also reports of Bluetooth and sound problems.
Maybe things are better now. Either way, I’ll upload a test image if you’d like, and for anyone else who wants to test things out. (And get rid of those Roms!!!)
As for the menu, ah yes you’re right!! I did set it to RGUI, fearing people may have compatibility/speed issues. I personally always use the XMB menu driver, since it makes accessing Roms within Retroarch easy, once you’ve populated your library etc, including cover art and info.
Before it gets too buried, here’s the post with the download links:
here was the forum thread about the custom repository > Gameshell ecosystem?
repo is at this time for stretch debian release
1 Like
There seems to be development going towards buster, and with it now moved to stable, I wouldn’t be surprised to see it become more mainstream in any upcoming official releases.
Eg,
I’ll wait to see what happens before investing time and effort into something that may become obsolete. But by all means, if you can do it, I’d love to see your results.
Just as a side, which quake were you trying to get running? There seems to be an older thread with it working.
More to the point, did the recent driver changes/kernel inadvertently break quake 1 working? I haven’t actually tried it myself, so can’t really comment either way.
I basically did the same thing described in the thread. I had the .pak files in a different location for testing purposes, but that shouldn’t make a difference. It runs smooth with lima but it won’t render properly with artifacts on the screen making it unplayable. In software mode using fbdev it renders fine but it runs at a framerate comparable to retroarch (<1fps) so I guess the current version of lima breaks it.
1 Like
Oh I have to update that post, as the new version is released
1 Like
Whoops! I think I pasted the wrong link as the example of development moving towards buster! Haha I was definitely looking at integrating your work into a future release @Petrakis
All the better for keeping things up to date and current! 
On the other hand, re: quake being broken, if anyone wants to use a version of the image without the newer kernel and Lima drivers, have a look at first post of this thread, and download the 191111 version that @guu has uploaded. It will have the original 0.4 kernel and drivers, and will have a functional launches switcher, and anything else that may have broken since the kernel/driver update. In the grand scheme of things, I guess you could call the 191111 version stable and 191122 experimental? That said I use the 191122 as my daily driver with no real consequent adversities.
Ok so I got Quake running (kinda).
At first I tried to get eduke32 running so I cloned the git and ran make … missing libraries/includes. So I used apt to get the missing files (yup bad idea) and voila - it built successfully. I used scp to copy the game files and started it and it ran awfully. The same with retroarch. So getting the dev-files through apt broke lima. I backed up my user directory, flashed the image, scp’d the userdir and played some duke3D. I then realized the problem with quake was me using apt to download quakespasm. So then I got the quakespasm source code and tried to compile that but a lot of libraries where missing. To fix that I did the only “rational” thing - I downloaded the deb packages to my archlinux desktop, unpacked them and copied them onto the sd (overwriting most of the older libraries on the image)
that shouldn’t have worked but it did.
So i set up Quake aaaaand had the same horrible graphical glitches as before.
That was when I started to take a look at quakespasms manpage and saw that there was a couple of OpenGL extensions that could be disabled:
-nomtex
Disable the use of the OpenGL multitexture extension.
-nocombine
Disable the use of the OpenGL texture combining extension.
-noadd Disable the use of the OpenGL additive texture environment
extension.
That got rid of the worst glitches.
It still has some problems:
- 2D assets like sprites and particles are not rendering their alphalevel properly (transparency) so all 2D assets have pink squares around them
- Shadows don’t render properly they have a kind of weird zebra-effect to them
- Certain lights flicker very badly
- there are some slight clipping issues with enemys flickering through walls at certain times.
Some of the same glitches can be seen in eduke32 when using the standard renderer instead of the classic one. So I guess the version of lima/mesa used in the image has some extensions broken that still work in the official 0.4 image. And it seems that it is not updated libraries that break lima it is just apt in general.
1 Like
Definitely sounds like an artefact of having the drivers installed in the user directory, then doing an apt upgrade.
Just to clarify; was the remedy more or less to do the above, without having done an apt upgrade? Another solution i might look into is doing an apt upgrade, and THEN doing the Lima driver upgrade AFTER. Theoretically, installing quake/duke should work.
The glitches that are present sound similar to those experienced in mupen64. That said, they’re still an improvement over what they were before, ie huge black boxes and chuggy performance. Given they’re the same problem, it might point us towards a solution. Thanks for posting up your findings!
For testing, could you share your unpacked deb files that you copied over, with your changes to extensions? I am extremely curious now!