- Apple Silicon builds target macOS 11.0 SDK, so almost all deprecation warning associated with this have also been fixed. (The remaining deprecation warnings in preferencesWindowDelegate.mm still need to be fixed in some other way.)
- Intel 64-bit developer builds now require macOS 10.12 SDK (Xcode 8 or later). Of note, this produces faster SSE4.1 code by default, but also requires a Penryn-era Core2Duo CPU or later. (Note that Intel 64-bit non-Haswell in release builds still use SSSE3.)
- Improves overall stability when running DeSmuME on macOS 10.5 Leopard.
- In addition, release builds running Intel 64-bit non-Haswell no longer require macOS 10.7 Lion. They can run on Leopard again!
- Finally fix some GUI issues in the About box when running Dark Mode on macOS 10.14 Mojave or later.
* Interface: Added a function to set the ARM9 next instruction
* Comment about potential JIT issues
* Interface: Made setting next instructions no-op with JIT
it's highly annoying to get the red X for any push or pull request
because mac os x interface build is broken since december.
fix it by installing glib which meson complains about.
Since NDS_Init takes no arguments, it should not hurt to call it early
in the gtk frontend, too.
This fixes the segfault in issue #415, although I could not get it to
run a r4 kernel in a quick test.
According to RFC 2396, the single quote character (') is allowed in uri
strings and is not escaped by gtk, so the action string constructed for
the recent files menu must be quoted with " instead of '.
This fixes issue #437
The data returned by Mic_ReadSample() must be transfered in 2 parts.
This must be done by every microphone driver.
I did test with Lunar: Dragon Song which values are considered loud,
since you can run away by screaming/blowing into the microphone. Values
from 33-223 don't trigger the escape, values from 0-32 and from 224-255
trigger an escape attempt. Thus 128 would be considered silence.
the offsets in the dump file are as follows (code snippet taken
from the dump function and annotated with locations from gbatek:
0x2000000
fp.fseek(0x000000,SEEK_SET); fp.fwrite(MMU.MAIN_MEM,0x800000); //arm9 main mem (8192K)
4 DTCM 027C0000h 16KB - - - R/W
or 0x800000 or 0xb000000 . DTCM location in real NDS varies, as the program can select where
it's mapped to, apparently.
fp.fseek(0x900000,SEEK_SET); fp.fwrite(MMU.ARM9_DTCM,0x4000); //arm9 DTCM (16K)
fp.fseek(0xA00000,SEEK_SET); fp.fwrite(MMU.ARM9_ITCM,0x8000); //arm9 ITCM (32K)
fp.fseek(0xB00000,SEEK_SET); fp.fwrite(MMU.ARM9_LCD,0xA4000); //LCD mem 656K
0 I/O and VRAM 04000000h 64MB - - R/W R/W
fp.fseek(0xC00000,SEEK_SET); fp.fwrite(MMU.ARM9_VMEM,0x800); //OAM
0xc000bc
fp.fseek(0xD00000,SEEK_SET); fp.fwrite(MMU.ARM7_ERAM,0x10000); //arm7 WRAM (64K)
fp.fseek(0xE00000,SEEK_SET); fp.fwrite(MMU.ARM7_WIRAM,0x10000); //arm7 wifi RAM ?
fp.fseek(0xF00000,SEEK_SET); fp.fwrite(MMU.SWIRAM,0x8000); //arm9/arm7 shared WRAM (32KB)
this is necessary to load saves from other devices or emulators,
as desmume uses its own incompatible format.
it works for importing .sav files from flashcarts, but only if the
file extension is .sav or .SAV - if using .dsv desmume guesses it's
of its own type and looks for a specific string, then fails.
the right code was taken from windows/importSave.cpp - it might make
sense to add the export item at some point too, however that will
probably require some more effort.
A call to the `SDL_DestroyTexture` method was forgotten, resulting in all the textures created to render the game's frames being stored indefinitely until running out of memory
This is a temporary fix so anyone using the interface (mainly `py-desmume` users) can have it working correctly again. Next step is to mirror the changes from POSIX CLI's main.cpp `Draw` method, if stable
rogerman