* sockaddr_in is a forward declaration on *BSD, explicitly include the correct header
* fix building with ENABLE_JIT on OpenBSD targets
* add wxallowed linker flag for openbsd targets
* OpenBSD armjit sc_exr -> sc_elr
* wxallowed -> wxneeded
* force mmap for jit on OpenBSD
* disable fastmem on OpenBSD
* fix typo in disabling fastmem for OpenBSD
* add missing space in this if
Set the protection on the code memory to RW when the fault handler
rewrites code, and set it back to RX, the protection prior to the
interrupt, after doing so.
This fixes a segfault that occurred on NetBSD, due to its PaX MPROTECT
policy, when trying to run fastmem.
This could potentially be the reason as to why fastmem does not work on
Apple Silicon Macs, although I am unable to confirm as I do not possess
such a device to test with.
Call the reset function of the JIT object instead of resetting the block
cache directly when disabling the JIT compiler, to ensure that the
protection on the code memory is switched to RW as required.
It is imperative that calls to ResetBlockCache() directly must be
preceeded by JitEnableWrite() to comply with executable-space protection
on systems that require it.
This fixes a segfault on NetBSD, due its PaX MPROTECT policy, that
occured when disabling JIT during runtime.
Call mprotect to switch the code memory protection between RW and RX
when needed on NetBSD, which is required due to PaX MPROTECT being
enabled on all binaries by default by the operating system.
This removes the need to run `paxctl +m melonDS`.
This patch was tested on a x64 VM running NetBSD 10.1. I can confirm
that this fixes JIT on NetBSD, however fastmem does not work as of yet
due to a segfault.
Although invoking mprotect does incur a performance penalty, it is still
faster than running without JIT.
A potentially faster alternative is to back the JIT code memory with an
anonymous file descriptor in physical memory, then map this physical
memory to two virtual memory addresses: one with RW permissions for code
generation, the other with RX permissions for code execution.
Instead of using platform-specific methods to create the anonymous file
descriptor, such as memfd_create on Linux, we could copy a 'trick' that
we use in fastmem already: calling shm_open, a POSIX standard, with a
random name, and immediately unlinking it.
However, this would add some more complexity and would be a bit harder
to implement. For now, this works fine. Perhaps another time...
Call JitEnableWrite() immediately following the allocation of the JIT
code memory in the x64 compiler to make certain that it is in RW mode.
This call is made following allocation in the A64 compiler already, see
9ad3d42 ("hopefully fix macos").
Switching the memory protection between RW and RX is required on systems
that enforce an executable-space protection policy, such as NetBSD and
OpenBSD, with PaX MPROTECT and W^X respectively.
However, adherence to these policies for these platforms is not
implemented yet, so at this moment in time this call should be a no-op
on x64.
* Upgrade to 2025.07.25
* Configure vcpkg settings in vcpkg.json, this avoids needing to
duplicate the vcpkg hash used in several places, and also avoids
needing to set overlay ports/triplets directories from CMake
* Add caching workaround so that builds won't take forever every time
* Build on windows-2025
* DSP HLE (support for AAC, G711 and Graphics ucodes)
* DSP audio output and mic input (both HLE and LLE)
* DSi I2S interface and mic input
* smarter mic input system
Change some styling to make the DS banner box in the ROM Info
dialog look more like the real banner box in the BIOS by:
- Adding the stripes inside the text box
- Adding the banded background in the box as a whole
- Adding the inner white border
- Disabling anti-aliasing on the title font
- Reducing letter spacing and line height
Reported on Discord for BizHawk that going into Ys II after doing Ys I would result in a corrupted save. DeSmuMe reportedly doesn't have this issue, and it has a 64KiB save instead.
* SPU audio latency improvements
Basically reverts audio buffer handling to what it was before commit 05b94ef, but with the mutexes kept for thread safety (which the referenced commit was trying to do).
The SPU audio buffer should still be thread-safe in theory... right?
* Audio output improvements
This commit changes the audio output buffer to be configured by a variable, and fixes the case where the sound driver may change the buffer size after calling SDL_OpenAudioDevice (e.g. if the buffer size is set too low for the driver to handle).
