search

MichaIng / DietPi

Lightweight justice for your single-board computer!
https://dietpi.com/
GNU General Public License v2.0
4.85k stars 495 forks source link

DietPi + AmiBerry | Optimized installation for Uae4arm #474

Closed Fourdee closed 8 years ago

Fourdee commented 8 years ago

Collaboration with the creator of AmiBerry (Dimitris):

https://blitterstudio.com/amiberry/

Notes:

https://github.com/Chips-fr/uae4arm-rpi https://dietpi.com/docs/software/gaming/#amiberry

RetroPie claim uae4all2 is quicker than uae4arm: https://github.com/retropie/retropie-setup/wiki/Amiga#emulators-uae4all2-uae4arm https://github.com/RetroPie/uae4all2

Legend

:u5408: = Not started :u55b6: = In progress :u6307: = Completed

Compile for:

:u6307: ARMv6 (RPi 1, if performance is acceptable?) :u6307: ARMv7 (RPi 2/3, should offer performance improvements using an updated arch) :u5408: Optional: Other devices (eg: Odroids / VM). :u6307: Host binaries on https://dietpi.com/downloads/binaries/bullseye/ respectively

DietPi-Autostart

:u6307: Add Amiga emulator boot option.

Documentation

:u6307: Instructions for the user after installation. eg: Where do they put their roms and firmware files. Example: https://dietpi.com/docs/software/gaming/#amiberry

For reference, the differences between the DietPi-AmiBerry and standard DietPi image:

Fourdee commented 8 years ago

@midwan

I think we can improve performance in Uae4ARM by setting 480p resolution if user selects Uae4arm autoboot option. Framebuffer size has a direct impact on RAM performance as framebuffer (display) shares the same memory and bandwidth: https://www.raspberrypi.org/forums/viewtopic.php?p=104973&sid=44bbe222489dcc082fcdf6faeccef711#p104973

So in theory, the smaller the resolution, the faster the memory throughput on RPi. Its not much, but every little counts. And the Uae4ARM menu looks great in 480p (full screen). img_20160829_143415

midwan commented 8 years ago

Not a bad idea, as long as the user is still able to use higher resolutions if they want to. For example, I use my Workbench at FullHD resolution - it's great for working on graphics apps, coding, multitasking, etc.

For games, you certainly don't need more than 480p of course.

On another matter, there seems to be a bug in Raspbian installations which makes the Scroll Lock key non-functionaly (the LED does not even turn on on the keyboard). I've managed to locate a fix for that, but I haven't checked if you already have addressed this in DietPi. The solution is to copy the attached file in /etc/udev/rules.d and then run udevadm control --reload-rules and reboot.

Can we include this fix in DietPi? It should benefit everyone if it works. 50-leds.rules.zip

Fourdee commented 8 years ago

@midwan

Not a bad idea, as long as the user is still able to use higher resolutions if they want to. For example, I use my Workbench at FullHD resolution - it's great for working on graphics apps, coding, multitasking, etc.

As far as I can tell, the emulator supports max 768x270 resolution via GUI. I did try raising these to 1080p (1920x1080) in autostart.aue, but locked up emulator on start. Maybe I missed something? 480p is 858x480p, so still higher than max uae4arm rendering resolution.

The RPi always outputs at 1080p, but the framebuffer size determines internal rendering (actual visible) resolution. It can even be set to 16x16, funny to watch hehe

root@DietPi:~# cat /DietPi/config.txt | grep framebuffer
framebuffer_width=854
framebuffer_height=480

Can we include this fix in DietPi? It should benefit everyone if it works.

Yep, I'll get this added for all RPi's :+1: 

cat << _EOF_ > /etc/udev/rules.d/50-leds.rules
ACTION=="add", SUBSYSTEM=="leds", ENV{DEVPATH}=="*/input*::scrolllock", ATTR{trigger}="kbd-scrollock"
_EOF_

note to self: Just needs testing

midwan commented 8 years ago

The config window is hardcoded to show at a specific resolution, but the actual Amiga screen that opens up is not, at least if you use Picasso96. If you use the Picasso96 RTG drivers from Workbench, you can open up a screen up to the maximum resolution your host system provides (1080p in the case of Pi).

FYI: Amiga PAL is 720x576 with overscan for example. Normal "HighRes" is 640x256 and that's what Workbench starts in by default. Games usually go for lower resolutions like 320x256 to gain some speed. PAL Interlace resolutions are 640x512. Using an RTG system (Picasso96) on the Amiga side, you can use the native gfx system to open up any resolution it supports, beyond the PAL limitations.

I think it should be able to switch to a higher resolution even if your starting framebuffer size is smaller, but we need to test this to be sure. :)

The test should go like this:

If the above scenario works, we're good to go. For games, you won't need to change resolution to a higher one anyway, only lower (e.g. 320x256) so we should be covered already.

If you have a configuration that starts with 480p, I can test the rest.

Fourdee commented 8 years ago

If you have a configuration that starts with 480p, I can test the rest.

@midwan

Excellent :+1: I'am still yet to spin up workbench, successfully hehe :) Configuration for the RPi framebuffer?

This will set RPi framebuffer to 480p

sed -i '/framebuffer_width=/c\framebuffer_width=854' /DietPi/config.txt
sed -i '/framebuffer_height=/c\framebuffer_height=480' /DietPi/config.txt
reboot

1080p if you want to return to this.

sed -i '/framebuffer_width=/c\framebuffer_width=1920' /DietPi/config.txt
sed -i '/framebuffer_height=/c\framebuffer_height=1080' /DietPi/config.txt
reboot
Fourdee commented 8 years ago

Note to self: Move and symlink `conf/`` to userdata dir. Basically means uninstall = No loss of saved configs.

midwan commented 8 years ago

Confirmed: user can switch resolution normally within the emulation, even to higher ones than 480p when the framebuffer is set to such.

So we can add that modification as well.

I've located a bug in uae (or perhaps it's Raspbian) with the CapsLock/NumLock keys. If you start the emulation from a console (i.e. no X is loaded) then those keys do not respond as expected (Caps Lock does not turn on the LED, and does not turn input into capitals). If you start the emulator from within X however, even from a console window there, it works fine.

I'm experimenting with a few changes but so far I haven't had much success.

Fourdee commented 8 years ago

@midwan

Xinit should work for this, creates a X instance, for the program command following it, try (from term, no desktop):

systemctl stop uae4arm-rpi
dietpi-software install 6
cd /etc/uae4arm-rpi
xinit ./uae4arm-rpi
midwan commented 8 years ago

It does indeed! Thanks for that!

Now I can cleanup the code a bit, finally!

Fourdee commented 8 years ago

@midwan Excellent. I'll create a script to detect if xinit needs to be run, then add to the uae4arm-rpi service.

midwan commented 8 years ago

👍 Awesome!

Fourdee commented 8 years ago

@midwan

Updates:

Fourdee commented 8 years ago

@midwan

I think we are nearly there? Lets try and get this finished up for v130, if i've missed any, please let me know:

We can apply online patches to the users system during DietPi updates. So, whatever we do after this is released, any updates for Uae4arm or fixes can be applied to the users system easily. In other words, anything we don't complete for v130, we can do it in v131.

midwan commented 8 years ago

Yes, I think we're quite close. I've been busy making (small) modifications to uae4arm, in order to fix a few things:

What remains to be done:

And of course: Test the whole solution from beginning to end using a DietPi image! So far I've been making most of my tests on a standard Raspbian, which I use as a test/dev environment. The DietPi image was used for short tests, but more in-depth ones should be done.

I plan to have all of the above sorted during this weekend. :)

One question: Once we're done with the first release, is there an easy way to package up an image with UAE already configured? I'd like to release that as "AmiBerry v2" for the lazy users that just want to flash something and not bother with configuring much. With Minibian I could do that by setting everything up and not expanding the filesystem, then create an image of the partitions (using dd). In DietPi I've noticed that the filesystem gets expanded on first boot, so how could I "shrink" it to create a custom image, while still retaining the ability to expand on the next boot (so end users can get the full card storage utilized)?

Fourdee commented 8 years ago

@midwan

Once we're done with the first release, is there an easy way to package up an image with UAE already configured? I'd like to release that as "AmiBerry v2" for the lazy users that just want to flash something and not bother with configuring much.

Yep, 2 options:

I'd highly recommend the Netinstall. This is the standard way DietPi can be automated. Ensures always upto date and doesn't require a new image creation each time AmiBerry is updated. In short, user would write image, plug in ethernet (or setup WiFi in /boot/dietpi.txt), power on and watch the magic.

I've been busy making (small) modifications to uae4arm, in order to fix a few things:

Excellent updates, might be small, but that is alot of improvements! Cant wait to give em a spin :+1:

Benchmark and measure any gains/losses on this build VS the original from Chips-fr. First tests show an improvement already in CPU/FPU operations, but I want to test the Graphical ones as well.

Not sure how you would benchmark this, is there any tests I could run?

And of course: Test the whole solution from beginning to end using a DietPi image! So far I've been making most of my tests on a standard Raspbian, which I use as a test/dev environment. The DietPi image was used for short tests, but more in-depth ones should be done.

I've been testing the hell out of it, whilst playing some games here an there lol ;) But yes, before we release, final tests and one following the online docs to ensure its correct.

midwan commented 8 years ago

The Netinstall option sounds great, how do we go about preparing that? It would be great if I could test the whole thing on my side, from start to end.

For benchmarking, I opted to use a tool from within the emulator that does a variety of tests, including low level stuff (like CPU, Memory, Disk speed, Graphics) but also real-life application performance, using some well known applications to perform tasks (e.g. an image manipulation program which it uses to process some pictures, a text editor, etc). It's not perfect, but it's a good overall indication of how the system performs. Better yet, it saves the output numbers for each test as a "module" and you get to compare it to other previously run modules, from other machines. So it makes it very easy to run a set of tests, save the results and compare them with a subsequent set of tests (it even has statistics).

You can get it from Aminet if you're interested, keep in mind it uses MUI so you'll need to have that installed too: http://aminet.net/search?query=sysspeed (I'm giving you the search option here so you can see and download modules other users have uploaded there as well, if you want)

Fourdee commented 8 years ago

The Netinstall option sounds great, how do we go about preparing that?

Doing image now , will post link when up.

You can get it from Aminet if you're interested, keep in mind it uses MUI so you'll need to have that installed too:

Excellent :+1: i'll take a look

Fourdee commented 8 years ago

@midwan

Ok, steps for automated installation image:

DietPi will now install everything. When its finished, Uae4ARM menu will be displayed (fast boot).

I'am aiming to release v130 as soon as AmiBerry is completed. Thats when the image can be distributed to the public.

midwan commented 8 years ago

Great, I'll test this as soon as I can!

midwan commented 8 years ago

I've just finished cleaning up and compiling new binaries for the emulator. I run several benchmarks and they all work well, no problems in any operations and they seem slightly faster than the original builds from Chips-fr. Not a huge difference, but still... :) The biggest difference seemed to be in some graphics operations, probably due to the NEON optimizations for the Pi 3 vs the Pi 2 processor.

One thing I've noticed, to which I'm not sure which way to go:

I'll upload these to the Dropbox folder as well. Should we have some sort of naming convention to distinguish the new versions from the previous ones? E.g. datestamp on the zip filename?

I've also updated the Raspberry Pi 1/Pi Zero compile, to get the latest fixes in that one too. It still does not have Picasso96 support though, because the one helper file is in ARM assembly and contains instructions that are not supported on that processor. If we manage to convert that to C++ it should work, but I'm not an Assembly expert... :(

I've downloaded the DietPi image mentioned above, will test it tomorrow so I can check if everything runs Ok with that.

I'm hoping that over the weekend we can confirm that everything is OK so we can go ahead with the release of v130!

midwan commented 8 years ago

I'm testing the image today. I run across one problem early on:

Not a huge problem since I could plug in the Ethernet, just thought you might want to investigate. ;-)

EDIT: I'll add any more issues here below:

Fourdee commented 8 years ago

@midwan

The WiFi doesn't seem to work at first boot.

Which:

The Path for configuration files is still pointing to /etc/uae4arm-rpi/conf/ in this image. I thought we should update this to dietpi_userdata/... to avoid losing any configuration?

The /etc/uae4arm-rpi/conf folder is symlinked (points to) dietpi_userdata:

root@DietPi:~# ls -lha /etc/uae4arm-rpi/
total 8.0M
drwxr-xr-x  3 root root 4.0K Sep  2 15:01 .
drwxr-xr-x 79 root root 4.0K Sep  2 15:29 ..
lrwxrwxrwx  1 root root   37 Sep  2 15:01 conf -> /mnt/dietpi_userdata/uae4arm-rpi/conf

This works. It only seems to be Uae4arm's ability to browse symlinks within the GUI that isn't supported.

The uae4arm binary needs to be updated. Which brings up the question: how will such updates to the binary be delivered? Should the user do something to get the latest version?

We can cover this with dietpi-update. I'll add some patch code to install the latest binaries for existing installations. All the user then needs to do is run dietpi-update when a updated version of DietPi and AmiBerry uae4arm binary is available (eg: v131).

It would be great if we could add a few more links to the default installation, as follows: /etc/uae4arm-rpi/dir -> /mnt/dietpi_userdata/uae4arm-rpi/dir (for directory "Disks") /etc/uae4arm-rpi/hdf -> /mnt/dietpi_userdata/uae4arm-rpi/hdf (for HDFs)

Yep, good idea. We have disks already symlinked. I'll do the hdf's.

root@DietPi:~# ls -lha /etc/uae4arm-rpi/
total 8.0M
drwxr-xr-x  3 root root 4.0K Sep  2 15:01 .
drwxr-xr-x 79 root root 4.0K Sep  2 15:29 ..
lrwxrwxrwx  1 root root   37 Sep  2 15:01 conf -> /mnt/dietpi_userdata/uae4arm-rpi/conf
drwxr-xr-x  2 root root 4.0K Aug 28 13:41 data
lrwxrwxrwx  1 root root   38 Sep  2 15:01 disks -> /mnt/dietpi_userdata/uae4arm-rpi/disks
lrwxrwxrwx  1 root root   46 Sep  2 15:01 floppy_images -> /mnt/dietpi_userdata/uae4arm-rpi/floppy_images
lrwxrwxrwx  1 root root   43 Sep  2 15:01 kickstarts -> /mnt/dietpi_userdata/uae4arm-rpi/kickstarts
lrwxrwxrwx  1 root root   43 Sep  2 15:01 savestates -> /mnt/dietpi_userdata/uae4arm-rpi/savestates
lrwxrwxrwx  1 root root   44 Sep  2 15:01 screenshots -> /mnt/dietpi_userdata/uae4arm-rpi/screenshots
lrwxrwxrwx  1 root root   29 Sep  2 15:01 uae4arm-rpi -> /etc/uae4arm-rpi/uae4arm-rpi3
-rwxr-xr-x  1 root root 3.4M May 27 13:30 uae4arm-rpi1
-rwxr-xr-x  1 root root 3.5M Aug 28 10:21 uae4arm-rpi2
-rwxr-xr-x  1 root root 1.1M Aug 28 09:20 uae4arm-rpi3
-rwxr-xr-x  1 root root  149 Sep  2 15:01 uae4arm-rpi_run.sh

I'll tweak the autostart.uae config file and send you a new version to include

Excellent :+1: i'll update the .zip on dietpi.com.

Also, selfish ask (its my favorite board). Whats the chances (and whats involved) in getting AmiBerry compiled for Odroid C2 (ARM64)? :smile:

midwan commented 8 years ago

I'm testing this on a RPi3, with the builtin Wifi. Sorry I didn't mention it before. :) Wifi details:

This only happened during the first boot after flashing the image. Ever since I rebooted (after the initial failure), the Wifi works.

I'll see if I can fix the symlink browsing from the code, it's a bit annoying indeed.

Meanwhile, I found a bug I'm investigating: In uae, if you use RSHIFT+another key in a quick combination, it crashes and throws you back in the console. If you press the keys a bit slower, this doesn't occur. It's probably related to the input handling, so I'm looking at that now to see if I can fix it quickly.

Fourdee commented 8 years ago

@midwan HDF folder now symlinked during installation:

lrwxrwxrwx  1 root root   36 Sep  3 13:17 hdf -> /mnt/dietpi_userdata/uae4arm-rpi/hdf

autostart.uae updated in uae4arm-rpi_v1.zip NB: I had to re-enable the GUI: use_gui=yes

midwan commented 8 years ago

Doh, sorry about the GUI, I forgot to change that back. :P

Fourdee commented 8 years ago

@midwan

I'll test WiFi installation, see what went wrong.

adfdir.conf /etc/uae4arm-rpi/conf/ instead of /mnt/dietpi_userdata/uae4arm-rpi/conf/

Done, updated zip. config_path= will be set to userdata directory during installation.

Performance

I've also noticed the internal resolution set in uae4arm plays a major factor in framerates. In elite low framerates were 720x270 @ 5fps, 320x200 was about 30fps. Whats a low resolution that would be good for most games (ideally to match their original resolution)? We could then add that to FAQ in online docs.

Fourdee commented 8 years ago

@midwan Fixed WiFi, I'll need to create an updated image. Will let you know when its up.

midwan commented 8 years ago

Great news! And I've made some progress with the Pi Zero version, I'll try to compile it soon to see if it works with Picasso96 support now.

Fourdee commented 8 years ago

@midwan Excellent :+1:

Ok, image updated: http://dietpi.com/downloads/images/DietPi-AmiBerry_RPi-armv6-(Jessie).7z Tested with WiFi installation, working great :)

I've updated the steps to set WiFi before booting (added WiFi country code): https://github.com/Fourdee/DietPi/issues/474#issuecomment-244384847. Very important, enables higher WiFi power and channels for selected country.

http://www.tweakguides.com/Amiga_4.html Note that most games came in PAL format, so 320x256 and 640x256 were the most common resolutions.

I'll add that to the online docs. Debating whether we should set 640x256 as default (instead of 768x270). Maybe even lower it to 320x256 for single core Raspberry Pi's. Should increase performance overall. Whats your thoughts?

midwan commented 8 years ago

Great work with the WiFi, I'll test the fresh image a bit later again.

Regarding resolution: The emulator should switch resolution according to what is requested, between HighRes, LowRes, their Laced equivalents and of course, Picasso96 modes. Did you see anything different that I'm missing? Or did I misunderstand your question?

midwan commented 8 years ago

More good news: The Pi Zero officially has Picasso96 support now! 🏆

midwan commented 8 years ago

I've just uploaded the current binaries in the Dropbox folder. The known bug with the keyboard I mentioned is still there however. If I manage to fix it, I'll post an update here.

Edit: I just noticed that Chips-fr has added some changes, I'll merge those in and re-deploy the binaries in a bit.

Edit2: Ok, uploaded.

Fourdee commented 8 years ago

@midwan

The emulator should switch resolution according to what is requested, between HighRes, LowRes, their Laced equivalents and of course, Picasso96 modes. Did you see anything different that I'm missing?

Yep, I found the framerate visually improved (roughly x2+) when using 320x256 in elite II, compared to 640x256. I'll need to run some GFX benchmarks to verify, but its certainly faster. Most likely, rendering interlaced lines uses up as much render time, as the ones without?

Edit2: Ok, uploaded.

Great stuff, autostart.uae now loads inputs automatically on 1st run!!!!! :+1: :+1:

EDIT: Silly question, what do I do with http://aminet.net/search?query=sysspeed once downloaded? lol

Fourdee commented 8 years ago

@midwan

Unless we have any further changes to make, lets run some final tests and get this released:

I'll make a start on the above, you are welcome to test as needed. If I missed any tests you think we should do, let me know.

Fourdee commented 8 years ago

@midwan All tests completed. We are good to release at the current state, just need your confirmation.

midwan commented 8 years ago

Awesome! I'm working on fixing that bug in uae, but I assume we can always push it out later with an update?

What did you think about the resolution? Wasn't the window placed on the top left corner of you screen when starting it with xinit?

On Sep 4, 2016 20:13, "Dan" notifications@github.com wrote:

@midwan https://github.com/midwan All tests completed. We are good to release, just need your confirmation.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/Fourdee/DietPi/issues/474#issuecomment-244619802, or mute the thread https://github.com/notifications/unsubscribe-auth/ADsp9Y5CFeHQm3THMtFTNWMEyGUtW-8Hks5qmwpFgaJpZM4JkUAy .

Fourdee commented 8 years ago

I'm working on fixing that bug in uae, but I assume we can always push it out later with an update?

Yep, we can patch users system with any updates in the next DietPi release (v131). If all goes to plan, v130 will be released tomorrow. So if you manage to get that bug fixed before hand, just let me know and I'll try and get it added before we release.

What did you think about the resolution? Wasn't the window placed on the top left corner of you screen when starting it with xinit?

I tested both 640x256 and 320x256 from autostart, full screen and seems fine. I have not tested via a Desktop. I'll run that test tomorrow just to make sure.

midwan commented 8 years ago

I've finally located the source of the bug, and working on a solution now. I might manage to fix it before tomorrow, so I'll let you know after I've tested it.

Regarding the resolution, here's what I saw:

If you verify the above, then I can think of a few possible routes:

No biggie I guess for now, but just wanted to let you know on what I've seen so that we can handle it in the future.

Confirmed: bugs is now squashed. :) I'm preparing new binaries and will upload them soon.

Edit: binaries are online since last night, I think we can release this anytime you can/want, unless you find anything else. Please let me know if there are any changes in the procedure to get the image, as I'll also publish that as instructions alongside the announcement at http://blitterstudio.com/amiberry once we're ready. :)

Fourdee commented 8 years ago

@midwan

Edit: binaries are online since last night

Excellent, i've updated zip and reinstalled, working well.

if the resolution is higher than that it's shown on the top left hand corner.

Yep confirmed. GUI size/location is affected by framebuffer size when running under X.

The framebuffer dimensions that DietPi boots in match the GUI resolution, at least roughly. I think this may already be the case if you see the GUI showing centered. ;-)

Yep. If the user selects any uae4arm autostart option in dietpi-autostart, DietPi will set 480p for framebuffer automatically.

I fix the Caps Lock handling so that it works with the fbcon as well, instead of only X11 inputs. That should eliminate the need to run it with xinit in the future.

Caps lock LED is only working for me when using xinit. I think for now, we keep the xinit launch. We can always patch this in the future if fixed.

Found some bugs:

./uae4arm-rpi -f conf/autostart.uae
fbset -depth 8 &> /dev/null
fbset -depth 16 &> /dev/null
xrefresh &> /dev/null

No fix at the moment. I'll make a note in the online docs.

midwan commented 8 years ago

Thanks for confirming the resolution issue. I agree that we should stick with the xinit method for now, until we get it working without that need later on.

How did you get to the black screen problem? Just normally exiting the emulation with F12 - then Quit? Does it happen consistently?

If you can give me some steps to recreate this, we might figure out what's happening...

Fourdee commented 8 years ago

@midwan

How did you get to the black screen problem? Just normally exiting the emulation with F12 - then Quit? Does it happen consistently?

Yep, so on a fresh install of the DietPi+AmiBerry image run (use another SDcard):

dietpi-software install 23
echo 2 > /DietPi/dietpi/.dietpi-autostart_index
reboot

When on the desktop, open System > LXterminal run:

systemctl start uae4arm-rpi

When uae4arm GUI pops up, click the Quit button. Black screen everytime. At least on my RPi 3. I believe it has something to do with uae4arm changing the resolution causing framebuffer to be "lost".

https://www.raspberrypi.org/forums/viewtopic.php?p=637497#p637497 If xbmc/kodi changed hdmi mode then the framebuffer will be lost, and you get a black screen on exit.

I tried the above fix mentioned by dom previously, no effect.

Edit:

Also tried from a desktop using RPi GL driver. Uae4arm fails to start.

midwan commented 8 years ago

OK, one more question: Is this a problem with the latest uae4arm build only as far as you know?

Fourdee commented 8 years ago

@midwan

I'll reserve v131 for AmiBerry hotfixes/bug fixes. So anything that doesn't make it into v130, we can release it in v131 within a day or two if needed.

I'am a bit annoyed with the desktop + uae4arm = black screen on exit. But the DietPi+AmiBerry image users will be fine. So i'am not too concerned at the moment.

@midwan I'll do a last pass on the DietPi-AmiBerry image installation and test. If no further issues or updates from your end, let me know and i'll release v130.

Fourdee commented 8 years ago

Is this a problem with the latest uae4arm build only as far as you know?

Only tested with the latest binary you uploaded last night. Do you have any RPi 3 previous binaries I can test?

midwan commented 8 years ago

I'll have to test the issue you mentioned when I'm home a bit later.

You should be able to see the earlier versions of the binaries from your Dropbox folder, using the History? If you can't, let me know and I'll locate an earlier version to test with.

Fourdee commented 8 years ago

@midwan

You should be able to see the earlier versions of the binaries from your Dropbox folder, using the History? If you can't, let me know and I'll locate an earlier version to test with.

:+1: I've tested the 1st uploaded version on RPi 3 (August 17, 2016 | 3MB | latest is 1.4MB~): :u6307: Exits fine from desktop :+1:

I'll put the release on hold until we can get this fixed. Now we know the issue originates from the binary.

midwan commented 8 years ago

Thanks for that info. It shouldn't be hard to find what's causing this then, I'll start looking into it now.

midwan commented 8 years ago

Interesting: I followed your instructions to recreate the problem, and I noticed something:

uae4arm is already running by the time you start into LXDE, with the service. If you open htop you'll see it in the top taking up 99% of CPU time.

Are you aware of that and did you stop it before re-running it?

Edit: it doesn't solve the issue of course. ;) I also noticed that the problem is only apparent if you start it with "xinit" when in the LXDE, if you start the binary directly it opens up in its own window and quits without an issue.

I think I know what's causing it, so I'll run a few test builds and see which one fixes it.

midwan commented 8 years ago

Bug fixed. :)

I'll compile and deploy updated binaries for all versions as soon as I test this in a few more scenarios.

Edit: New binaries in Dropbox. I've included a SHA-256 checksum file for the archive, to help keep track of each version since they have the same name. Let me know if that helps or if you prefer another method.

Changes in this build:

Fourdee commented 8 years ago

@midwan

uae4arm is already running by the time you start into LXDE, with the service. If you open htop you'll see it in the top taking up 99% of CPU time.

Ah yes, lol, this is because I didn't set the autostart option correctly (echo 2 > /DietPi/dietpi/.dietpi-autostart_index). This doesn't disable the uae4arm-rpi service. Should of been /DietPi/dietpi/dietpi-autostart 2. But good spot :+1:

Restored the screen opening to the previous approach - Opens a full screen with the resolution detected. Removed variable setting (screen_is_picasso=0) while quitting. Removed extra gui events that are not relevant to the RPi (Pandora-specific).

Excellent work :+1: :+1: . Exits to desktop perfectly :dancer:

@midwan

Ok, few last questions:

Aside from the above, I think we are good to release? Just need your confirmation :+1: