DietPi + AmiBerry | Optimized installation for Uae4arm

[Fourdee]

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

🈴 = 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 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

[midwan]

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]

@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: https://github.com/Fourdee/DietPi/issues/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]

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]

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]

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

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]

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]

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]

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]

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

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

• Write DietPi image
• Before powering on, follow these instructions: https://github.com/Fourdee/DietPi/blob/master/TESTING-BRANCH.md#steps-to-use-the-dietpi-testing-branch
• When DietPi-Software appears, select DietPi optimized menu, select Uae4Arm (located under Emulation and Gaming)
• Go start install

[Fourdee]

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

[midwan]

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

[Fourdee]

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

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]

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]

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

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

[midwan]

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]

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:

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

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)

Adding logo.nologo (disables the boot logo in the console)

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

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]

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:

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

[Fourdee]

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

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]

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]

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

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

[Fourdee]

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

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]

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]

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

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

[midwan]

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]

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]

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

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

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:

• Updated zip
• Updated doc: http://dietpi.com/phpbb/viewtopic.php?f=8&t=5&p=64#p64

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]

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

• Download image: http://dietpi.com/downloads/images/DietPi-AmiBerry_RPi-armv6-(Jessie).7z
• Write image
• Plug in Ethernet, OR optionally set WiFi in /boot/dietpi.txt:
  • SetWifi_Enabled=1
  • Set Wifi_SSID=MyWirelessSSID
  • Set Wifi_KEY=MyAccessKey
  • Set wifi_country_code=. This will enable channels and higher power ratings allowed for your country. Example country codes are: GB US DE JP. Full list: https://en.wikipedia.org/wiki/ISO_3166-1_alpha-2
  • Save changes
• Insert SD
• Power on.

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 👍

[midwan]

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

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

[midwan]

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]

@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

• or @Fourdee will change this option in DietPi-AmiBerry_RPi-armv6-(Jessie).7z per default.
• It is as well possible, do make a AmiBerry dependencywith OpennSSH, like for gog :
  https://github.com/Fourdee/DietPi/blob/master/dietpi/dietpi-software#L9877
  So it will be install with AmiBerry per default.

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:

https://github.com/Fourdee/DietPi/issues/271

BTW:

http://blitterstudio.com/amiberry/

really nice statement. 👍

[midwan]

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

[Fourdee]

@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: https://github.com/Fourdee/DietPi/issues/501

[midwan]

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]

@midwan
Ticket for OpenSSH: https://github.com/Fourdee/DietPi/issues/502

[Fourdee]

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

[midwan]

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
https://github.com/Fourdee/DietPi/issues/474#issuecomment-245335653, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADsp9V68RJ6rYl71WVQDDDmutnJv1iiLks5qnuQLgaJpZM4JkUAy
.