2011-10-02 10:05:45 +00:00
|
|
|
#ifdef NALL_STRING_INTERNAL_HPP
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-10-02 10:05:45 +00:00
|
|
|
//XML v1.0 subset parser
|
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
|
|
|
//revision 0.03
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
namespace nall {
|
2011-12-30 06:41:29 +00:00
|
|
|
namespace XML {
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
struct Node : Markup::Node {
|
|
|
|
protected:
|
|
|
|
inline string escape() const {
|
|
|
|
string result = data;
|
|
|
|
result.replace("&", "&");
|
|
|
|
result.replace("<", "<");
|
|
|
|
result.replace(">", ">");
|
|
|
|
if(attribute == false) return result;
|
|
|
|
result.replace("\'", "'");
|
|
|
|
result.replace("\"", """);
|
|
|
|
return result;
|
2011-12-31 09:24:58 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
inline bool isName(char c) const {
|
|
|
|
if(c >= 'A' && c <= 'Z') return true;
|
|
|
|
if(c >= 'a' && c <= 'z') return true;
|
|
|
|
if(c >= '0' && c <= '9') return true;
|
|
|
|
if(c == '.' || c == '_') return true;
|
|
|
|
if(c == '?') return true;
|
|
|
|
return false;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
inline bool isWhitespace(char c) const {
|
|
|
|
if(c == ' ' || c == '\t') return true;
|
|
|
|
if(c == '\r' || c == '\n') return true;
|
|
|
|
return false;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//copy part of string from source document into target string; decode markup while copying
|
2013-05-02 11:25:45 +00:00
|
|
|
inline void copy(string& target, const char* source, unsigned length) {
|
2011-12-30 06:41:29 +00:00
|
|
|
target.reserve(length + 1);
|
|
|
|
|
|
|
|
#if defined(NALL_XML_LITERAL)
|
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
|
|
|
memory::copy(target.pointer(), source, length);
|
2011-12-30 06:41:29 +00:00
|
|
|
target[length] = 0;
|
|
|
|
return;
|
|
|
|
#endif
|
|
|
|
|
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
|
|
|
char* output = target.pointer();
|
2011-12-30 06:41:29 +00:00
|
|
|
while(length) {
|
|
|
|
if(*source == '&') {
|
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(!memory::compare(source, "<", 4)) { *output++ = '<'; source += 4; length -= 4; continue; }
|
|
|
|
if(!memory::compare(source, ">", 4)) { *output++ = '>'; source += 4; length -= 4; continue; }
|
|
|
|
if(!memory::compare(source, "&", 5)) { *output++ = '&'; source += 5; length -= 5; continue; }
|
|
|
|
if(!memory::compare(source, "'", 6)) { *output++ = '\''; source += 6; length -= 6; continue; }
|
|
|
|
if(!memory::compare(source, """, 6)) { *output++ = '\"'; source += 6; length -= 6; continue; }
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
if(attribute == false && source[0] == '<' && source[1] == '!') {
|
|
|
|
//comment
|
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(!memory::compare(source, "<!--", 4)) {
|
2011-12-30 06:41:29 +00:00
|
|
|
source += 4, length -= 4;
|
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
|
|
|
while(memory::compare(source, "-->", 3)) source++, length--;
|
2011-12-30 06:41:29 +00:00
|
|
|
source += 3, length -= 3;
|
|
|
|
continue;
|
2010-10-03 08:17:11 +00:00
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//CDATA
|
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(!memory::compare(source, "<![CDATA[", 9)) {
|
2011-12-30 06:41:29 +00:00
|
|
|
source += 9, length -= 9;
|
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
|
|
|
while(memory::compare(source, "]]>", 3)) *output++ = *source++, length--;
|
2011-12-30 06:41:29 +00:00
|
|
|
source += 3, length -= 3;
|
|
|
|
continue;
|
|
|
|
}
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
*output++ = *source++, length--;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2011-12-30 06:41:29 +00:00
|
|
|
*output = 0;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
inline bool parseExpression(const char*& p) {
|
2011-12-30 06:41:29 +00:00
|
|
|
if(*(p + 1) != '!') return false;
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//comment
|
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(!memory::compare(p, "<!--", 4)) {
|
|
|
|
while(*p && memory::compare(p, "-->", 3)) p++;
|
2011-12-30 06:41:29 +00:00
|
|
|
if(!*p) throw "unclosed comment";
|
|
|
|
p += 3;
|
2010-08-09 13:28:56 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//CDATA
|
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(!memory::compare(p, "<![CDATA[", 9)) {
|
|
|
|
while(*p && memory::compare(p, "]]>", 3)) p++;
|
2011-12-30 06:41:29 +00:00
|
|
|
if(!*p) throw "unclosed CDATA";
|
|
|
|
p += 3;
|
|
|
|
return true;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//DOCTYPE
|
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(!memory::compare(p, "<!DOCTYPE", 9)) {
|
2011-12-30 06:41:29 +00:00
|
|
|
unsigned counter = 0;
|
|
|
|
do {
|
|
|
|
char n = *p++;
|
|
|
|
if(!n) throw "unclosed DOCTYPE";
|
|
|
|
if(n == '<') counter++;
|
|
|
|
if(n == '>') counter--;
|
|
|
|
} while(counter);
|
|
|
|
return true;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
return false;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//returns true if tag closes itself (<tag/>); false if not (<tag>)
|
2013-05-02 11:25:45 +00:00
|
|
|
inline bool parseHead(const char*& p) {
|
2011-12-30 06:41:29 +00:00
|
|
|
//parse name
|
2013-05-02 11:25:45 +00:00
|
|
|
const char* nameStart = ++p; //skip '<'
|
2011-12-30 06:41:29 +00:00
|
|
|
while(isName(*p)) p++;
|
2013-05-02 11:25:45 +00:00
|
|
|
const char* nameEnd = p;
|
2011-12-30 06:41:29 +00:00
|
|
|
copy(name, nameStart, nameEnd - nameStart);
|
|
|
|
if(name.empty()) throw "missing element name";
|
|
|
|
|
|
|
|
//parse attributes
|
|
|
|
while(*p) {
|
|
|
|
while(isWhitespace(*p)) p++;
|
|
|
|
if(!*p) throw "unclosed attribute";
|
|
|
|
if(*p == '?' || *p == '/' || *p == '>') break;
|
|
|
|
|
|
|
|
//parse attribute name
|
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
|
|
|
Node attribute;
|
|
|
|
attribute.attribute = true;
|
2011-12-30 06:41:29 +00:00
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
const char* nameStart = p;
|
2011-12-30 06:41:29 +00:00
|
|
|
while(isName(*p)) p++;
|
2013-05-02 11:25:45 +00:00
|
|
|
const char* nameEnd = p;
|
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
|
|
|
copy(attribute.name, nameStart, nameEnd - nameStart);
|
|
|
|
if(attribute.name.empty()) throw "missing attribute name";
|
2011-12-30 06:41:29 +00:00
|
|
|
|
|
|
|
//parse attribute data
|
|
|
|
if(*p++ != '=') throw "missing attribute value";
|
|
|
|
char terminal = *p++;
|
|
|
|
if(terminal != '\'' && terminal != '\"') throw "attribute value not quoted";
|
2013-05-02 11:25:45 +00:00
|
|
|
const char* dataStart = p;
|
2011-12-30 06:41:29 +00:00
|
|
|
while(*p && *p != terminal) p++;
|
|
|
|
if(!*p) throw "missing attribute data terminal";
|
2013-05-02 11:25:45 +00:00
|
|
|
const char* dataEnd = p++; //skip closing terminal
|
2011-12-30 06:41:29 +00:00
|
|
|
|
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
|
|
|
copy(attribute.data, dataStart, dataEnd - dataStart);
|
|
|
|
children.append(attribute);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//parse closure
|
|
|
|
if(*p == '?' && *(p + 1) == '>') { p += 2; return true; }
|
|
|
|
if(*p == '/' && *(p + 1) == '>') { p += 2; return true; }
|
|
|
|
if(*p == '>') { p += 1; return false; }
|
|
|
|
throw "invalid element tag";
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//parse element and all of its child elements
|
2013-05-02 11:25:45 +00:00
|
|
|
inline void parseElement(const char*& p) {
|
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
|
|
|
Node node;
|
|
|
|
if(node.parseHead(p) == false) node.parse(p);
|
2011-12-30 06:41:29 +00:00
|
|
|
children.append(node);
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//return true if </tag> matches this node's name
|
2013-05-02 11:25:45 +00:00
|
|
|
inline bool parseClosureElement(const char*& p) {
|
2011-12-30 06:41:29 +00:00
|
|
|
if(p[0] != '<' || p[1] != '/') return false;
|
|
|
|
p += 2;
|
2013-05-02 11:25:45 +00:00
|
|
|
const char* nameStart = p;
|
2011-12-30 06:41:29 +00:00
|
|
|
while(*p && *p != '>') p++;
|
|
|
|
if(*p != '>') throw "unclosed closure element";
|
2013-05-02 11:25:45 +00:00
|
|
|
const char* nameEnd = p++;
|
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(memory::compare(name.data(), nameStart, nameEnd - nameStart)) throw "closure element name mismatch";
|
2011-12-30 06:41:29 +00:00
|
|
|
return true;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
//parse contents of an element
|
2013-05-02 11:25:45 +00:00
|
|
|
inline void parse(const char*& p) {
|
|
|
|
const char* dataStart = p;
|
|
|
|
const char* dataEnd = p;
|
2011-12-30 06:41:29 +00:00
|
|
|
|
|
|
|
while(*p) {
|
|
|
|
while(*p && *p != '<') p++;
|
|
|
|
if(!*p) break;
|
|
|
|
dataEnd = p;
|
|
|
|
if(parseClosureElement(p) == true) break;
|
|
|
|
if(parseExpression(p) == true) continue;
|
|
|
|
parseElement(p);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2011-12-30 06:41:29 +00:00
|
|
|
|
|
|
|
copy(data, dataStart, dataEnd - dataStart);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2011-12-30 06:41:29 +00:00
|
|
|
};
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
struct Document : Node {
|
|
|
|
string error;
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
inline bool load(const char* document) {
|
2011-12-30 06:41:29 +00:00
|
|
|
if(document == nullptr) return false;
|
|
|
|
reset();
|
|
|
|
try {
|
|
|
|
parse(document);
|
2013-05-02 11:25:45 +00:00
|
|
|
} catch(const char* error) {
|
2011-12-30 06:41:29 +00:00
|
|
|
reset();
|
|
|
|
this->error = error;
|
|
|
|
return false;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2011-12-30 06:41:29 +00:00
|
|
|
return true;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2011-12-30 06:41:29 +00:00
|
|
|
inline Document() {}
|
2013-05-02 11:25:45 +00:00
|
|
|
inline Document(const char* document) { load(document); }
|
2011-12-30 06:41:29 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|