Amiberry: Single click on the selected config file launches the emulation

[midwan]

Instead of the expected double-click to start the selected config file, sometimes if it's already selected and the user clicks on it once, it launches the emulation as well.

[Fourdee]

@midwan
This happened to me a few times during testing, unexpected launch via single click. Would be great to see it changed to double click, regardless of selection.

[midwan]

I've made a change to test out a different approach:

• Double click on a configuration entry just loads that configuration. It does not boot into it as well.
• The GUI now starts at the same color depth your current display is in, instead of the previously hardcoded 16-bit. Not sure if this has any negative impact (it shouldn't). If we find out that it does, we can easily switch back.

[Fourdee]

The GUI now starts at the same color depth your current display is in, instead of the previously hardcoded 16-bit. Not sure if this has any negative impact (it shouldn't). If we find out that it does, we can easily switch back.

@midwan

May have issues with alpha on 32bit. Would need testing:

Framebuffer bit depth can be set with (config.txt):

framebuffer_depth=32

Option to ignore alpha channel with (config.txt). This was used to prevent alpha corruptions when using 32bit. Not sure if its still required with latest kernel:

framebuffer_ignore_alpha=1

The above claims to affect framebuffer, untested on OpenGL driver. http://elinux.org/RPiconfig

[midwan]

Would you prefer to leave it at 16-bit? I noticed that the default Raspbian image I test with starts at 32-bit.

[midwan]

@Fourdee binaries of this build are now online. I changed the archive format to 7-zip instead of ZIP, that saves us about a megabyte... :P Let me know if that's a problem, or if you find anything wrong with this build.

[Fourdee]

@midwan

Would you prefer to leave it at 16-bit? I noticed that the default Raspbian image I test with starts at 32-bit.

We dont define the bit depth on the DietPi image in config.txt. So i'am unsure what the default currently is. I'll need to check :wink: lol

Really depends on what the Amiga can output and how uae4arm renders. If the amiga/uae4arm render is 8/16bit, I'd assume 16bit would be the preferred bitdepth?

binaries

Excellent :+1: I'll give it a spin 1st chance I get tomorrow.

7zip

My preferred compression type. All good.

[midwan]

I've only changed this for the GUI, not the actual Amiga emulation screen.
That is still the same as it was. ;-)
For the record, Amiga screens are 8-bit for AGA, 8/16/24-bit with
Picasso96. Games do not usually benefit from a higher bit depth as they are
using AGA only (some exceptions are there, with games that used a
screenmode you specified, such as Gloom Deluxe).

[Fourdee]

@midwan

New binary installation is available in testing branch (http://dietpi.com/downloads/binaries/all/uae4arm-rpi_v2.zip).

I've done a test installation of:

• write and install v130 AmiBerry image.
• Change gitbranch= master to testing branch in /DietPi/dietpi.txt
• dietpi-update to update to v131. Updates uae4arm binaries
• Reboot, working fine in elite.

So

• existing installations will have their binaries updated (v2) when v131 is released and they run dietpi-update
• New installations will have the v2 binary installed.

We also backup the users current autostart.uae to autostart_pre-dietpi-update.uae during any updates.

[midwan]

I tested this with my DietPi-Amibian image, which was already on the testing branch.
It upgraded normally, and started up the UAE session. However, the new UAE configuration had lost my Hard drives config, the list was empty. The rest of the settings seemed to have survived...

Edit: the "Show GUI on startup" setting was also lost (I had it to disabled)

[Fourdee]

@midwan

The testing branch isn't stable and shouldn't be used between versions (eg: updating from a previous testing installation to the next dietpi testing version). It could make for very broken installation as things change before a official release.

Your end-users will be using the v130 AmiBerry image, which is master branch.

So i'd recommend for testing the update on existing installations:

• Writing the image end-users are using: http://dietpi.com/downloads/images/DietPi-AmiBerry_RPi-armv6-(Jessie).7z
• Let it complete the installation
  
  
  
  • Now the installation is at the same state your end-users will be at.
  
  
• Now we can switch to the testing branch in dietpi.txt, then run dietpi-update
  
  
  
  • Now we are at the state where 'if this was released, your end-users would have this state'
  
  

And for testing a new installation

• Writing the image end-users are using: http://dietpi.com/downloads/images/DietPi-AmiBerry_RPi-armv6-(Jessie).7z
• Change to testing branch in dietpi.txt
• Power on and test.
  
  
  
  • This is the installation that new users will experience, once v131 is released.
  
  

Both should have an identical outcome.

I've tested both outcomes, seems fine for me. But I would appreciate if you could test also, just to make sure.

[midwan]

@Fourdee sure, I'll run another test and let you know.