ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/higan/sfc/coprocessor/necdsp/necdsp.hpp

23 lines
523 B
C++
Raw Normal View History

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
struct NECDSP : Processor::uPD96050, Thread {
Update to v095r06 release. byuu says: Changelog: - fixed I/O register reads; perfect score on endrift's I/O tests now - fixed mouse capture clipping on Windows [Cydrak] - several hours of code maintenance work done on the SFC core All higan/sfc files should now use the auto fn() -> ret; syntax. Haven't converted all unsigned->uint yet. Also, probably won't do sfc/alt as that's mostly just speed hack stuff. Errata: - forgot auto& instead of just auto on SuperFamicom::Video::draw_cursor, which makes Super Scope / Justifier crash. Will be fixed in the next WIP.
2015-11-14 00:52:51 +00:00
static auto Enter() -> void;
Update to v097r13 release. byuu says: I refactored my schedulers. Added about ten lines to each scheduler, and removed about 100 lines of calling into internal state in the scheduler for the FC,SFC cores and about 30-40 lines for the other cores. All of its state is now private. Also reworked all of the entry points to static auto Enter() and auto main(). Where Enter() handles all the synchronization stuff, and main() doesn't need the while(true); loop forcing another layer of indentation everywhere. Took a few hours to do, but totally worth it. I'm surprised I didn't do this sooner. Also updated icarus gmake install rule to copy over the database.
2016-02-09 11:51:12 +00:00
auto main() -> void;
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
Update to v097r15 release. byuu says: Changelog: - higan now uses Natural<Size>/Integer<Size> for its internal types - Super Famicom emulation now uses uint24 instead of uint for bus addresses (it's a 24-bit bus) - cleaned up gb/apu MMIO writes - cleaned up sfc/coprocessor/msu1 MMIO writes - ~3% speed penalty I've wanted to do that 24-bit bus thing for so long, but have always been afraid of the speed impact. It's probably going to hurt balanced/performance once they compile again, but it wasn't significant enough to harm the accuracy core's frame rate, thankfully. Only lost one frame per second. The GBA core handlers are clearly going to take a lot more work. The bit-ranges will make it substantially easier to handle, though. Lots of 32-bit registers where certain values span multiple bytes, but we have to be able to read/write at byte-granularity.
2016-02-16 09:32:49 +00:00
auto read(uint24 addr, uint8 data) -> uint8;
auto write(uint24 addr, uint8 data) -> void;
Update to v074 release. byuu says (since v073): This release adds full low-level emulation of the NEC uPD96050 coprocessor, used by the ST-0010 (F1 Race of Champions II) and the ST-0011 (Hayazashi Nidan Morita Shougi). The former was already playable with HLE, but lacked timing emulation. The latter has never been playable through emulation before now. But as with SD Gundam GX before, you really weren't missing much. [...] Also new in this release is my own Game Boy emulator. It is being used to provide native Super Game Boy support, built directly into bsnes. This core is released under the GPLv2, but I am willing to grant a more permissive license for other SNES emulators, if anyone is interested. Of course I cannot compete with the quality of gambatte, and certainly not from only a weeks' worth of work. Currently, there is no Game Boy-side sound output and there are quite a few bugs remaining in its emulation core. I would appreciate any help on this, the Game Boy is not my forte. So yes, we are taking a step back today, so that we may take two steps forward in the future. [...] Lastly, the debugger is still Linux-only, but it is now stable enough to be considered usable. Check it out if you like, compile with -DDEBUGGER to enable it.
2011-01-11 10:30:47 +00:00
Update to v097r15 release. byuu says: Changelog: - higan now uses Natural<Size>/Integer<Size> for its internal types - Super Famicom emulation now uses uint24 instead of uint for bus addresses (it's a 24-bit bus) - cleaned up gb/apu MMIO writes - cleaned up sfc/coprocessor/msu1 MMIO writes - ~3% speed penalty I've wanted to do that 24-bit bus thing for so long, but have always been afraid of the speed impact. It's probably going to hurt balanced/performance once they compile again, but it wasn't significant enough to harm the accuracy core's frame rate, thankfully. Only lost one frame per second. The GBA core handlers are clearly going to take a lot more work. The bit-ranges will make it substantially easier to handle, though. Lots of 32-bit registers where certain values span multiple bytes, but we have to be able to read/write at byte-granularity.
2016-02-16 09:32:49 +00:00
auto readRAM(uint24 addr, uint8 data) -> uint8;
auto writeRAM(uint24 addr, uint8 data) -> void;
Update to v074 release. byuu says (since v073): This release adds full low-level emulation of the NEC uPD96050 coprocessor, used by the ST-0010 (F1 Race of Champions II) and the ST-0011 (Hayazashi Nidan Morita Shougi). The former was already playable with HLE, but lacked timing emulation. The latter has never been playable through emulation before now. But as with SD Gundam GX before, you really weren't missing much. [...] Also new in this release is my own Game Boy emulator. It is being used to provide native Super Game Boy support, built directly into bsnes. This core is released under the GPLv2, but I am willing to grant a more permissive license for other SNES emulators, if anyone is interested. Of course I cannot compete with the quality of gambatte, and certainly not from only a weeks' worth of work. Currently, there is no Game Boy-side sound output and there are quite a few bugs remaining in its emulation core. I would appreciate any help on this, the Game Boy is not my forte. So yes, we are taking a step back today, so that we may take two steps forward in the future. [...] Lastly, the debugger is still Linux-only, but it is now stable enough to be considered usable. Check it out if you like, compile with -DDEBUGGER to enable it.
2011-01-11 10:30:47 +00:00
Update to v095r06 release. byuu says: Changelog: - fixed I/O register reads; perfect score on endrift's I/O tests now - fixed mouse capture clipping on Windows [Cydrak] - several hours of code maintenance work done on the SFC core All higan/sfc files should now use the auto fn() -> ret; syntax. Haven't converted all unsigned->uint yet. Also, probably won't do sfc/alt as that's mostly just speed hack stuff. Errata: - forgot auto& instead of just auto on SuperFamicom::Video::draw_cursor, which makes Super Scope / Justifier crash. Will be fixed in the next WIP.
2015-11-14 00:52:51 +00:00
auto init() -> void;
auto load() -> void;
auto unload() -> void;
auto power() -> void;
Update to v074 release. byuu says (since v073): This release adds full low-level emulation of the NEC uPD96050 coprocessor, used by the ST-0010 (F1 Race of Champions II) and the ST-0011 (Hayazashi Nidan Morita Shougi). The former was already playable with HLE, but lacked timing emulation. The latter has never been playable through emulation before now. But as with SD Gundam GX before, you really weren't missing much. [...] Also new in this release is my own Game Boy emulator. It is being used to provide native Super Game Boy support, built directly into bsnes. This core is released under the GPLv2, but I am willing to grant a more permissive license for other SNES emulators, if anyone is interested. Of course I cannot compete with the quality of gambatte, and certainly not from only a weeks' worth of work. Currently, there is no Game Boy-side sound output and there are quite a few bugs remaining in its emulation core. I would appreciate any help on this, the Game Boy is not my forte. So yes, we are taking a step back today, so that we may take two steps forward in the future. [...] Lastly, the debugger is still Linux-only, but it is now stable enough to be considered usable. Check it out if you like, compile with -DDEBUGGER to enable it.
2011-01-11 10:30:47 +00:00
Update to v095r06 release. byuu says: Changelog: - fixed I/O register reads; perfect score on endrift's I/O tests now - fixed mouse capture clipping on Windows [Cydrak] - several hours of code maintenance work done on the SFC core All higan/sfc files should now use the auto fn() -> ret; syntax. Haven't converted all unsigned->uint yet. Also, probably won't do sfc/alt as that's mostly just speed hack stuff. Errata: - forgot auto& instead of just auto on SuperFamicom::Video::draw_cursor, which makes Super Scope / Justifier crash. Will be fixed in the next WIP.
2015-11-14 00:52:51 +00:00
auto firmware() const -> vector<uint8>;
auto serialize(serializer&) -> 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
uint Frequency = 0;
Update to v074 release. byuu says (since v073): This release adds full low-level emulation of the NEC uPD96050 coprocessor, used by the ST-0010 (F1 Race of Champions II) and the ST-0011 (Hayazashi Nidan Morita Shougi). The former was already playable with HLE, but lacked timing emulation. The latter has never been playable through emulation before now. But as with SD Gundam GX before, you really weren't missing much. [...] Also new in this release is my own Game Boy emulator. It is being used to provide native Super Game Boy support, built directly into bsnes. This core is released under the GPLv2, but I am willing to grant a more permissive license for other SNES emulators, if anyone is interested. Of course I cannot compete with the quality of gambatte, and certainly not from only a weeks' worth of work. Currently, there is no Game Boy-side sound output and there are quite a few bugs remaining in its emulation core. I would appreciate any help on this, the Game Boy is not my forte. So yes, we are taking a step back today, so that we may take two steps forward in the future. [...] Lastly, the debugger is still Linux-only, but it is now stable enough to be considered usable. Check it out if you like, compile with -DDEBUGGER to enable it.
2011-01-11 10:30:47 +00:00
};
extern NECDSP necdsp;