search

MichaIng / DietPi

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

DietPi + AmiBerry | Optimized installation for Uae4arm #474

Closed Fourdee closed 8 years ago

Fourdee commented 8 years ago

Collaboration with the creator of AmiBerry (Dimitris):

https://blitterstudio.com/amiberry/

Notes:

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

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

Legend

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

Compile for:

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

DietPi-Autostart

:u6307: Add Amiga emulator boot option.

Documentation

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

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

midwan commented 8 years ago

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:

What's missing compared to WinUAE:

I have forked uae4arm-rpi (https://github.com/midwan/uae4arm-rpi) and added RPi 3 as a new platform, with CPU optimizations for the cortex-a53 which it has. I haven't managed to fully compile a version for the Pi Zero yet (due to missing instructions from that CPU) but we may be able to do so later on. I am also interested in getting it to work with my Pine64.

The Pi 1 build does run on the Zero, but it does not have Picasso96 support (it wasn't enabled for the Pi 1 target platform) and might crash if it reaches an unsupported instruction I assume.

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

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

How will we handle the amiga emulator boot option? In AmiBerry I used a systemd service configured to run very early, to have it boot as quick as possible into UAE - with some system tweaks I managed to do that in under 2.7 seconds from cold boot. ;-)

Fourdee commented 8 years ago

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

midwan commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

Fourdee commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

@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 commented 8 years ago

@midwan

Ok initial sourcecode is done. Some notes for testing:

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

Method 1 - Automated installation from fresh image:

Method 2 - Standard installation:

Fourdee commented 8 years ago

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

midwan commented 8 years ago

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

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

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

Fourdee commented 8 years ago

@midwan

midwan commented 8 years ago

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 commented 8 years ago

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:

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 commented 8 years ago

@midwan Any objections if we use?

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 commented 8 years ago

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

midwan commented 8 years ago

I did some quick tests today:

These problems are not apparent in the other ports of UAE4Arm such as the Android port, which is more often updated with bug fixes. I was planning to compare the sources and see if we can implement any of those fixes in the rpi port. Additionally, I wanted to go through the code in general and see how much I can fix (certainly several compiler warnings about deprecated operations), perhaps also getting pieces from the other various UAE ports where possible. It's a project that will take time though, which is why I mentioned that about the option to select which version of UAE to install. ;-)

I still have to test the "testing" branch of DietPi, including the uae service (either what you have done, if it's available, or setting it up myself). I hope to do this tonight if time permits, otherwise for sure during the weekend. I'll post my results and any comments here.

midwan commented 8 years ago

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 commented 8 years ago

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 commented 8 years ago

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

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

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

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

Fourdee commented 8 years ago

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

Option 2: Uae4arm (standard boot)

compatible/stable 12+ seconds boot.

The items I'd like to leave out:

midwan commented 8 years ago

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?

Fourdee commented 8 years ago

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

midwan commented 8 years ago

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:

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?

Fourdee commented 8 years ago

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:

image image image image

midwan commented 8 years ago

👍 Looks good!

Fourdee commented 8 years ago

@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

midwan commented 8 years ago

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

Fourdee commented 8 years ago

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 commented 8 years ago

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

midwan commented 8 years ago

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

Fourdee commented 8 years ago

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

midwan commented 8 years ago

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?

Fourdee commented 8 years ago

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

midwan commented 8 years ago

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.

Fourdee commented 8 years ago

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

midwan commented 8 years ago

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

On Aug 28, 2016 13:58, "Dan" notifications@github.com 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 .

Fourdee commented 8 years ago

@midwan

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

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

Fourdee commented 8 years ago

@midwan

Questions:

From my testing. To successfully run uae4arm:

midwan commented 8 years ago

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:

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:

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 commented 8 years ago

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

Fourdee commented 8 years ago

@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 commented 8 years ago

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

midwan commented 8 years ago

Good work there! 👍

Regarding the items in RED:

<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 commented 8 years ago

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

Fourdee commented 8 years ago

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

midwan commented 8 years ago

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.

Fourdee commented 8 years ago

@midwan

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

config_path=/etc/uae4arm-rpi/conf/
rom_path=/mnt/dietpi_userdata/uae4arm-rpi/kickstarts/
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:

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