Amiberry : is JIT + WHDLoad broken on RPI4 ?

yserra

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.

yserra

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 -G

Everything 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?

BuZz

@yserra I will test.

yserra

@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?

Doody

@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 ---
~

yserra

@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.

BuZz

@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/conf folder. 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.

BuZz

@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.

yserra

@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.

officerdibble

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.

Geoff

@officerdibble

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.