2016-01-07 08:14:33 +00:00
|
|
|
#pragma once
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-09-27 11:55:02 +00:00
|
|
|
#include <stdarg.h>
|
|
|
|
|
#include <stdio.h>
|
|
|
|
|
#include <stdlib.h>
|
|
|
|
|
#include <string.h>
|
|
|
|
|
|
|
|
|
|
#include <algorithm>
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <initializer_list>
|
2013-05-05 09:21:30 +00:00
|
|
|
#include <memory>
|
2011-09-27 11:55:02 +00:00
|
|
|
|
2013-04-09 13:31:46 +00:00
|
|
|
#include <nall/platform.hpp>
|
2011-09-29 12:08:22 +00:00
|
|
|
#include <nall/atoi.hpp>
|
2011-09-27 11:55:02 +00:00
|
|
|
#include <nall/function.hpp>
|
2013-04-09 13:31:46 +00:00
|
|
|
#include <nall/intrinsics.hpp>
|
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
|
|
|
#include <nall/memory.hpp>
|
2015-12-06 21:11:41 +00:00
|
|
|
#include <nall/primitives.hpp>
|
Update to v094r17 release.
byuu says:
This updates higan to use the new Markup::Node changes. This is a really
big change, and one slight typo anywhere could break certain classes of
games from playing.
I don't have ananke hooked up again yet, so I don't have the ability to
test this much. If anyone with some v094 game folders wouldn't mind
testing, I'd help out a great deal.
I'm most concerned about testing one of each SNES special chip game.
Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using
the fancier lookups, eg node["rom[0]/name"], which I had to convert to
a rather ugly node["rom"].at(0)["name"], which I'm fairly confident
won't work. I'm going to blame that on the fumes from the shelves I just
stained >.> Might work with node.find("rom[0]/name")(0) though ...? But
so ugly ... ugh.
That aside, this WIP adds the accuracy-PPU inlining, so the accuracy
profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
|
|
|
#include <nall/shared-pointer.hpp>
|
2011-09-27 11:55:02 +00:00
|
|
|
#include <nall/stdint.hpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <nall/utility.hpp>
|
Update to v084r01 release.
I rewrote the S-SMP processor core (implementation of the 256 opcodes),
utilizing my new 6502-like syntax. It matches what bass v05r01 uses.
Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with
"adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from
55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as
template arguments, and instead just use a switch table to pass them as
function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's
arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't
test further.
This does have the potential to cause some regressions if I've messed
anything up, and none of the above tests caught it, so as always,
testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic
set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about
legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside
term(). Without it, there is a tiny pop when the driver is
re-initialized. But with it, the entire emulator would lock up for five
whole seconds waiting on that call to complete. I'll take the pop any
day over that.
2011-11-17 12:05:35 +00:00
|
|
|
#include <nall/varint.hpp>
|
2011-09-27 11:55:02 +00:00
|
|
|
#include <nall/vector.hpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2016-05-16 09:51:12 +00:00
|
|
|
namespace nall {
|
|
|
|
|
|
|
|
|
|
struct string;
|
|
|
|
|
struct format;
|
|
|
|
|
struct lstring;
|
|
|
|
|
|
|
|
|
|
struct string_view {
|
|
|
|
|
inline string_view();
|
|
|
|
|
inline string_view(const string_view& source);
|
|
|
|
|
inline string_view(string_view&& source);
|
|
|
|
|
inline string_view(const char* data);
|
|
|
|
|
inline string_view(const char* data, uint size);
|
|
|
|
|
inline string_view(const string& source);
|
|
|
|
|
template<typename... P> inline string_view(P&&... p);
|
|
|
|
|
inline ~string_view();
|
|
|
|
|
|
|
|
|
|
inline auto operator=(const string_view& source) -> string_view&;
|
|
|
|
|
inline auto operator=(string_view&& source) -> string_view&;
|
|
|
|
|
|
|
|
|
|
inline operator const char*() const;
|
|
|
|
|
inline auto data() const -> const char*;
|
|
|
|
|
inline auto size() const -> uint;
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
string* _string;
|
|
|
|
|
const char* _data;
|
|
|
|
|
mutable int _size;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
#define NALL_STRING_ALLOCATOR_ADAPTIVE
|
|
|
|
|
//#define NALL_STRING_ALLOCATOR_COPY_ON_WRITE
|
|
|
|
|
//#define NALL_STRING_ALLOCATOR_SMALL_STRING_OPTIMIZATION
|
|
|
|
|
//#define NALL_STRING_ALLOCATOR_VECTOR
|
|
|
|
|
|
|
|
|
|
//cast.hpp
|
|
|
|
|
template<typename T> struct stringify;
|
|
|
|
|
|
|
|
|
|
//format.hpp
|
|
|
|
|
template<typename... P> inline auto print(P&&...) -> void;
|
|
|
|
|
template<typename... P> inline auto print(FILE*, P&&...) -> void;
|
|
|
|
|
inline auto integer(intmax value, long precision = 0, char padchar = '0') -> string;
|
|
|
|
|
inline auto natural(uintmax value, long precision = 0, char padchar = '0') -> string;
|
|
|
|
|
inline auto hex(uintmax value, long precision = 0, char padchar = '0') -> string;
|
|
|
|
|
inline auto octal(uintmax value, long precision = 0, char padchar = '0') -> string;
|
|
|
|
|
inline auto binary(uintmax value, long precision = 0, char padchar = '0') -> string;
|
|
|
|
|
template<typename T> inline auto pointer(const T* value, long precision = 0) -> string;
|
|
|
|
|
inline auto pointer(uintptr value, long precision = 0) -> string;
|
|
|
|
|
inline auto real(long double value) -> string;
|
|
|
|
|
|
|
|
|
|
//match.hpp
|
|
|
|
|
inline auto tokenize(const char* s, const char* p) -> bool;
|
|
|
|
|
inline auto tokenize(lstring& list, const char* s, const char* p) -> bool;
|
|
|
|
|
|
|
|
|
|
//path.hpp
|
|
|
|
|
inline auto pathname(string_view self) -> string;
|
|
|
|
|
inline auto filename(string_view self) -> string;
|
|
|
|
|
|
|
|
|
|
inline auto dirname(string_view self) -> string;
|
|
|
|
|
inline auto basename(string_view self) -> string;
|
|
|
|
|
inline auto prefixname(string_view self) -> string;
|
|
|
|
|
inline auto suffixname(string_view self) -> string;
|
|
|
|
|
|
|
|
|
|
//utility.hpp
|
|
|
|
|
inline auto slice(string_view self, int offset = 0, int length = -1) -> string;
|
|
|
|
|
|
|
|
|
|
inline auto integer(char* result, intmax value) -> char*;
|
|
|
|
|
inline auto natural(char* result, uintmax value) -> char*;
|
|
|
|
|
inline auto real(char* str, long double value) -> uint;
|
|
|
|
|
|
|
|
|
|
struct string {
|
|
|
|
|
using type = string;
|
|
|
|
|
|
|
|
|
|
protected:
|
|
|
|
|
#if defined(NALL_STRING_ALLOCATOR_ADAPTIVE)
|
|
|
|
|
enum : uint { SSO = 24 };
|
|
|
|
|
union {
|
|
|
|
|
struct { //copy-on-write
|
|
|
|
|
char* _data;
|
|
|
|
|
uint* _refs;
|
|
|
|
|
};
|
|
|
|
|
struct { //small-string-optimization
|
|
|
|
|
char _text[SSO];
|
|
|
|
|
};
|
|
|
|
|
};
|
|
|
|
|
inline auto _allocate() -> void;
|
|
|
|
|
inline auto _copy() -> void;
|
|
|
|
|
inline auto _resize() -> void;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if defined(NALL_STRING_ALLOCATOR_COPY_ON_WRITE)
|
|
|
|
|
char* _data;
|
|
|
|
|
mutable uint* _refs;
|
|
|
|
|
inline auto _allocate() -> char*;
|
|
|
|
|
inline auto _copy() -> char*;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if defined(NALL_STRING_ALLOCATOR_SMALL_STRING_OPTIMIZATION)
|
|
|
|
|
enum : uint { SSO = 24 };
|
|
|
|
|
union {
|
|
|
|
|
char* _data;
|
|
|
|
|
char _text[SSO];
|
|
|
|
|
};
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
#if defined(NALL_STRING_ALLOCATOR_VECTOR)
|
|
|
|
|
char* _data;
|
|
|
|
|
#endif
|
|
|
|
|
|
|
|
|
|
uint _capacity;
|
|
|
|
|
uint _size;
|
|
|
|
|
|
|
|
|
|
public:
|
|
|
|
|
inline string();
|
|
|
|
|
template<typename T = char> inline auto get() -> T*;
|
|
|
|
|
template<typename T = char> inline auto data() const -> const T*;
|
|
|
|
|
inline auto reset() -> type&;
|
|
|
|
|
inline auto reserve(uint) -> type&;
|
|
|
|
|
inline auto resize(uint) -> type&;
|
|
|
|
|
inline auto operator=(const string&) -> type&;
|
|
|
|
|
inline auto operator=(string&&) -> type&;
|
|
|
|
|
|
|
|
|
|
template<typename T, typename... P> string(T&& s, P&&... p) : string() {
|
|
|
|
|
append(forward<T>(s), forward<P>(p)...);
|
|
|
|
|
}
|
|
|
|
|
~string() { reset(); }
|
|
|
|
|
|
|
|
|
|
explicit operator bool() const { return _size; }
|
|
|
|
|
operator const char*() const { return (const char*)data(); }
|
|
|
|
|
|
|
|
|
|
auto size() const -> uint { return _size; }
|
|
|
|
|
auto capacity() const -> uint { return _capacity; }
|
|
|
|
|
|
|
|
|
|
auto operator==(const string& source) const -> bool {
|
|
|
|
|
return size() == source.size() && memory::compare(data(), source.data(), size()) == 0;
|
|
|
|
|
}
|
|
|
|
|
auto operator!=(const string& source) const -> bool {
|
|
|
|
|
return size() != source.size() || memory::compare(data(), source.data(), size()) != 0;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
auto operator==(const char* source) const -> bool { return strcmp(data(), source) == 0; }
|
|
|
|
|
auto operator!=(const char* source) const -> bool { return strcmp(data(), source) != 0; }
|
|
|
|
|
|
|
|
|
|
auto operator==(string_view source) const -> bool { return compare(source) == 0; }
|
|
|
|
|
auto operator!=(string_view source) const -> bool { return compare(source) != 0; }
|
|
|
|
|
auto operator< (string_view source) const -> bool { return compare(source) < 0; }
|
|
|
|
|
auto operator<=(string_view source) const -> bool { return compare(source) <= 0; }
|
|
|
|
|
auto operator> (string_view source) const -> bool { return compare(source) > 0; }
|
|
|
|
|
auto operator>=(string_view source) const -> bool { return compare(source) >= 0; }
|
|
|
|
|
|
|
|
|
|
string(const string& source) : string() { operator=(source); }
|
|
|
|
|
string(string&& source) : string() { operator=(move(source)); }
|
|
|
|
|
|
|
|
|
|
auto begin() -> char* { return &get()[0]; }
|
|
|
|
|
auto end() -> char* { return &get()[size()]; }
|
|
|
|
|
auto begin() const -> const char* { return &data()[0]; }
|
|
|
|
|
auto end() const -> const char* { return &data()[size()]; }
|
|
|
|
|
|
|
|
|
|
//atoi.hpp
|
|
|
|
|
inline auto integer() const -> intmax;
|
|
|
|
|
inline auto natural() const -> uintmax;
|
|
|
|
|
inline auto real() const -> double;
|
|
|
|
|
|
|
|
|
|
//core.hpp
|
|
|
|
|
inline auto operator[](int) const -> const char&;
|
|
|
|
|
template<typename... P> inline auto assign(P&&...) -> type&;
|
|
|
|
|
template<typename T, typename... P> inline auto append(const T&, P&&...) -> type&;
|
|
|
|
|
template<typename... P> inline auto append(const nall::format&, P&&...) -> type&;
|
|
|
|
|
inline auto append() -> type&;
|
|
|
|
|
template<typename T> inline auto _append(const stringify<T>&) -> string&;
|
|
|
|
|
inline auto length() const -> uint;
|
|
|
|
|
|
|
|
|
|
//datetime.hpp
|
|
|
|
|
inline static auto date(time_t = 0) -> string;
|
|
|
|
|
inline static auto time(time_t = 0) -> string;
|
|
|
|
|
inline static auto datetime(time_t = 0) -> string;
|
|
|
|
|
|
|
|
|
|
//find.hpp
|
|
|
|
|
template<bool, bool> inline auto _find(int, string_view) const -> maybe<uint>;
|
|
|
|
|
|
|
|
|
|
inline auto find(string_view source) const -> maybe<uint>;
|
|
|
|
|
inline auto ifind(string_view source) const -> maybe<uint>;
|
|
|
|
|
inline auto qfind(string_view source) const -> maybe<uint>;
|
|
|
|
|
inline auto iqfind(string_view source) const -> maybe<uint>;
|
|
|
|
|
|
|
|
|
|
inline auto findFrom(int offset, string_view source) const -> maybe<uint>;
|
|
|
|
|
inline auto ifindFrom(int offset, string_view source) const -> maybe<uint>;
|
|
|
|
|
|
|
|
|
|
//format.hpp
|
|
|
|
|
inline auto format(const nall::format& params) -> type&;
|
|
|
|
|
|
|
|
|
|
//compare.hpp
|
|
|
|
|
template<bool> inline static auto _compare(const char*, uint, const char*, uint) -> int;
|
|
|
|
|
|
|
|
|
|
inline static auto compare(string_view, string_view) -> int;
|
|
|
|
|
inline static auto icompare(string_view, string_view) -> int;
|
|
|
|
|
|
|
|
|
|
inline auto compare(string_view source) const -> int;
|
|
|
|
|
inline auto icompare(string_view source) const -> int;
|
|
|
|
|
|
|
|
|
|
inline auto equals(string_view source) const -> bool;
|
|
|
|
|
inline auto iequals(string_view source) const -> bool;
|
|
|
|
|
|
|
|
|
|
inline auto beginsWith(string_view source) const -> bool;
|
|
|
|
|
inline auto ibeginsWith(string_view source) const -> bool;
|
|
|
|
|
|
|
|
|
|
inline auto endsWith(string_view source) const -> bool;
|
|
|
|
|
inline auto iendsWith(string_view source) const -> bool;
|
|
|
|
|
|
|
|
|
|
//convert.hpp
|
|
|
|
|
inline auto downcase() -> type&;
|
|
|
|
|
inline auto upcase() -> type&;
|
|
|
|
|
|
|
|
|
|
inline auto qdowncase() -> type&;
|
|
|
|
|
inline auto qupcase() -> type&;
|
|
|
|
|
|
|
|
|
|
inline auto transform(string_view from, string_view to) -> type&;
|
|
|
|
|
|
|
|
|
|
//match.hpp
|
|
|
|
|
inline auto match(string_view source) const -> bool;
|
|
|
|
|
inline auto imatch(string_view source) const -> bool;
|
|
|
|
|
|
|
|
|
|
//replace.hpp
|
|
|
|
|
template<bool, bool> inline auto _replace(string_view, string_view, long) -> type&;
|
|
|
|
|
inline auto replace(string_view from, string_view to, long limit = LONG_MAX) -> type&;
|
|
|
|
|
inline auto ireplace(string_view from, string_view to, long limit = LONG_MAX) -> type&;
|
|
|
|
|
inline auto qreplace(string_view from, string_view to, long limit = LONG_MAX) -> type&;
|
|
|
|
|
inline auto iqreplace(string_view from, string_view to, long limit = LONG_MAX) -> type&;
|
|
|
|
|
|
|
|
|
|
//split.hpp
|
|
|
|
|
inline auto split(string_view key, long limit = LONG_MAX) const -> lstring;
|
|
|
|
|
inline auto isplit(string_view key, long limit = LONG_MAX) const -> lstring;
|
|
|
|
|
inline auto qsplit(string_view key, long limit = LONG_MAX) const -> lstring;
|
|
|
|
|
inline auto iqsplit(string_view key, long limit = LONG_MAX) const -> lstring;
|
|
|
|
|
|
|
|
|
|
//trim.hpp
|
|
|
|
|
inline auto trim(string_view lhs, string_view rhs, long limit = LONG_MAX) -> type&;
|
|
|
|
|
inline auto trimLeft(string_view lhs, long limit = LONG_MAX) -> type&;
|
|
|
|
|
inline auto trimRight(string_view rhs, long limit = LONG_MAX) -> type&;
|
|
|
|
|
|
|
|
|
|
inline auto itrim(string_view lhs, string_view rhs, long limit = LONG_MAX) -> type&;
|
|
|
|
|
inline auto itrimLeft(string_view lhs, long limit = LONG_MAX) -> type&;
|
|
|
|
|
inline auto itrimRight(string_view rhs, long limit = LONG_MAX) -> type&;
|
|
|
|
|
|
|
|
|
|
inline auto strip() -> type&;
|
|
|
|
|
inline auto stripLeft() -> type&;
|
|
|
|
|
inline auto stripRight() -> type&;
|
|
|
|
|
|
|
|
|
|
//utility.hpp
|
|
|
|
|
inline static auto read(string_view filename) -> string;
|
|
|
|
|
inline static auto repeat(string_view pattern, uint times) -> string;
|
|
|
|
|
inline auto fill(char fill = ' ') -> type&;
|
|
|
|
|
inline auto hash() const -> uint;
|
|
|
|
|
inline auto remove(uint offset, uint length) -> type&;
|
|
|
|
|
inline auto reverse() -> type&;
|
|
|
|
|
inline auto size(int length, char fill = ' ') -> type&;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct lstring : vector<string> {
|
|
|
|
|
using type = lstring;
|
|
|
|
|
|
|
|
|
|
lstring(const lstring& source) { vector::operator=(source); }
|
|
|
|
|
lstring(lstring& source) { vector::operator=(source); }
|
|
|
|
|
lstring(lstring&& source) { vector::operator=(move(source)); }
|
|
|
|
|
template<typename... P> lstring(P&&... p) { append(forward<P>(p)...); }
|
|
|
|
|
|
|
|
|
|
//list.hpp
|
|
|
|
|
inline auto operator==(const lstring&) const -> bool;
|
|
|
|
|
inline auto operator!=(const lstring&) const -> bool;
|
|
|
|
|
|
|
|
|
|
inline auto operator=(const lstring& source) -> type& { return vector::operator=(source), *this; }
|
|
|
|
|
inline auto operator=(lstring& source) -> type& { return vector::operator=(source), *this; }
|
|
|
|
|
inline auto operator=(lstring&& source) -> type& { return vector::operator=(move(source)), *this; }
|
|
|
|
|
|
|
|
|
|
inline auto isort() -> type&;
|
|
|
|
|
|
|
|
|
|
template<typename... P> inline auto append(const string&, P&&...) -> type&;
|
|
|
|
|
inline auto append() -> type&;
|
|
|
|
|
|
|
|
|
|
inline auto find(string_view source) const -> maybe<uint>;
|
|
|
|
|
inline auto ifind(string_view source) const -> maybe<uint>;
|
|
|
|
|
inline auto match(string_view pattern) const -> lstring;
|
|
|
|
|
inline auto merge(string_view separator) const -> string;
|
|
|
|
|
inline auto strip() -> type&;
|
|
|
|
|
|
|
|
|
|
//split.hpp
|
|
|
|
|
template<bool, bool> inline auto _split(string_view, string_view, long) -> lstring&;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
struct format : vector<string> {
|
|
|
|
|
using type = format;
|
|
|
|
|
|
|
|
|
|
template<typename... P> format(P&&... p) { reserve(sizeof...(p)); append(forward<P>(p)...); }
|
|
|
|
|
template<typename T, typename... P> inline auto append(const T&, P&&... p) -> type&;
|
|
|
|
|
inline auto append() -> type&;
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
}
|
|
|
|
|
|
2015-09-28 11:56:46 +00:00
|
|
|
#include <nall/string/view.hpp>
|
Update to v094r20 release.
byuu says:
Main reason for this WIP was because of all the added lines to hiro for
selective component disabling. May as well get all the diff-noise apart
from code changes.
It also merges something I've been talking to Cydrak about ... making
nall::string::(integer,decimal) do built-in binary,octal,hex decoding
instead of just failing on those. This will have fun little side effects
all over the place, like being able to view a topic on my forum via
"forum.byuu.org/topic/0b10010110", heh.
There are two small changes to higan itself, though. First up, I fixed
the resampler ratio when loading non-SNES games. Tested and I can play
Game Boy games fine now. Second, I hooked up menu option hiding for
reset and controller selection. Right now, this works like higan v094,
but I'm thinking I might want to show the "Device -> Controller" even if
that's all that's there. It kind of jives nicer with the input settings
window to see the labels there, I think. And if we ever do add more
stuff, it'll be nice that people already always expect that menu there.
Remaining issues:
* add slotted cart loader (SGB, BSX, ST)
* add DIP switch selection window (NSS)
* add timing configuration (video/audio sync)
2015-05-23 05:37:08 +00:00
|
|
|
#include <nall/string/atoi.hpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <nall/string/cast.hpp>
|
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
|
|
|
#include <nall/string/compare.hpp>
|
|
|
|
|
#include <nall/string/convert.hpp>
|
2012-02-26 07:59:44 +00:00
|
|
|
#include <nall/string/core.hpp>
|
2012-10-22 22:45:18 +00:00
|
|
|
#include <nall/string/datetime.hpp>
|
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
|
|
|
#include <nall/string/find.hpp>
|
2013-01-21 12:27:15 +00:00
|
|
|
#include <nall/string/format.hpp>
|
2013-05-05 09:21:30 +00:00
|
|
|
#include <nall/string/list.hpp>
|
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
|
|
|
#include <nall/string/match.hpp>
|
|
|
|
|
#include <nall/string/path.hpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <nall/string/replace.hpp>
|
|
|
|
|
#include <nall/string/split.hpp>
|
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
|
|
|
#include <nall/string/trim.hpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <nall/string/utility.hpp>
|
2013-07-29 09:42:45 +00:00
|
|
|
#include <nall/string/eval/node.hpp>
|
|
|
|
|
#include <nall/string/eval/literal.hpp>
|
|
|
|
|
#include <nall/string/eval/parser.hpp>
|
|
|
|
|
#include <nall/string/eval/evaluator.hpp>
|
Update to v091r05 release.
[No prior releases were posted to the WIP thread. -Ed.]
byuu says:
Super Famicom mapping system has been reworked as discussed with the
mask= changes. offset becomes base, mode is gone. Also added support for
comma-separated fields in the address fields, to reduce the number of
map lines needed.
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<superfx revision="2">
<rom name="program.rom" size="0x200000"/>
<ram name="save.rwm" size="0x8000"/>
<map id="io" address="00-3f,80-bf:3000-32ff"/>
<map id="rom" address="00-3f:8000-ffff" mask="0x8000"/>
<map id="rom" address="40-5f:0000-ffff"/>
<map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/>
<map id="ram" address="70-71:0000-ffff"/>
</superfx>
</cartridge>
Or in BML:
cartridge region=NTSC
superfx revision=2
rom name=program.rom size=0x200000
ram name=save.rwm size=0x8000
map id=io address=00-3f,80-bf:3000-32ff
map id=rom address=00-3f:8000-ffff mask=0x8000
map id=rom address=40-5f:0000-ffff
map id=ram address=00-3f,80-bf:6000-7fff size=0x2000
map id=ram address=70-71:0000-ffff
As a result of the changes, old mappings will no longer work. The above
XML example will run Super Mario World 2: Yoshi's Island. Otherwise,
you'll have to write your own.
All that's left now is to work some sort of database mapping system in,
so I can start dumping carts en masse.
The NES changes that FitzRoy asked for are mostly in as well.
Also, part of the reason I haven't released a WIP ... but fuck it, I'm
not going to wait forever to post a new WIP.
I've added a skeleton driver to emulate Campus Challenge '92 and
Powerfest '94. There's no actual emulation, except for the stuff I can
glean from looking at the pictures of the board. It has a DSP-1 (so
SR/DR registers), four ROMs that map in and out, RAM, etc.
I've also added preliminary mapping to upload high scores to a website,
but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
|
|
|
#include <nall/string/markup/node.hpp>
|
Update to v094r17 release.
byuu says:
This updates higan to use the new Markup::Node changes. This is a really
big change, and one slight typo anywhere could break certain classes of
games from playing.
I don't have ananke hooked up again yet, so I don't have the ability to
test this much. If anyone with some v094 game folders wouldn't mind
testing, I'd help out a great deal.
I'm most concerned about testing one of each SNES special chip game.
Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using
the fancier lookups, eg node["rom[0]/name"], which I had to convert to
a rather ugly node["rom"].at(0)["name"], which I'm fairly confident
won't work. I'm going to blame that on the fumes from the shelves I just
stained >.> Might work with node.find("rom[0]/name")(0) though ...? But
so ugly ... ugh.
That aside, this WIP adds the accuracy-PPU inlining, so the accuracy
profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
|
|
|
#include <nall/string/markup/find.hpp>
|
Update to v091r05 release.
[No prior releases were posted to the WIP thread. -Ed.]
byuu says:
Super Famicom mapping system has been reworked as discussed with the
mask= changes. offset becomes base, mode is gone. Also added support for
comma-separated fields in the address fields, to reduce the number of
map lines needed.
<?xml version="1.0" encoding="UTF-8"?>
<cartridge region="NTSC">
<superfx revision="2">
<rom name="program.rom" size="0x200000"/>
<ram name="save.rwm" size="0x8000"/>
<map id="io" address="00-3f,80-bf:3000-32ff"/>
<map id="rom" address="00-3f:8000-ffff" mask="0x8000"/>
<map id="rom" address="40-5f:0000-ffff"/>
<map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/>
<map id="ram" address="70-71:0000-ffff"/>
</superfx>
</cartridge>
Or in BML:
cartridge region=NTSC
superfx revision=2
rom name=program.rom size=0x200000
ram name=save.rwm size=0x8000
map id=io address=00-3f,80-bf:3000-32ff
map id=rom address=00-3f:8000-ffff mask=0x8000
map id=rom address=40-5f:0000-ffff
map id=ram address=00-3f,80-bf:6000-7fff size=0x2000
map id=ram address=70-71:0000-ffff
As a result of the changes, old mappings will no longer work. The above
XML example will run Super Mario World 2: Yoshi's Island. Otherwise,
you'll have to write your own.
All that's left now is to work some sort of database mapping system in,
so I can start dumping carts en masse.
The NES changes that FitzRoy asked for are mostly in as well.
Also, part of the reason I haven't released a WIP ... but fuck it, I'm
not going to wait forever to post a new WIP.
I've added a skeleton driver to emulate Campus Challenge '92 and
Powerfest '94. There's no actual emulation, except for the stuff I can
glean from looking at the pictures of the board. It has a DSP-1 (so
SR/DR registers), four ROMs that map in and out, RAM, etc.
I've also added preliminary mapping to upload high scores to a website,
but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
|
|
|
#include <nall/string/markup/bml.hpp>
|
|
|
|
|
#include <nall/string/markup/xml.hpp>
|
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
|
|
|
#include <nall/string/transform/cml.hpp>
|
|
|
|
|
#include <nall/string/transform/dml.hpp>
|