and who said waterbox can't thread. well, it sort of can't. but it sort of can.
the speedup isn't that great, but speed is now pretty close (5%?) to snes9x in the only game that matters (final fantasy 5)
For the external cores, I simply listed whatever the release build we have right now built them with. There are other makefiles and such hanging around...
Nyma cores have to move some big complex structs on init and it's annoying and error prone. This solution is not fast, but these are one time transfers anyway, and it does keep code size and saved size down. Architecture yay.
This was benign, because libunwind will ignore a frame header it doesn't understand (__eh_frame was still fine). But now there's no spew in the console. And over the next 50 years it will save a combined 0.3 seconds of cpu time
The goal here is to provide an unwind implementation that works. We (probably) don't have a working ldso, so reconfigure libunwind to work without that. To do that, it needs __eh_frame_* variables which it can addressof to find the locations of .eh_frame and .eh_frame_hdr. There is no way I could get gold to add these at all, so switch back to ld and add a custom linkscript. The custom linkscript gives us the opportunity to simplify the savestate memory mapping stuff inside ElfLoader, which should knock a bit of time off of state loads -- those VirtualProtect calls are not cheap. This also removes a potential source of nondeterminism with certain clever out of range pointers.
Any waterbox core that I didn't recompile for this commit will assert now until it is recompiled, because .wbxsyscall is in the wrong palace.
Trigger condition: Any 32x rom smaller than 4MB in total size that tries to read out of bounds between its actual end and the 4MB limit
I've fixed the emulator crash, but I do not know if such roms are actually mirroring correctly - they probably aren't
Create an all new waterbox build environment:
WSL2 + Ubuntu 20.04 LTS (Other linuxes may work)
Musl libc with waterbox customizations
LLVM's libclang-rt, libunwind, libcxxabi, libcxx
Static linking to elf files
Compared with the old system, this is easier to set up a dev env for and easier to update in the future. The executables are larger but produce smaller savestates due to static linking. The modern toolchain means advanced library features and language features that sometimes appear in some upstream cores will be reusable.
If you tried setting your gains to 100 in the previous patch, it worked sort of, but I decided to incorporate ekeeke/Genesis-Plus-GX@f6f4556 as well to actually fix it completely, and rescale the setting properly so that 1.0 really is neutral gain.
Fixes#1319
gpgx upstream automatically gives 64KiB sram to every game of size 2MB or lower, unless specifically overrided. That sucks and we don't do it. But some games do need it; there's not enough information to autodetect otherwise. So add a flag that we can set in gameDB for it, and set it true for two known games that have problems otherwise.
mapper_32k_w expects to be able to write to rom area, so those roms now need larger savestate space
We could be extra clever and alloc_invisible the space and then restore after loadstate, but this pokeymans garbage doesn't deserve that work
nattthebear