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

nemo93

@all the new Amiberry is there (v5)! There will be an effort to get it integrated into Retropie. I can only test on Pi4 therefore any feedback from other Pi's versions will be appreciated.

EDIT: I've slightly edited the OP to add the step-by-step guide to upgrade to v5 for those of you who can't wait to get it added to Retropie!

moonston333

hi all

ive just went back to playing whdload amiga games on my pi3 and PC
im just wondering how do i bypass the protection screen on games.

its just some games i tried they load up and then get to a screen where they ask me to enter a code or word from the manual of the game.

anyone have this same issue thanks in advance

nemo93

@moonston333 can you please mention the games you got this issue with? In some (most?) packages the protection has been removed and entering any characters followed by enter should just work. Other example is Another World where you can simply select any drawings 3 times and you'll get to the main screen.

nemo93

Testing of the new 5.x version is looking good. Thus far I haven't found a single issue. Overall the emulation is really great (at least on my Pi4 with current Retropie 4.8 - 32-bit Buster with fake KMS).

I'm using that post to thank Buzz and cmitu big time for the huge effort to update the script allowing Amiberry 5.x to be updated/compiled without troubles on Retropie. Thank you!

Some fixes have been pushed to master branch recently and should be ported to 5.1 tag in the coming hours. This 5.1 tag has to be the one used by Retropie's install script to get the best experience.

Couple of comments for the record:

update from 3.3 is seamless. Remember to move your kickstart roms to the Retropie $BIOS/amiga new folder
display settings (width/height/autoheight) can still be fetched from the external XML...
...or from amiberry.conf (global settings). If you already have an existing .uae this one will take precedence.
CPU/Chipset and few other settings are still fetched from XML
there's a new "auto-crop" feature which resizes the screen to the best values automatically. (works best on SDL2)
CHD support. Therefore if you have CD32 images that format will help to save some space and keep things tidy
8Mb of Fast RAM (Z2) is now set by default
run games from a real floppy drive connected to a Greaseweazle board

Hereafter the settings to be set in amiberry.conf. Those are definitely recommended if you're new to Amiga and/or don't want to spend time on the configuration. If you're an advanced user and got .uae config files don't worry these will still take precedence. Amiberry will check for settings in that order: .uae > whdload_db.xml > amiberry.conf

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

I'll keep on updating that thread. Feel free to post any feedback.

vretro

Thanks for all the efforts to bring Amiberry 5.1 to Retropie (Available now in a binary update)

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.