2016-01-07 08:14:33 +00:00
|
|
|
#pragma once
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
//dynamic linking support
|
|
|
|
|
2011-09-29 12:08:22 +00:00
|
|
|
#include <nall/intrinsics.hpp>
|
2016-05-16 09:51:12 +00:00
|
|
|
#include <nall/path.hpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <nall/stdint.hpp>
|
|
|
|
#include <nall/string.hpp>
|
|
|
|
#include <nall/utility.hpp>
|
|
|
|
|
Update to v094r29 release.
byuu says:
Note: for Windows users, please go to nall/intrinsics.hpp line 60 and
correct the typo from "DISPLAY_WINDOW" to "DISPLAY_WINDOWS" before
compiling, otherwise things won't work at all.
This will be a really major WIP for the core SNES emulation, so please
test as thoroughly as possible.
I rewrote the 65816 CPU core's dispatcher from a jump table to a switch
table. This was so that I could pass class variables as parameters to
opcodes without crazy theatrics.
With that, I killed the regs.r[N] stuff, the flag_t operator|=, &=, ^=
stuff, and all of the template versions of opcodes.
I also removed some stupid pointless flag tests in xcn and pflag that
would always be true.
I sure hope that AWJ is happy with this; because this change was so that
my flag assignments and branch tests won't need to build regs.P into
a full 8-bit variable anymore.
It does of course incur a slight performance hit when you pass in
variables by-value to functions, but it should help with binary size
(and thus cache) by reducing a lot of extra functions. (I know I could
have used template parameters for some things even with a switch table,
but chose not to for the aforementioned reasons.)
Overall, it's about a ~1% speedup from the previous build. The CPU core
instructions were never a bottleneck, but I did want to fix the P flag
building stuff because that really was a dumb mistake v_v'
2015-06-22 13:31:49 +00:00
|
|
|
#if defined(PLATFORM_WINDOWS)
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <windows.h>
|
2011-08-08 12:01:09 +00:00
|
|
|
#include <nall/windows/utf8.hpp>
|
Update to v094r29 release.
byuu says:
Note: for Windows users, please go to nall/intrinsics.hpp line 60 and
correct the typo from "DISPLAY_WINDOW" to "DISPLAY_WINDOWS" before
compiling, otherwise things won't work at all.
This will be a really major WIP for the core SNES emulation, so please
test as thoroughly as possible.
I rewrote the 65816 CPU core's dispatcher from a jump table to a switch
table. This was so that I could pass class variables as parameters to
opcodes without crazy theatrics.
With that, I killed the regs.r[N] stuff, the flag_t operator|=, &=, ^=
stuff, and all of the template versions of opcodes.
I also removed some stupid pointless flag tests in xcn and pflag that
would always be true.
I sure hope that AWJ is happy with this; because this change was so that
my flag assignments and branch tests won't need to build regs.P into
a full 8-bit variable anymore.
It does of course incur a slight performance hit when you pass in
variables by-value to functions, but it should help with binary size
(and thus cache) by reducing a lot of extra functions. (I know I could
have used template parameters for some things even with a switch table,
but chose not to for the aforementioned reasons.)
Overall, it's about a ~1% speedup from the previous build. The CPU core
instructions were never a bottleneck, but I did want to fix the P flag
building stuff because that really was a dumb mistake v_v'
2015-06-22 13:31:49 +00:00
|
|
|
#else
|
|
|
|
#include <dlfcn.h>
|
2010-08-09 13:28:56 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
namespace nall {
|
2013-05-02 11:25:45 +00:00
|
|
|
|
|
|
|
struct library {
|
|
|
|
library() = default;
|
|
|
|
~library() { close(); }
|
|
|
|
|
|
|
|
library& operator=(const library&) = delete;
|
|
|
|
library(const library&) = delete;
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
explicit operator bool() const { return open(); }
|
|
|
|
auto open() const -> bool { return handle; }
|
|
|
|
auto open(const string&, const string& = "") -> bool;
|
|
|
|
auto openAbsolute(const string&) -> bool;
|
|
|
|
auto sym(const string&) -> void*;
|
|
|
|
auto close() -> void;
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
private:
|
|
|
|
uintptr_t handle = 0;
|
2010-08-09 13:28:56 +00:00
|
|
|
};
|
|
|
|
|
Update to v094r29 release.
byuu says:
Note: for Windows users, please go to nall/intrinsics.hpp line 60 and
correct the typo from "DISPLAY_WINDOW" to "DISPLAY_WINDOWS" before
compiling, otherwise things won't work at all.
This will be a really major WIP for the core SNES emulation, so please
test as thoroughly as possible.
I rewrote the 65816 CPU core's dispatcher from a jump table to a switch
table. This was so that I could pass class variables as parameters to
opcodes without crazy theatrics.
With that, I killed the regs.r[N] stuff, the flag_t operator|=, &=, ^=
stuff, and all of the template versions of opcodes.
I also removed some stupid pointless flag tests in xcn and pflag that
would always be true.
I sure hope that AWJ is happy with this; because this change was so that
my flag assignments and branch tests won't need to build regs.P into
a full 8-bit variable anymore.
It does of course incur a slight performance hit when you pass in
variables by-value to functions, but it should help with binary size
(and thus cache) by reducing a lot of extra functions. (I know I could
have used template parameters for some things even with a switch table,
but chose not to for the aforementioned reasons.)
Overall, it's about a ~1% speedup from the previous build. The CPU core
instructions were never a bottleneck, but I did want to fix the P flag
building stuff because that really was a dumb mistake v_v'
2015-06-22 13:31:49 +00:00
|
|
|
#if defined(PLATFORM_LINUX) || defined(PLATFORM_BSD)
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::open(const string& name, const string& path) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(handle) close();
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
if(path) handle = (uintptr_t)dlopen(string(path, "lib", name, ".so"), RTLD_LAZY);
|
2016-05-16 09:51:12 +00:00
|
|
|
if(!handle) handle = (uintptr_t)dlopen(string(Path::user(), ".local/lib/lib", name, ".so"), RTLD_LAZY);
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!handle) handle = (uintptr_t)dlopen(string("/usr/local/lib/lib", name, ".so"), RTLD_LAZY);
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
if(!handle) handle = (uintptr_t)dlopen(string("lib", name, ".so"), RTLD_LAZY);
|
2013-05-02 11:25:45 +00:00
|
|
|
return handle;
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::openAbsolute(const string& name) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(handle) close();
|
|
|
|
handle = (uintptr_t)dlopen(name, RTLD_LAZY);
|
|
|
|
return handle;
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::sym(const string& name) -> void* {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!handle) return nullptr;
|
|
|
|
return dlsym((void*)handle, name);
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::close() -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!handle) return;
|
|
|
|
dlclose((void*)handle);
|
|
|
|
handle = 0;
|
|
|
|
}
|
2013-11-28 10:29:01 +00:00
|
|
|
#elif defined(PLATFORM_MACOSX)
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::open(const string& name, const string& path) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(handle) close();
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
if(path) handle = (uintptr_t)dlopen(string(path, "lib", name, ".dylib"), RTLD_LAZY);
|
Update to v098r11 release.
byuu says:
Changelog:
- fixed nall/path.hpp compilation issue
- fixed ruby/audio/xaudio header declaration compilation issue (again)
- cleaned up xaudio2.hpp file to match my coding syntax (12.5% of the
file was whitespace overkill)
- added null terminator entry to nall/windows/utf8.hpp argc[] array
- nall/windows/guid.hpp uses the Windows API for generating the GUID
- this should stop all the bug reports where two nall users were
generating GUIDs at the exact same second
- fixed hiro/cocoa compilation issue with uint# types
- fixed major higan/sfc Super Game Boy audio latency issue
- fixed higan/sfc CPU core bug with pei, [dp], [dp]+y instructions
- major cleanups to higan/processor/r65816 core
- merged emulation/native-mode opcodes
- use camel-case naming on memory.hpp functions
- simplify address masking code for memory.hpp functions
- simplify a few opcodes themselves (avoid redundant copies, etc)
- rename regs.* to r.* to match modern convention of other CPU cores
- removed device.order<> concept from Emulator::Interface
- cores will now do the translation to make the job of the UI easier
- fixed plurality naming of arrays in Emulator::Interface
- example: emulator.ports[p].devices[d].inputs[i]
- example: vector<Medium> media
- probably more surprises
Major show-stoppers to the next official release:
- we need to work on GB core improvements: LY=153/0 case, multiple STAT
IRQs case, GBC audio output regs, etc.
- we need to re-add software cursors for light guns (Super Scope,
Justifier)
- after the above, we need to fix the turbo button for the Super Scope
I really have no idea how I want to implement the light guns. Ideally,
we'd want it in higan/video, so we can support the NES Zapper with the
same code. But this isn't going to be easy, because only the SNES knows
when its output is interlaced, and its resolutions can vary as
{256,512}x{224,240,448,480} which requires pixel doubling that was
hard-coded to the SNES-specific behavior, but isn't appropriate to be
exposed in higan/video.
2016-05-25 11:13:02 +00:00
|
|
|
if(!handle) handle = (uintptr_t)dlopen(string(Path::user(), ".local/lib/lib", name, ".dylib"), RTLD_LAZY);
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!handle) handle = (uintptr_t)dlopen(string("/usr/local/lib/lib", name, ".dylib"), RTLD_LAZY);
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
if(!handle) handle = (uintptr_t)dlopen(string("lib", name, ".dylib"), RTLD_LAZY);
|
2013-05-02 11:25:45 +00:00
|
|
|
return handle;
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::openAbsolute(const string& name) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(handle) close();
|
|
|
|
handle = (uintptr_t)dlopen(name, RTLD_LAZY);
|
|
|
|
return handle;
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::sym(const string& name) -> void* {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!handle) return nullptr;
|
|
|
|
return dlsym((void*)handle, name);
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::close() -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!handle) return;
|
|
|
|
dlclose((void*)handle);
|
|
|
|
handle = 0;
|
|
|
|
}
|
|
|
|
#elif defined(PLATFORM_WINDOWS)
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::open(const string& name, const string& path) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(handle) close();
|
Update to v094r09 release.
byuu says:
This will easily be the biggest diff in the history of higan. And not in
a good way.
* target-higan and target-loki have been blown away completely
* nall and ruby massively updated
* phoenix replaced with hiro (pretty near a total rewrite)
* target-higan restarted using hiro (just a window for now)
* all emulation cores updated to compile again
* installation changed to not require root privileges (installs locally)
For the foreseeable future (maybe even permanently?), the new higan UI
will only build under Linux/BSD with GTK+ 2.20+. Probably the most
likely route for Windows/OS X will be to try and figure out how to build
hiro/GTK on those platforms, as awful as that would be. The other
alternative would be to produce new UIs for those platforms ... which
would actually be a good opportunity to make something much more user
friendly.
Being that I just started on this a few hours ago, that means that for
at least a few weeks, don't expect to be able to actually play any
games. Right now, you can pretty much just compile the binary and that's
it. It's quite possible that some nall changes didn't produce
compilation errors, but will produce runtime errors. So until the UI can
actually load games, we won't know if anything is broken. But we should
mostly be okay. It was mostly just trim<1> -> trim changes, moving to
Hash::SHA256 (much cleaner), and patching some reckless memory copy
functions enough to compile.
Progress isn't going to be like it was before: I'm now dividing my time
much thinner between studying and other hobbies.
My aim this time is not to produce a binary for everyone to play games
on. Rather, it's to keep the emulator alive. I want to be able to apply
critical patches again. And I would also like the base of the emulator
to live on, for use in other emulator frontends that utilize higan.
2015-02-26 10:10:46 +00:00
|
|
|
if(path) {
|
|
|
|
string filepath = {path, name, ".dll"};
|
|
|
|
handle = (uintptr_t)LoadLibraryW(utf16_t(filepath));
|
|
|
|
}
|
|
|
|
if(!handle) {
|
|
|
|
string filepath = {name, ".dll"};
|
|
|
|
handle = (uintptr_t)LoadLibraryW(utf16_t(filepath));
|
|
|
|
}
|
2013-05-02 11:25:45 +00:00
|
|
|
return handle;
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::openAbsolute(const string& name) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(handle) close();
|
|
|
|
handle = (uintptr_t)LoadLibraryW(utf16_t(name));
|
|
|
|
return handle;
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::sym(const string& name) -> void* {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!handle) return nullptr;
|
|
|
|
return (void*)GetProcAddress((HMODULE)handle, name);
|
|
|
|
}
|
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::close() -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!handle) return;
|
|
|
|
FreeLibrary((HMODULE)handle);
|
|
|
|
handle = 0;
|
|
|
|
}
|
|
|
|
#else
|
2015-07-14 09:32:43 +00:00
|
|
|
inline auto library::open(const string&, const string&) -> bool { return false; }
|
|
|
|
inline auto library::openAbsolute(const string&) -> bool { return false; }
|
|
|
|
inline auto library::sym(const string&) -> void* { return nullptr; }
|
|
|
|
inline auto library::close() -> void {}
|
2013-05-02 11:25:45 +00:00
|
|
|
#endif
|
|
|
|
|
|
|
|
}
|