2011-10-02 10:05:45 +00:00
|
|
|
#ifdef NALL_STRING_INTERNAL_HPP
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
namespace nall {
|
|
|
|
|
Update to v084r01 release.
I rewrote the S-SMP processor core (implementation of the 256 opcodes),
utilizing my new 6502-like syntax. It matches what bass v05r01 uses.
Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with
"adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from
55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as
template arguments, and instead just use a switch table to pass them as
function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's
arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't
test further.
This does have the potential to cause some regressions if I've messed
anything up, and none of the above tests caught it, so as always,
testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic
set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about
legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside
term(). Without it, there is a tiny pop when the driver is
re-initialized. But with it, the entire emulator would lock up for five
whole seconds waiting on that call to complete. I'll take the pop any
day over that.
2011-11-17 12:05:35 +00:00
|
|
|
//convert any (supported) type to a const char* without constructing a new nall::string
|
|
|
|
//this is used inside istring(...) to build nall::string values
|
|
|
|
template<typename T> struct stringify;
|
|
|
|
|
|
|
|
// base types
|
|
|
|
|
|
|
|
template<> struct stringify<bool> {
|
|
|
|
bool value;
|
|
|
|
operator const char*() const { return value ? "true" : "false"; }
|
|
|
|
stringify(bool value) : value(value) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<char> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(char value) { integer(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
// signed integers
|
|
|
|
|
|
|
|
template<> struct stringify<signed char> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(signed char value) { integer(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<signed short> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(signed short value) { integer(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<signed int> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(signed int value) { integer(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<signed long> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(signed long value) { integer(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<signed long long> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(signed long long value) { integer(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<unsigned bits> struct stringify<int_t<bits>> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(int_t<bits> value) { integer(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
// unsigned integers
|
|
|
|
|
|
|
|
template<> struct stringify<unsigned char> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(unsigned char value) { decimal(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<unsigned short> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(unsigned short value) { decimal(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<unsigned int> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(unsigned int value) { decimal(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<unsigned long> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(unsigned long value) { decimal(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<unsigned long long> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(unsigned long long value) { decimal(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
template<unsigned bits> struct stringify<uint_t<bits>> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
|
|
|
stringify(uint_t<bits> value) { decimal(data, value); }
|
|
|
|
};
|
|
|
|
|
|
|
|
// floating-point
|
|
|
|
|
|
|
|
template<> struct stringify<float> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
stringify(float value) { fp(data, value); }
|
Update to v084r01 release.
I rewrote the S-SMP processor core (implementation of the 256 opcodes),
utilizing my new 6502-like syntax. It matches what bass v05r01 uses.
Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with
"adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from
55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as
template arguments, and instead just use a switch table to pass them as
function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's
arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't
test further.
This does have the potential to cause some regressions if I've messed
anything up, and none of the above tests caught it, so as always,
testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic
set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about
legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside
term(). Without it, there is a tiny pop when the driver is
re-initialized. But with it, the entire emulator would lock up for five
whole seconds waiting on that call to complete. I'll take the pop any
day over that.
2011-11-17 12:05:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<double> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
stringify(double value) { fp(data, value); }
|
Update to v084r01 release.
I rewrote the S-SMP processor core (implementation of the 256 opcodes),
utilizing my new 6502-like syntax. It matches what bass v05r01 uses.
Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with
"adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from
55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as
template arguments, and instead just use a switch table to pass them as
function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's
arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't
test further.
This does have the potential to cause some regressions if I've messed
anything up, and none of the above tests caught it, so as always,
testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic
set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about
legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside
term(). Without it, there is a tiny pop when the driver is
re-initialized. But with it, the entire emulator would lock up for five
whole seconds waiting on that call to complete. I'll take the pop any
day over that.
2011-11-17 12:05:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<long double> {
|
|
|
|
char data[256];
|
|
|
|
operator const char*() const { return data; }
|
Update to v084r03 release.
(r02 was not posted to the WIP thread)
byuu says:
Internally, all color is processed with 30-bit precision. The filters
also operate at 30-bit depth.
There's a new config file setting, video.depth, which defaults to 24.
This causes the final output to downsample to 24-bit, as most will
require.
If you set it to 30-bit, the downsampling will not occur, and bsnes will
ask ruby for a 30-bit surface. If you don't have one available, you're
going to get bad colors. Or maybe even a crash with OpenGL.
I don't yet have detection code to make sure you have an appropriate
visual in place.
30-bit mode will really only work if you are running Linux, running Xorg
at Depth 30, use the OpenGL or XShm driver, have an nVidia Quadro or AMD
FireGL card with the official drivers, and have a 30-bit capable
monitor.
Lots of planning and work for very little gain here, but it's nice that
it's finally finished.
Oh, I had to change the contrast/brightness formulas a tiny bit, but
they still work and look nice.
2011-12-03 03:22:54 +00:00
|
|
|
stringify(long double value) { fp(data, value); }
|
Update to v084r01 release.
I rewrote the S-SMP processor core (implementation of the 256 opcodes),
utilizing my new 6502-like syntax. It matches what bass v05r01 uses.
Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with
"adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from
55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as
template arguments, and instead just use a switch table to pass them as
function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's
arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't
test further.
This does have the potential to cause some regressions if I've messed
anything up, and none of the above tests caught it, so as always,
testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic
set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about
legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside
term(). Without it, there is a tiny pop when the driver is
re-initialized. But with it, the entire emulator would lock up for five
whole seconds waiting on that call to complete. I'll take the pop any
day over that.
2011-11-17 12:05:35 +00:00
|
|
|
};
|
|
|
|
|
|
|
|
// strings
|
|
|
|
|
|
|
|
template<> struct stringify<char*> {
|
|
|
|
const char *value;
|
|
|
|
operator const char*() const { return value; }
|
|
|
|
stringify(char *value) : value(value) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<const char*> {
|
|
|
|
const char *value;
|
|
|
|
operator const char*() const { return value; }
|
|
|
|
stringify(const char *value) : value(value) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<string> {
|
|
|
|
const string &value;
|
|
|
|
operator const char*() const { return value; }
|
|
|
|
stringify(const string &value) : value(value) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<const string&> {
|
|
|
|
const string &value;
|
|
|
|
operator const char*() const { return value; }
|
|
|
|
stringify(const string &value) : value(value) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<cstring> {
|
|
|
|
const char *value;
|
|
|
|
operator const char*() const { return value; }
|
|
|
|
stringify(const cstring &value) : value(value) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<const cstring&> {
|
|
|
|
const char *value;
|
|
|
|
operator const char*() const { return value; }
|
|
|
|
stringify(const cstring &value) : value(value) {}
|
|
|
|
};
|
2010-08-09 13:28:56 +00:00
|
|
|
|
|
|
|
#if defined(QSTRING_H)
|
Update to v084r01 release.
I rewrote the S-SMP processor core (implementation of the 256 opcodes),
utilizing my new 6502-like syntax. It matches what bass v05r01 uses.
Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with
"adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from
55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as
template arguments, and instead just use a switch table to pass them as
function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's
arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't
test further.
This does have the potential to cause some regressions if I've messed
anything up, and none of the above tests caught it, so as always,
testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic
set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about
legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside
term(). Without it, there is a tiny pop when the driver is
re-initialized. But with it, the entire emulator would lock up for five
whole seconds waiting on that call to complete. I'll take the pop any
day over that.
2011-11-17 12:05:35 +00:00
|
|
|
|
|
|
|
template<> struct stringify<QString> {
|
|
|
|
const QString &value;
|
|
|
|
operator const char*() const { return value.toUtf8().constData(); }
|
|
|
|
stringify(const QString &value) : value(value) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
template<> struct stringify<const QString&> {
|
|
|
|
const QString &value;
|
|
|
|
operator const char*() const { return value.toUtf8().constData(); }
|
|
|
|
stringify(const QString &value) : value(value) {}
|
|
|
|
};
|
|
|
|
|
|
|
|
string::operator QString() const {
|
|
|
|
return QString::fromUtf8(*this);
|
|
|
|
}
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
#endif
|
|
|
|
|
Update to v084r01 release.
I rewrote the S-SMP processor core (implementation of the 256 opcodes),
utilizing my new 6502-like syntax. It matches what bass v05r01 uses.
Took 10 hours.
Due to being able to group the "mov reg,mem" opcodes together with
"adc/sbc/ora/and/eor/cmp" sets, the total code size was reduced from
55.7KB to 42.5KB for identical accuracy and speed.
I also dropped the trick I was using to pass register variables as
template arguments, and instead just use a switch table to pass them as
function arguments. Makes the table a lot easier to read.
Passes all of my S-SMP tests, and all of blargg's
arithmetic/cycle-timing S-SMP tests. Runs Zelda 3 great as well. Didn't
test further.
This does have the potential to cause some regressions if I've messed
anything up, and none of the above tests caught it, so as always,
testing would be appreciated.
Anyway, yeah. By writing the actual processor with this new mnemonic
set, it confirms the parallels I've made.
My guess is that Sony really did clone the 6502, but was worried about
legal implications or something and changed the mnemonics last-minute.
(Note to self: need to re-enable snes.random before v085 official.)
EDIT: oh yeah, I also commented out the ALSA snd_pcm_drain() inside
term(). Without it, there is a tiny pop when the driver is
re-initialized. But with it, the entire emulator would lock up for five
whole seconds waiting on that call to complete. I'll take the pop any
day over that.
2011-11-17 12:05:35 +00:00
|
|
|
//
|
|
|
|
|
|
|
|
template<typename T> stringify<T> make_string(T value) {
|
|
|
|
return stringify<T>(std::forward<T>(value));
|
|
|
|
}
|
|
|
|
|
2010-08-09 13:28:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
#endif
|