bsnes/higan/md/cartridge/cartridge.cpp

299 lines
8.3 KiB
C++
Raw Normal View History

Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
#include <md/md.hpp>
namespace MegaDrive {
Cartridge cartridge;
Update to v102r16 release. byuu says: Changelog: - Emulator::Stream now allows adding low-pass and high-pass filters dynamically - also accepts a pass# count; each pass is a second-order biquad butterworth IIR filter - Emulator::Stream no longer automatically filters out >20KHz frequencies for all streams - FC: added 20Hz high-pass filter; 20KHz low-pass filter - GB: removed simple 'magic constant' high-pass filter of unknown cutoff frequency (missed this one in the last WIP) - GB,SGB,GBC: added 20Hz high-pass filter; 20KHz low-pass filter - MS,GG,MD/PSG: added 20Hz high-pass filter; 20KHz low-pass filter - MD: added save state support (but it's completely broken for now; sorry) - MD/YM2612: fixed Voice#3 per-operator pitch support (fixes sound effects in Streets of Rage, etc) - PCE: added 20Hz high-pass filter; 20KHz low-pass filter - WS,WSC: added 20Hz high-pass filter; 20KHz low-pass filter So, the point of the low-pass filters is to remove frequencies above human hearing. If we don't do this, then resampling will introduce aliasing that results in sounds that are audible to the human ear. Which basically an annoying buzzing sound. You'll definitely hear the improvement from these in games like Mega Man 2 on the NES. Of course, these already existed before, so this WIP won't sound better than previous WIPs. The high-pass filters are a little more complicated. Their main role is to remove DC bias and help to center the audio stream. I don't understand how they do this at all, but ... that's what everyone who knows what they're talking about says, thus ... so be it. I have set all of the high-pass filters to 20Hz, which is below the limit of human hearing. Now this is where it gets really interesting ... technically, some of these systems actually cut off a lot of range. For instance, the GBA should technically use an 800Hz high-pass filter when output is done through the system's speakers. But of course, if you plug in headphones, you can hear the lower frequencies. Now 800Hz ... you definitely can hear. At that level, nearly all of the bass is stripped out and the audio is very tinny. Just like the real system. But for now, I don't want to emulate the audio being crushed that badly. I'm sticking with 20Hz everywhere since it won't negatively affect audio quality. In fact, you should not be able to hear any difference between this WIP and the previous WIP. But theoretically, DC bias should mostly be removed as a result of these new filters. It may be that we need to raise the values on some cores in the future, but I don't want to do that until we know for certain that we have to. What I can say is that compared to even older WIPs than r15 ... the removal of the simple one-pole low-pass and high-pass filters with the newer three-pass, second-order filters should result in much better attenuation (less distortion of audible frequencies.) Probably not enough to be noticeable in a blind test, though.
2017-03-08 20:20:40 +00:00
#include "serialization.cpp"
Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
auto Cartridge::hashes() const -> vector<string> {
vector<string> hashes;
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
hashes.append(information.hash);
if(slot) for(auto& hash : slot->hashes()) hashes.append(hash);
return hashes;
}
auto Cartridge::manifests() const -> vector<string> {
vector<string> manifests;
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
manifests.append(information.manifest);
if(slot) for(auto& manifest : slot->manifests()) manifests.append(manifest);
return manifests;
}
auto Cartridge::titles() const -> vector<string> {
vector<string> titles;
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
titles.append(information.title);
if(slot) for(auto& title : slot->titles()) titles.append(title);
return titles;
}
Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
auto Cartridge::load() -> bool {
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
unload();
if(auto loaded = platform->load(ID::MegaDrive, "Mega Drive", "md", {"Auto", "NTSC-J", "NTSC-U", "PAL"})) {
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
information.pathID = loaded.pathID;
information.region = loaded.option;
Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
} else return false;
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(auto fp = platform->open(pathID(), "manifest.bml", File::Read, File::Required)) {
information.manifest = fp->reads();
Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
} else return false;
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
information.document = BML::unserialize(information.manifest);
information.hash = information.document["game/sha256"].text();
information.title = information.document["game/label"].text();
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(!loadROM(rom, information.document["game/board/memory(type=ROM,content=Program)"])) {
return unload(), false;
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(!loadROM(patch, information.document["game/board/memory(type=ROM,content=Patch)"])) {
patch.reset();
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(!loadRAM(ram, information.document["game/board/memory(type=RAM,content=Save)"])) {
ram.reset();
}
Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(information.region == "Auto") {
if(auto region = information.document["game/region"].text()) {
information.region = region.upcase();
} else {
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
information.region = "NTSC-J";
}
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
read = {&Cartridge::readLinear, this};
write = {&Cartridge::writeLinear, this};
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(rom.size > 0x200000) {
read = {&Cartridge::readBanked, this};
write = {&Cartridge::writeBanked, this};
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(patch) {
slot = new Cartridge{depth + 1};
if(!slot->load()) slot.reset();
read = {&Cartridge::readLockOn, this};
write = {&Cartridge::writeLockOn, this};
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(rom.data[0x120>>1]==0x4761 || rom.data[0x120>>1]==0x6147) {
slot = new Cartridge{depth + 1};
if(!slot->load()) slot.reset();
read = {&Cartridge::readGameGenie, this};
write = {&Cartridge::writeGameGenie, this};
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
//easter egg: power draw increases with each successively stacked cartridge
//simulate increasing address/data line errors as stacking increases
if(depth >= 3) {
auto reader = read;
auto writer = write;
auto scramble = [=](uint32 value) -> uint32 {
uint chance = max(1, (1 << 19) >> depth) - 1;
if((random() & chance) == 0) value ^= 1 << (random() & 31);
return value;
};
read = [=](uint22 address) -> uint16 {
return scramble(reader(scramble(address)));
};
write = [=](uint22 address, uint16 data) -> void {
writer(scramble(address), scramble(data));
};
}
return true;
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::save() -> void {
saveRAM(ram, information.document["game/board/memory(type=RAM,content=Save)"]);
if(slot) slot->save();
}
auto Cartridge::unload() -> void {
rom.reset();
patch.reset();
ram.reset();
read.reset();
write.reset();
if(slot) slot->unload();
slot.reset();
}
auto Cartridge::power() -> void {
ramEnable = 1;
ramWritable = 1;
for(uint n : range(8)) romBank[n] = n;
gameGenie = {};
}
//
auto Cartridge::loadROM(Memory& rom, Markup::Node memory) -> bool {
if(!memory) return false;
auto name = string{memory["content"].text(), ".", memory["type"].text()}.downcase();
rom.size = memory["size"].natural() >> 1;
rom.mask = bit::round(rom.size) - 1;
rom.data = new uint16[rom.mask + 1]();
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(auto fp = platform->open(pathID(), name, File::Read, File::Required)) {
for(uint n : range(rom.size)) rom.data[n] = fp->readm(2);
} else return false;
return true;
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::loadRAM(Memory& ram, Markup::Node memory) -> bool {
if(!memory) return false;
auto name = string{memory["content"].text(), ".", memory["type"].text()}.downcase();
if(auto mode = memory["mode"].text()) {
if(mode == "lo" ) ram.bits = 0x00ff;
if(mode == "hi" ) ram.bits = 0xff00;
if(mode == "word") ram.bits = 0xffff;
}
ram.size = memory["size"].natural() >> (ram.bits == 0xffff);
ram.mask = bit::round(ram.size) - 1;
ram.data = new uint16[ram.mask + 1]();
if(!(bool)memory["volatile"]) {
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(auto fp = platform->open(pathID(), name, File::Read)) {
for(uint n : range(ram.size)) {
if(ram.bits != 0xffff) ram.data[n] = fp->readm(1) * 0x0101;
if(ram.bits == 0xffff) ram.data[n] = fp->readm(2);
}
}
}
return true;
Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::saveRAM(Memory& ram, Markup::Node memory) -> bool {
if(!memory) return false;
if((bool)memory["volatile"]) return true;
auto name = string{memory["content"].text(), ".", memory["type"].text()}.downcase();
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(auto fp = platform->open(pathID(), name, File::Write)) {
for(uint n : range(ram.size)) {
if(ram.bits != 0xffff) fp->writem(ram.data[n], 1);
if(ram.bits == 0xffff) fp->writem(ram.data[n], 2);
}
} else return false;
return true;
Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
}
//
auto Cartridge::readIO(uint24 address) -> uint16 {
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(slot) slot->readIO(address);
return 0x0000;
}
auto Cartridge::writeIO(uint24 address, uint16 data) -> void {
if(address == 0xa130f1) ramEnable = data.bit(0), ramWritable = data.bit(1);
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
if(address == 0xa130f3) romBank[1] = data;
if(address == 0xa130f5) romBank[2] = data;
if(address == 0xa130f7) romBank[3] = data;
if(address == 0xa130f9) romBank[4] = data;
if(address == 0xa130fb) romBank[5] = data;
if(address == 0xa130fd) romBank[6] = data;
if(address == 0xa130ff) romBank[7] = data;
if(slot) slot->writeIO(address, data);
}
//
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::readLinear(uint22 address) -> uint16 {
if(ramEnable && ram && address >= 0x200000) return ram.read(address);
return rom.read(address);
Update to v101r04 release. byuu says: Changelog: - pulled the (u)intN type aliases into higan instead of leaving them in nall - added 68K LINEA, LINEF hooks for illegal instructions - filled the rest of the 68K lambda table with generic instance of ILLEGAL - completed the 68K disassembler effective addressing modes - still unsure whether I should use An to decode absolute addresses or not - pro: way easier to read where accesses are taking place - con: requires An to be valid; so as a disassembler it does a poor job - making it optional: too much work; ick - added I/O decoding for the VDP command-port registers - added skeleton timing to all five processor cores - output at 1280x480 (needed for mixed 256/320 widths; and to handle interlace modes) The VDP, PSG, Z80, YM2612 are all stepping one clock at a time and syncing; which is the pathological worst case for libco. But they also have no logic inside of them. With all the above, I'm averaging around 250fps with just the 68K core actually functional, and the VDP doing a dumb "draw white pixels" loop. Still way too early to tell how this emulator is going to perform. Also, the 320x240 mode of the Genesis means that we don't need an aspect correction ratio. But we do need to ensure the output window is a multiple 320x240 so that the scale values work correctly. I was hard-coding aspect correction to stretch the window an additional \*8/7. But that won't work anymore so ... the main higan window is now 640x480, 960x720, or 1280x960. Toggling aspect correction only changes the video width inside the window. It's a bit jarring ... the window is a lot wider, more black space now for most modes. But for now, it is what it is.
2016-08-12 01:07:04 +00:00
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::writeLinear(uint22 address, uint16 data) -> void {
//emulating ramWritable will break commercial software:
//it does not appear that many (any?) games actually connect $a130f1.d1 to /WE;
//hence RAM ends up always being writable, and many games fail to set d1=1
if(ramEnable && ram && address >= 0x200000) return ram.write(address, data);
}
//
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::readBanked(uint22 address) -> uint16 {
address = romBank[address.bits(19,21)] << 19 | address.bits(0,18);
return rom.read(address);
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::writeBanked(uint22 address, uint16 data) -> void {
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
//
auto Cartridge::readLockOn(uint22 address) -> uint16 {
if(address < 0x200000) return rom.read(address);
if(ramEnable && address >= 0x300000) return patch.read(address);
if(slot) return slot->read(address);
return 0x0000;
}
auto Cartridge::writeLockOn(uint22 address, uint16 data) -> void {
if(slot) return slot->write(address, data);
}
//
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::readGameGenie(uint22 address) -> uint16 {
if(gameGenie.enable) {
for(auto& code : gameGenie.codes) {
if(code.enable && code.address == address) return code.data;
}
if(slot) return slot->read(address);
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
return rom.read(address);
Update to v102r17 release. byuu says: Changelog: - GBA: process audio at 2MHz instead of 32KHz¹ - MD: do not allow the 68K to stop the Z80, unless it has been granted bus access first - MD: do not reset bus requested/granted signals when the 68K resets the Z80 - the above two fix The Lost Vikings - MD: clean up the bus address decoding to be more readable - MD: add support for a13000-a130ff (#TIME) region; pass to cartridge I/O² - MD: emulate SRAM mapping used by >16mbit games; bank mapping used by >32mbit games³ - MD: add 'reset pending' flag so that loading save states won't reload 68K PC, SP registers - this fixes save state support ... mostly⁴ - MD: if DMA is not enabled, do not allow CD5 to be set [Cydrak] - this fixes in-game graphics for Ristar. Title screen still corrupted on first run - MD: detect and break sprite lists that form an infinite loop [Cydrak] - this fixes the emulator from dead-locking on certain games - MD: add DC offset to sign DAC PCM samples [Cydrak] - this improves audio in Sonic 3 - MD: 68K TAS has a hardware bug that prevents writing the result back to RAM - this fixes Gargoyles - MD: 68K TRAP should not change CPU interrupt level - this fixes Shining Force II, Shining in the Darkness, etc - icarus: better SRAM heuristics for Mega Drive games Todo: - need to serialize the new cartridge ramEnable, ramWritable, bank variables ¹: so technically, the GBA has its FIFO queue (raw PCM), plus a GB chipset. The GB audio runs at 2MHz. However, I was being lazy and running the sequencer 64 times in a row, thus decimating the audio to 32KHz. But simply discarding 63 out of every 64 samples resorts in muddier sound with more static in it. However ... increasing the audio thread processing intensity 64-fold, and requiring heavy-duty three-chain lowpass and highpass filters is not cheap. For this bump in sound quality, we're eating a loss of about 30% of previous performance. Also note that the GB audio emulation in the GBA core still lacks many of the improvements made to the GB core. I was hoping to complete the GB enhancements, but it seems like I'm never going to pass blargg's psychotic edge case tests. So, first I want to clean up the GB audio to my current coding standards, and then I'll port that over to the GBA, which should further increase sound quality. At that point, it sound exceed mGBA's audio quality (due to the ridiculously high sampling rate and strong-attenuation audio filtering.) ²: word writes are probably not handled correctly ... but games are only supposed to do byte writes here. ³: the SRAM mapping is used by games like "Story of Thor" and "Phantasy Star IV." Unfortunately, the former wasn't released in the US and is region protected. So you'll need to change the NTSU to NTSCJ in md/system/system.cpp in order to boot it. But it does work nicely now. The write protection bit is cleared in the game, and then it fails to write to SRAM (soooooooo many games with SRAM write protection do this), so for now I've had to disable checking that bit. Phantasy Star IV has a US release, but sadly the game doesn't boot yet. Hitting some other bug. The bank mapping is pretty much just for the 40mbit Super Street Fighter game. It shows the Sega and Capcom logos now, but is hitting yet another bug and deadlocking. For now, I emulate the SRAM/bank mapping registers on all cartridges, and set sane defaults. So long as games don't write to $a130XX, they should all continue to work. But obviously, we need to get to a point where higan/icarus can selectively enable these registers on a per-game basis. ⁴: so, the Mega Drive has various ways to lock a chip until another chip releases it. The VDP can lock the 68K, the 68K can lock the Z80, etc. If this happens when you save a state, it'll dead-lock the emulator. So that's obviously a problem that needs to be fixed. The fix will be nasty ... basically, bypassing the dead-lock, creating a miniature, one-instruction-long race condition. Extremely unlikely to cause any issues in practice (it's only a little worse than the SNES CPU/SMP desync), but ... there's nothing I can do about it. So you'll have to take it or leave it. But yeah, for now, save states may lock up the emulator. I need to add code to break the loops when in the process of creating a save state still.
2017-03-10 10:23:29 +00:00
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::writeGameGenie(uint22 address, uint16 data) -> void {
if(gameGenie.enable) {
if(slot) return slot->write(address, data);
}
if(address == 0x02 && data == 0x0001) {
gameGenie.enable = true;
}
if(address >= 0x04 && address <= 0x20 && !address.bit(0)) {
address = address - 0x04 >> 1;
auto& code = gameGenie.codes[address / 3];
if(address % 3 == 0) code.address.bits(16,23) = data.byte(0);
if(address % 3 == 1) code.address.bits( 0,15) = data;
if(address % 3 == 2) code.data = data, code.enable = true;
}
}
//
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
Cartridge::Memory::operator bool() const {
return size;
}
auto Cartridge::Memory::reset() -> void {
delete[] data;
data = nullptr;
size = 0;
mask = 0;
bits = 0;
Update to v102r17 release. byuu says: Changelog: - GBA: process audio at 2MHz instead of 32KHz¹ - MD: do not allow the 68K to stop the Z80, unless it has been granted bus access first - MD: do not reset bus requested/granted signals when the 68K resets the Z80 - the above two fix The Lost Vikings - MD: clean up the bus address decoding to be more readable - MD: add support for a13000-a130ff (#TIME) region; pass to cartridge I/O² - MD: emulate SRAM mapping used by >16mbit games; bank mapping used by >32mbit games³ - MD: add 'reset pending' flag so that loading save states won't reload 68K PC, SP registers - this fixes save state support ... mostly⁴ - MD: if DMA is not enabled, do not allow CD5 to be set [Cydrak] - this fixes in-game graphics for Ristar. Title screen still corrupted on first run - MD: detect and break sprite lists that form an infinite loop [Cydrak] - this fixes the emulator from dead-locking on certain games - MD: add DC offset to sign DAC PCM samples [Cydrak] - this improves audio in Sonic 3 - MD: 68K TAS has a hardware bug that prevents writing the result back to RAM - this fixes Gargoyles - MD: 68K TRAP should not change CPU interrupt level - this fixes Shining Force II, Shining in the Darkness, etc - icarus: better SRAM heuristics for Mega Drive games Todo: - need to serialize the new cartridge ramEnable, ramWritable, bank variables ¹: so technically, the GBA has its FIFO queue (raw PCM), plus a GB chipset. The GB audio runs at 2MHz. However, I was being lazy and running the sequencer 64 times in a row, thus decimating the audio to 32KHz. But simply discarding 63 out of every 64 samples resorts in muddier sound with more static in it. However ... increasing the audio thread processing intensity 64-fold, and requiring heavy-duty three-chain lowpass and highpass filters is not cheap. For this bump in sound quality, we're eating a loss of about 30% of previous performance. Also note that the GB audio emulation in the GBA core still lacks many of the improvements made to the GB core. I was hoping to complete the GB enhancements, but it seems like I'm never going to pass blargg's psychotic edge case tests. So, first I want to clean up the GB audio to my current coding standards, and then I'll port that over to the GBA, which should further increase sound quality. At that point, it sound exceed mGBA's audio quality (due to the ridiculously high sampling rate and strong-attenuation audio filtering.) ²: word writes are probably not handled correctly ... but games are only supposed to do byte writes here. ³: the SRAM mapping is used by games like "Story of Thor" and "Phantasy Star IV." Unfortunately, the former wasn't released in the US and is region protected. So you'll need to change the NTSU to NTSCJ in md/system/system.cpp in order to boot it. But it does work nicely now. The write protection bit is cleared in the game, and then it fails to write to SRAM (soooooooo many games with SRAM write protection do this), so for now I've had to disable checking that bit. Phantasy Star IV has a US release, but sadly the game doesn't boot yet. Hitting some other bug. The bank mapping is pretty much just for the 40mbit Super Street Fighter game. It shows the Sega and Capcom logos now, but is hitting yet another bug and deadlocking. For now, I emulate the SRAM/bank mapping registers on all cartridges, and set sane defaults. So long as games don't write to $a130XX, they should all continue to work. But obviously, we need to get to a point where higan/icarus can selectively enable these registers on a per-game basis. ⁴: so, the Mega Drive has various ways to lock a chip until another chip releases it. The VDP can lock the 68K, the 68K can lock the Z80, etc. If this happens when you save a state, it'll dead-lock the emulator. So that's obviously a problem that needs to be fixed. The fix will be nasty ... basically, bypassing the dead-lock, creating a miniature, one-instruction-long race condition. Extremely unlikely to cause any issues in practice (it's only a little worse than the SNES CPU/SMP desync), but ... there's nothing I can do about it. So you'll have to take it or leave it. But yeah, for now, save states may lock up the emulator. I need to add code to break the loops when in the process of creating a save state still.
2017-03-10 10:23:29 +00:00
}
Update to 20180726 release. byuu says: Once again, I wasn't able to complete a full WIP revision. This WIP-WIP adds very sophisticated emulation of the Sega Genesis Lock-On and Game Genie cartridges ... essentially, through recursion and a linked list, higan supports an infinite nesting of cartridges. Of course, on real hardware, after you stack more than three or four cartridges, the power draw gets too high and things start glitching out more and more as you keep stacking. I've heard that someone chained up to ten Sonic & Knuckles cartridges before it finally became completely unplayable. And so of course, higan emulates this limitation as well ^-^. On the fourth cartridge and beyond, it will become more and more likely that address and/or data lines "glitch" out randomly, causing various glitches. It's a completely silly easter egg that requires no speed impact whatsoever beyond the impact of the new linked list cartridge system. I also designed the successor to Emulator::Interface::cap,get,set. Those were holdovers from the older, since-removed ruby-style accessors. In its place is the new Emulator::Interface::configuration,configure API. There's the usual per-property access, and there's also access to read and write all configurable options at once. In essence, this enables introspection into core-specific features. So far, you can control processor version#s, PPU VRAM size, video settings, and hacks. As such, the .sys/manifest.bml files are no longer necessary. Instead, it all goes into .sys/configuration.bml, which is generated by the emulator if it's missing. higan is going to take this even further and allow each option under "Systems" to have its own editable configuration file. So if you wanted, you could have a 1/1/1 SNES menu option, and a 2/1/3 SNES menu option. Or a Model 1 Genesis option, and a Model 2 Genesis option. Or the various Game Boy model revisions. Or an "SNES-Fast" and "SNES-Accurate" option. I've not fully settled on the syntax of the new configuration API. I feel it might be useful to provide type information, but I really quite passionately hate any<T> container objects. For now it's all string-based, because strings can hold anything in nall. I might also change the access rules. Right now it's like: emulator→configure("video/blurEmulation", true); but it might be nicer as "Video::Blur Emulation", or "Video.BlurEmulation", or something like that.
2018-07-26 10:36:43 +00:00
auto Cartridge::Memory::read(uint24 address) -> uint16 {
if(!size) return 0x0000;
return data[address >> 1 & mask];
}
auto Cartridge::Memory::write(uint24 address, uint16 word) -> void {
if(!size) return;
if(bits == 0x00ff) word.byte(1) = word.byte(0);
if(bits == 0xff00) word.byte(0) = word.byte(1);
data[address >> 1 & mask] = word;
}
Update to v100r02 release. byuu says: Sigh ... I'm really not a good person. I'm inherently selfish. My responsibility and obligation right now is to work on loki, and then on the Tengai Makyou Zero translation, and then on improving the Famicom emulation. And yet ... it's not what I really want to do. That shouldn't matter; I should work on my responsibilities first. Instead, I'm going to be a greedy, self-centered asshole, and work on what I really want to instead. I'm really sorry, guys. I'm sure this will make a few people happy, and probably upset even more people. I'm also making zero guarantees that this ever gets finished. As always, I wish I could keep these things secret, so if I fail / give up, I could just drop it with no shame. But I would have to cut everyone out of the WIP process completely to make it happen. So, here goes ... This WIP adds the initial skeleton for Sega Mega Drive / Genesis emulation. God help us. (minor note: apparently the new extension for Mega Drive games is .md, neat. That's what I chose for the folders too. I thought it was .smd, so that'll be fixed in icarus for the next WIP.) (aside: this is why I wanted to get v100 out. I didn't want this code in a skeleton state in v100's source. Nor did I want really broken emulation, which the first release is sure to be, tarring said release.) ... So, basically, I've been ruminating on the legacy I want to leave behind with higan. 3D systems are just plain out. I'm never going to support them. They're too complex for my abilities, and they would run too slowly with my design style. I'm not willing to compromise my design ideals. And I would never want to play a 3D game system at native 240p/480i resolution ... but 1080p+ upscaling is not accurate, so that's a conflict I want to avoid entirely. It's also never going to emulate computer systems (X68K, PC-98, FM-Towns, etc) because holy shit that would completely destroy me. It's also never going emulate arcade machines. So I think of higan as a collection of 2D emulators for consoles and handhelds. I've gone over every major 2D gaming system there is, looking for ones with games I actually care about and enjoy. And I basically have five of those systems supported already. Looking at the remaining list, I see only three systems left that I have any interest in whatsoever: PC-Engine, Master System, Mega Drive. Again, I'm not in any way committing to emulating any of these, but ... if I had all of those in higan, I think I'd be content to really, truly, finally stop writing more emulators for the rest of my life. And so I decided to tackle the most difficult system first. If I'm successful, the Z80 core should cover a lot of the work on the SMS. And the HuC6280 should land somewhere between the NES and SNES in terms of difficulty ... closer to the NES. The systems that just don't appeal to me at all, which I will never touch, include, but are not limited to: * Atari 2600/5200/7800 * Lynx * Jaguar * Vectrex * Colecovision * Commodore 64 * Neo-Geo * Neo-Geo Pocket / Color * Virtual Boy * Super A'can * 32X * CD-i * etc, etc, etc. And really, even if something were mildly interesting in there ... we have to stop. I can't scale infinitely. I'm already way past my limit, but I'm doing this anyway. Too many cores bloats everything and kills quality on everything. I don't want higan to become MESS v2. I don't know what I'll do about the Famicom Disk System, PC-Engine CD, and Mega CD. I don't think I'll be able to achieve 60fps emulating the Mega CD, even if I tried to. I don't know what's going to happen here with even the Mega Drive. Maybe I'll get driven crazy with the documentation and quit. Maybe it'll end up being too complicated and I'll quit. Maybe the emulation will end up way too slow and I'll give up. Maybe it'll take me seven years to get any games playable at all. Maybe Steve Snake, AamirM and Mike Pavone will pool money to hire a hitman to come after me. Who knows. But this is what I want to do, so ... here goes nothing.
2016-07-09 04:21:37 +00:00
}