Waterbox supports threads now, but they're not real threads on the host side because that's complicated and can be nondeterministic. Instead, everything is scheduled to share one host thread. This means that scheduling is actually cooperative and certain patterns of spinlocks and other nonsense can fail to work at all, but "regular" code probably will.
With this, add DobieStation PS2 core. This core was selected because it has threads and is otherwise simple to port; easy to build and a good core/frontend separation. It's not a wonderful core however, with low speed (made abysmally lower by our lack of real threads) and low compatibility, so it remains a curiosity for now.
This would fail to work on any core that used the serviceprovider to provide a settings definition that wasn't on the iemulator itself? Guess we never did that
* poc - have a default core menu that provides a generic settings menu item, wire up some cores to this generic menu that only have settings to begin wtih
* vectrex - remove strong type for settings, if there are no settings the convention is to use object, which allows GenericCoreConfig to be smart
* convert saturn menu to default core menu
* fixups
* convert PCFX menu to generic core menu
* convert snes9x and faust to generic core menu
* convert GBLink to generic core menus
* convert MAME to generic core menu
* convert NGP to generic core menu
* convert GGLink to generic core menu
* convert wonderswan to generic core menu
* convert virtualboy to generic core menu
Finalizers in SpeexResampler and QuickNes assume that the underlying native dll still exists when they run, as they have to in order to successfully clean up leaked memory. This is not true if those resolvers, which were stored as static fields themselves, had been finalized, which can only happen on app exit (because the static fields were readonly and always kept their value). If a SpeexResampler or QuickNes was never disposed and itself lasted all the way to app exit, then the order of these two finalizers would be unspecified and a crash could happen.
In normal circumstances, this was only observable in DS core because apparently Suuper couldn't copy paste properly and missed the dispose part, but that was already fixed in 129d454a67.
Updated the msx bios filename based on mame 0.221 and cbios0.29a, this way it fixes the filename conflict while using the feature "Organize" through Firmware Manager.
Couldn't figure it out about the bios_test origin, so I kept that one unchanged.
The existing API was such that BulkPeekUint(Start: 20, EndInclusive: 39) would actually read from the address range [20, 100) instead of [20, 40). That's completely broken. The hex editor, the only consumer of the API, made the same exact mistake in reverse so the problem wasn't immediately apparent, but it was a giant land mine waiting to happen. Fix them both.
If a particular core instance doesn't use up too much memory, then we don't charge the host OS for that memory.
The strange thing here is that, testing locally on Windows 10, we were already getting the desired semantics even with SEC_COMMIT and not SEC_RESERVE. This commit is still important because:
1) Windows might be providing me an optimization it can't guarantee,
2) Linux might not be able to provide the same optimization
3) In any event, this patch also trims down xor snapshots to match the actual needed size.
Add 'nyma' project
The goal is to eventually update all of our Mednafen cores. For now, there is a work in progress import of the Mednafen pce core. Basic gameplay with hucard, turbocd, and supergrafix is supported, but the core is not complete yet.
This actually makes saveram saving and loading somewhat slower on all waterbox cores, but whatever... it's more important to be simple and readable in this code than fast.
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.
nattthebear