ShuriZma
/
bsnes
mirror of https://github.com/bsnes-emu/bsnes.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
bsnes/sfc/alt/cpu/mmio.cpp

300 lines
7.4 KiB
C++
Raw Normal View History

Update to v095r10 release. byuu says: Changelog: - int_t<bits> replaced with Integer<bits> - uint_t<bits> replaced with Natural<bits> - fixed "Synchronize Audio" menu option that broke recently - all of sfc/performance ported to "auto function() -> return;" syntax With this WIP, all of higan is finally ported over to the new function declaration syntax. Thank the gods. There's still going to be periodic disruption for diffs from porting over signed->int, unsigned->uint, and whatever we come up with for the new Natural<> and Integer<> classes. But the worst of it's behind us now.
2015-12-06 21:11:41 +00:00
auto CPU::mmio_read(uint addr) -> uint8 {
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
if((addr & 0xffc0) == 0x2140) {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
synchronizeSMP();
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return smp.port_read(addr & 3);
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
switch(addr & 0xffff) {
case 0x2180: {
uint8 result = bus.read(0x7e0000 | status.wram_addr);
status.wram_addr = (status.wram_addr + 1) & 0x01ffff;
return result;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4016: {
uint8 result = regs.mdr & 0xfc;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
result |= device.controllerPort1->data() & 3;
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
return result;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4017: {
uint8 result = (regs.mdr & 0xe0) | 0x1c;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
result |= device.controllerPort2->data() & 3;
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
return result;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4210: {
uint8 result = (regs.mdr & 0x70);
result |= status.nmi_line << 7;
result |= 0x02; //CPU revision
status.nmi_line = false;
return result;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4211: {
uint8 result = (regs.mdr & 0x7f);
result |= status.irq_line << 7;
status.irq_line = false;
return result;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4212: {
uint8 result = (regs.mdr & 0x3e);
unsigned vbstart = ppu.overscan() == false ? 225 : 240;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
if(vcounter() >= vbstart && vcounter() <= vbstart + 2) result |= 0x01;
if(hcounter() <= 2 || hcounter() >= 1096) result |= 0x40;
if(vcounter() >= vbstart) result |= 0x80;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
return result;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4213: return status.pio;
case 0x4214: return status.rddiv >> 0;
case 0x4215: return status.rddiv >> 8;
case 0x4216: return status.rdmpy >> 0;
case 0x4217: return status.rdmpy >> 8;
case 0x4218: return status.joy1l;
case 0x4219: return status.joy1h;
case 0x421a: return status.joy2l;
case 0x421b: return status.joy2h;
case 0x421c: return status.joy3l;
case 0x421d: return status.joy3h;
case 0x421e: return status.joy4l;
case 0x421f: return status.joy4h;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
if((addr & 0xff80) == 0x4300) {
unsigned i = (addr >> 4) & 7;
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
switch(addr & 0xff8f) {
case 0x4300: {
return (channel[i].direction << 7)
| (channel[i].indirect << 6)
| (channel[i].unused << 5)
| (channel[i].reverse_transfer << 4)
| (channel[i].fixed_transfer << 3)
| (channel[i].transfer_mode << 0);
}
case 0x4301: return channel[i].dest_addr;
case 0x4302: return channel[i].source_addr >> 0;
case 0x4303: return channel[i].source_addr >> 8;
case 0x4304: return channel[i].source_bank;
case 0x4305: return channel[i].transfer_size >> 0;
case 0x4306: return channel[i].transfer_size >> 8;
case 0x4307: return channel[i].indirect_bank;
case 0x4308: return channel[i].hdma_addr >> 0;
case 0x4309: return channel[i].hdma_addr >> 8;
case 0x430a: return channel[i].line_counter;
case 0x430b: case 0x430f: return channel[i].unknown;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
}
}
return regs.mdr;
}
Update to v095r10 release. byuu says: Changelog: - int_t<bits> replaced with Integer<bits> - uint_t<bits> replaced with Natural<bits> - fixed "Synchronize Audio" menu option that broke recently - all of sfc/performance ported to "auto function() -> return;" syntax With this WIP, all of higan is finally ported over to the new function declaration syntax. Thank the gods. There's still going to be periodic disruption for diffs from porting over signed->int, unsigned->uint, and whatever we come up with for the new Natural<> and Integer<> classes. But the worst of it's behind us now.
2015-12-06 21:11:41 +00:00
auto CPU::mmio_write(uint addr, uint8 data) -> void {
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
if((addr & 0xffc0) == 0x2140) {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
synchronizeSMP();
Updated to v067r21 release. byuu says: This moves toward a profile-selection mode. Right now, it is incomplete. There are three binaries, one for each profile. The GUI selection doesn't actually do anything yet. There will be a launcher in a future release that loads each profile's respective binary. I reverted away from blargg's SMP library for the time being, in favor of my own. This will fix most of the csnes/bsnes-performance bugs. This causes a 10% speed hit on 64-bit platforms, and a 15% speed hit on 32-bit platforms. I hope to be able to regain that speed in the future, I may also experiment with creating my own fast-SMP core which drops bus hold delays and TEST register support (never used by anything, ever.) Save states now work in all three cores, but they are not cross-compatible. The profile name is stored in the description field of the save states, and it won't load a state if the profile name doesn't match. The debugger only works on the research target for now. Give it time and it will return for the other targets. Other than that, let's please resume testing on all three once again. See how far we get this time :) I can confirm the following games have issues on the performance profile: - Armored Police Metal Jacket (minor logo flickering, not a big deal) - Chou Aniki (won't start, so obviously unplayable) - Robocop vs The Terminator (major in-game flickering, unplayable) Anyone still have that gigantic bsnes thread archive from the ZSNES forum? Maybe I posted about how to fix those two broken games in there, heh. I really want to release this as v1.0, but my better judgment says we need to give it another week. Damn.
2010-10-20 11:22:44 +00:00
port_write(addr & 3, data);
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
switch(addr & 0xffff) {
case 0x2180: {
bus.write(0x7e0000 | status.wram_addr, data);
status.wram_addr = (status.wram_addr + 1) & 0x01ffff;
return;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x2181: {
status.wram_addr = (status.wram_addr & 0x01ff00) | (data << 0);
return;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x2182: {
status.wram_addr = (status.wram_addr & 0x0100ff) | (data << 8);
return;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x2183: {
status.wram_addr = (status.wram_addr & 0x00ffff) | ((data & 1) << 16);
return;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4016: {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
device.controllerPort1->latch(data & 1);
device.controllerPort2->latch(data & 1);
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
return;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4200: {
bool nmi_enabled = status.nmi_enabled;
bool virq_enabled = status.virq_enabled;
bool hirq_enabled = status.hirq_enabled;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
status.nmi_enabled = data & 0x80;
status.virq_enabled = data & 0x20;
status.hirq_enabled = data & 0x10;
status.auto_joypad_poll_enabled = data & 0x01;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
if(!nmi_enabled && status.nmi_enabled && status.nmi_line) {
status.nmi_transition = true;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
if(status.virq_enabled && !status.hirq_enabled && status.irq_line) {
status.irq_transition = true;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
if(!status.virq_enabled && !status.hirq_enabled) {
status.irq_line = false;
status.irq_transition = false;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
status.irq_lock = true;
return;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4201: {
if((status.pio & 0x80) && !(data & 0x80)) ppu.latch_counters();
status.pio = data;
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4202: {
status.wrmpya = data;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4203: {
status.wrmpyb = data;
status.rdmpy = status.wrmpya * status.wrmpyb;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4204: {
status.wrdiva = (status.wrdiva & 0xff00) | (data << 0);
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4205: {
status.wrdiva = (data << 8) | (status.wrdiva & 0x00ff);
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4206: {
status.wrdivb = data;
status.rddiv = status.wrdivb ? status.wrdiva / status.wrdivb : 0xffff;
status.rdmpy = status.wrdivb ? status.wrdiva % status.wrdivb : status.wrdiva;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4207: {
status.htime = (status.htime & 0x0100) | (data << 0);
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4208: {
status.htime = ((data & 1) << 8) | (status.htime & 0x00ff);
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x4209: {
status.vtime = (status.vtime & 0x0100) | (data << 0);
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x420a: {
status.vtime = ((data & 1) << 8) | (status.vtime & 0x00ff);
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x420b: {
for(unsigned i = 0; i < 8; i++) channel[i].dma_enabled = data & (1 << i);
if(data) dma_run();
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x420c: {
for(unsigned i = 0; i < 8; i++) channel[i].hdma_enabled = data & (1 << i);
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
case 0x420d: {
status.rom_speed = data & 1 ? 6 : 8;
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
return;
}
}
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
if((addr & 0xff80) == 0x4300) {
Update to v095r10 release. byuu says: Changelog: - int_t<bits> replaced with Integer<bits> - uint_t<bits> replaced with Natural<bits> - fixed "Synchronize Audio" menu option that broke recently - all of sfc/performance ported to "auto function() -> return;" syntax With this WIP, all of higan is finally ported over to the new function declaration syntax. Thank the gods. There's still going to be periodic disruption for diffs from porting over signed->int, unsigned->uint, and whatever we come up with for the new Natural<> and Integer<> classes. But the worst of it's behind us now.
2015-12-06 21:11:41 +00:00
uint i = (addr >> 4) & 7;
Updated to v067r23 release. byuu says: Fixed bsnes launcher on Windows XP Fixed Windows bsnes launcher internationalization support (emulator can be in a folder with spaces and Japanese characters, and you can drag a Japanese file name onto the launcher, and it will load it properly) Moved fast CPU to use a switch table for MMIO, unfortunately for no speed gain Bus::read/write take uint24 parameters for address, luckily no speed penalty MMIOAccess gained a handle() function, and hid the mmio[] table. Makes hooking it cleaner Added malloc.h header to nall/function.hpp to fix a ridiculous GCC 4.5.0 error Fixed a fairly large bug in the fast CPU IRQ handler, which fixes Robocop et al Forgot to bump revision to .24 in the compiled binaries, too lazy to recompile or hex edit to change them Unfortunately, in order to add nice battery usage, I have to add the sleep calls to the video and audio wait loops. But they don't know anything about the GUI and its settings, nor do I really want to make them know about this setting. I do not want to force allow it. Even with the media timer trick, Sleep(0) makes Vsync+Async fail a lot more frequently than never sleeping at all. I would rather laptop users suffer 100% utilization of a single core than for all users to not be able to get good audio+video sync. Not sure what to do about that, so I'll probably just remove the battery usage comment from performance mode for now.
2010-08-18 05:33:29 +00:00
switch(addr & 0xff8f) {
case 0x4300: {
channel[i].direction = data & 0x80;
channel[i].indirect = data & 0x40;
channel[i].unused = data & 0x20;
channel[i].reverse_transfer = data & 0x10;
channel[i].fixed_transfer = data & 0x08;
channel[i].transfer_mode = data & 0x07;
return;
}
case 0x4301: {
channel[i].dest_addr = data;
return;
}
case 0x4302: {
channel[i].source_addr = (channel[i].source_addr & 0xff00) | (data << 0);
return;
}
case 0x4303: {
channel[i].source_addr = (data << 8) | (channel[i].source_addr & 0x00ff);
return;
}
case 0x4304: {
channel[i].source_bank = data;
return;
}
case 0x4305: {
channel[i].transfer_size = (channel[i].transfer_size & 0xff00) | (data << 0);
return;
}
case 0x4306: {
channel[i].transfer_size = (data << 8) | (channel[i].transfer_size & 0x00ff);
return;
}
case 0x4307: {
channel[i].indirect_bank = data;
return;
}
case 0x4308: {
channel[i].hdma_addr = (channel[i].hdma_addr & 0xff00) | (data << 0);
return;
}
case 0x4309: {
channel[i].hdma_addr = (data << 8) | (channel[i].hdma_addr & 0x00ff);
return;
}
case 0x430a: {
channel[i].line_counter = data;
return;
}
case 0x430b: case 0x430f: {
channel[i].unknown = data;
return;
}
}
}
Update to 20100810-2 release. byuu says: I wrote a new CPU core from scratch. It has range-based IRQs, and is good enough even to run F-1 Grand Prix and Sink or Swim. It also uses a binary min-heap array for the timing priority queue. This resulted in a ~40% speedup. I also added in blargg's snes_spc library, which is an S-SMP + S-DSP emulator. I am still using his accurate DSP core, and not the fast one. This gives an additional ~10% speedup. THIS IS NOT PERFECT, THERE WILL BE BUGS! I already know that Tales of Phantasia and Star Ocean are hitting some edge cases. Now that it's fast enough, hopefully blargg can take a look at it. Something he couldn't test before because you can't rip SPCs of these games, so it's probably something simple. My CPU core also doesn't nail every last possible edge case. So things like Wild Guns and the two or three games that rely on NMI/IRQ hold aren't going to work ... yet. Be patient. The SuperFX and SA-1 cores are still cycle-accurate. It wouldn't hurt compatibility to reduce their precision a bit. End result is that you can now get well over 60fps in normal games even n a first-generation Intel Atom.
2010-08-11 00:40:59 +00:00
}