[Amiga] Amiberry + WHDLoad = Holy Grail - Amiberry's official thread

yserra

Thank you so much to all the team.

During my first tests, I could check that:

so far, all ADF work as expected (automatic selection of A500/A1200 configuration when running non-AGA/AGA games from ES)
WHDload games now let you select training options with a real mouse when they start (you don't have anymore to create a separate configuration with port0=mouse for each WHDload game). I experimented some rare screen flashing with Chaos Engine 2 (Retroarch booting screen appears during a fraction of a second)
booting on real floppy disks from a Greaseweazle board now work! Actually, "Normal" mode seems to be the best option, since "Fast", "Turbo", or "accurate" modes don't show any observable acceleration nor reliability. By the way, I experimented some failure with track loading demos like the famous State of the Art (this one works perfectly from an .adf).

My configuration: Raspberry Pi 4B, with 4GB RAM, external USB hard drive, USB mouse, 2x USB "PS3" gamepads, original Amiga 1000 keyboard connected to USB through an Arduino Leonardo board, and the latest RetroPie on May 4th, 2022.

nemo93

As mentioned the new script bringing Amiberry 5.1 has now been merged in Retropie \o/ Please go ahead and update your version. Feel free to report back.

Keep in mind that for now Retropie is still on Buster (32-bit + fKMS) and that's the default setup on which Amiberry 5.x has been heavily tested. I still highly recommend to use the above settings if you're new to Amiga or don't want to spend time on the config.

@BuZz @mitu thanks so much for the new script, it's fantastic.
@midwan @HoraceAndSpider for always improving Amiberry!

ecto

Just a quick question: I'm using KMS (not fKMS). Should I install the binary update or rather compile from source?
Thanks for your continuous support for Amiberry!
The Amiga was my first (actually second after the c16) computer and I have very fond memories. And now it never played better! :)

Oh. Another quick question: are there any plans for shader support sometime in the future? I really dig the scanning effects of the zfast shader...

mitu

@ecto Installing from source should work.

ecto

@mitu Thanks, I'll try that later and give a short report.

nemo93

@ecto about shader support, I haven't seen mention of that lately. If you're on KMS/64-bit/SDL2 it should work ok with the following settings instead. This will enforce the new autocrop feature to resize screen automatically.

default_horizontal_centering=yes
default_vertical_centering=yes
default_auto_crop=yes
default_width=720
default_height=568
default_whd_writecache=yes
allow_display_settings_from_xml=no

Feel free to report back in case of issue.

ecto

@nemo93 Thanks again!
Compiling and installing worked great and Amiberry started fine. I also tried the binary install but that doesn't work with my setup.
Looking at these amiberry.conf values you posted, I think they already are in the default config after the install? Anyways, they work great and the games are looking glorious!
One thing I noticed though: Although those settings are in the .conf file, they are not represented in the GUI (the checkmarks for the centering aren't there). It's a minor thing, but at first I was wondering if Amiberry didn't load the standard config file.

nemo93

@ecto good news :-) Those values should indeed be default but there are some edge cases were they aren't (upgrade from previous releases mostly).

The new auto-crop feature (auto screen resizing) works best with SDL2 and it's enabled only for that target. Yet as of typing Amiberry will be built against DispmanX (unless you're on 64-bit/aarch64). This guarantees the best perf on fKMS/32-bit systems. In that scenario parameters for games are fetched from an XML file (as long as allow_display_settings_from_xml=yes).

If you are on KMS/64-bit you have SDL2 version and you want that auto-crop feature enabled. When turned on it will take precedence over any other display settings including centering (as long as allow_display_settings_from_xml=no). Hence why these boxes are unchecked even if specified otherwise from amiberry.conf.

Hope this helps.

ecto

@nemo93 said in [Amiga] Amiberry + WHDLoad = Holy Grail - Amiberry's official thread:

If you are on KMS/64-bit you have SDL2 version and you want that auto-crop feature enabled. When turned on it will take precedence over any other display settings including centering (as long as allow_display_settings_from_xml=no). Hence why these boxes are unchecked even if specified otherwise from amiberry.conf.

Hope this helps.

Yes, very much. Thanks. I will set allow_display_settings_from_xml=no then.

I have another question to all Amiberry users here: Has anyone tried Biing (AGA)? It uses hires interlaced mode, but Amiberry seems to struggle with that. Sometimes it works (if I play around with Line Mode or Interlaced Line Modeand sometimes I get the game in hires, and sometimes not. Any ideas? (Besides from playing the DOS version)?

nemo93

Amiberry 5.4 is there and it's a recommended update for all users. Many bugfixes and improvements as usual.

One thing to note is that double line mode will be selected by default only if you have no amiberry.conf (eg. fresh install). If you already have amiberry.conf no modification will be made. You are free to set default_line_mode=1 in that file if you will (documentation). This mode should come with no impact on RPi4 yet there might be some performance hit on lower spec devices (ie. RPi3).

@ecto I'm afraid Biing is not part of my testbed. Do you still experience issue with it? What's your RPi model?

Hope this helps.

moreginger

Hmmm... I did a fresh RetroPie install a couple of weeks ago, and amiberry seemed to work fine. I turned it on today and I can't get things to start. I get the startup dialog saying "Launching... Press a button to configure Errors are logged to /dev/shm/runcommand.log", after a while a cursor appears in the top left and that's it, it's not possible to quit or do anything through the UI.
(ssh still works though)
I can't see anything interesting in that log file. I configured amiberry to write to a log (at /opt/retropie/emulators/amiberry/amiberry.log as per default) but there is nothing there... ah it's not writable.

OK now I get:

...
mapped_malloc(): 0x00000000 - 0x00200000 (0x20000000 - 0x20200000) -> Chip memory (chip)
ROM loader.. (<none>)
Failed to open '/opt/retropie/emulators/amiberry'

Does that mean it failed to scan my kickstarts? It seems to have copied them from /home/pi/RetroPie/BIOS/amiga/ into /opt/retropie/emulators/amiberry/kickstarts though. I don't have symlinks in /opt/retropie/emulators/amiberry/whdboot/save-data/Kickstarts, there seem to be some "RTB" files in there corresponding to my kickstarts. There is a symlink to my rom.key though.

Any ideas what is going wrong here?

P.S. I tried a clean reinstall of RetroPie just now and got the same result, and also with a source build of amiberry.

nemo93

@moreginger thanks for reporting. I'll need further details about your exact setup and environment please. Like your RPi version, your exact Retropie and Amiberry release number, your OS, etc. The more details the better as it's very unlikely to get such issue on a standard RPi + Retropie installation. Given it has been quite heavily tested I suspect something weird on your setup.

Couple of advices (if I may): delete/remove any Amiberry you have on your system. Use Retropie-Setup for that. Then delete also every KickStart from /home/pi/RetroPie/BIOS/amiga/. Feel free to backup those KickStart as well as your amiberry.conf and any other files you see fit. Last reinstall Amiberry from Source again from Retropie-Setup. Store the 3 KickStart roms noted on that page with the little checkmark and in /home/pi/RetroPie/BIOS/amiga/. That's all. Any game (assuming you're relying on the .lha format) should now run fine.

Hope this helps.

moreginger

@nemo93 Thanks for looking in to this. This is what I did last night.

Raspberry Pi 3B
Burned retropie-buster-4.8-rpi2_3_zero2w.img
Enable ssh
Update all packages with retropie-setup
Install amiberry from optional (initially compiled, later from source)
Copied kickstarts and rom key to /home/pi/RetroPie/BIOS/amiga/
Launch amiberry
Change System ROMs path to /home/pi/RetroPie/BIOS/amiga/ (left other config paths as defaults) (I see this is unnecessary now as it defaults to a symlink to the same path)
Enable logging
Rescan paths
Copy some lha files to /home/pi/RetroPie/roms/amiga/
Try to launch any file - amiberry locks up as described

I tried delete + kickstarts and reinstall from source as you suggested, and got the same issue. I notice my kickstarts have different CRCs to the page you linked. I'm guessing that's because they are Amiga Forever kickstarts requiring decryption? I'll look into that a bit more next.

moreginger

@nemo93 OK so I acquired a couple of kickstarts that match the crc32s. They seem to work, thanks. I'm pretty sure my Amiga Forever ones were working in the past though?

sirhenrythe5th

@moreginger i never had "Amiga Forever", but as long as i am into Amiga-Emulation these kickstarts with a rom.key were only usable in Amiga Forever.
So, yeah, it may have caused the issues.

moreginger

@sirhenrythe5th As I say, I'm 90% sure it used to work. See e.g. https://retropie.org.uk/forum/post/167494

nemo93

@moreginger nothing has changed in Amiberry about the Amiga Forever area, on purpose. Amiberry's author still use those + the newer 3.2.1 ones without issues. I do not have any experience hence I can't assist you further I'm afraid. Just be sure the files are "readable" by your OS (file permission) and that they are valid.

nemo93

Amiberry 5.5.1 is there and is a recommended update for all users. Many bugfixes and improvements as usual (full changelog here).

The most important change is the new 'default' for CPU. Prior to 5.5 any games either AGA or non-AGA were defaulting to the Amiga 1200 configuration. From now on every non-AGA games (majority) will rely on the classic Amiga 600 configuration (68000/7Mhz) whereas anything AGA/CD32 will stick to Amiga 1200 (68020/14Mhz). This simplifies code on Amiberry's side while improving compatibility as well as accuracy. For the few outliers the external 'xml' file will set appropriate defaults whenever needed to ensure a smooth user experience.

As a bonus plenty of 'custom controls' have been added to allow more and more games to play with only a controller (no more keyboard required).

Thanks to the authors and contributors of this great emulator as well as the many packagers ensuring Amiga still lives on in 2023!

ecto

@nemo93 This new release really makes a difference! This new A600 default for non-AGA/ECS games is great.
I always use "Hostages" as a test for new Amiberry versions, and now it runs perfectly.
Thanks for all your work!

nemo93

HI! I'm calling for help given a weird issue appeared recently which is quite hard to track down. If you can compile latest Amiberry master and report back that would be helpful.

The issue:
On some controller(s) it's possible to trigger reset once by pressing a button. Reset will occur once at the first press of a button, subsequent presses do nothing (button does work as it should).

Affected controllers:

Xbox One controller (bluetooth). Pressing any face button at any time during a game will trigger a reset. Pressing the same button again will not trigger another reset. Please note that a single press of a single button will do. I'm not talking about the Retroarch combo (hotkey+<button>). In fact any buttons on that controller will reset emulation except D-Pad, L2 and R2 triggers and the hotkey which is mapped to select/back here.

Check-list:
This can be reproduced 100% of the time on the above controller(s) with any games. Default Retropie installation and environment. OS packages up-to-date. The Xbox One controller relies on the xpadneo driver also provided by Retropie. Make sure to have default_retroarch_reset=yes set in amiberry.conf.

Thanks in advance.