bsnes/higan/sfc/coprocessor/epsonrtc/epsonrtc.cpp

201 lines
3.4 KiB
C++
Raw Normal View History

#include <sfc/sfc.hpp>
namespace SuperFamicom {
#include "memory.cpp"
#include "time.cpp"
#include "serialization.cpp"
EpsonRTC epsonrtc;
auto EpsonRTC::Enter() -> void {
while(true) scheduler.synchronize(), epsonrtc.main();
}
auto EpsonRTC::main() -> void {
if(wait) { if(--wait == 0) ready = 1; }
clocks++;
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((clocks & ~0x00ff) == 0) roundSeconds(); //125 microseconds
if((clocks & ~0x3fff) == 0) duty(); //1/128th second
if((clocks & ~0x7fff) == 0) irq(0); //1/64th second
if(clocks == 0) { //1 second
seconds++;
irq(1);
if(seconds % 60 == 0) irq(2); //1 minute
if(seconds % 1440 == 0) irq(3), seconds = 0; //1 hour
tick();
}
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 EpsonRTC::init() -> void {
}
auto EpsonRTC::load() -> void {
secondlo = 0;
secondhi = 0;
batteryfailure = 1;
minutelo = 0;
minutehi = 0;
resync = 0;
hourlo = 0;
hourhi = 0;
meridian = 0;
daylo = 0;
dayhi = 0;
dayram = 0;
monthlo = 0;
monthhi = 0;
monthram = 0;
yearlo = 0;
yearhi = 0;
weekday = 0;
hold = 0;
calendar = 0;
irqflag = 0;
roundseconds = 0;
irqmask = 0;
irqduty = 0;
irqperiod = 0;
pause = 0;
stop = 0;
atime = 0;
test = 0;
}
auto EpsonRTC::unload() -> void {
}
auto EpsonRTC::power() -> 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
create(EpsonRTC::Enter, 32'768 * 64);
clocks = 0;
seconds = 0;
chipselect = 0;
state = State::Mode;
offset = 0;
wait = 0;
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
ready = 0;
holdtick = 0;
}
auto EpsonRTC::sync() -> void {
time_t systime = time(0);
tm* timeinfo = localtime(&systime);
uint second = min(59, timeinfo->tm_sec);
secondlo = second % 10;
secondhi = second / 10;
uint minute = timeinfo->tm_min;
minutelo = minute % 10;
minutehi = minute / 10;
uint hour = timeinfo->tm_hour;
if(atime) {
hourlo = hour % 10;
hourhi = hour / 10;
} else {
meridian = hour >= 12;
hour %= 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
if(hour == 0) hour = 12;
hourlo = hour % 10;
hourhi = hour / 10;
}
uint day = timeinfo->tm_mday;
daylo = day % 10;
dayhi = day / 10;
uint month = 1 + timeinfo->tm_mon;
monthlo = month % 10;
monthhi = month / 10;
uint year = timeinfo->tm_year % 100;
yearlo = year % 10;
yearhi = year / 10;
weekday = timeinfo->tm_wday;
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
resync = true; //alert program that time has changed
}
auto EpsonRTC::read(uint24 addr, uint8 data) -> uint8 {
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
cpu.synchronize(*this);
addr &= 3;
if(addr == 0) {
return chipselect;
}
if(addr == 1) {
if(chipselect != 1) return 0;
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(ready == 0) return 0;
if(state == State::Write) return mdr;
if(state != State::Read) return 0;
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
ready = 0;
wait = 8;
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(offset++);
}
if(addr == 2) {
return ready << 7;
}
return data;
}
auto EpsonRTC::write(uint24 addr, uint8 data) -> void {
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
cpu.synchronize(*this);
addr &= 3, data &= 15;
if(addr == 0) {
chipselect = data;
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(chipselect != 1) rtcReset();
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
ready = 1;
}
if(addr == 1) {
if(chipselect != 1) return;
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(ready == 0) return;
if(state == State::Mode) {
if(data != 0x03 && data != 0x0c) return;
state = State::Seek;
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
ready = 0;
wait = 8;
mdr = data;
}
else if(state == State::Seek) {
if(mdr == 0x03) state = State::Write;
if(mdr == 0x0c) state = State::Read;
offset = data;
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
ready = 0;
wait = 8;
mdr = data;
}
else if(state == State::Write) {
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
rtcWrite(offset++, data);
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
ready = 0;
wait = 8;
mdr = data;
}
}
}
}