For .uae files to show in your listing, the system must be set up to recognised .uae files as an amiga 'file type'. From version 4.2 of RetroPie, this is is automatically the case when Amiberry or UAE4ARM are installed from the 'optional packages' section.
If you are using an older version, consider updating, or if you are using EmulationStation, you can verify in the files /home/pi/.emulationstation/es_systems.cfg or /etc/emulationstation/es_systems.cfg that the 'Amiga' section contains .uae file extensions under the <extension> tag.
If all is in order, then you should also reset the ownership permissions of transferred .uae files, as this may be hiding files from visibility. (see below.)
There are various areas you should verify to check for any errors in your install.
Check the Kickstart(s)
If you do not see the Amiga Kickstart screen at all, you will need must Try loading Amiberry directly, without launching a game. You should be able to reach the configuration menu. From here, you should manually select the kick31.rom file in the Emulator menu (under 'rom'), and click 'reset'. Screenshots below.
Reset File Permissions
You should always try a reset of the ownership permissions of transferred files, as this may be hiding files from visibility from the program. (see below.)
Re-build the .uae Configurations with UAE Config Maker
If you are using existing / pre-prepared .uae files, including those from this site, and especially if you are using a pre-built system, or not using a standard RetroPie and EmulationStation setup (even if you have made modifications yourself) then you should try building new .uae configuration files specifically for your setup, from scratch. This can be achieved by using the UAE Config Maker. For installation/running instructions, see below.
Ensure you are using an up-to-date version of RetroPie, and/or not using a pre-built images (e.g. Rey's Image etc.)
If you are pre-installed images for your RetroPie, it is possible that certain dependencies may be missing, or a file/folder structure may differ from the Project requirements. As such, support cannot be given to resolve your problem, and you should consider whether the original author of that image can be contacted for support or to update their build. It is always recommended to install directly on top of an up-to-date RetroPie image only.
Search the FaceBook Group
You may find further help is available via the project's FaceBook Group - please search the group for answer to your problems, using key search words and taking in comments from the experience of others.
Assistance and De-Bugging
If you are still having problems with loading after following all of the above, please provide all of the information you can before requesting help on the group; including details of how you installed RetroPie, the exact nature of the problem occurring, which steps you have undertaken to try and resolve the issue.
A copy of the contents of the debug file /dev/shm/runcommand.log should be posted to assist. Additionally, if you remove the file /home/pi/RetroPie/roms/amiga-data/_BootWHD/devs/system-configuration and attempt to load a game again, then you may be able to see the Amiga DOS screen. Please post a picture of that screen if an error appears there also.
When asking for assistance on the group, please be aware that those spending time of development may not have time to answer your specific query, and we recommend you *please* reach out to the group as a whole first for your answers and do not private message developers directly for help, there are very knowledgeable board moderators and experts who can help.
RetroPie itself includes an option for this in it's own settings/config menus called "Restore Ownership of /pi/roms" or similar.
You can do this manually from the command line (i.e. via SSH, or from exiting RetroPie) with the following;
sudo chown -hR pi:pi /home/pi/RetroPie
Some known valid Kickstart ROMs are detailed below, and your files can be verified with an Online CRC32 Checker.
FileName |
Known As |
CRC32 |
kick31.rom | Kickstart v3.1 rev 40.68 (1993)(Commodore)(A1200).rom | 1483a091 / 1d9aa278 |
cd32kick31.rom | Kickstart v3.1 rev 40.60 (1993)(Commodore)(CD32).rom | 1e62d4a5 |
cd32ext.rom | CD32 Extended-ROM rev 40.60 (1993)(Commodore)(CD32).rom | 87746be2 |
kick13.rom | Kickstart v1.3 rev 34.5 (1987)(Commodore)(A500-A1000-A2000-CDTV).rom | c4f0f55f |
As mentioned elsewhere, it is essential these are stored in the following folder: /home/pi/RetroPie/bios/Amiga/
There are various possible causes of these problems, but two menu panels from which these issues might be resolved - both are for the setup of Amiga being emulated (sadly even on the real hardware backwards compatibility was not great, although WHDLoad does a lot to level the playing field), and coupled with the accuracy of emulation for this often timing-sensitive machine, incorrect settings can cause issues with some games.
Using F12 (or whatever key/button has been set for bring up the emulator menu) you should try some of the alternative settings in the CPU and Chipset menus to see if they can resolve the issue. If so, you should submit your changes online so that they will filter into future .uae files that might be distributed, and the changes picked up when using the UAE Config Maker in the future. (see below.)
It is quite likely that the reason for this is due to the host Configuration save path within the emulator not being set to the roms folder of RetroPie.
In the 'paths' option of the Emulator you will need to change the "Configuration files" option to /home/pi/RetroPie/roms/amiga. If this has been performed successfully, the .uae configuration files from RetroPie will now also be displayed on the 'Configurations' tab of the emulator.
<jedi> That's good. You've taken your first step into a larger world. </jedi>
This project is all about continuous improvement, and feedback from the users which will improve the experience for everyone is key to that. If you have tweeked or improved settings for any game, whether that be adding memory requirements, switching to 'mouse' control, or setting you have simply found that the name the game is spelt incorrectly, there is probably a file which you can add to via the Settings sections of GitHub.
Any game which has it's data-folder path (the game folder located in /roms/amiga-data/) specified in any of those lists, will then have the new setting applied when the UAE Config Maker updates are made. You can submit the change directly to GitHub and 'commit' the new entry for approval by the project team.
Thanks come from all of the developers for anyone who submits information in this way, and you may even find yourself on a Hall of Fame!
Accuracy. There is a common misconception arising from the Console scene that 'games' and 'ROMs' are interchangeable descriptions. This comes from the fact that many Consoles had their games stored on Cartridges, which were 'ROMs' by definition (ROM = Read Only Memory) and this continues to this day with CD, DVD and Blu-Ray's still being a form of ROMs - so images of these media formats are often simply referred to as 'ROMs'.
However, this becomes complete nonsense for most Amiga usage. Firstly, the primary distribution of games for the Amiga was on Floppy Disk, which is a read/write media format. Images of these are commonly ADF (Amiga Disk File), and are also writable. Secondly, this page is dedicated to a Hard-Drive solution (WHDLoad) which is obviously also a read/write media format, and we will either deal with the actual data files, or if an image is required, an HDF (Hard Disk File) might be used.
In Amiga emulation, the only ROMS we would generally refer to are for the Amiga KickStart (firmware) ROMs, which might be referred to in Console terms as the 'BIOS', and are images of the Amiga Chips which stored the KickStart.
WHDLoad is a software package for the Amiga platform to make installation of software such as games to a hard disk easier, where the original software relied on customised loading routines, specifically for Floppy drives.
This gives much higher compatibility for Amiga software, which can sometimes have hardware incompatibilities making them hard to use in emulated environments due to the widely varying hardware specifications of the Amiga product line across its history. WHDLoad circumvents the operating system in the Amiga for greater compatibility and preserves the original program environment.
WHDLoad carries a number of benefits which make it ideal for an emulated game-playing environment, including:
WHDLoad performs these tasks by using game-data 'ripped' from the original disks, and a bespoke '.slave' file for each game, which contains game-specific code to appl patches on the original game in order to perform the above functions. Specific game slaves are more developed than others, and the full details of the functions of each are available via the WHDLoad project pages.
Further information on WHDLoad, and the individual game slaves (including regular updates) and main documentation and bug submission systems, is available from (www.whdload.de).
Maintaining the WHDLoad slave data is a long task. It has taken considerable to time to take the files loving committed to the wider Amiga community as RetroPlay's Pre-Installed WHDLoad packs and separate them into data packs suitable for this Project. This has involved the removal of re-named duplicates, other language versions and alternative versions and separating into individual packages, and has taken a lot of hours to reach it's present state.
Since this was done with a single data-extraction of the pre-installed packages, it is known and accepted that not all provided games will have the most recent slave file, and that some new installs are not yet included. It is planned to improve this over time, and updated data-packs will be provided as soon as is realistically feasible - unfortunately there is little capacity in the existing development team at present to do this, and we are instead looking at a longer term solution that will provide users an easier route to updating files. As a result, we cannot put a time-scale on any update.
The team would gladly take additional support in getting the available files updated, and if you wish to contribute to this are of the project., please contact the team via our FaceBook Group.
JHT was a similar program to WHDload around 1998 or so, and initially developed at the same time, for the same task - installing custom-loader games to Hard Drive via game code patching.
JST was developed by Jean Francois-Fabre, also known as JOTD. Jean-Francois did notice that WHDload was more developed however, and ceased developing the project, choosing, not long after (and still to this day) to instead codes WHDLoad slaves himself.
There should be no need to support JST installs in this project, since all of the JST loaders were ported directly to WHDLoad.
Yes you can. Scanning of CD32 ISO/CUE images is accepted by the Config Maker, so you will need to generate your own if they do not exists. Each game must be unpacked (i.e. not ZIP) and have the game data (ISO/CUE/WAV files) contained within a single sub-folder, that has the same name as the contained CUE file. You should store this in /home/pi/RetroPie/bios/Amiga/roms/amiga-data/GamesCD32/
Example:
Liberation - Captive II v2.02-2.00c (1994-04-08)(Mindscape)[!][CDD3716]/Liberation - Captive II v2.02-2.00c (1994-04-08)(Mindscape)[!][CDD3716].cue
Liberation - Captive II v2.02-2.00c (1994-04-08)(Mindscape)[!][CDD3716]/Liberation - Captive II v2.02-2.00c (1994-04-08)(Mindscape)(Track 01 of 11)[!][CDD3716].iso
Liberation - Captive II v2.02-2.00c (1994-04-08)(Mindscape)[!][CDD3716]/Liberation - Captive II v2.02-2.00c (1994-04-08)(Mindscape)(Track 02 of 11)[!][CDD3716].wav
Liberation - Captive II v2.02-2.00c (1994-04-08)(Mindscape)[!][CDD3716]/Liberation - Captive II v2.02-2.00c (1994-04-08)(Mindscape)(Track 03 of 11)[!][CDD3716].wav
...
Additionally to this, you will need the two Kickstart rom files for the CD32. The CD32 Kickstart 3.1 rom, which you should rename cd32kick31.rom and also the CD32's second "extended" rom file, which you will need to rename cd32ext.rom. As with your other kickstarts, you should place these in /home/pi/RetroPie/BIOS/Amiga/
In order to ensure you are given the most recent guidance on installing the UAE Config Maker, there is no duplication of installation instructions on this page.
Install Instructions can be found directly via the Project's ReadMe documentation on GitHub.
The UAE Config Maker is a Python script which is entirely command line based. For full details it is recommended you go via the ReadMe documentation on GitHub, where the install and running instructions are included.
You can also install a script for the UAE Config Maker direct to the RetroPie Menu, which will auto-update from GitHub when major releases happen.
You will need to use the UAGS (Universal Amiga Game Scraper) program. This is available on GitHub at present with more details to be provided in the future.
In short, this is a Python script for scraping Amiga game box-art and information from the public contribution openretro.org database, hosted by Frode Solheim and is able to scrape data to a much higher accuracy (around 90% results returned) than the RetroPie in-built scraper (which returns around 20% of results.)
In short; probably never.
The lack of standardisation in these areas means that we will not supply these items as part of this project. When requested, no one was able to give a 'standard' format/size/resolution etc for Video clips, and wheel art seems to differ from theme to theme.
The UAGS scraper will however download box-art automatically, stored in 'boxart' and generate a gamelist.xml including these. It also has the option to download additional images that may be useful however; a game title-screen in 'wheels' (.png format) and an in-game screenshot in 'snaps' (.png format) which can be used where you do not have a video clip.
There are other users within the Project FaceBook Group who are looking into creating packs with this kind of media content in them, and you would be best off reaching out to the group for their assistance.
Due to the large numbers of different controllers available, this FAQ (and the FaceBook Group) cannot assist with individual Controller queries. However, you you should verify that your controller is showing as available, and is picked up as 'js0' by the system.
You can do this from the command line with the the following being entered into the Command Line/SSH:
cd dev/input
dir
If your controller is instead registered as 'js1' or another input device, you will need to make changes to the .uae Config files to accommodate. .e.g by changing the 'joyport1=joy1' line in the .uae template file to 'joyport1=joy2'. You will need to learn how to use the UAE Config Maker to do this.
Any issues beyond this, (assuming your controller is functioning normally), would be an Amiberry/UAE4ARM matter, and this is an area of both emulators which need further development.
The default quit button is set to '16', which is the PS button the PlayStation 3 joypad. It is possible to change the set Quit Button in all of the .uae Config Files, using the UAE Config Maker, but it is not possible to map a button combination such as Start-Select.
Basically, you can have any button you like to quit, but not a combination such as Start+Select.
You will need to establish what button number your input device (joypad) has for the button you which to assign to quit. Using a PS3 pad for example, it is often useful to map to the PS button. Use the command jstest with the input number for your device to locate this, such as with the below:
jstest /dev/input/js0
Changing the Quit Key, and other host options, are performed the same way. It is required for these options to be set within the individual .uae configuration files, and so therefore you will need to generate new .uae files specific to your host setup.
This is made considerably easier with using the UAE Config Maker, where you can edit the file hostconfig.uaetemp (which is a text file) and allows you to specify these options. When you then re-build the .uae files, your 'host' options will have been placed into the .uae files.
Further details on how to install/run the UAE Config Maker are already part of the main guide for this project.
Yes you can. The answer to this is the same as the above question about setting the quitkey (see here) only using the option gfx_correct_aspect= [True / False] in the hostconfig.uaetemp file.
Yes but it requires technical understanding, and probably some patience.
Follow this post by Karl Warren, which explains how to create a virtual xBox controller and use xboxdrv to map your controller to it.
Future development of Amiberry will no doubt bring this function to the emulator itself, but you should also ensure the game is included on the GitHub settings list of games which require mouse control.
In emulation, not at present (Custom buttons are not supported) but a better way would be to request the WHDLoad slave author removes 'keyboard dependency' from the game, with either 2 button or CD32 Pad control support. Request this via the Mantis Bugtracker (mantis.whdload.de) , and/or the WHDLoad.de info page for the individual game. (www.whdload.de).