-
-
Notifications
You must be signed in to change notification settings - Fork 496
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DietPi + AmiBerry | Optimized installation for Uae4arm #474
Comments
UAE4All2 does not have JIT, 68040 or Picasso96 emulation, among other things. UAE4Arm is a newer build based on UAE4All but adds several new features (but also maybe some bugs): The main differences to UAE4ALL:
What's missing compared to WinUAE:
I have forked uae4arm-rpi (https://github.com/midwan/uae4arm-rpi) and added RPi 3 as a new platform, with CPU optimizations for the cortex-a53 which it has. I haven't managed to fully compile a version for the Pi Zero yet (due to missing instructions from that CPU) but we may be able to do so later on. I am also interested in getting it to work with my Pine64. The Pi 1 build does run on the Zero, but it does not have Picasso96 support (it wasn't enabled for the Pi 1 target platform) and might crash if it reaches an unsupported instruction I assume. I can easily compile the latest sources and produce binaries for Pi 1, 2 and 3 to upload in the specified location. I can also take care of the instructions after installation (where each things goes, how to configure the emulator, etc.) How will we handle the amiga emulator boot option? In AmiBerry I used a systemd service configured to run very early, to have it boot as quick as possible into UAE - with some system tweaks I managed to do that in under 2.7 seconds from cold boot. ;-) |
Great to have you onboard for this one, cant wait 👍
Does uae4arm-rpi run on X11 or FB?
Excellent, I'll host these on http://dietpi.com so we can use them in the installation. I've sent you an invite to a dropbox share we can use as a temp upload location.
Awesome, once you have this ready, let me know and I'll give you access to edit the online forum docs, or I can copy/paste it in.
Impressive boot time, really is. I think we should be able to use your systemd service as a special case for this software installation. You will need to add Once i've got the compiled binaries, i'll crack on with adding the installation code into DietPi-Software. |
uae4arm-rpi is customized (from the main uae4arm which uses SDL) to use dispmanx on the Pi, for direct access to the display hardware. It gives somewhat better performance than using SDL. The code has pieces that control this based on a declared variable, so the SDL parts are also still in place from what I've seen. I'm not sure what we can use for the Pine yet, as I haven't seen much of the low-level stuff available there. Probably going for the SDL approach would be the most realistic for now. We can work on improving that later I guess. :) I'll upload a fresh compile for each target later today and test out the boot times we can get on a real Pi 3. |
I've just added the uae4arm-rpi binaries in the dropbox folder. I have compiled a version for RPI1, 2 and 3 so you'll find 3 executables in the archive named accordingly. I've also included the expected folder structure, so that this archive can simply be extracted somewhere and it's ready to go (you still need to add the ROMs and disks/HDFs/whatever of course). How do we plan to keep them up-to-date? I've forked the uae4arm-rpi project with the aim of improving it, so new versions will be coming soon. We should have some mechanism to upgrade the binaries when necessary. |
Excellent 👍 I'd like to make a few changes to
This will allow us to install to So the online docs can say, put your roms into
Ok, so we can do a few things:
|
I'll get the dietpi-software code added later today for the installation. I'll then give you the instructions for how to test the installation on the testing branch :) |
OK with modifying the .conf file, it's a default template anyway. :) Up to now, the archive has been the same (only the binaries inside it changed, directory structure was the same). I'm thinking if in the future we should give the users the option to choose the version installed, between say a cutting-edge but experimental version and an older but more stable one. In that case, we'll need to version the binaries at least (or the whole archive). I'm OK with both approaches. If we wanted to be really special, we could also add the option to download and compile directly from source. I have that option in AmiBerry (takes care of installing required dev packages, clones project from github, runs proper make statement depending on Pi platform detected). One thing to note: I found that the current version of uae4arm-rpi does NOT work properly if the user upgrades the Pi firmware to the latest available (currently 4.4y). It works OK with the previous one which is the one that currently comes with a default Jessie installation. We should have a warning about that or even an option to roll back a firmware upgrade to the previous one, until we (or Chips-fr) fixes this problem. |
Sounds good, I think we should use a version id on the binary.zip. Allows us to control the updates, and generally good practice to separate the versions.
Yep, i'd be up for that aswell.
Ok, i'll take a look and see if we can automatically install a previous kernel version during installation. |
It works fine with the latest kernel and system updates (so you can do apt-get upgrade and apt-get dist-upgrade without fear), I was referring to the GPU firmware upgrade only: rpi-update (https://github.com/Hexxeh/rpi-update) |
@midwan I also tried with 4.1.21, same issue.
|
- Initial code for uae4arm: https://github.com/Fourdee/DietPi/issues/474
Ok initial sourcecode is done. Some notes for testing:
Heres how to install it on DietPi, using testing branch.Method 1 - Automated installation from fresh image:
Method 2 - Standard installation:
|
@midwan |
+ uae4arm set 128MB GPU: https://github.com/Fourdee/DietPi/issues/474#issuecomment-240503813 + uae4arm, autostart before dietpi-service: https://github.com/Fourdee/DietPi/issues/474#issuecomment-240519529
|
What would the implications be if the user has set /mnt/dietpi_userdata to a network share? I mean of course they won't be available until the networking service is up, but do you see anything that would block uae4arm from starting if it's configured that way? Unless there's something that would interfere with that, then it's ok if it runs in the background (in parallel with uae), the same as the rest of the services. In other words, we can have a uae service running very early without blocking the rest of the services that will also run in parallel. Networking will be available when the relevant service is up, which is probably OK considering that the Workbench would have just booted by then also (and the user will not need network before Workbench starts up anyway). And that's just the worst-case scenario I can think of, if they are using just for launching a game, then networking is probably not even needed for that session. Do you see a problem with this approach? Like I said, I'm not sure what the implications are with using /mnt/dietpi_userdata on a network share. |
I think the only issue would be for the user, example:
If we wanted to avoid this, I believe we can simply add |
@midwan
I'll also create symlinks for each, from
Until this point i thought ROM/Kickstarts were the same thing lol :) |
@midwan |
I did some quick tests today:
These problems are not apparent in the other ports of UAE4Arm such as the Android port, which is more often updated with bug fixes. I was planning to compare the sources and see if we can implement any of those fixes in the rpi port. Additionally, I wanted to go through the code in general and see how much I can fix (certainly several compiler warnings about deprecated operations), perhaps also getting pieces from the other various UAE ports where possible. It's a project that will take time though, which is why I mentioned that about the option to select which version of UAE to install. ;-) I still have to test the "testing" branch of DietPi, including the uae service (either what you have done, if it's available, or setting it up myself). I hope to do this tonight if time permits, otherwise for sure during the weekend. I'll post my results and any comments here. |
I've just tested the "testing" branch, good work in automating everything! :) I compared the startup times with systemd-analyze and converted the plots from both DietPi "testing" and my own AmiBerry: In DietPi, uae4arm.service starts around the 3s mark. In AmiBerry it does around 2.7s. The difference is not that big, but I noticed that the kernel takes about twice the time to load. Meanwhile, I will experiment a bit with the boot options, to see if I can make it a little faster. |
@midwan Ok, so, I'am going to work on the Option 1: Uae4arm (fast boot)< 3 seconds. Fastest possible boot time to uae4arm. May be unstable with certain SDcards.
Option 2: Uae4arm (standard boot)compatible/stable 12+ seconds boot.
The items I'd like to leave out:
|
Regarding the |
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? If you can give me some steps to recreate this, we might figure out what's happening... |
Yep, so on a fresh install of the DietPi+AmiBerry image run (use another SDcard):
When on the desktop, open System > LXterminal run:
When uae4arm GUI pops up, click the Quit button. Black screen everytime. At least on my RPi 3.
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. |
OK, one more question: Is this a problem with the latest uae4arm build only as far as you know? |
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 |
Only tested with the latest binary you uploaded last night. Do you have any RPi 3 previous binaries I can test? |
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? |
👍 I'll put the release on hold until we can get this fixed. Now we know the issue originates from the binary. |
Thanks for that info. It shouldn't be hard to find what's causing this then, I'll start looking into it now. |
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 think I know what's causing it, so I'll run a few test builds and see which one fixes it. |
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:
|
Ah yes, lol, this is because I didn't set the autostart option correctly (
Excellent work 👍 👍 . Exits to desktop perfectly 💃 Ok, few last questions:
Aside from the above, I think we are good to release? Just need your confirmation 👍 |
@Fourdee you're right on the default keyboard layout. Regarding the floppy emulation: higher speed will work fine in may (most?) cases, except the weird ones which expected the floppy speed to be fixed and had hardcoded stuff based on that. I don't think there are many such cases, but there could be some demo/game that has a problem with a faster floppy speed. Of course, it can always be changed one way or the other, so setting it to higher by default might be a good approach. I believe we're good to go. I will continue working on the Caps Lock issue in parallel and once we fix that, we update the binaries. If any other bug comes along, we can handle it separately in the Issues section of my fork: https://github.com/midwan/uae4arm-rpi/issues |
Excellent, I've set floppy speed
Excellent, let me just check everything is wrapped up my end, then I'll send the merge to master branch. May be a couple of hours, but i'll let you know when v130 is released. Then you can release the image to public :)
Will do 👍 I'll also reserve v131 for a few days. Just incase we need to apply any urgent fixes/improvements. |
v130 (06/09/16) New device: NanoPi M2 DietPi image is now available. Many thanks to k-plan for sending me this tiny, but powerful board!: http://dietpi.com/phpbb/viewtopic.php?f=8&t=620#p2664 Changes / Improvements / Optimizations: DietPi-Software | Uae4ARM | Amiga emulator for your Raspberry Pi. Collaboration with the creator of AmiBerry (Dimitris) to bring you the highest performance Amiga emulation, running on lightweight DietPi: http://dietpi.com/phpbb/viewtopic.php?f=8&t=5&p=64#p64 DietPi-Software | ARM64 | Squeezebox Server (Logitech Media Centre) and Squeezelite are now available for installation: https://github.com/Fourdee/DietPi/issues/354 DietPi-Software | Pi-hole | Installation updated to latest version 2.9: https://github.com/Fourdee/DietPi/issues/478 DietPi-Software | RPi monitor updated to latest version, thanks to WolfganP: https://github.com/Fourdee/DietPi/issues/238#issuecomment-241461096 DietPi-Software | You can now find the URL links for the online docs in the Help Menu. It will also list the URL links for each peice of software installed: https://github.com/Fourdee/DietPi/issues/483 DietPi-Software | xcompmgr is now installed by default with Xserver on ALL devices. Limits desktop composition effects to improve performance and reduce "moving window lag". DietPi-Config | Raspberry Pi OpenGL driver can now be enabled in 'Display Options' > 'Change Resolutions' menu. Requires RPi 2 or 3: https://github.com/Fourdee/DietPi/issues/497 DietPi-Config | Added RPi 3 overclocking profiles: https://github.com/Fourdee/DietPi/issues/485 DietPi-Config | Added Stress test. Available from Tools menu. This can be used to test stability of your system (runs CPU, Ram and filesystem IO tests based on your device capabilities). DietPi-Backup | Will no longer backup manpages/docs and .deb package caches. DietPi-Apt-Get_Update | Has been removed. This previously allowed for threaded apt-get updates in background. We have now reverted to standard usage of apt-get update. Bug fixes: DietPi-Banner | IP address will now display if one exists on system. Raspberry Pi | Improved detection for RPi 3 devices, when overclocked. Raspberry Pi | Fix for scroll lock LED by Midwan: https://github.com/Fourdee/DietPi/issues/474#issuecomment-243215674 Raspberry Pi | Resolved an issue where running Kodi from desktop would render artifacts on exit. Many thanks to 467815891a for reporting the issue: https://github.com/Fourdee/DietPi/issues/484 Raspberry Pi | Mixer volume will now be set to -0.1db during boot (originally -50db), if soundcard is enabled.
@midwan Final instructions for users of the automated installation image:
DietPi will now install everything. When its finished, Uae4ARM menu will be displayed (fast boot). For reference, the differences between the
|
@Fourdee Fantastic! Our work will finally be enjoyed by more people! :) I'll prepare a proper announcement and post it on the official Amiberry page. I'll keep working on improving uae4arm-rpi, and will let you know when I have new updates that can be pushed to users. I'd like to return the kind words, it's been great fun working with you as well. Professional, quick to respond and experienced in what you do. That combination is no so common in today's world, especially in open source "fun" projects such as this. Thank you! |
For the record, here's the official page: http://blitterstudio.com/amiberry/ |
One thing that came up from users rather quickly:
Could we have that instead of Dropbear enabled when Amiberry is configured? Question 2: Is it possible to plug a USB drive to copy files directly? I know that we have the option to use a USB drive for User Data Location, but I noticed it didn't automount one if I just plug it in. In my earlier version I had the "usbmount" package installed, so it would auto-mount USB drives under /mnt/usb/ which made things easy. Do you have any suggestions for this? |
Quick and easy by user:
https://github.com/Fourdee/DietPi/blob/master/dietpi.txt#L47 Some line down. user can as well trigger samba or ftp server installation by first booting.
But this can only do Fourdee, if he will think it is meaningful.
Will be a really nice feature, but only can work, if we get this on work: https://github.com/Fourdee/DietPi/issues/271 BTW: really nice statement. 👍 |
Thanks for the suggestion, I've added that as a note in the page (and the announcements). |
Excellent write up and thanks for all the DietPi mentions 👍
Dropbear SSH server is installed by default. Although its lightweight, it lacks SCP/SFTP file transfer support when compared to OpenSSH server.
Yep no problem. This image can be customized as per @midwan's request. For existing installations, users can change Dropbear to OpenSSH by running
I'll need to check if |
Can we please have OpenSSH installed by default in the dedicated AmiBerry image? It would simplify things a lot, since most users expect to be able to transfer files over via SSH. That's also the case with other similar images (e.g. Amibian, previous version of AmiBerry, etc.) I've already made a note about existing installations, and even customizing the dietpi.txt for those who want it installed at first boot. So for now, we're covered I believe. The USB mount would also be great to have, for the same reasons as above. Let's see if it works well with the current system and decide on that. |
@midwan |
@midwan |
Thanks! :) On Sep 7, 2016 18:20, "Dan" notifications@github.com wrote:
|
Collaboration with the creator of AmiBerry (Dimitris):
https://blitterstudio.com/amiberry/
Notes:
RetroPie claim uae4all2 is quicker than uae4arm: https://github.com/retropie/retropie-setup/wiki/Amiga#emulators-uae4all2-uae4arm
https://github.com/RetroPie/uae4all2
Legend
🈴 = Not started
🈺 = In progress
🈯 = Completed
Compile for:
🈯 ARMv6 (RPi 1, if performance is acceptable?)
🈯 ARMv7 (RPi 2/3, should offer performance improvements using an updated arch)
🈴 Optional: Other devices (eg: Odroids / VM).
🈯 Host binaries on https://dietpi.com/downloads/binaries/bullseye/ respectively
DietPi-Autostart
🈯 Add Amiga emulator boot option.
Documentation
🈯 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 standardDietPi
image:/boot/dietpi.txt
AUTO_Install_Enable=1
AUTO_DietpiSoftware_Install_ID=108
Uae4ARM install enabled.AUTO_AutoStartTarget=6
Uae4ARM fast boot enabled.AUTO_DietpiSoftware_SSHServerIndex=-2
OpenSSH server for SCP/SFTPThe text was updated successfully, but these errors were encountered: