Skip to content
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

Closed
Fourdee opened this Issue Aug 15, 2016 · 113 comments

Comments

Projects
None yet
3 participants
@Fourdee
Copy link
Collaborator

Fourdee commented Aug 15, 2016

Collaboration with the creator of AmiBerry (Dimitris):

http://blitterstudio.com/amiberry/

Notes:

https://github.com/Chips-fr/uae4arm-rpi
http://dietpi.com/phpbb/viewtopic.php?f=9&t=23#p2562

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 http://dietpi.com/downloads/binaries/all/uae4arm-rpi_v1.zip

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: http://dietpi.com/phpbb/viewtopic.php?f=8&t=5&p=1949#p1949

For reference, the differences between the DietPi-AmiBerry and standard DietPi 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/SFTP

@Fourdee Fourdee added this to the v129 milestone Aug 15, 2016

@Fourdee Fourdee self-assigned this Aug 15, 2016

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 16, 2016

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):
https://github.com/lubomyr/uae4arm/blob/master/Readme_Pandora.txt

The main differences to UAE4ALL:

  • Different 68000 core (newcpu instead of FAME/C) with support for 32 bit addressing mode
  • Support for 68030 and 68040 cpus
  • FPU (68881, 68882 and internal 68040)
  • JIT
  • Autodetect Amiga ROMs
  • Up to 5 HDDs
  • Lot of new audio options
  • Picasso96
  • GUI
  • bsdsockets
  • RDB hardfiles
  • Support for rp9
  • CD32 support

What's missing compared to WinUAE:

  • Cycle exact emulation of cpu and blitter
  • SCSI support
  • AHI
  • Builtin debugger
    and some more...

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. ;-)

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 16, 2016

@midwan

Great to have you onboard for this one, cant wait 👍

I am also interested in getting it to work with my Pine64.

Does uae4arm-rpi run on X11 or FB?
We are still yet to implement the X11 mali drm drivers for Pine 64: #380

I can easily compile the latest sources and produce binaries for Pi 1, 2 and 3 to upload in the specified location.

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.

I can also take care of the instructions after installation (where each things goes, how to configure the emulator, etc.)

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.

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. ;-)

Impressive boot time, really is.
We may have issues reaching that with DietPi with the current autoboot system. Mainly due to the dietpi-service which sets up Ramlog and Ramdisk during boot. The current "autoboot" section is triggered by /etc/rc.local (idle systemd service that runs very last): https://github.com/Fourdee/DietPi/blob/master/dietpi/login#L49-L99

I think we should be able to use your systemd service as a special case for this software installation. You will need to add After=dietpi-service.service under [Unit] for your service.

Once i've got the compiled binaries, i'll crack on with adding the installation code into DietPi-Software.

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 16, 2016

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.

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 17, 2016

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.

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 17, 2016

@midwan

I've just added the uae4arm-rpi binaries in the dropbox folder.

Excellent 👍

I'd like to make a few changes to adfdir.conf if thats ok?:

path=/etc/uae4arm-rpi
config_path=/etc/uae4arm-rpi/conf/
rom_path=/mnt/dietpi_userdata/uae4arm-rpi/kickstarts/

This will allow us to install to /etc/uae4arm-rpi. /mnt/dietpi_userdata allows users to have their roms stored on USB drive/SDcard/custom location as set in dietpi-software. DietPi automatically symlinks this directory if located off SDcard: http://dietpi.com/phpbb/viewtopic.php?f=8&t=478
Fileserver choices (proftpd and samba server) also point to /mnt/dietpi_userdata by default.

So the online docs can say, put your roms into /mnt/dietpi_userdata/uae4arm-rpi/kickstarts, and, a method to transfer them over with a file server: http://dietpi.com/phpbb/viewtopic.php?f=8&t=15#p19

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.

Ok, so we can do a few things:

  • If the installation code does not change, we can simply overwrite uae4arm-rpi.zip with the new one on dietpi.com. Any user which then installs it, will be using the updated version
  • If the installation code changes, we will have to give it a version number eg: uae4arm-rpi_v2.zip. this way, we can modify the installation code to use the latest version, when that version of DietPi is then released and users update dietpi, the updated installation code and file will be used.
  • DietPi also has a patch system (https://github.com/Fourdee/DietPi/blob/master/dietpi/patch_file), so we can target current uae4arm installations and apply an update. If we need to reinstall the program, we can use dietpi-software uninstall 108 (to uninstall it), then dietpi-software install 108 to (install it). dietpi-software list gives a list of software indexes.
@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 17, 2016

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

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 17, 2016

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.
I've already opened a ticket about this on Chips-fr project, but so far I haven't seen much activity so it may take a while for it to be fixed (unless I manage to fix it myself).

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 17, 2016

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.

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.

Source code option

Yep, i'd be up for that aswell.
We can create two installations, one for binary and one for source. Lets get the binary installation done 1st and go from there. Depending on when v129 is released, if need be, we can look at adding the source compile installation option at a later date (eg: for DietPi v130)

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).

Ok, i'll take a look and see if we can automatically install a previous kernel version during installation.

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 17, 2016

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)

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 17, 2016

@midwan
I get a black screen after selecting start from the menu, is this the issue with 4.4 kernel you were mentioning earlier, or possibly something else?

I also tried with 4.1.21, same issue.

            #4.1.21 https://github.com/Hexxeh/rpi-firmware/commit/4bc6b67905e3206f8cf4d9a316f3343aaaf14d62
            # AGI rpi-update #4.4 hangs uae4arm.
            # rpi-update 4bc6b67905e3206f8cf4d9a316f3343aaaf14d62

Fourdee added a commit that referenced this issue Aug 17, 2016

v129
- Initial code for uae4arm: #474
@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 17, 2016

@midwan

Ok initial sourcecode is done. Some notes for testing:

  • No change to kernel version, until we know which kernel version is stable.
  • I've enabled the auto start boot service for testing purposes.

Heres how to install it on DietPi, using testing branch.

Method 1 - Automated installation from fresh image:

  • Write DietPi image
  • Save this file
    dietpi.txt
    to /boot/dietpi.txt
  • Plug in ethernet
  • Power on, watch the magic

Method 2 - Standard installation:

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 17, 2016

@midwan
I completely forgot GPU memory split, 128MB gpu required for uae4arm?

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 17, 2016

Yeap, it won't work with the default 16MB (I tested it also, you get a black screen and the system hangs). Using 128MB is enough to make it work in my tests, it boots into my Workbench 3.1 HDF normally. No change in the current kernel is required.

I'll get the testing branch version and test things out there as well. From a first investigation, it seems that the dietpi.service takes roughly 4 seconds in bootup, so if we start it after that it will be much slower than the AmiBerry approach.

To compare, here's a startup graph from AmiBerry after the tweaks I made (notice how early "uae4arm.service" is started):
image

Fourdee added a commit that referenced this issue Aug 17, 2016

v129
+ uae4arm set 128MB GPU:
#474 (comment)
+ uae4arm, autostart before dietpi-service:
#474 (comment)
@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 17, 2016

@midwan

  • 128MB GPU will be set during installation
  • Boot speed, yep.
    Lets try starting uae4arm before dietpi-service. It should be ok as uae4arm doesn't use /var/log. The only possible downside would be if the user has /mnt/dietpi_userdata set to a network share. So if needed we could have 2 autoboot options "normal" (run uae4arm after everything has finished) and fast (the current mode using your service)?
@midwan

This comment has been minimized.

Copy link

midwan commented Aug 18, 2016

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.

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 18, 2016

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?

I think the only issue would be for the user, example:

  • System boots
  • uae4arm menu is loaded
  • User is loading roms from a network share (/mnt/Samba, or any other network location), and the network filesystem mount has not completed yet. The user may say "where the hell did my roms go" :)
    It probably wouldn't happen, but there is a chance it can.

If we wanted to avoid this, I believe we can simply add After=remote-fs.target to the service. In theory this shouldn't increase the boot time if the user does not have a network mount, however, we'd need to test to verify.

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 18, 2016

@midwan
Any objections if we use?

  • /mnt/dietpi_userdata/uae4arm-rpi/roms/ = ROM directory
  • /mnt/dietpi_userdata/uae4arm-rpi/kickstarts/ - Kickstarts
  • /mnt/dietpi_userdata/uae4arm-rpi/savestates/ - savestates
  • /mnt/dietpi_userdata/uae4arm-rpi/screenshots/ - screenshots

I'll also create symlinks for each, from /etc/uae4arm-rpi/folder to /mnt/dietpi_userdata/uae4arm-rpi/folder

/mnt/dietpi_userdata will ensure all "user data" is stored in the location of the users choosing (either USB drive/SD/custom location).
The symlinks will also allow the user to use either /etc/uae4arm-rpi/folder or /mnt/dietpi_userdata/uae4arm-rpi/folder, but always points to /mnt/dietpi_userdata/uae4arm-rpi/folder.

root@DietPi:~# ls -lha /etc/uae4arm-rpi/
total 11M
drwxr-xr-x  4 root root 4.0K Aug 18 10:29 .
drwxr-xr-x 78 root root 4.0K Aug 18 10:29 ..
drwxr-xr-x  2 root root 4.0K Aug 17 12:13 conf
drwxr-xr-x  2 root root 4.0K Aug 17 12:13 data
lrwxrwxrwx  1 root root   38 Aug 18 10:29 disks -> /mnt/dietpi_userdata/uae4arm-rpi/disks
lrwxrwxrwx  1 root root   43 Aug 18 10:29 kickstarts -> /mnt/dietpi_userdata/uae4arm-rpi/kickstarts
lrwxrwxrwx  1 root root   37 Aug 18 10:29 roms -> /mnt/dietpi_userdata/uae4arm-rpi/roms
lrwxrwxrwx  1 root root   43 Aug 18 10:29 savestates -> /mnt/dietpi_userdata/uae4arm-rpi/savestates
lrwxrwxrwx  1 root root   44 Aug 18 10:29 screenshots -> /mnt/dietpi_userdata/uae4arm-rpi/screenshots
lrwxrwxrwx  1 root root   29 Aug 18 10:29 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.6M May 27 13:24 uae4arm-rpi2
-rwxr-xr-x  1 root root 3.6M May 27 13:07 uae4arm-rpi3

Until this point i thought ROM/Kickstarts were the same thing lol :)

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 18, 2016

@midwan
RPi 3 on DietPi install (used GIMP to convert the .svgz, not sure what happened there lol):
image

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 18, 2016

I did some quick tests today:

  • Updating to the latest firmware does not break uae4arm, at least not in DietPi. Perhaps in my earlier tests I had forgotten to check the memory split and that's why I got the black screen problem. In any case, it does not seem to be an issue.
  • I tested a new compile of uae4arm in which I had added an extra resolution in the Picasso96 modes: 1920 x 1080 (1080p). It seemed silly that the native resolution of the HDMI output would not be there by default. It works fine in my tests, you just need to untick the "Keep 4:3 aspect ratio" in the configuration screen of uae (otherwise the display is stretched).
  • There seems to be some bug(s) regarding keyboard and mouse input in uae4arm. Namely, sometimes the Input devices are set both to mouse (without you changing the configuration for that) and the result is that the mouse does not work at all. I had to restart the emulator multiple times to get it to work again when that happened. The second issue is that keyboard input is sluggish in general, when detecting the keypresses. This results in weird scenarios where, you press the Left Windows key (Left Amiga in the emulation) and it stays pressed even though you don't hold it down. Or if you keep a key pressed for a while, the stream of input continues for way more than when you release it again.

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.

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 18, 2016

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:

DietPi:
dietpi-testing

AmiBerry:
amiberry-startup

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.
Also, do you object to having the boot text optionally hidden? So that the first thing that comes up after powering up would be the emulator config/environment directly.

Meanwhile, I will experiment a bit with the boot options, to see if I can make it a little faster.

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 18, 2016

Good news, I managed to speed it up further! 👍

Adding boot_delay=0 in the config.txt saves us 1 second, since by default it waits for 1 second until the SDcard is ready before it boots. I haven't seen any problems with my cards with setting this to 0, but they may be an issue potentially with low quality cards.

After modifying the boot_delay, I went on to further speed things up in the booting process. This time by modifying /boot/cmdline.txt as follows:

Adding loglevel=3 (only display critical errors in startup)
dietpi-loglevel3

Adding logo.nologo (disables the boot logo in the console)
dietpi-loglevel3nologo

And finally, console=tty3 (changing the default console to tty3 so we don't get any boot messages shown):
dietpi-loglevel3nologotty3

In my environment, this brought down the whole process to 4 seconds less than where I started. And see how fast uae4arm.service is started there, that's even faster than my AmiBerry... ;-)

There might be more speed optimizations possible, but this is already quite promising.

@midwan

This comment has been minimized.

Copy link

midwan commented Aug 18, 2016

One more modification which seemed to speed things up a bit, but not very consistently during reboots:
Set the default boot mode to console:

systemctl set-default multi-user.target
ln -fs /lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@tty1.service

The best results I got after a few tries, were these:
dietpi-consoleboot

you may want to test this one on your end as well though. ;)

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Aug 19, 2016

@midwan
Impressive results 👍 If i'am reading this right, roughly 2.42~ - 2.46~ seconds boot time?

Ok, so, I'am going to work on the dietpi-autostart options today. Based on your results, heres what I've planned:

Option 1: Uae4arm (fast boot)

< 3 seconds. Fastest possible boot time to uae4arm. May be unstable with certain SDcards.

  • Your startup systemD service
  • boot_delay=0 in the config.txt
  • logo.nologo in cmdline.txt
  • loglevel=3 in cmdline.txt

Option 2: Uae4arm (standard boot)

compatible/stable 12+ seconds boot.

  • Normal DietPi boot, selected application launched at the very end of boot.

The items I'd like to leave out:

  • console=tty3
    I really dislike this. Although i'am all up for minimizing the amount of "on screen gibberish" some of our novice Linux users don't really need or want to see, I strongly believe we should never disable it entirely.
@midwan

This comment has been minimized.

Copy link

midwan commented Aug 19, 2016

Regarding the console=tty3 option, it doesn't actually disable it entirely. It just moves them to tty3, which can be accessed with Ctrl-Alt-F3 if you want to.
It doesn't have to be enabled by default, but what about having it as an option (for those novice Linux users who don't want to see those messages)? Perhaps only an option if you select the "fast boot" method?

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 5, 2016

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

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 5, 2016

@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

This comment has been minimized.

Copy link

midwan commented Sep 5, 2016

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

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 5, 2016

@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

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 5, 2016

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

This comment has been minimized.

Copy link

midwan commented Sep 5, 2016

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

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 5, 2016

@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.

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

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

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 5, 2016

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

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 5, 2016

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

This comment has been minimized.

Copy link

midwan commented Sep 5, 2016

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:

  • 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).
@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 6, 2016

@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 👍

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 👍 👍 . Exits to desktop perfectly 💃

@midwan

Ok, few last questions:

  • Default keys for keyboard as a joystick, from what I can figure out, is the following correct?
    • Arrows keys = direction
    • Page down = fire/button 1
    • Page up = fire/button 2
  • Floppy drive emulation speed. I've been testing this over the last few days at 800%, all the games I have seem to load perfectly, and around 8x faster. Do you have any experience with this setting causing issues, and, should we enable 800% by default in our installation?

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

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 6, 2016

@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

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 6, 2016

except the weird ones which expected the floppy speed to be fixed and had hardcoded stuff based on that
Of course, it can always be changed one way or the other, so setting it to higher by default might be a good approach.

Excellent, I've set floppy speed 800% by default in the autostart.uae:

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.

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 :)
🈯️ Final installation test

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

Will do 👍 I'll also reserve v131 for a few days. Just incase we need to apply any urgent fixes/improvements.

@Fourdee Fourdee referenced this issue Sep 6, 2016

Merged

v130 #499

Fourdee added a commit that referenced this issue Sep 6, 2016

Merge pull request #499 from Fourdee/testing
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: #354

DietPi-Software | Pi-hole | Installation updated to latest version 2.9: #478

DietPi-Software | RPi monitor updated to latest version, thanks to WolfganP: #238 (comment)

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: #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: #497

DietPi-Config | Added RPi 3 overclocking profiles: #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: #474 (comment)

Raspberry Pi | Resolved an issue where running Kodi from desktop would render artifacts on exit. Many thanks to 467815891a for reporting the issue: #484

Raspberry Pi | Mixer volume will now be set to -0.1db during boot (originally -50db), if soundcard is enabled.
@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 6, 2016

@midwan
All done, v130 is released.
The DietPi-AmiBerry installation image can now be used: http://dietpi.com/downloads/images/DietPi-AmiBerry_RPi-armv6-(Jessie).7z

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 DietPi-AmiBerry and standard DietPi image:

  • /boot/dietpi.txt
    • AUTO_Install_Enable=1
    • AUTO_DietpiSoftware_Install_ID=108 Uae4ARM install enabled.
    • AUTO_AutoStartTarget=6 Uae4ARM fast boot enabled.

Personal note: @midwan

Its been great fun working together with you on this (seriously, good fun with a professional attitude from start to finish, even if i did get distracted playing Elite II now and then lol).
Bringing back those good childhood memories is priceless, so thank you. You've done great work, really impressed and it shows your passionate about what you do.
Hopefully users of this installation can appreciate the work that has gone into it, and, have many months/years of enjoyment 👍

As mentioned, i'll reserve v131 for a few days in case we need to send out fixes/enchantments. Past that, keep in touch and keep me informed of any updates, i'll patch them in at request 👍

@Fourdee Fourdee closed this Sep 6, 2016

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 6, 2016

@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!

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 6, 2016

For the record, here's the official page: http://blitterstudio.com/amiberry/

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 6, 2016

One thing that came up from users rather quickly:

  • They can't connect with SSH to transfer files, because we don't have the proper SSH Server enabled by default. I know that if you install it from the dietpi menu it works, but it's an extra step which they didn't have to take with other distros.

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?

@k-plan

This comment has been minimized.

Copy link
Collaborator

k-plan commented Sep 7, 2016

@midwan

They can't connect with SSH to transfer files, because we don't have the proper SSH Server enabled by default. I know that if you install it from the dietpi menu it works, but it's an extra step which they didn't have to take with other distros.

Quick and easy by user:

  • edit the line in /boot/dietpi.txt before the first booting to:

    AUTO_DietpiSoftware_SSHServerIndex=-2

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.
DietPi-Automation is one of the coolest feature for setting up by users requirements.
http://dietpi.com/phpbb/viewtopic.php?f=8&t=273

But this can only do Fourdee, if he will think it is meaningful.


so it would auto-mount USB drives under /mnt/usb/ which made things easy. Do you have any suggestions for this?

Will be a really nice feature, but only can work, if we get this on work:

#271

BTW:

http://blitterstudio.com/amiberry/

really nice statement. 👍

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 7, 2016

Thanks for the suggestion, I've added that as a note in the page (and the announcements).

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 7, 2016

@midwan

http://blitterstudio.com/amiberry/

Excellent write up and thanks for all the DietPi mentions 👍

They can't connect with SSH to transfer files, because we don't have the proper SSH Server enabled by default.

Dropbear SSH server is installed by default. Although its lightweight, it lacks SCP/SFTP file transfer support when compared to OpenSSH server.

OpenSSH server
or @Fourdee will change this option in DietPi-AmiBerry_RPi-armv6-(Jessie).7z per default.

Yep no problem. This image can be customized as per @midwan's request.
@midwan If you want this by default for your image, just let me know and I'll update the image with OpenSSH server (for SCP/SFTP transfers), instead of Dropear.

For existing installations, users can change Dropbear to OpenSSH by running

dietpi-software > SSH server menu > select OpenSSH server. Return back to main menu, then select install Go start install

USB drive transfer files / usbmount

I'll need to check if usbmount is compatible with our existing mounting system (manual in fstab). If it is, we can add the package by default to installation.
If not, i'll need to have a look and see what we can do to help users transfers files from USB drive, whilst being compatible with our "dedicated USB drive / user data" system.
Ticket: #501

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 7, 2016

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.

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 7, 2016

@midwan
Ticket for OpenSSH: #502

@Fourdee

This comment has been minimized.

Copy link
Collaborator Author

Fourdee commented Sep 7, 2016

@midwan
Not sure if your on twitter, did this tweet: https://twitter.com/DietPi_/status/773555280793698304

@midwan

This comment has been minimized.

Copy link

midwan commented Sep 7, 2016

Thanks! :)

On Sep 7, 2016 18:20, "Dan" notifications@github.com wrote:

@midwan https://github.com/midwan
Not sure if your on twitter, did this tweet: https://twitter.com/DietPi_/
status/773555280793698304


You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#474 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADsp9V68RJ6rYl71WVQDDDmutnJv1iiLks5qnuQLgaJpZM4JkUAy
.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.