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

A Former User

Has anyone tried a REAL Amiga image from a Amiga SDCard ?
I have imaged my real Amiga 1200 4Gb image that I made over a 2-year period, to a image file "wb31.img". It's a fully working Workbench 3.1, with a average size of WHLoad games, utils, music, etc..
I have tested this image in the latest WinUAE, on my PC, and it works great. But on my Pi 3B+, with the latest binary Amiberry, it doesn't properly recognise the image size- it gets the size wrong(3.8Gb), and of course doesn't then boot - it just goes to the Amiga boot screen. I have tested a small image made in WinUAE, just a fresh install of Workbench 3.1, no games or utils, and around 50Mb in size, and it works great in Amiberry.
Does Amiberry actually support the booting of HD images that have been imaged from a real Amiga 1200 ?

mitu

@John_RM_70 I think it might be the size of the image - this particular bug report seems similar to your issue.

A Former User

@mitu Thanks, that does look like the issue. I think it was perfectly summed up by this post

"There doesn't appear to be any support for real RDB HDF files, only 'partition' HDF's and a max size of 1GB. 4GB is the limit on a real Amiga without 3rd party software or OS >3.1"

So that looks like a long-standing issue that is just waiting for a fix.

Thanks, mitu.

LifeAsASuffix

I’ve got a strange issue; it was mentioned in the thread but i never saw a resolution. I have installed Amiberry from Source, loaded the kickstart.rom files in the BIOS folder, and added a few .iha files to the ROMs folder. When i launched the first rom everything went great. Boot screen loaded Loader came up with info, game loaded and controls worked perfectly. I exited the game and wen’t to launch another and Nothing. Blank screen, no Bootscreen, no loader, no mouse cursor. I can bring up the GUI, and everything looks normal. When I restart from here I get a hand holding a disk, so something isn’t loading right.
I restarted, checked the kickstart files, checked the symblinks, and am now updating Amiberry (though it was only installed 2 days ago). Everything looks normal, but honestly I don’t know what they should be, but i didn’t change anything from working to not.
I’m sure I’m overlooking something simple, it loaded once (Chuck Yeager Advanced Flight Trainer 2) so I think i have all the right files in all the right places, but now nothing will load.
Thanks -Ed

BiZzAr721

@LifeAsASuffix Did you ever get this issue sorted out? I just got Amiberry set up, and ran into this issue with a few select CD32 games. Everything else I checked has been working. I joined WHD bug reporting to document Banshee just going to a black screen. Bug Reports

In the debug report I had an error stating "the installed program requireds the AGA chipset." At amiberry boot logo, if I press hotkey + xto get to amiberry menu, then change chipset to AGA, the game will load fine, just without controller mapped.

By the way, anyone involved in Amiberry / WHDloader - thank you. Amazing work!

dudleydes

@BiZzAr721 Amiberry gets its game specific settings from whdload.xml which can be found in /opt/retropie/emulators/amiberry/whdboot/game-data/ .

The latest version available at the Amiberry github currently supports v3.2 of Banshee CD32 so v3.3 will launch with the default (non-AGA) settings. You are better off opening an issue at the Github page to let the devs know so that they can update the whdload.xml file.

In the meantime, you can create a game specific setting for v3.3 by following the instructions at: https://github.com/midwan/amiberry/wiki/WHDLoad-Auto-booting#game-specific-settings-improving-game-compatibility.

BiZzAr721

Thank you. I will be sure to do both later this evening!

EDIT:
I opened a issue at github. I also created game specific settings, so got it working! I originally thought WHDload was more of an index of games compatible, including all previous versions of each game listed and that everything else on what & how to run the game was within the .lha. When I update Amiberry with a newer whdload.xml, do previous versions of games still run correctly when I new version is released?

youxia

Hi, I'm trying to get Amiberry to display properly on a CRT TV via composite. I was advised to use this guide: https://github.com/mcgurk/Raspberry-Amiga-Emulation ("Optional: 288p composite output"). Seems its possible with some tweaks. My problem is it seems a bit dated in respect to configs (I'm using Amiberry 2.24) and I don't know where to put the following changes:

amiberry.gfx_correct_aspect=false
amiberry.horizontal_offset=0
amiberry.vertical_offset=-16

gfx_framerate=0
gfx_linemode=double
gfx_width=720
gfx_height=288
gfx_width_windowed=720
gfx_height_windowed=288
gfx_width_fullscreen=720
gfx_height_fullscreen=288
gfx_correct_aspect=false

I tried various configs, from hostpref to making individual .whd & .uae files but nothing is really working. It seems some of these configs have different syntax? (eg: LINE_DOUBLING=TRUE instead of gfx_linemode=double)

Using that alternative syntax seemed to effect some changes when the game starts, but as soon as I get into F12 menu, everything reverts to default config.

Any ideas on how to deal with this most appreciated.

Dwarfboysim

HI all,
I used to love playing this as a child. I have an LHA version but it runs too fast. Was advised to set BITTER-WAIT in the WHDLOAD_DB.XML file which has made the speed correct but now the game has a flickering effect. Particularly if a person is on the screen such as the Nurse in the Hospital or your assistant at the start.

Anyone got any further tips on how to fine tune this game?

Also would love to know all the parameters and values I can set for the individual games in the whdload.xmil to avoid have UAE’s as well for the LHA games.

Also anyone know of plans for someone to do Bone Cruncher and Starways as LHA files? Both need kick start 1.2 and minimal RAM/CPU settings otherwise they won’t load

FYI my system is:

System spec below:
Raspberry Pi 3 Model B
Raspberry Pi 2.5 amp PSU
SanDisk 64GB SD card
4 x Logitech F710 Wireless Controllers
1x 4 port USB 2 Hub
1 x Logitech Wireless Mouse and Keyboard
O.S. RetroPie 4.4 with most recent updates

Thanks,
Greg

HoraceAndSpider

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

@BiZzAr721 Amiberry gets its game specific settings from whdload.xml which can be found in /opt/retropie/emulators/amiberry/whdboot/game-data/ .

The latest version available at the Amiberry github currently supports v3.2 of Banshee CD32 so v3.3 will launch with the default (non-AGA) settings. You are better off opening an issue at the Github page to let the devs know so that they can update the whdload.xml file.

In the meantime, you can create a game specific setting for v3.3 by following the instructions at: https://github.com/midwan/amiberry/wiki/WHDLoad-Auto-booting#game-specific-settings-improving-game-compatibility.

Hi mate

Just to let you know I auto-sync all of the latest WHDLoad game every few days. The Python script that generates the XML is also run in “update” mode (new entries only) every 2 days, and a full “refresh all” sync is down very week. These changes are immediately pushed to the Amiberry XML GitHub, so it should never be out of date by more than 3 days, as long as my computer stays online! (If anyone wants to host a backup, I would welcome it, please get in contact)

The XML generator actually re-uses a lot of the old Config Maker code, and so any game that is updated, provided it still has the same directory path inside the LHA, will immediately pick up the right settings even on an updated version, without anyone needing to lift a finger.

AGA, CD32 and NTSC modes should all be self-detected from the filenames. Please let me know (via the Amiberry GitHub ideally) if this is not the case.

I am working on a “download Xml” button in-emulator for this regularly updated source, as the new updated booter is using the xml to really speed up compatibility and faster loading times.

HoraceAndSpider

Also I should probably say I am surpressing the support for the .whd file as I feel this is unnecessary as the .uae files (which are far more flexible) will be loaded with the game anyway, and I would rather contributions were made for the XML to be correctly updated.

BiZzAr721

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

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

@BiZzAr721 Amiberry gets its game specific settings from whdload.xml which can be found in /opt/retropie/emulators/amiberry/whdboot/game-data/ .

The latest version available at the Amiberry github currently supports v3.2 of Banshee CD32 so v3.3 will launch with the default (non-AGA) settings. You are better off opening an issue at the Github page to let the devs know so that they can update the whdload.xml file.

In the meantime, you can create a game specific setting for v3.3 by following the instructions at: https://github.com/midwan/amiberry/wiki/WHDLoad-Auto-booting#game-specific-settings-improving-game-compatibility.

Hi mate

Just to let you know I auto-sync all of the latest WHDLoad game every few days. The Python script that generates the XML is also run in “update” mode (new entries only) every 2 days, and a full “refresh all” sync is down very week. These changes are immediately pushed to the Amiberry XML GitHub, so it should never be out of date by more than 3 days, as long as my computer stays online! (If anyone wants to host a backup, I would welcome it, please get in contact)

The XML generator actually re-uses a lot of the old Config Maker code, and so any game that is updated, provided it still has the same directory path inside the LHA, will immediately pick up the right settings even on an updated version, without anyone needing to lift a finger.

AGA, CD32 and NTSC modes should all be self-detected from the filenames. Please let me know (via the Amiberry GitHub ideally) if this is not the case.

I am working on a “download Xml” button in-emulator for this regularly updated source, as the new updated booter is using the xml to really speed up compatibility and faster loading times.

Thanks for your work! I love the idea of adding a "download xml" button in emulator as well.

LineOf7s

So, to be clear, should we be regularly grabbing the latest whdload.xml file from github in order to maximise Amiberry compatibility?

HoraceAndSpider

@LineOf7s absolutely, but unless you have manually installed my fork there isn’t much point in that until the main branch is updated (probably when I finish the download button - hopefully during this week)

LineOf7s

Aaah I see.

I shall await The Button. :)

HoraceAndSpider

finished "the button" today :)

It's on my fork, awaiting merge into the main branch.

Apekop123

Quick question, when I try to download TinTin on the moon there are two versions, one with .files at the end and one with .image. Which one should I use? When I put them in the roms folder neither of them starts. Or should I be doing something with the .lha files?
Thanks in advance!

HoraceAndSpider

@Apekop123

It should make very litttle difference on Amiberry.

Tbh, for RetroPie the image one might load ever so slightly faster becuase it only has to cache a file for each original floppy disk.

The only difference in these, is that the original HD installer... (remember, WHDLoad was originally designed to run games that only played on disk, on our hard drives some 20 years ago, and it’s still going strong!!) ...would have had two options: one to install the game by creating “images” of the entire original disks, and one that would have extracted individual files from the disk. Not all installers do this, becuase it really depends on the way the original data was stored.

The files option is better for file space but that’s not really an issue for us here. I like files on my “power” Amiga system because I like seeing if I can make level edits or things like that, but I confess I’d use image versions for RetroPie.

Hope that helps explain

HoraceAndSpider

@Apekop123 I will have to test both to see why they don’t work - there shouldn’t be any difference

Apekop123

Thanks for the explanation. Hopefully I can get one of these to run for me. Great you're willing to look into this!