bsnes/higan/sfc/coprocessor/sharprtc/sharprtc.cpp

132 lines
2.3 KiB
C++
Raw Normal View History

#include <sfc/sfc.hpp>
namespace SuperFamicom {
#include "memory.cpp"
#include "time.cpp"
#include "serialization.cpp"
SharpRTC sharprtc;
auto SharpRTC::Enter() -> void {
while(true) scheduler.synchronize(), sharprtc.main();
}
auto SharpRTC::main() -> void {
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
tickSecond();
step(1);
Update to v100r14 release. byuu says: (Windows: compile with -fpermissive to silence an annoying error. I'll fix it in the next WIP.) I completely replaced the time management system in higan and overhauled the scheduler. Before, processor threads would have "int64 clock"; and there would be a 1:1 relationship between two threads. When thread A ran for X cycles, it'd subtract X * B.Frequency from clock; and when thread B ran for Y cycles, it'd add Y * A.Frequency from clock. This worked well and allowed perfect precision; but it doesn't work when you have more complicated relationships: eg the 68K can sync to the Z80 and PSG; the Z80 to the 68K and PSG; so the PSG needs two counters. The new system instead uses a "uint64 clock" variable that represents time in attoseconds. Every time the scheduler exits, it subtracts the smallest clock count from all threads, to prevent an overflow scenario. The only real downside is that rounding errors mean that roughly every 20 minutes, we have a rounding error of one clock cycle (one 20,000,000th of a second.) However, this only applies to systems with multiple oscillators, like the SNES. And when you're in that situation ... there's no such thing as a perfect oscillator anyway. A real SNES will be thousands of times less out of spec than 1hz per 20 minutes. The advantages are pretty immense. First, we obviously can now support more complex relationships between threads. Second, we can build a much more abstracted scheduler. All of libco is now abstracted away completely, which may permit a state-machine / coroutine version of Thread in the future. We've basically gone from this: auto SMP::step(uint clocks) -> void { clock += clocks * (uint64)cpu.frequency; dsp.clock -= clocks; if(dsp.clock < 0 && !scheduler.synchronizing()) co_switch(dsp.thread); if(clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread); } To this: auto SMP::step(uint clocks) -> void { Thread::step(clocks); synchronize(dsp); synchronize(cpu); } As you can see, we don't have to do multiple clock adjustments anymore. This is a huge win for the SNES CPU that had to update the SMP, DSP, all peripherals and all coprocessors. Likewise, we don't have to synchronize all coprocessors when one runs, now we can just synchronize the active one to the CPU. Third, when changing the frequencies of threads (think SGB speed setting modes, GBC double-speed mode, etc), it no longer causes the "int64 clock" value to be erroneous. Fourth, this results in a fairly decent speedup, mostly across the board. Aside from the GBA being mostly a wash (for unknown reasons), it's about an 8% - 12% speedup in every other emulation core. Now, all of this said ... this was an unbelievably massive change, so ... you know what that means >_> If anyone can help test all types of SNES coprocessors, and some other system games, it'd be appreciated. ---- Lastly, we have a bitchin' new about screen. It unfortunately adds ~200KiB onto the binary size, because the PNG->C++ header file transformation doesn't compress very well, and I want to keep the original resource files in with the higan archive. I might try some things to work around this file size increase in the future, but for now ... yeah, slightly larger archive sizes, sorry. The logo's a bit busted on Windows (the Label control's background transparency and alignment settings aren't working), but works well on GTK. I'll have to fix Windows before the next official release. For now, look on my Twitter feed if you want to see what it's supposed to look like. ---- EDIT: forgot about ICD2::Enter. It's doing some weird inverse run-to-save thing that I need to implement support for somehow. So, save states on the SGB core probably won't work with this WIP.
2016-07-30 03:56:12 +00:00
synchronize(cpu);
}
auto SharpRTC::init() -> void {
}
auto SharpRTC::load() -> void {
return;
second = 0;
minute = 0;
hour = 0;
day = 0;
month = 0;
year = 0;
weekday = 0;
}
auto SharpRTC::unload() -> void {
Update to v075 release. byuu says: This release brings improved Super Game Boy emulation, the final SHA256 hashes for the DSP-(1,1B,2,3,4) and ST-(0010,0011) coprocessors, user interface improvements, and major internal code restructuring. Changelog (since v074): - completely rewrote memory sub-system to support 1-byte granularity in XML mapping - removed Memory inheritance and MMIO class completely, any address can be mapped to any function now - SuperFX: removed SuperFXBus : Bus, now implemented manually - SA-1: removed SA1Bus : Bus, now implemented manually - entire bus mapping is now static, happens once on cartridge load - as a result, read/write handlers now handle MMC mapping; slower average case, far faster worst case - namespace memory is no more, RAM arrays are stored inside the chips they are owned by now - GameBoy: improved CPU HALT emulation, fixes Zelda: Link's Awakening scrolling - GameBoy: added serial emulation (cannot connect to another GB yet), fixes Shin Megami Tensei - Devichil - GameBoy: improved LCD STAT emulation, fixes Sagaia - ui: added fullscreen support (F11 key), video settings allows for three scale settings - ui: fixed brightness, contrast, gamma, audio volume, input frequency values on program startup - ui: since Qt is dead, config file becomes bsnes.cfg once again - Super Game Boy: you can now load the BIOS without a game inserted to see a pretty white box - ui-gameboy: can be built without SNES components now - libsnes: now a UI target, compile with 'make ui=ui-libsnes' - libsnes: added WRAM, APURAM, VRAM, OAM, CGRAM access (cheat search, etc) - source: removed launcher/, as the Qt port is now gone - source: Makefile restructuring to better support new ui targets - source: lots of other internal code cleanup work
2011-01-27 08:52:34 +00:00
}
auto SharpRTC::power() -> void {
create(SharpRTC::Enter, 1);
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
state = State::Read;
index = -1;
}
auto SharpRTC::sync() -> void {
time_t systime = time(0);
tm* timeinfo = localtime(&systime);
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
second = min(59, timeinfo->tm_sec);
minute = timeinfo->tm_min;
hour = timeinfo->tm_hour;
day = timeinfo->tm_mday;
month = 1 + timeinfo->tm_mon;
year = 900 + timeinfo->tm_year;
weekday = timeinfo->tm_wday;
}
auto SharpRTC::read(uint24 addr, uint8 data) -> uint8 {
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
addr &= 1;
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
if(addr == 0) {
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
if(state != State::Read) return 0;
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
if(index < 0) {
index++;
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
return 15;
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
} else if(index > 12) {
index = -1;
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
return 15;
} else {
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
return rtcRead(index++);
}
}
return data;
}
auto SharpRTC::write(uint24 addr, uint8 data) -> void {
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
addr &= 1, data &= 15;
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
if(addr == 1) {
if(data == 0x0d) {
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
state = State::Read;
index = -1;
return;
}
if(data == 0x0e) {
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
state = State::Command;
return;
}
if(data == 0x0f) return; //unknown behavior
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
if(state == State::Command) {
if(data == 0) {
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
state = State::Write;
index = 0;
} else if(data == 4) {
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
state = State::Ready;
index = -1;
//reset time
second = 0;
minute = 0;
hour = 0;
day = 0;
month = 0;
year = 0;
weekday = 0;
} else {
//unknown behavior
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
state = State::Ready;
}
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
return;
}
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
if(state == State::Write) {
if(index >= 0 && index < 12) {
rtcWrite(index++, data);
if(index == 12) {
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
//day of week is automatically calculated and written
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
weekday = calculateWeekday(1000 + year, month, day);
Update to v089r06 release. [Yes, the release number is re-used. -Ed.] byuu says: I had some bugs in r07 that I couldn't track down, DKJM2's clock was getting all out of sync. So I just reverted to r05, blew away both RTCs entirely, and wrote them cleanly from scratch (obviously looking off the old code.) A bit extreme, but it worked. I believe I found the error in the process, day and month were resetting the counter to 0 instead of 1, it wasn't handling leap year, etc. While I was at it, I fixed the day-of-week calculation. The SharpRTC epoch is actually 1000-01-01, and not 1900-01-01. I'm sure you guys will be really happy that if it ever becomes 1000AD again and you're playing a ROM hack that uses the SharpRTC and relies on its weekday value that it will show the correct day now ... Kind of a pain to compute, but nothing compared to the seventh circle of hell that was my IBM dBase III Julian<>Gregorian conversion functions :/ Also found a few bugs in the Epson code this way. And I moved the round seconds actions and flag clear to +125us after flag set. So, if you had the old r06 or r07, please delete those. Unfortunately, this took all of my energy today, so the file names inside manifest changes will have to be in the next WIP. EDIT: ran a diff against old r07 and new r06. - added if(days == 31) case twice in EpsonRTC::tick_day() - forgot weekday = 0; in SharpRTC::load() - need to move the cartridge+cheat objects up in sfc/Makefile again - System::init() needs assert(interface != nullptr /* not 0 */)
2012-05-24 23:26:06 +00:00
}
}
return;
}
}
}
}