78bf2285fc
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. |
||
|---|---|---|
| .. | ||
| .vscode | ||
| src | ||
| .gitignore | ||
| Cargo.lock | ||
| Cargo.toml | ||
| README.md | ||
| build-debug-no-dirty-detection.bat | ||
| build-debug-no-dirty-detection.sh | ||
| build-debug.bat | ||
| build-debug.sh | ||
| build-release.bat | ||
| build-release.sh | ||
README.md
Waterboxhost
This is the native support code for Waterbox. It's intended to be consumed as a shared library from the host environment with a C api. For most work with Waterbox cores, you don't need to get into this at all.
API
The public api is mostly all in src/cinterface.rs and has basic documentation on it. Bare minimum sequence of calls to
get going:
- (Optional) In a release environment, turn off certain checks to speed things up
wbx_set_always_evict_blocks() - Create an environment, and load the ELF into it
wbx_create_host()wbx_activate_host() - Connect exports from the guest executable to your host system
wbx_get_proc_addr() - Run the guest system's init, using function pointers it exposed through
wbx_get_proc_addr() - Get ready to take savestates
wbx_seal() - Run emulation, using frameadvance or other advance functions exposed by the guest through
wbx_get_proc_addr() - Save and load states as needed
wbx_save_state()wbx_load_state() - Tear down the environment when done with it. (One shot processes that are about to exit can skip this; the OS will clean everything up)
wbx_deactivate_host()wbx_destroy_host()
Some more advanced features:
- If you're keeping around multiple hosts that may compete for the same address space,
use
wbx_activate_host()andwbx_deactivate_host()to switch between them. - If you'd like to expose files to the virtual filesystem, see
wbx_mount_file()andwbx_unmount_file(). - If you need to call dynamically exposed functions that are not part of the static exports, see
wbx_get_callin_addr(). - If you'd like the guest code to be able to call callbacks that you pass to it, see
wbx_get_callback_addr().
Building
Standard rust build infrastructure is used and can be installed with rustup. At the moment, we're using the nightly-x86_64-pc-windows-gnu
chain on Windows, and the nightly-x86_64-unknown-linux-gnu chain on linux. I don't know much about crosspiling, but presumably that will work.
The linux chain works fine in WSL, anyway. When used in a Windows environment with the right default chain, build-release.bat will build
waterboxhost.dll and copy it to the right place. When used in a Linux (or WSL) environment with the right default chain, build-release.sh
will build libwaterboxhost.so and copy it to the right place.