Amiberry : is JIT + WHDLoad broken on RPI4 ?
-
Hi all,
Under Amiberry (Amiga Emulator), launching any WHDLoad game with JIT emulation activated goes to a black screen and nothing more happens.My configuration is a Raspberry Pi 4B 4GB RAM with Retropie 4.7.1.
To reproduce the issue, do :
- Launch any Amiga-WHDLoad Game (.lha) from EmulationStation
- Wait until the game has started to be sure it normally runs, then press Select+X (or F12) to access the Amiberry control Panel
- On the left side, select "CPU and FPU", then tick "JIT", then click on the "Reset" Button -> The emulated Amiga seems to reset, the mouse pointer appears briefly on the left-upper corner then BOOM, you're stuck on a black screen of the death.
You would argue that JIT emulation ("Just-In-Time" emulation, the super fast emulator engine) is not necessary for Amiga games since they are fast enough without it.
BUT, because of this issue, it's not possible neither to boot Amiberry with a Workbench 3.1 hardfile (.hdf) to emulate, for instance, a super fast Amiga 68040 workstation. It's possible to boot it without JIT, but, well, the emulation is then sloooow, but sloooow...
Yes, I think I'm not alone having bought a Raspberry Pi 4 to get in 2020 the fastest Amiga ever made... What a disappointment, isn't it?Some additional details:
- JIT emulation works with all the Amiga 500 or Amiga 1200 (AGA) games when booted from ADF files (emulated floppy)
- JIT emulation breaks even Amiga 500 WHDLoad games, and that's really weird because JIT is normally only activated for 68020+ emulation. And Amiga 500 games only use 68000 code...
- The issue is exactly the same if you save a configuration with JIT=ON for any WHDLoad game and boot it directly from EmulationStation without going through the Select+X manipulation-> seems to boot, then stuck in Black screen.
- When I boot my emulated Amiga4000 from an HDF hardfile with JIT=ON, the issue is not a "Black screen of Death", it's just Amiberry brutally quitting to EmulationStation right after accessing the HDF.
Does all this sound familiar to you?
Thanks in advance for your help.
-
hi @yserra! This is due to some internal bug within the Amiberry/UAE code. You'll end up with a black screen or unexpected behavior whenever
JIT is enabled AND when Z2 memory is > 0.
=> to prevent this from happening set Z2 to 0 and add some Z3 instead.Also ensure to have the latest Amiberry compiled/installed (v3.3+) and to update the XML file as well. I've been updating the list to ensure the best compatibility with WHDLOAD packages. Yet if you still face issue with a specific package please let me know.
-
Yes, thank you @nemo93, you're right: all the WHDLoad games are loaded with a 4MB Z2 memory by default!
Many thanks, my WHDLoad with JIT question is now resolved!
Ok, but, the question of why I can't boot from a Workbench 3.1 .hdf file with JIT=ON still remains. My configuration has no Z2 memory at all. As soon as I run it with JIT=ON, Amiberry quits and I'm back to EmulationStation.
The .hdf hardfile I want to boot from is a 524,3 MB file, with a regular Workbench 3.1 installed on it. This exact .hdf hardfile has been tested 100% working on another machine, a Mac with the FS-UAE emulator, and its JIT parameter ON.
To be sure, i recently removed from this .hdf file any weird AmigaOS driver like 68040.library that could be buggy and could crash the Amiga when there is no MMU emulated, because I read somewhere that JIT breaks the MMU emulation. (actually, I read this from the FS-UAE documentation but, well, on FS-UAE, this configuration boots perfectly with 68040.library when JIT is ON, so I'm not sure this does really matters.).What I did:
I named this .hdf hardfile : Amiga4000.hdf,
I put it in the ~/Retropie/roms/amiga/ folder,
I created an Amiga4000.uae config file in the same folder where I selected :
a valid 3.1 Kickstart bios,
a 68040 CPU (I tried 68020 and 68030 with the same result),
Internal FPU (I tried with and without it),
128 MB Z3 memory (I tried with and without it),
16 MB RTG graphic (I tried 32 MB, 64MB...)
and 128 MB CPU board memory (with or without it).
-> when I run all this without JIT : everything works, the Amiga boots from the hardfile, launch Workbench 3.1, shows 68040 CPU...
-> when I run the exact same configuration with JIT=ON : the Runcommand script launches Amiberry, Amiberry seems to start booting from the hdf and... quits immediately, back to EmulationStation.What am I doing wrong?
Thanks for your help.
-
Just to mention: apparently, it's not an Amiberry issue, it's seems to be a Retropie 4.7 issue:
When I run from the command line:
cd /opt/retropie/emulators/amiberry ./amiberry -f ~/RetroPie/roms/amiga/Amiga4000.uae -GEverything works as expected! It boots my emulated Amiga 68040 with JIT=ON from my Workbench 3.1 hardfile (so Amiga4000.hdf) and I can enjoy a super fast emulated Amiga with 423,759 Dhrystones / 442.33 MIPS /151.97 Mflops/ 801x faster than a base Amiga!
But... it doesn't work from the Runcommand script that is automatically launched from EmulationStation...
Do you think it's a RetroPie 4.7 bug? Or could I make something myself to repair it?
-
@yserra I will test.
-
@buzz How went your tests?
I still can't find a solution to this issue. So, to remind you:
- take any Workbench 3.x hardfile (.hdf)
- create a new configuration with this .hdf and JIT, then save it as an .uae file in ~/Retropie/roms/amiga (because EmulationStation doesn't recognize .hdf files...). Let's call it Amiga4000.uae.
- Launch it from EmulationStation -> it quits.
- Launch the exact same command as EmulationStation launches, but from the terminal:
/opt/retropie/emulators/amiberry/amiberry.sh auto ~/RetroPie/roms/amiga/Amiga4000.uae-> it works.
That's not normal. It should work from EmulationStation as it does from the terminal. Something seems to be broken in a script somewhere.
Should I open a new thread, since this issue is beyond the WHDLoad issue mentioned in the title? -
@yserra Exactly the same issue as you, I can confirm that running Amiberry from the command line works fine.
When run through emulationstation the following error in runcommand.log is logged :-
Parameters:
Executing: bash "/home/pi/RetroPie/roms/amiga/+Start Amiberry.sh"
INFO: --- New exception ---
INFO: Error not in JIT code.
INFO: Segmentation Fault
INFO: info.si_signo = 11
INFO: info.si_errno = 0
INFO: info.si_code = -6
INFO: info.si_addr = 00000642
INFO: r0 = 0x00000000
INFO: r1 = 0xbe88451c
INFO: r2 = 0x00000000
INFO: r3 = 0x00000008
INFO: r4 = 0xb6f39968
INFO: r5 = 0x0000000b
INFO: r6 = 0xbe88451c
INFO: r7 = 0x000000af
INFO: r8 = 0x10000000
INFO: r9 = 0x00100000
INFO: r10 = 0x20000000
INFO: FP = 0x03a98680
INFO: IP = 0x00000000
INFO: SP = 0xbe884518
INFO: LR = 0x00000000
INFO: PC = 0xb6d2a8ec
INFO: CPSR = 0x00000010
INFO: Fault Address = 0x30000004
INFO: Trap no = 0x0000000e
INFO: Err Code = 0x00000206
INFO: Old Mask = 0x00000000
INFO: LR - 0x00000000: symbol not found
INFO: Stack trace:
INFO: 0x001887c4 <(null) + 0x001887c4> (./amiberry)
INFO: 0xb66f7130 <__default_rt_sa_restorer + 0x00000000> (/lib/arm-linux-gnueabi hf/libc.so.6)
INFO: IP out of range
INFO: Stack trace (non-dedicated):
INFO: ./amiberry() [0x1888dc]
INFO: /lib/arm-linux-gnueabihf/libc.so.6(__default_rt_sa_restorer+0) [0xb66f7130 ]
INFO: End of stack trace.
INFO: --- end exception ---
~ -
@doody I never found the solution to repair it. At the end, I got something that worked only from SSH, but no more from the Raspberry Pi terminal! This went totally crazy!
So, what I did, i restarted from scratch, this time building up the .hdf file only from Amiberry. The .hdf file I used before had been created on my Mac, with the FS-UAE emulator (and it still works like a charm on FS-UAE for Mac).
And, yes! This time, my new .hdf hardfile, with JIT, fully build up from Amiberry, works directly from EmulationStation! With almost the same .uae config file (I changed so many time the parameters, I can tell you the issue didn't come from there).
I suspect there was on my old hdf a .library that was run at the Amiga boot, or even a command at the beginning of my Startup-sequence that generated an exception with the JIT engine in Amiberry (but not with the JIT engine of other Amiga emulators...) and this exception couldn't be handled correctly by the local console. I don't know what/why. Maybe we will never know.
-
@yserra Probably a new thread would have been best.
Btw if you're launching from a .uae file I prefer to symlink it to the
/opt/retropie/configs/amiga/amiberry/conffolder. Then it's always available in the amiberry GUI to adjust.I wasn't able to reproduce the issue btw. I tested with ClassicWb picasso 96 hdf I had handy. It worked fine from emulation station as it did from command line. I would need a copy of your configs and hdf to test further.
-
@yserra sounds like there was some option that confused things. Maybe path related (relative vs absolute?)
I have caused amiberry to crash before with certain options so it's possible you had some combination that had an issue.
[Edit] sorry misread. The hdf should be fine. I thought you had generated the config elsewhere sorry. Anyway if it's working now all good.
As I said above and think I would need example configs and hdf to debug further. Glad you have it working.
-
@buzz Thank you for your answer. My copy of the hdf that makes Amiberry quits immediately (when JIT is on) from Emulation Station but not from SSH is a 500 GB file. I could I share it with you?
(EDIT) Regarding the config, I tried so many configurations (with more or less RAM in each categories, chipsets and so on) that I'm almost sure the only combinaison that fails is JIT + something inside the hdf that is launched at boot time.
What I could better do is to give you the list of all the Amiga Libs and commands that are running at startup from this HDF, with their respective versions. There is an Amiga tool, SnoopDos, that can trace the filesystem access. I just need to investigate to understand how to use it. Then it should be easy to reproduce the same boot, since all the startup Amiga commands and libraries are free to download from the Aminet freeware webarchive.
-
Amazing.
I'm new to this scene and thought I was an idiot for a while until I read this post, I'm having the exact same issues and been looking for solutions, looks like I'm in the same boat.
Does anyone know why the mouse pointer position does not match the screen position?
Any how, I'm about done with RetroPi for now it's just too buggy, think I will settle for the Amiberry emulation on DietPi.
Good Luck people.
-
I found that by editing the config.txt file that corrects it.
I used sudo nano /boot/config.txt and removed the # in front of disable_overscan=1 to enable it.
Contributions to the project are always appreciated, so if you would like to support us with a donation you can do so here.
Hosting provided by Mythic-Beasts. See the Hosting Information page for more information.