DietPi 🚀 - DietPi + AmiBerry | Optimized installation for Uae4arm

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

midwan on 16 Aug 2016

👍1

@midwan

Great to have you onboard for this one, cant wait :+1:

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.

Fourdee on 16 Aug 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 on 16 Aug 2016

👍1

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.

midwan on 17 Aug 2016

👍1

@midwan

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

Excellent :+1:

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 on 17 Aug 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 :)

Fourdee on 17 Aug 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).

midwan on 17 Aug 2016

👍1

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.

Fourdee on 17 Aug 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)

midwan on 17 Aug 2016

👍1

@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 on 17 Aug 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:

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 on 17 Aug 2016

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

Fourdee on 17 Aug 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):

midwan on 17 Aug 2016

👍1

@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)?

Fourdee on 17 Aug 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.

midwan on 18 Aug 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 on 18 Aug 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 on 18 Aug 2016

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

Fourdee on 18 Aug 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 on 18 Aug 2016

👍1

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 on 18 Aug 2016

👍1

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 on 18 Aug 2016

🎉1 👍1

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/[email protected] /etc/systemd/system/getty.target.wants/[email protected]

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

midwan on 18 Aug 2016

@midwan
Impressive results :+1: 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.

Fourdee on 19 Aug 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 on 19 Aug 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

Yep, but most novice users wouldn't know how to do that :) If the boot fails, they would be staring at their monitor with a blank screen and probably say "its broken" lol.

Perhaps only an option if you select the "fast boot" method?

Ok, lets make "fast boot" to your specs. We can always add a whiptail message, highlighting the benefits of using this mode, and, possible drawbacks (eg: boot_delay=0 might break SDcard boot)?

Fourdee on 19 Aug 2016

I have never seen boot fail due to boot_delay=0 (yet), but theoretically it would probably mean that the boot device was not found because it needed more time to initialize, and the whole process would stop there - unless it retries after a bit.
The worst case scenario would be that the user can't boot from that card anymore. They'd need to plug it to another working machine and edit the config.txt file from there, removing/commenting that line (or setting it back to the default value of 1).

So the possible drawbacks as far as I know are:

Might fail to boot if the sdcard needs more time to initialize. In that case you need to edit the config.txt file and remove the boot_delay=0 line.
Boot messages will be shown in the tty3, so if something goes wrong and it's displayed there, you'll need to use Ctrl-Alt-F3 to see them.

We would also add this information in the documentation/wiki somewhere, so people are aware of it or can look it up if something goes wrong.

What do you think?

midwan on 19 Aug 2016

👍1

We would also add this information in the documentation/wiki somewhere, so people are aware of it or can look it up if something goes wrong.
What do you think?

Perfect:

Fourdee on 19 Aug 2016

👍 Looks good!

midwan on 19 Aug 2016

@midwan
I just need to add in these options to the code: https://github.com/Fourdee/DietPi/issues/474#issuecomment-240992216

Heres the updated automated installation config for uae4arm with autoboot 6 set (fast boot):
dietpi.txt

Fourdee on 19 Aug 2016

Thanks, I'll test it out and get back to you!

midwan on 19 Aug 2016

👍1

There seems to be some bug(s) regarding keyboard and mouse input in uae4arm.

Yep, confirmed. Seems very inconsistent in which combination of settings actually works, and when. Either that, or I've misunderstood the menu lol

Fourdee on 19 Aug 2016

@midwan
I've just released v129 and nudged this to v130 so we can continue work on it.
I just want to make sure we get the installation perfect, and, gives us some extra time.

Fourdee on 21 Aug 2016

Sure, no problem. :)
Could we add some sort of reference to AmiBerry in this?

midwan on 22 Aug 2016

@midwan

Could we add some sort of reference to AmiBerry in this?

Yep no worries.
I'll also mention the collab with AmiBerry in the changelog, and the online docs. If you can think of anything else, and/or have a preferred wording/description, please let me know.

I believe all that is left on this ticket is:

:u5408: Online documentation.
:u5408: ? Installation option to compile Uae4ARM (I'll need any notes you have on building)
:u5408: ? Possibility of compile + binary for other devices (eg: ARM64 C2/PineA64)
:u5408: Final testing and tweaking.

Fourdee on 23 Aug 2016

Great!
I've been working on setting up an environment to allow me to further develop uae4arm these days, and yesterday I reached the first milestone: a working cross-compiler with the ability to remote debug the emulator. Now I can start fixing some of those bugs and try to merge in the latest WinUAE sources from the various pieces.

I have a Pine64 so I will try to port it over to that as well.

Where can I begin working on the documentation? Is there an online resource I can edit, or shall I prepare it locally and then we'll upload it?

midwan on 23 Aug 2016

👍1

@midwan

I reached the first milestone: a working cross-compiler with the ability to remote debug the emulator. Now I can start fixing some of those bugs and try to merge in the latest WinUAE sources from the various pieces.

Excellent :+1:, sounds like a awesome setup. Would be great to see any improvements to Uae4ARM.

I have a Pine64 so I will try to port it over to that as well.

Brilliant, I can test the Odroid C2 at my end (ARM64) with your binaries.

Where can I begin working on the documentation? Is there an online resource I can edit, or shall I prepare it locally and then we'll upload it?

Usually, I just add a new post for the documentation on our PhpBB forums: http://dietpi.com/phpbb/viewtopic.php?f=8&t=5#p5 (I'd like to have a better/cleaner system for the online docs, but it works for now)
I can also link to another url (eg: Google docs) if you prefer.
If not, send me a draft of the documentation and i'll transfer to the forums.

Fourdee on 23 Aug 2016

I've just updated the uae4arm binaries on Dropbox. The latest version incorporates some bugfixes and some code that should help fix the LED problems with a Keyrah adapter if you have it.

They are also smaller in size, since I compressed the executable (it will decompress itself during runtime).
I haven't changed the RPI-1 binary, since I'm still trying to compile that one correctly. The changed ones are for the RPI-2 and 3, but all 3 of them are included to keep the archive consistent.

midwan on 28 Aug 2016

🎉1 👍1

@midwan

fix the LED problems with a Keyrah adapter if you have it.

Nope, but I ended up browsing http://amigakit.com/ for a good half hour lol.

They are also smaller in size, since I compressed the executable (it will decompress itself during runtime).
I haven't changed the RPI-1 binary, since I'm still trying to compile that one correctly

Excellent :+1: i've uploaded the new zip to dietpi.com. Next time you install from testing branch, it will use your updated zip.
I'll run a test install today on RPi 3.

Any updates on documentation, or still in the works?

Fourdee on 28 Aug 2016

I'll work on the docs later today, should not take too long.

On Aug 28, 2016 13:58, "Dan" [email protected] wrote:

@midwan https://github.com/midwan

fix the LED problems with a Keyrah adapter if you have it.

Nope, but I ended up browsing http://amigakit.com/ for a good half hour
lol.

They are also smaller in size, since I compressed the executable (it will
decompress itself during runtime).
I haven't changed the RPI-1 binary, since I'm still trying to compile that
one correctly

Excellent 👍 i've uploaded the new zip to dietpi.com. Next time you
install from testing branch, it will use your updated zip.
I'll run a test install today on RPi 3.

Any updates on documentation, or still in the works?

—
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-242970901, or mute
the thread
https://github.com/notifications/unsubscribe-auth/ADsp9SSZBGWK-dbY-h1AGRpadgSvJe2Fks5qkXfYgaJpZM4JkUAy
.

midwan on 28 Aug 2016

❤1 👍1

@midwan

Appears Uae4ARM doesn't support/display symlinks when browsing filesystem.

So, datapaths for user uae4arm data (roms/kickstarts etc) are:

SDcard only = /mnt/dietpi_userdata/uae4arm-rpi
USB drive installed via DietPi = /mnt/usb_1/uae4arm-rpi

Fourdee on 28 Aug 2016

@midwan

Questions:

AROS KS ROM (built-in) does not work for me. Just get red lines on screen. Is this expected?
Can we provide Kickstarter roms files (eg: 1.3) with our installation, is it legal?

From my testing. To successfully run uae4arm:

Start uae4arm via systemctl start uae4arm-rpi (if not set for autostart during boot)
Select "Load autostart.uae" (This never auto loads inputs for me)
Choose a kickstarter rom. (I cant get AROS builtin to work)
Choose a floppy disk .adf
Start

Fourdee on 28 Aug 2016

Regarding the data paths:

UAE4arm is compiled with predefined search paths for the "data" folders, expecting them to be in the same folder the binary is in. So the structure should look like this:

uae4arm-rpi
data/
conf/
kickstarts/
savestates/
screenshots/

We could change that in the compiled binary if it makes sense, but usually it's fine if you keep things together. Anything extra, such as paths for HDFs, ADFs, directories etc. are saved in configuration files.

The AROS KS ROM does work, but it has some dependency on the CPU you choose (I believe it doesn't work with 68000, try with 68020 or higher). It's not 100% compatible though, so some things will not quite work until it has further evolved.

The original Kickstart ROMs are still under copyright I'm afraid, the current owner is Cloanto which offers them for purchase as part of the Amiga Forever package. Independent license deals are also possible, but they will come at a cost. If you own Amiga Forever, then you can use the ROMs contained there with any emulator. It's the same situation with WinUAE on Windows or any other platform really. Until we get a fully compatible AROS rom (if ever) or this license situation changes, we're stuck with that.

For running uae4arm:

you can provide a command line parameter to load a specified config file automatically. The parameter is "-f ". So you can open the config window once, set things up the way you want them and save the configuration. After that you can auto-load it with that parameter.
You can also configure uae4arm to Hide the configuration window on startup, i.e. start direct into emulation. This combined with the previous option makes it possible to auto-start a configured Workbench environment, once you set it up.

Of course, if you want to boot from an ADF for a game, then this doesn't apply - you have to enter the configuration to choose which floppy to load. But you could have a A500 configuration auto-loaded for example, if you wanted to.

So for my environment, since I mostly boot into a customized 3.9 Workbench (such as AmiKit), I have the following setup:

autostart UAE, or run it manually once.
Set up a configuration for the highest possible CPU speed, AGA chipset, select either HDF or directory based drives (and copy over my pre-installed environment), select ROM 3.1.
Save the configuration with an appropriate name, say "autostart".
After I've tested the setup and verified everything works, I then change my start to:

uae4arm-rpi3 -f conf/autostart.uae

Of course, you can have your autostarting service with the above line to begin with, and provide a preset "autostart" configuration with the most common settings. Then the end-users can always modify that configuration accordingly.

midwan on 28 Aug 2016

👍1

Hi Dan,
I'm attaching the first documentation file here, hope that's ok.
I've marked some areas with yellow so we can work on those and update them accordingly. Let me know if we should include any additional info or if you have any comments on this. It's a first draft, we could improve it further with some input (and coffee). :)

The format is .odt, I assume that's OK? If not, let me know what format you'd prefer instead.
AmiBerry.zip

midwan on 28 Aug 2016

👍1

@midwan

UAE4arm is compiled with predefined search paths for the "data" folders, expecting them to be in the same folder the binary is in. So the structure should look like this:
uae4arm-rpi
data/
conf/
kickstarts/
savestates/
screenshots/

Yep, as dietpi uses a single location for userdata /mnt/dietpi_userdata, during installation we create symlinks to replace the following folders:

kickstarts/
savestates/
screenshots/
roms/
disks/

So in general terms, those folders exist in /etc/uae4arm-rpi/, but are pointing to /mnt/dietpi_userdata/uae4arm-rpi/[foldername]
But as I mentioned earlier, uae4arm (at least the front end) cannot see or browse symlinks. So could be an issue when our users have a USB drive or custom location for their DietPi user data location.
Although, as per: https://github.com/Fourdee/DietPi/commit/b060a49c1ec5996fa80ead470768a261127a1b5e DietPi will change all conf locations during installation, to now match the actual location, instead of symlink)

The original Kickstart ROMs are still under copyright I'm afraid
The AROS KS ROM does work, but it has some dependency on the CPU you choose (I believe it doesn't work with 68000, try with 68020 or higher).

Shame, a true definition of "milking every last drop for money".
Yep, so the official kickstarter roms are a must if you want the best experience.

uae4arm-rpi3 -f conf/autostart.uae

We have this set in the service already, but still fails to load inputs and bindings: https://github.com/Fourdee/DietPi/blob/testing/dietpi/conf/uae4arm-rpi.service#L8
I have to click "load" each time I run uae4arm for those settings to get loaded and applied. Might need to put this into documentation.

Also, we create a symlink from uae4arm-rpi to the device specific binary, during DietPi installation. So either /etc/uae4arm-rpi/uae4arm-rpi or /etc/uae4arm-rpi/uae4arm-rpi[MyDeviceNumber] works.

I'm attaching the first documentation file here, hope that's ok.

Excellent, I'll take a look :+1:

PS. I loaded up elite frontier eariler, man that brings back some memories lol

Fourdee on 28 Aug 2016

@midwan
Nice documentation :+1:

Based on your documentation, I tried to replicate what a new user would need to do, step by step.
I ended with up this: http://dietpi.com/phpbb/viewtopic.php?f=8&t=5&p=64#p64

Aside from 'First Run Setup', all items in RED are areas I'd like to discuss/improve. If you have any other areas you'd like to discuss, please let me know.

Fourdee on 28 Aug 2016

Good work there! 👍

Regarding the items in RED:

Donations: Sure, no problem with that. :)
Disclaimer: kind of obvious really, we could just mention that we don't supply any Kickstart ROMs or other copyrighted material (that should keep the lawyers away), that should cover it.
Image: I was planning to make a proper logo, but haven't gotten to it yet. Can we update it later if necessary?
Kickstarts path: Any path will work in the end, what the predefined setting helps with is whether UAE will automatically find them when it first starts up or not. You can always go in the configuration and change the paths, they will be saved as such from then on. Or, alternatively I can easily compile a version with another predefined path for the various components, so that it ties together with DietPi better. Let me know which way you prefer.
ADFs: I'm a bit skeptical about the wording here. ROMs are normally Kickstart ROMs in the Amiga world, since they refer to physical chips (which could only be read from). ADFs are just floppy disk images, which can be read/written to as well. You can create empty ADFs from within the emulators, write stuff to them etc. So maybe calling them ROMs might be confusing for people?
Also, there are many ADFs which are offered for free from their creators nowadays, not everything is under copyright. So we should rephrase that last sentence a bit, IMHO.
Also, there's no predefined path that UAE expects to find ADFs in, it can be anywhere.
Hard drive images: UAE can work with either hardfiles (HDFs) or a normal directory containing Amiga files. Those can also be placed anywhere you want, the emulator allows you to browse for the path to them in order to use them. HDFs can be created in WinUAE (and/or other emulators) and just copied over. They are virtual hard disks, containing filesystem, files, etc. They have a bit lower performance than normal directories, since read/write operations have to happen within that single file.
Normal directories are the other option. You can just create an empty directory, select it in uae and it will be used as an Amiga hard drive. You can use it to install Workbench, copy files etc. Of course you can have multiple such directories, each representing a separate disk (or partition) in your emulated system.
For example, I have the following setup:

<uae4arm>/dir/System
<uae4arm>/dir/Work

System contains my Workbench 3.9 installation, while Work contains my applications and extra software I have there. I have selected them both in my UAE configuration, assigning a Device Name (DH0: and DH1: respectively) and Volume Label (System and Work respectively). Here's a screenshot of what the config looks like from within uae:
img_20160828_221306

Finally, it would be ideal to fix the problem about the bindings you mentioned. I'll work on that and see what I can do, the aim should be to eventually have a system that can boot directly even without going in the config screen at all.

midwan on 28 Aug 2016

👍1

Here's an updated logo, since a friend was kind enough to design it for me:
amiberry logo

midwan on 29 Aug 2016

@midwan

Epic image. I may ask your friend to create one for DietPi lol! It looks excellent :+1:

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

You can always go in the configuration and change the paths, they will be saved as such from then on. Or, alternatively I can easily compile a version with another predefined path for the various components, so that it ties together with DietPi better. Let me know which way you prefer.

We apply the paths directly to the /etc/uae4arm-rpi/conf/adfdir.conf and /etc/uae4arm-rpi/conf/autostart.uae during installation, but it doesn't seem to find or list any content, unless the user browses Roms and Kickstarts.
I also tried the "Rescan Rom" button, has no effect on listed Kickstarts or ADF's.

Finally, it would be ideal to fix the problem about the bindings you mentioned. I'll work on that and see what I can do, the aim should be to eventually have a system that can boot directly even without going in the config screen at all.

This would be great :+1:
It seems to load the CPU/sound/display settings fine, but the Input settings are never loaded, until the user selects "load" on the autostart.uae configuration.

I updated the zip file to contain the paths that DietPi will use /mnt/dietpi_userdata/uae4arm-rpi in the config files: adfdir.conf and autostart.uae
http://dietpi.com/downloads/binaries/all/uae4arm-rpi_v1.zip
You may want to copy these and use them when creating updated zips.

Hard drive images:

Excellent :+1: Makes sense now.
I think I may leave this out for now, too much documentation can cause confusion for the user?

DFs: I'm a bit skeptical about the wording here. ROMs are normally Kickstart ROMs in the Amiga world, since they refer to physical chips (which could only be read from).

Yep :+1: I'am so used to calling emulator games "Roms" (n64 etc)
I think we should then change the folder rom to floppy_images?

Fourdee on 29 Aug 2016

I'm not sure the adfdir.conf file is actually used, I found it there in the original archive so I kept it, but I will have to check the source code to be 100% sure. It may be irrelevant and we can throw it away if that's the case.

The *.uae files are certainly used and whatever is in them should be loaded/respected though. If there's a bug in loading the input settings, we'll have to get it fixed.

We could call the floppy images folder floppy_imagesor adf, depends on how long you like your folder names I guess. :) Either one is good I believe.

I'll prepare a custom compile with the DietPi paths later today, to see if that helps at all.

midwan on 29 Aug 2016

👍1

@midwan

As far as I can tell, adfdir.conf gets used for:

Default paths (left hand side menu 'PATH' option)

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

When user browses filesystem (eg: ... button)

path=/mnt/dietpi_userdata/uae4arm-rpi/

I've updated the paths in this file and now Kickstarts are being listed automatically on 1st run!
The paths in this file require a slash after the last directory /, else, doesn't work.

We could call the floppy images folder floppy_imagesor adf, depends on how long you like your folder names I guess. :) Either one is good I believe.

Lets go with floppy_images, user friendly :). I'll update the sourcecode and zip. Will let you know when its ready.

Done, updated Zip http://dietpi.com/downloads/binaries/all/uae4arm-rpi_v1.zip with:

Configs and folder structure, floppy_images location instead of roms
Kickstarts are being listed automatically on 1st run.

Current installation structure and symlinks.

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

Fourdee on 29 Aug 2016

@midwan

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

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

Fourdee on 29 Aug 2016

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

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

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

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

midwan on 29 Aug 2016

@midwan

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

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

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

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

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

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

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

note to self: Just needs testing

Fourdee on 30 Aug 2016

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

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

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

The test should go like this:

Boot in 480p
Run uae4arm, boot a Workbench installation which has Picasso96 setup (I have such an environment handy)
Try to change resolution from within the emulation, see if it can go higher than 480p without problems.

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

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

midwan on 30 Aug 2016

👍1

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

@midwan

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

This will set RPi framebuffer to 480p

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

1080p if you want to return to this.

sed -i '/framebuffer_width=/c\framebuffer_width=1920' /DietPi/config.txt
sed -i '/framebuffer_height=/c\framebuffer_height=1080' /DietPi/config.txt
reboot

Fourdee on 30 Aug 2016

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

Fourdee on 30 Aug 2016

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

So we can add that modification as well.

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

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

midwan on 31 Aug 2016

👍1

@midwan

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

systemctl stop uae4arm-rpi
dietpi-software install 6
cd /etc/uae4arm-rpi
xinit ./uae4arm-rpi

Fourdee on 31 Aug 2016

It does indeed! Thanks for that!

Now I can cleanup the code a bit, finally!

midwan on 31 Aug 2016

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

Fourdee on 31 Aug 2016

👍 Awesome!

midwan on 31 Aug 2016

@midwan

Updates:

Fix cap/num lock keys.
Updated uae4arm service to run a script, which checks and launch xinit if no Xserver is currently running: https://github.com/Fourdee/DietPi/blob/c6eda6633ba96eb43601ad0a5ece0c9ea825fc8a/dietpi/dietpi-software#L5685-L5699
Xserver now installed with AmiBerry installation (for xinit)
conf folder now moved to user_data folder. User created configs will not be deleted during a uninstall.

Fourdee on 1 Sep 2016

@midwan

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

:u5408: Optional: Installation for other devices (eg: Odroids). We can do this after v130 is released. Possibly add it in for v131 if you are up for it? I can test on all devices, code it into DietPi etc, I just need the compiled binaries.
:u55b6: Issue/bug: autostart.aue does not automatically load all settings (eg: inputs). As per the documentation, a workaround to click "load" is covered in the end user guide. So not urgent, but would be nice to get this working automatically.

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

Fourdee on 2 Sep 2016

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

It now opens the config window in a resolution just enough for the GUI dimensions, instead of duplicating whatever screenmode you had. So you can boot your console to 1080p for example and the GUI will still open up at 480p to display. This looks nicer and is also faster (more responsive). So there's no need to change the boot resolution. ;-)
When you select a Directory as a virtual Hard drive, it will now automatically fill it the volume label to be the same as the directory name (it used to be the same as Device Name, e.g. DH0. It was a bit of a pain to have to rename that all the time).
Integrated options to assign the LEDs to custom options, to accommodate for Keyrah adapter users. The Keyrah adapter allows you to connect a real Amiga keyboard and you can assign the HDD, Floppy and Power LEDs to it as well.
Integrated fixes to make CapsLock Led and functionality work - this seems to work correctly only when launched with "xinit" for now though, not from the console.
Cleaned up and reformatted the code, to make it more readable.
Enabled Picasso96 by default for all builds.
Integrated some improvements from the Android port.
Further optimized the binary with compiler flags (from TomB's Pandora version) as well as Pi model specific flags for each CPU/Arch.

What remains to be done:

Benchmark and measure any gains/losses on this build VS the original from Chips-fr. First tests show an improvement already in CPU/FPU operations, but I want to test the Graphical ones as well.
Change the inline assembly code where needed to allow it to compile on a Pi1/Pi Zero CPU. Some instructions used there are not supported on the ARMv6 architecture they have. My plan is to change them to standard C++ methods if possible, to make the code more portable. This can always be done at a later stage however, no need to delay the release for it. The Pi 2 and 3 builds work and are the most important ones for now.

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

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

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

midwan on 2 Sep 2016

👍1

@midwan

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

Yep, 2 options:

Netinstall: DietPi image with the automated installation flags pre-setup in/boot/dietpi.txt.
- :u6307: Everything is installed and configured automatically on first run with no user inputs.
- :u6307: The image will always update to latest DietPi version on 1st run, so, we will never need to update the image itself.
- :u55b6: Requires a network connection for the initial setup.
- :u6307: Auto partition 2 expansion.
- We could also flag Samba server for installation to allow for Rom transfers over net?
Standard image with everything pre-installed (non-DietPi way)
- :u6307: No installation required: Everything pre-installed and configured.
- :u5408: No updates on 1st run, so you'll need to create a new/updated image required for each AmiBerry release.
- :u55b6: No auto filesystem expansion (would need a resize script to execute on 1st run)
- :u5408: User would need to manually symlink /etc/uae4arm-rpi/uae4arm-rpi to their hardware model (eg: 1/2/3). Else, our service and autostart wont work if device is different to what was used during the image creation.

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

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

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

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

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

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

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

Fourdee on 2 Sep 2016

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

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

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

midwan on 2 Sep 2016

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

Doing image now , will post link when up.

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

Excellent :+1: i'll take a look

Fourdee on 2 Sep 2016

@midwan

Ok, steps for automated installation image:

Download image: http://dietpi.com/downloads/images/DietPi-AmiBerry_RPi-armv6-(Jessie).7z
Write image
Set testing branch: (As we are still in testing. This wont be needed once v130 is released)
- Open /boot/dietpi.txt and change gitbranch= to gitbranch=testing (bottom of file).
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).

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

Fourdee on 2 Sep 2016

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

midwan on 2 Sep 2016

👍1

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

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

With the resolution change I implemented for the config window, it looks fine if started from the console but if you start it with "xinit" the window is placed on the top-left corner of your screen and the resolution is the native one (e.g. 1080p). Is there a way to specify resolution in xinit to avoid that?
Alternatively you can run it from the console of course, but then we have the issue with the Caps Lock not working... Argh. :(

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

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

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

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

midwan on 2 Sep 2016

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

The WiFi doesn't seem to work at first boot. I enabled it in the dietpi.txt as per your instructions, but it didn't seem to connect. During boot, I got several "Testing connection to http://mirrordirector.raspbian.org/raspbian/" messages, and after 20 attempts it stopped with a "Connection test failed".
After manually rebooting, it seemed to connect and work.

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

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

The Path for configuration files is still pointing to /etc/uae4arm-rpi/conf/ in this image. I thought we should update this to dietpi_userdata/... to avoid losing any configuration?
The uae4arm binary needs to be updated. Which brings up the question: how will such updates to the binary be delivered? Should the user do something to get the latest version?
It would be great if we could add a few more links to the default installation, as follows:
/etc/uae4arm-rpi/dir -> /mnt/dietpi_userdata/uae4arm-rpi/dir (for directory "Disks")
/etc/uae4arm-rpi/hdf -> /mnt/dietpi_userdata/uae4arm-rpi/hdf (for HDFs)
I'll tweak the autostart.uae config file and send you a new version to include, to correspond with the latest fixes. Hopefully it should help fix the input settings problem also. (Edit: now attached)
autostart.zip

midwan on 3 Sep 2016

👍1

@midwan

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

Which:

Raspberry Pi Model (eg: 3)?
WiFi device (eg: Onboard RPi3, or, edimax USB nano wifi)?
WiFi country code (eg: what country you are currently living in)?
WiFi channel used by your router (eg 1-13)?

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

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

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

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

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

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

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

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

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

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

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

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

Fourdee on 3 Sep 2016

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

Country: Sweden
Channel: 9

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

Conf folder:
You're right that the conf folder is symlinked, I was referring to the adfdir.conf file contained there. It contains config_path and rom_path values, and the first one was still pointing to /etc/uae4arm-rpi/conf/ instead of /mnt/dietpi_userdata/uae4arm-rpi/conf/. I fixed it locally and it seems to work.

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

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

midwan on 3 Sep 2016

@midwan
HDF folder now symlinked during installation:

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

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

Fourdee on 3 Sep 2016

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

midwan on 3 Sep 2016

😄1 👍1

@midwan

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

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

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

Performance

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

Fourdee on 3 Sep 2016

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

Fourdee on 3 Sep 2016

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

midwan on 3 Sep 2016

🎉1 👍1

@midwan
Excellent :+1:

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

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

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

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

Fourdee on 3 Sep 2016

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

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

midwan on 3 Sep 2016

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

midwan on 3 Sep 2016

🎉1 👍1

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

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

Edit2: Ok, uploaded.

midwan on 3 Sep 2016

👍1

@midwan

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

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

Edit2: Ok, uploaded.

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

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

Fourdee on 3 Sep 2016

@midwan

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

:u6307: Automated installation test using DietPi-AmiBerry image (http://dietpi.com/downloads/images/DietPi-AmiBerry_RPi-armv6-(Jessie).7z) + set WiFi to test both at same time (RPi 3).
:u6307: Manual installation test using DietPi standard image (http://dietpi.com/downloads/images/DietPi_RPi-armv6-(Jessie).7z)
:u6307: RPi 1 (256MB) binary test (Does it play Elite II?)
:u6307: RPi 2 binary test (Does it play Elite II?)
:u6307: RPi 3 binary test (Does it play Elite II? Hell yes)
:u6307: : Online documentation test (eg: follow online guide and check for any errors) http://dietpi.com/phpbb/viewtopic.php?f=8&t=5&p=64&hilit=amiberry#p64

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

Fourdee on 4 Sep 2016

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

Fourdee on 4 Sep 2016

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

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

On Sep 4, 2016 20:13, "Dan" [email protected] wrote:

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

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

midwan on 4 Sep 2016

👍1

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

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

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

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

Fourdee on 4 Sep 2016

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

Regarding the resolution, here's what I saw:

If you start uae4arm using xinit, then it opens at a resolution identical to your framebuffer (or X). Since the GUI is now changes to take up only as much as it needs, if the resolution is higher than that it's shown on the top left hand corner. E.g. if you boot to the console with a 1080p framebuffer.
If you start uae4arm without xinit, then it will open the resolution the GUI asks for, and it will be centered on screen. It looks better this way, but then we go back to the Caps Lock handling problem.

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

The framebuffer dimensions that DietPi boots in match the GUI resolution, at least roughly. I think this may already be the case if you see the GUI showing centered. ;-)
I fix the Caps Lock handling so that it works with the fbcon as well, instead of only X11 inputs. That should eliminate the need to run it with xinit in the future.

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

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

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

midwan on 5 Sep 2016

👍1

@midwan

Edit: binaries are online since last night

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

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

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

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

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

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

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

Found some bugs:

:u6307: Improved detection for running X server in our launch script. (eg: if we need to run xinit or not).
:u5408: Black screen after exiting uae4arm on a desktop. Similar to the Kodi issue. I tried to apply the known workaround of refreshing framebuffer, end up with corrupt screen and hard lock:

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

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

Fourdee on 5 Sep 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...

midwan on 5 Sep 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.

Fourdee on 5 Sep 2016

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

midwan on 5 Sep 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 on 5 Sep 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?

Fourdee on 5 Sep 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.

midwan on 5 Sep 2016

👍1

@midwan

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

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

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

Fourdee on 5 Sep 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 on 5 Sep 2016

❤1 👍1

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 on 5 Sep 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).

midwan on 5 Sep 2016

❤1 🎉1 👍1

@midwan

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

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

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

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

@midwan

Ok, few last questions:

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 :+1:

Fourdee on 6 Sep 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

midwan on 6 Sep 2016

👍1

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 :)
:u6307: 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 :+1: I'll also reserve v131 for a few days. Just incase we need to apply any urgent fixes/improvements.

Fourdee on 6 Sep 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:

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 :+1:

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 :+1:

Fourdee on 6 Sep 2016

👍1

@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 on 6 Sep 2016

👍2 ❤1

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

midwan on 6 Sep 2016

❤1 🎉1 👍1

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?

midwan on 6 Sep 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

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. :+1:

k-plan on 7 Sep 2016

❤1 👍1

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

midwan on 7 Sep 2016

@midwan

http://blitterstudio.com/amiberry/

Excellent write up and thanks for all the DietPi mentions :+1:

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

Fourdee on 7 Sep 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.

midwan on 7 Sep 2016

👍1

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

Fourdee on 7 Sep 2016

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

Fourdee on 7 Sep 2016

Thanks! :)

On Sep 7, 2016 18:20, "Dan" [email protected] 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
.

midwan on 7 Sep 2016

DietPi + AmiBerry | Optimized installation for Uae4arm

Collaboration with the creator of AmiBerry (Dimitris):

Notes:

Legend

Compile for:

DietPi-Autostart

Documentation

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

Most helpful comment

All 113 comments

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

Method 1 - Automated installation from fresh image:

Method 2 - Standard installation:

Option 1: Uae4arm (fast boot)

Option 2: Uae4arm (standard boot)

The items I'd like to leave out:

I believe all that is left on this ticket is:

Questions:

From my testing. To successfully run uae4arm:

Done, updated Zip http://dietpi.com/downloads/binaries/all/uae4arm-rpi_v1.zip with:

Updates:

Ok, steps for automated installation image:

Performance

Found some bugs:

Edit:

Ok, few last questions:

Final instructions for users of the automated installation image:

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

Personal note: @midwan

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

Related issues

DietPi + AmiBerry | Optimized installation for Uae4arm

Collaboration with the creator of AmiBerry (Dimitris):

Notes:

Legend

Compile for:

DietPi-Autostart

Documentation

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

Most helpful comment

All 113 comments

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

Method 1 - Automated installation from fresh image:

Method 2 - Standard installation:

Option 1: Uae4arm (fast boot)

Option 2: Uae4arm (standard boot)

The items I'd like to leave out:

I believe all that is left on this ticket is:

Questions:

From my testing. To successfully run uae4arm:

Done, updated Zip http://dietpi.com/downloads/binaries/all/uae4arm-rpi_v1.zip with:

Updates:

Ok, steps for automated installation image:

Performance

Found some bugs:

Edit:

Ok, few last questions:

Final instructions for users of the automated installation image:

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

Personal note: @midwan

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

Related issues

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

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