2016-01-07 08:14:33 +00:00
|
|
|
#pragma once
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2011-06-05 03:45:04 +00:00
|
|
|
#include <nall/platform.hpp>
|
2015-08-02 06:23:13 +00:00
|
|
|
#include <nall/file-system-object.hpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
#include <nall/stdint.hpp>
|
|
|
|
#include <nall/string.hpp>
|
|
|
|
#include <nall/utility.hpp>
|
Update to v093r02 release.
byuu says:
Changelog:
- nall: fixed major memory leak in string class
- ruby: video shaders support #define-based settings now
- phoenix/GTK+: support > 256x256 icons for window / task bar / alt-tab
- sfc: remove random/ and config/, merge into system/
- ethos: delete higan.png (48x48), replace with higan512.png (512x512)
as new higan.png
- ethos: default gamma to 100% (no color adjustment)
- ethos: use "Video Shaders/Display Emulation/" instead of "Video
Shaders/Emulation/"
- use g++ instead of g++-4.7 (g++ -v must be >= 4.7)
- use -std=c++11 instead of -std=gnu++11
- applied a few patches from Debian upstream to make their packaging job
easier
So because colors are normalized in GLSL, I won't be able to offer video
shaders absolute color literals. We will have to perform basic color
conversion inside the core.
As such, the current plan is to create some sort of Emulator::Settings
interface. With that, I'll connect an option for color correction, which
will be on by default. For FC/SFC, that will mean gamma correction
(darker / stronger colors), and for GB/GBC/GBA, it will mean simulating
the weird brightness levels of the displays. I am undecided on whether
to use pea soup green for the GB or not. By not doing so, it'll be
easier for the display emulation shader to do it.
2013-11-09 11:45:54 +00:00
|
|
|
#include <nall/varint.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/hash/sha256.hpp>
|
Update to v088r03 release.
byuu says:
static vector<uint8_t> file::read(const string &filename); replaces:
static bool file::read(const string &filename, uint8_t *&data, unsigned
&size); This allows automatic deletion of the underlying data.
Added vectorstream, which is obviously a vector<uint8_t> wrapper for
a data stream. Plan is for all data accesses inside my emulation cores
to take stream objects, especially MSU1. This lets you feed the core
anything: memorystream, filestream, zipstream, gzipstream, httpstream,
etc. There will still be exceptions for link and serial, those need
actual library files on disk. But those aren't official hardware devices
anyway.
So to help with speed a bit, I'm rethinking the video rendering path.
Previous system:
- core outputs system-native samples (SNES = 19-bit LRGB, NES = 9-bit
emphasis+palette, DMG = 2-bit grayscale, etc.)
- interfaceSystem transforms samples to 30-bit via lookup table inside
the emulation core
- interfaceSystem masks off overscan areas, if enabled
- interfaceUI runs filter to produce new target buffer, if enabled
- interfaceUI transforms 30-bit video to native display depth (24-bit or
30-bit), and applies color-adjustments (gamma, etc) at the same time
New system:
- all cores now generate an internal palette, and call
Interface::videoColor(uint32_t source, uint16_t red, uint16_t green,
uint16_t blue) to get native display color post-adjusted (gamma, etc
applied already.)
- all cores output to uint32_t* buffer now (output video.palette[color]
instead of just color)
- interfaceUI runs filter to produce new target buffer, if enabled
- interfaceUI memcpy()'s buffer to the video card
videoColor() is pretty neat. source is the raw pixel (as per the
old-format, 19-bit SNES, 9-bit NES, etc), and you can create a color
from that if you really want to. Or return that value to get a buffer
just like v088 and below. red, green, blue are 16-bits per channel,
because why the hell not, right? Just lop off all the bits you don't
want. If you have more bits on your display than that, fuck you :P
The last step is extremely difficult to avoid. Video cards can and do
have pitches that differ from the width of the texture. Trying to make
the core account for this would be really awful. And even if we did
that, the emulation routine would need to write directly to a video card
RAM buffer. Some APIs require you to lock the video buffer while
writing, so this would leave the video buffer locked for a long time.
Probably not catastrophic, but still awful. And lastly, if the
emulation core tried writing directly to the display texture, software
filters would no longer be possible (unless you -really- jump through
hooks and divert to a memory buffer when a filter is enabled, but ...
fuck.)
Anyway, the point of all that work was to eliminate an extra video copy,
and the need for a really painful 30-bit to 24-bit conversion (three
shifts, three masks, three array indexes.) So this basically reverts us,
performance-wise, to where we were pre-30 bit support.
[...]
The downside to this is that we're going to need a filter for each
output depth. Since the array type is uint32_t*, and I don't intend to
support higher or lower depths, we really only need 24+30-bit versions
of each filter. Kinda shitty, but oh well.
2012-04-27 12:12:53 +00:00
|
|
|
#include <nall/stream/memory.hpp>
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
namespace nall {
|
2013-05-02 11:25:45 +00:00
|
|
|
|
2015-08-02 06:23:13 +00:00
|
|
|
struct file : file_system_object, varint {
|
2015-12-21 09:16:47 +00:00
|
|
|
enum class mode : uint { read, write, modify, append, readwrite = modify, writeread = append };
|
|
|
|
enum class index : uint { absolute, relative };
|
2013-05-02 11:25:45 +00:00
|
|
|
|
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
|
|
|
static auto copy(const string& sourcename, const string& targetname) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
file rd, wr;
|
|
|
|
if(rd.open(sourcename, mode::read) == false) return false;
|
|
|
|
if(wr.open(targetname, mode::write) == false) return false;
|
2015-12-21 09:16:47 +00:00
|
|
|
for(uint n = 0; n < rd.size(); n++) wr.write(rd.read());
|
2013-05-02 11:25:45 +00:00
|
|
|
return true;
|
|
|
|
}
|
|
|
|
|
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
|
|
|
//attempt to rename file first
|
|
|
|
//this will fail if paths point to different file systems; fall back to copy+remove in this case
|
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
|
|
|
static auto move(const string& sourcename, const string& targetname) -> bool {
|
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(rename(sourcename, targetname)) return true;
|
|
|
|
if(!writable(sourcename)) return false;
|
|
|
|
if(copy(sourcename, targetname)) {
|
|
|
|
remove(sourcename);
|
|
|
|
return true;
|
Update to v093r02 release.
byuu says:
Changelog:
- nall: fixed major memory leak in string class
- ruby: video shaders support #define-based settings now
- phoenix/GTK+: support > 256x256 icons for window / task bar / alt-tab
- sfc: remove random/ and config/, merge into system/
- ethos: delete higan.png (48x48), replace with higan512.png (512x512)
as new higan.png
- ethos: default gamma to 100% (no color adjustment)
- ethos: use "Video Shaders/Display Emulation/" instead of "Video
Shaders/Emulation/"
- use g++ instead of g++-4.7 (g++ -v must be >= 4.7)
- use -std=c++11 instead of -std=gnu++11
- applied a few patches from Debian upstream to make their packaging job
easier
So because colors are normalized in GLSL, I won't be able to offer video
shaders absolute color literals. We will have to perform basic color
conversion inside the core.
As such, the current plan is to create some sort of Emulator::Settings
interface. With that, I'll connect an option for color correction, which
will be on by default. For FC/SFC, that will mean gamma correction
(darker / stronger colors), and for GB/GBC/GBA, it will mean simulating
the weird brightness levels of the displays. I am undecided on whether
to use pea soup green for the GB or not. By not doing so, it'll be
easier for the display emulation shader to do it.
2013-11-09 11:45:54 +00:00
|
|
|
}
|
|
|
|
return false;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
static auto truncate(const string& filename, uint size) -> bool {
|
2015-08-02 06:23:13 +00:00
|
|
|
#if defined(API_POSIX)
|
2013-05-02 11:25:45 +00:00
|
|
|
return truncate(filename, size) == 0;
|
2015-08-02 06:23:13 +00:00
|
|
|
#elif defined(API_WINDOWS)
|
|
|
|
if(auto fp = _wfopen(utf16_t(filename), L"rb+")) {
|
|
|
|
bool result = _chsize(fileno(fp), size) == 0;
|
2013-05-02 11:25:45 +00:00
|
|
|
fclose(fp);
|
2015-08-02 06:23:13 +00:00
|
|
|
return result;
|
2012-06-25 12:49:39 +00:00
|
|
|
}
|
2015-08-02 06:23:13 +00:00
|
|
|
return false;
|
2013-05-02 11:25:45 +00:00
|
|
|
#endif
|
|
|
|
}
|
2012-06-25 12:49:39 +00:00
|
|
|
|
2015-08-02 06:23:13 +00:00
|
|
|
//returns false if specified filename is a directory
|
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
|
|
|
static auto exists(const string& filename) -> bool {
|
2015-08-02 06:23:13 +00:00
|
|
|
#if defined(API_POSIX)
|
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
|
|
|
struct stat data;
|
|
|
|
if(stat(filename, &data) != 0) return false;
|
2015-08-02 06:23:13 +00:00
|
|
|
#elif defined(API_WINDOWS)
|
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
|
|
|
struct __stat64 data;
|
|
|
|
if(_wstat64(utf16_t(filename), &data) != 0) return false;
|
|
|
|
#endif
|
|
|
|
return !(data.st_mode & S_IFDIR);
|
|
|
|
}
|
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
static auto size(const string& filename) -> uintmax {
|
2015-08-02 06:23:13 +00:00
|
|
|
#if defined(API_POSIX)
|
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
|
|
|
struct stat data;
|
|
|
|
stat(filename, &data);
|
2015-08-02 06:23:13 +00:00
|
|
|
#elif defined(API_WINDOWS)
|
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
|
|
|
struct __stat64 data;
|
|
|
|
_wstat64(utf16_t(filename), &data);
|
|
|
|
#endif
|
|
|
|
return S_ISREG(data.st_mode) ? data.st_size : 0u;
|
|
|
|
}
|
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
static auto read(const string& filename) -> vector<uint8> {
|
|
|
|
vector<uint8> memory;
|
2013-05-02 11:25:45 +00:00
|
|
|
file fp;
|
|
|
|
if(fp.open(filename, mode::read)) {
|
|
|
|
memory.resize(fp.size());
|
|
|
|
fp.read(memory.data(), memory.size());
|
Update to v088r14 release.
byuu says:
Changelog:
- added NSS DIP switch settings window (when loading NSS carts with
appropriate manifest.xml file)
- added video shader selection (they go in ~/.config/bsnes/Video
Shaders/ now)
- added driver selection
- added timing settings (not only allows video/audio settings, also has
code to dynamically compute the values for you ... and it actually
works pretty good!)
- moved "None" controller device to bottom of list (it is the least
likely to be used, after all)
- added Interface::path() to support MSU1, USART, Link
- input and hotkey mappings remember list position after assignment
- and more!
target-ethos now has all of the functionality of target-ui, and more.
Final code size for the port is 101.2KB (ethos) vs 167.6KB (ui).
A ~67% reduction in code size, yet it does even more! And you can add or
remove an entire system with only three lines of code (Makefile include,
header include, interface append.)
The only problem left is that the BS-X BIOS won't load the BS Zelda no
Densetsu file.
I can't figure out why it's not working, would appreciate any
assistance, but otherwise I'm probably just going to leave it broken for
v089, sorry.
So the show stoppers for a new release at this point are:
- fix laevateinn to compile with the new interface changes (shouldn't be
too hard, it'll still use the old, direct interface.)
- clean up Emulator::Interface as much as possible (trim down
Information, mediaRequest should use an alternate struct designed to
load firmware / slots separately)
- enhance purify to strip SNES ROM headers, and it really needs a GUI
interface
- it would be highly desirable to make a launcher that can create
a cartridge folder from an existing ROM set (* ethos will need to
accept command-line arguments for this.)
- probably need to remember which controller was selected in each port
for each system across runs
- need to fix the cursor for Super Scope / Justifier games (move from
19-bit to 32-bit colors broke it)
- have to refactor that cache.(hv)offset thing to fix ASP
2012-05-06 23:27:42 +00:00
|
|
|
}
|
2013-05-02 11:25:45 +00:00
|
|
|
return memory;
|
|
|
|
}
|
Update to v088r14 release.
byuu says:
Changelog:
- added NSS DIP switch settings window (when loading NSS carts with
appropriate manifest.xml file)
- added video shader selection (they go in ~/.config/bsnes/Video
Shaders/ now)
- added driver selection
- added timing settings (not only allows video/audio settings, also has
code to dynamically compute the values for you ... and it actually
works pretty good!)
- moved "None" controller device to bottom of list (it is the least
likely to be used, after all)
- added Interface::path() to support MSU1, USART, Link
- input and hotkey mappings remember list position after assignment
- and more!
target-ethos now has all of the functionality of target-ui, and more.
Final code size for the port is 101.2KB (ethos) vs 167.6KB (ui).
A ~67% reduction in code size, yet it does even more! And you can add or
remove an entire system with only three lines of code (Makefile include,
header include, interface append.)
The only problem left is that the BS-X BIOS won't load the BS Zelda no
Densetsu file.
I can't figure out why it's not working, would appreciate any
assistance, but otherwise I'm probably just going to leave it broken for
v089, sorry.
So the show stoppers for a new release at this point are:
- fix laevateinn to compile with the new interface changes (shouldn't be
too hard, it'll still use the old, direct interface.)
- clean up Emulator::Interface as much as possible (trim down
Information, mediaRequest should use an alternate struct designed to
load firmware / slots separately)
- enhance purify to strip SNES ROM headers, and it really needs a GUI
interface
- it would be highly desirable to make a launcher that can create
a cartridge folder from an existing ROM set (* ethos will need to
accept command-line arguments for this.)
- probably need to remember which controller was selected in each port
for each system across runs
- need to fix the cursor for Super Scope / Justifier games (move from
19-bit to 32-bit colors broke it)
- have to refactor that cache.(hv)offset thing to fix ASP
2012-05-06 23:27:42 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
static auto read(const string& filename, uint8* data, uint size) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
file fp;
|
|
|
|
if(fp.open(filename, mode::read) == false) return false;
|
|
|
|
fp.read(data, size);
|
|
|
|
fp.close();
|
|
|
|
return true;
|
|
|
|
}
|
Update to v088r14 release.
byuu says:
Changelog:
- added NSS DIP switch settings window (when loading NSS carts with
appropriate manifest.xml file)
- added video shader selection (they go in ~/.config/bsnes/Video
Shaders/ now)
- added driver selection
- added timing settings (not only allows video/audio settings, also has
code to dynamically compute the values for you ... and it actually
works pretty good!)
- moved "None" controller device to bottom of list (it is the least
likely to be used, after all)
- added Interface::path() to support MSU1, USART, Link
- input and hotkey mappings remember list position after assignment
- and more!
target-ethos now has all of the functionality of target-ui, and more.
Final code size for the port is 101.2KB (ethos) vs 167.6KB (ui).
A ~67% reduction in code size, yet it does even more! And you can add or
remove an entire system with only three lines of code (Makefile include,
header include, interface append.)
The only problem left is that the BS-X BIOS won't load the BS Zelda no
Densetsu file.
I can't figure out why it's not working, would appreciate any
assistance, but otherwise I'm probably just going to leave it broken for
v089, sorry.
So the show stoppers for a new release at this point are:
- fix laevateinn to compile with the new interface changes (shouldn't be
too hard, it'll still use the old, direct interface.)
- clean up Emulator::Interface as much as possible (trim down
Information, mediaRequest should use an alternate struct designed to
load firmware / slots separately)
- enhance purify to strip SNES ROM headers, and it really needs a GUI
interface
- it would be highly desirable to make a launcher that can create
a cartridge folder from an existing ROM set (* ethos will need to
accept command-line arguments for this.)
- probably need to remember which controller was selected in each port
for each system across runs
- need to fix the cursor for Super Scope / Justifier games (move from
19-bit to 32-bit colors broke it)
- have to refactor that cache.(hv)offset thing to fix ASP
2012-05-06 23:27:42 +00:00
|
|
|
|
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
|
|
|
static auto write(const string& filename, const string& text) -> bool {
|
2015-12-21 09:16:47 +00:00
|
|
|
return write(filename, (const uint8*)text.data(), text.size());
|
2013-05-02 11:25:45 +00:00
|
|
|
}
|
2011-08-14 10:34:11 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
static auto write(const string& filename, const vector<uint8>& buffer) -> bool {
|
2015-10-08 11:04:42 +00:00
|
|
|
return write(filename, buffer.data(), buffer.size());
|
2013-05-02 11:25:45 +00:00
|
|
|
}
|
2012-07-15 09:47:35 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
static auto write(const string& filename, const uint8* data, uint size) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
file fp;
|
|
|
|
if(fp.open(filename, mode::write) == false) return false;
|
|
|
|
fp.write(data, size);
|
|
|
|
fp.close();
|
|
|
|
return true;
|
|
|
|
}
|
Update to higan v091r14 and ananke v00r03 releases.
byuu says:
higan changelog:
- generates title displayed in emulator window by asking the core
- core builds title solely from "information/title" ... if it's not
there, you don't get a title at all
- sub-system load menu is gone ... since there are multiple revisions of
the SGB, this never really worked well anyway
- to load an SGB, BS-X or ST cartridge, load the base cartridge first
- "File->Load Game" moved to "Load->Import Game" ... may cause a bit of
confusion to new users, but I don't like having a single-item menu,
we'll just have to explain it to new users
- browser window redone to look like ananke
- home button here goes to ~/Emulation rather than just ~ like ananke,
since this is the home of game folders
- game folder icon is now the executable icon for the Tango theme
(orange diamond), meant to represent a complete game rather than
a game file or archive
ananke changelog:
- outputs GBC games to "Game Boy Color/" instead of "Game Boy/"
- adds the file basename to "information/title"
Known issues:
- using ananke to load a GB game trips the Super Famicom SGB mode and
fails (need to make the full-path auto-detection ignore non-bootable
systems)
- need to dump and test some BS-X media before releasing
- ananke lacks BS-X Satellaview cartridge support
- v092 isn't going to let you retarget the ananke/higan game folder path
of ~/Emulation, you will have to wait for a future version if that
bothers you so greatly
[Later, after the v092 release, byuu posted this additional changelog:
- kill laevateinn
- add title()
- add bootable, remove load
- combine file, library
- combine [][][] paths
- fix SFC subtype handling XML->BML
- update file browser to use buttons
- update file browser keyboard handling
- update system XML->BML
- fix sufami turbo hashing
- remove Cartridge::manifest
]
2012-12-25 05:31:55 +00:00
|
|
|
|
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
|
|
|
static auto create(const string& filename) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
//create an empty file (will replace existing files)
|
|
|
|
file fp;
|
|
|
|
if(fp.open(filename, mode::write) == false) return false;
|
|
|
|
fp.close();
|
|
|
|
return true;
|
|
|
|
}
|
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
|
|
|
|
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
|
|
|
static auto sha256(const string& filename) -> string {
|
2013-05-02 11:25:45 +00:00
|
|
|
auto buffer = read(filename);
|
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
|
|
|
return Hash::SHA256(buffer.data(), buffer.size()).digest();
|
2013-05-02 11:25:45 +00:00
|
|
|
}
|
2011-08-06 14:03:52 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto read() -> uint8 {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return 0xff; //file not open
|
|
|
|
if(file_mode == mode::write) return 0xff; //reads not permitted
|
|
|
|
if(file_offset >= file_size) return 0xff; //cannot read past end of file
|
|
|
|
buffer_sync();
|
|
|
|
return buffer[(file_offset++) & buffer_mask];
|
|
|
|
}
|
2013-01-21 12:27:15 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto readl(uint length = 1) -> uintmax {
|
|
|
|
uintmax data = 0;
|
2013-05-02 11:25:45 +00:00
|
|
|
for(int i = 0; i < length; i++) {
|
2015-12-21 09:16:47 +00:00
|
|
|
data |= (uintmax)read() << (i << 3);
|
Update to v091r06 release.
byuu says:
This release adds initial database support.
The way it works is you can now load game folders as you always have, or
you can load a game file. If you load a game file, it tries to create
a game folder for you by looking up the file's sha256 in a database. If
it can't find it, sorry, the game won't play. I'm not hooking up the
oldschool "make up a manifest" code here. The easiest way to handle this
is to get me every game so I can dump it and add it to the database :D
The database entries are complete entries that can be copied directly.
So it describes the board, the information, file layout, etc. That'll be
what comes with higan releases in the future.
Internally, I'm separating the information and board descriptions, and
will use a tool to merge the two together.
Here's a current database copy, with one game in it. Still hammering out
some details, but it's mostly how it's going to look.
cartridge region=NTSC
board type=1CB5B-20
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
information
name: Super Mario World 2 - Yoshi's Island (SNS) (1.1)
title: Super Mario World 2: Yoshi's Island
sha256: bd763c1a56365c244be92e6cffefd318780a2a19eda7d5baf1c6d5bd6c1b3e06
board: SHVC-1CB5B-20
rom: 0x200000
ram: 0x8000
layout
file name=program.rom size=0x200000
2012-10-13 09:26:19 +00:00
|
|
|
}
|
2013-05-02 11:25:45 +00:00
|
|
|
return data;
|
|
|
|
}
|
Update to v091r06 release.
byuu says:
This release adds initial database support.
The way it works is you can now load game folders as you always have, or
you can load a game file. If you load a game file, it tries to create
a game folder for you by looking up the file's sha256 in a database. If
it can't find it, sorry, the game won't play. I'm not hooking up the
oldschool "make up a manifest" code here. The easiest way to handle this
is to get me every game so I can dump it and add it to the database :D
The database entries are complete entries that can be copied directly.
So it describes the board, the information, file layout, etc. That'll be
what comes with higan releases in the future.
Internally, I'm separating the information and board descriptions, and
will use a tool to merge the two together.
Here's a current database copy, with one game in it. Still hammering out
some details, but it's mostly how it's going to look.
cartridge region=NTSC
board type=1CB5B-20
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
information
name: Super Mario World 2 - Yoshi's Island (SNS) (1.1)
title: Super Mario World 2: Yoshi's Island
sha256: bd763c1a56365c244be92e6cffefd318780a2a19eda7d5baf1c6d5bd6c1b3e06
board: SHVC-1CB5B-20
rom: 0x200000
ram: 0x8000
layout
file name=program.rom size=0x200000
2012-10-13 09:26:19 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto readm(uint length = 1) -> uintmax {
|
|
|
|
uintmax data = 0;
|
2013-05-02 11:25:45 +00:00
|
|
|
while(length--) {
|
|
|
|
data <<= 8;
|
|
|
|
data |= read();
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2013-05-02 11:25:45 +00:00
|
|
|
return data;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto reads(uint length) -> string {
|
2015-07-14 09:32:43 +00:00
|
|
|
string result;
|
|
|
|
result.resize(length);
|
|
|
|
for(auto& byte : result) byte = read();
|
|
|
|
return result;
|
|
|
|
}
|
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto read(uint8* buffer, uint length) -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
while(length--) *buffer++ = read();
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto write(uint8 data) -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return; //file not open
|
|
|
|
if(file_mode == mode::read) return; //writes not permitted
|
|
|
|
buffer_sync();
|
|
|
|
buffer[(file_offset++) & buffer_mask] = data;
|
|
|
|
buffer_dirty = true;
|
|
|
|
if(file_offset > file_size) file_size = file_offset;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto writel(uintmax data, uint length = 1) -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
while(length--) {
|
|
|
|
write(data);
|
|
|
|
data >>= 8;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2013-05-02 11:25:45 +00:00
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto writem(uintmax data, uint length = 1) -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
for(int i = length - 1; i >= 0; i--) {
|
|
|
|
write(data >> (i << 3));
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2013-05-02 11:25:45 +00:00
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-07-14 09:32:43 +00:00
|
|
|
auto writes(const string& s) -> void {
|
|
|
|
for(auto byte : s) write(byte);
|
|
|
|
}
|
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto write(const uint8* buffer, uint length) -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
while(length--) write(*buffer++);
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
template<typename... Args> auto print(Args... args) -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
string data(args...);
|
|
|
|
const char* p = data;
|
|
|
|
while(*p) write(*p++);
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
auto flush() -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
buffer_flush();
|
|
|
|
fflush(fp);
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto seek(int offset, index index_ = index::absolute) -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return; //file not open
|
|
|
|
buffer_flush();
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
intmax req_offset = file_offset;
|
2013-05-02 11:25:45 +00:00
|
|
|
switch(index_) {
|
|
|
|
case index::absolute: req_offset = offset; break;
|
|
|
|
case index::relative: req_offset += offset; break;
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
if(req_offset < 0) req_offset = 0; //cannot seek before start of file
|
|
|
|
if(req_offset > file_size) {
|
|
|
|
if(file_mode == mode::read) { //cannot seek past end of file
|
|
|
|
req_offset = file_size;
|
|
|
|
} else { //pad file to requested location
|
|
|
|
file_offset = file_size;
|
|
|
|
while(file_size < req_offset) write(0x00);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
file_offset = req_offset;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto offset() const -> uint {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return 0; //file not open
|
|
|
|
return file_offset;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto size() const -> uint {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return 0; //file not open
|
|
|
|
return file_size;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2015-12-21 09:16:47 +00:00
|
|
|
auto truncate(uint size) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return false; //file not open
|
2015-08-02 06:23:13 +00:00
|
|
|
#if defined(API_POSIX)
|
2013-05-02 11:25:45 +00:00
|
|
|
return ftruncate(fileno(fp), size) == 0;
|
2015-08-02 06:23:13 +00:00
|
|
|
#elif defined(API_WINDOWS)
|
2013-05-02 11:25:45 +00:00
|
|
|
return _chsize(fileno(fp), size) == 0;
|
|
|
|
#endif
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
auto end() -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return true; //file not open
|
|
|
|
return file_offset >= file_size;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
auto open() const -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
return fp;
|
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
explicit operator bool() const {
|
|
|
|
return open();
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
auto open(const string& filename, mode mode_) -> bool {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(fp) return false;
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
switch(file_mode = mode_) {
|
2015-08-02 06:23:13 +00:00
|
|
|
#if defined(API_POSIX)
|
2013-05-02 11:25:45 +00:00
|
|
|
case mode::read: fp = fopen(filename, "rb" ); break;
|
|
|
|
case mode::write: fp = fopen(filename, "wb+"); break; //need read permission for buffering
|
|
|
|
case mode::readwrite: fp = fopen(filename, "rb+"); break;
|
|
|
|
case mode::writeread: fp = fopen(filename, "wb+"); break;
|
2015-08-02 06:23:13 +00:00
|
|
|
#elif defined(API_WINDOWS)
|
2013-05-02 11:25:45 +00:00
|
|
|
case mode::read: fp = _wfopen(utf16_t(filename), L"rb" ); break;
|
|
|
|
case mode::write: fp = _wfopen(utf16_t(filename), L"wb+"); break;
|
|
|
|
case mode::readwrite: fp = _wfopen(utf16_t(filename), L"rb+"); break;
|
|
|
|
case mode::writeread: fp = _wfopen(utf16_t(filename), L"wb+"); break;
|
|
|
|
#endif
|
2013-03-15 13:11:33 +00:00
|
|
|
}
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return false;
|
|
|
|
buffer_offset = -1; //invalidate buffer
|
|
|
|
file_offset = 0;
|
|
|
|
fseek(fp, 0, SEEK_END);
|
|
|
|
file_size = ftell(fp);
|
|
|
|
fseek(fp, 0, SEEK_SET);
|
|
|
|
return true;
|
|
|
|
}
|
2013-03-15 13:11:33 +00:00
|
|
|
|
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
|
|
|
auto close() -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return;
|
|
|
|
buffer_flush();
|
|
|
|
fclose(fp);
|
|
|
|
fp = nullptr;
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
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
|
|
|
auto operator=(const file&) -> file& = delete;
|
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
|
|
|
file(const file&) = delete;
|
|
|
|
file() = default;
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
file(const string& filename, mode mode_) {
|
|
|
|
open(filename, mode_);
|
|
|
|
}
|
2010-08-09 13:28:56 +00:00
|
|
|
|
2013-05-02 11:25:45 +00:00
|
|
|
~file() {
|
|
|
|
close();
|
|
|
|
}
|
|
|
|
|
|
|
|
private:
|
|
|
|
enum { buffer_size = 1 << 12, buffer_mask = buffer_size - 1 };
|
|
|
|
char buffer[buffer_size] = {0};
|
|
|
|
int buffer_offset = -1; //invalidate buffer
|
|
|
|
bool buffer_dirty = false;
|
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
|
|
|
FILE* fp = nullptr;
|
2015-12-21 09:16:47 +00:00
|
|
|
uint file_offset = 0;
|
|
|
|
uint file_size = 0;
|
2013-05-02 11:25:45 +00:00
|
|
|
mode file_mode = mode::read;
|
|
|
|
|
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
|
|
|
auto buffer_sync() -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return; //file not open
|
|
|
|
if(buffer_offset != (file_offset & ~buffer_mask)) {
|
|
|
|
buffer_flush();
|
|
|
|
buffer_offset = file_offset & ~buffer_mask;
|
2010-08-09 13:28:56 +00:00
|
|
|
fseek(fp, buffer_offset, SEEK_SET);
|
2015-12-21 09:16:47 +00:00
|
|
|
uint length = (buffer_offset + buffer_size) <= file_size ? buffer_size : (file_size & buffer_mask);
|
|
|
|
if(length) auto unused = fread(buffer, 1, length, fp);
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
2013-05-02 11:25:45 +00:00
|
|
|
}
|
|
|
|
|
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
|
|
|
auto buffer_flush() -> void {
|
2013-05-02 11:25:45 +00:00
|
|
|
if(!fp) return; //file not open
|
|
|
|
if(file_mode == mode::read) return; //buffer cannot be written to
|
|
|
|
if(buffer_offset < 0) return; //buffer unused
|
|
|
|
if(buffer_dirty == false) return; //buffer unmodified since read
|
|
|
|
fseek(fp, buffer_offset, SEEK_SET);
|
2015-12-21 09:16:47 +00:00
|
|
|
uint length = (buffer_offset + buffer_size) <= file_size ? buffer_size : (file_size & buffer_mask);
|
|
|
|
if(length) auto unused = fwrite(buffer, 1, length, fp);
|
2013-05-02 11:25:45 +00:00
|
|
|
buffer_offset = -1; //invalidate buffer
|
|
|
|
buffer_dirty = false;
|
|
|
|
}
|
|
|
|
};
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|