bsnes/icarus/core/super-famicom.cpp

64 lines
2.6 KiB
C++
Raw Normal View History

auto Icarus::superFamicomManifest(string location) -> string {
vector<uint8_t> buffer;
2015-08-21 11:29:53 +00:00
auto files = directory::files(location, "*.rom");
concatenate(buffer, {location, "program.rom"});
concatenate(buffer, {location, "data.rom" });
for(auto& file : files.match("*.program.rom")) concatenate(buffer, {location, file});
for(auto& file : files.match("*.data.rom" )) concatenate(buffer, {location, file});
for(auto& file : files.match("*.boot.rom" )) concatenate(buffer, {location, file});
2015-08-21 11:29:53 +00:00
return superFamicomManifest(buffer, location);
}
auto Icarus::superFamicomManifest(vector<uint8_t>& buffer, string location) -> string {
if(settings["icarus/UseDatabase"].boolean()) {
auto digest = Hash::SHA256(buffer).digest();
for(auto game : Database::SuperFamicom.find("game")) {
Update to v106r05 release. byuu says: Changelog: - Super Famicom: added remaining generic board types - icarus: improved Super Famicom heuristics - icarus: reworked BS Memory heuristics - icarus: reworked Sufami Turbo heuristics Notes: this is really complicated, and is going to take a long time to work 100% smoothly again. Starting off, I am trying to get rid of the weird edge case zero-byte SRAM mapping for the Cx4. It has the RAM region present, but returns logic low (0x00) instead of open bus, when SRAM isn't present. I started by making it `map=ram` instead of `ram/map`, which is gross, and then it ended up detecing the map tag ending in RAM and pulling the Cx4 data RAM into that slot. Ugh. The preservation board mapping is still as it was before and will need to be updated once I get the syntax down. The BS Memory and Sufami Turbo moving to the new `game/memory` ending means I can't use the SuperFamicom::Cartridge::loadMemory function that looks at the old-style rom/ram tags. Because I didn't write more code, the result is those sub-carts won't load now. The old heuristics were short-circuiting on SA1 before bothering with BS-X slots, so that's why SD Gundam G-Next wasn't asking for a data pack. The problem is, I don't know where the BS-X pack maps to on this cartridge. It's at c0-ef on the other BS-X slotted cartridges, but that's mapped to the SA1 on regular SA1 cartridges, so ... for now, it's not actually mapped in. I'm still struggling with naming conventions on all these boards. I'll make a public post about that, though.
2018-02-10 21:45:44 +00:00
if(game["sha256"].text() == digest) return BML::serialize(game);
Update to higan and icarus v095r15 release. r13 and r14 weren't posted as individual releases, but their changelogs were posted. byuu says about r13: I'm not going to be posting WIPs for r13 and above for a while. The reason is that I'm working on the major manifest overhaul I've discussed previously on the icarus subforum. I'm recreating my boards database from scratch using the map files and the new map analyzer. The only games that will load are ones I've created board definitions for, and updated sfc/cartridge/markup.cpp to parse. Once I've finished all the boards, then I'll update the heuristics. Then finally, I'll sync the syntax changes over to the fc, gb, gba cores. Once that's done, I'll start posting WIPs again, along with a new build of icarus. But I'll still post changelogs as I work through things. Changelog (r13): - preservation: created new database-builder tool (merges region-specific databases with boards) - icarus: support new, external database format (~/.config/icarus/Database/(Super Famicom.bml, ...) - added 1A3B-(10,11,12); 1A3B-20 byuu says about r14: r14 work: I successfully created mappings for every board used in the US set. I also updated icarus' heuristics to use the new mappings, and created ones there for the boards that are only in the JP set. Then I patched icarus to support pulling games out of the database when it's used on a game folder to generate a manifest file. Then I updated a lot of code in higan/sfc to support the new mapping syntax. sfc/cartridge/markup.cpp is about half the size it used to be with the new mappings, and I was able to kill off both map/id and map/select entirely. Then I updated all four emulated systems (and both subsystems) to use "board" as the root node, and harmonized their syntax (made them all more consistent with each other.) Then I added a manifest viewer to the tools window+menu. It's kind of an advanced user feature, but oh well. No reason to coddle people when the feature is very useful for developers. The viewer will show all manifests in order when you load multi-cart games as well. Still not going to call any syntax 100% done right now, but thankfully with the new manifest-free folders, nobody will have to do anything to use the new format. Just download the new version and go. The Super Famicom Event stuff is currently broken (CC92/PF94 boards). That's gonna be fun to support. byuu says about r15: EDIT: small bug in icarus with heuristics. Edit core/super-famicom.cpp line 27: if(/*auto*/ markup = cartridge.markup) { Gotta remove that "auto" so that it returns valid markup. Resolved the final concerns I had with the new manifest format. Right now there are two things that are definitely broken: MCC (BS-X Town cart) and Event (CC '92 and PF'94). And there are a few things that are untested: SPC7110, EpsonRTC, SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
2015-12-19 08:52:34 +00:00
}
}
if(settings["icarus/UseHeuristics"].boolean()) {
Heuristics::SuperFamicom game{buffer, location};
if(auto manifest = game.manifest()) return manifest;
2015-08-21 11:29:53 +00:00
}
Update to higan and icarus v095r15 release. r13 and r14 weren't posted as individual releases, but their changelogs were posted. byuu says about r13: I'm not going to be posting WIPs for r13 and above for a while. The reason is that I'm working on the major manifest overhaul I've discussed previously on the icarus subforum. I'm recreating my boards database from scratch using the map files and the new map analyzer. The only games that will load are ones I've created board definitions for, and updated sfc/cartridge/markup.cpp to parse. Once I've finished all the boards, then I'll update the heuristics. Then finally, I'll sync the syntax changes over to the fc, gb, gba cores. Once that's done, I'll start posting WIPs again, along with a new build of icarus. But I'll still post changelogs as I work through things. Changelog (r13): - preservation: created new database-builder tool (merges region-specific databases with boards) - icarus: support new, external database format (~/.config/icarus/Database/(Super Famicom.bml, ...) - added 1A3B-(10,11,12); 1A3B-20 byuu says about r14: r14 work: I successfully created mappings for every board used in the US set. I also updated icarus' heuristics to use the new mappings, and created ones there for the boards that are only in the JP set. Then I patched icarus to support pulling games out of the database when it's used on a game folder to generate a manifest file. Then I updated a lot of code in higan/sfc to support the new mapping syntax. sfc/cartridge/markup.cpp is about half the size it used to be with the new mappings, and I was able to kill off both map/id and map/select entirely. Then I updated all four emulated systems (and both subsystems) to use "board" as the root node, and harmonized their syntax (made them all more consistent with each other.) Then I added a manifest viewer to the tools window+menu. It's kind of an advanced user feature, but oh well. No reason to coddle people when the feature is very useful for developers. The viewer will show all manifests in order when you load multi-cart games as well. Still not going to call any syntax 100% done right now, but thankfully with the new manifest-free folders, nobody will have to do anything to use the new format. Just download the new version and go. The Super Famicom Event stuff is currently broken (CC92/PF94 boards). That's gonna be fun to support. byuu says about r15: EDIT: small bug in icarus with heuristics. Edit core/super-famicom.cpp line 27: if(/*auto*/ markup = cartridge.markup) { Gotta remove that "auto" so that it returns valid markup. Resolved the final concerns I had with the new manifest format. Right now there are two things that are definitely broken: MCC (BS-X Town cart) and Event (CC '92 and PF'94). And there are a few things that are untested: SPC7110, EpsonRTC, SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
2015-12-19 08:52:34 +00:00
return {};
2015-08-21 11:29:53 +00:00
}
auto Icarus::superFamicomImport(vector<uint8_t>& buffer, string location) -> string {
auto name = Location::prefix(location);
auto source = Location::path(location);
string target{settings["Library/Location"].text(), "Super Famicom/", name, ".sfc/"};
2015-08-21 11:29:53 +00:00
auto manifest = superFamicomManifest(buffer, location);
if(!manifest) return failure("failed to parse ROM image");
2015-08-21 11:29:53 +00:00
if(!create(target)) return failure("library path unwritable");
if(exists({source, name, ".srm"}) && !exists({target, "save.ram"})) {
copy({source, name, ".srm"}, {target, "save.ram"});
}
2015-08-21 11:29:53 +00:00
if(settings["icarus/CreateManifests"].boolean()) write({target, "manifest.bml"}, manifest);
uint offset = 0;
auto document = BML::unserialize(manifest);
for(auto rom : document.find("game/board/memory")) {
if(rom["type"].text() != "ROM") continue;
auto name = string{rom["architecture"].text(), ".", rom["content"].text(), ".rom"}.trimLeft(".", 1L).downcase();
auto size = rom["size"].natural();
if(size > buffer.size() - offset) {
Update to v106r21 release. byuu says: Changelog: - higan: target-tomoko has been renamed to target-higan - Super Famicom: event has been renamed to processor(architecture=uPD78214) - Super Famicom: SNES-EVENT supported once more; under board IDs EVENT-CC92 and EVENT-PF94 - Super Famicom: SNES-EVENT preliminarily set up to use DIP switch settings ala the Nintendo Super System (incomplete) - Super Famicom: MCC PSRAM moved inside the MCU, as it is remappable - Super Famicom: MCC emulation rewritten from scratch; it is now vastly more accurate than before - Super Famicom: added BSC-1A5B9P-01 board definition to database; corrected BS-MCC-RAM board definition - Super Famicom: moved SHVC-LN3B-01 RAM outside of processor(identifier=SDD1) - higan: when selecting a default game to load for a new system entry, it will change the system option to match the media type - higan: the load text box on the system entry window is now editable; can be used to erase entries - icarus: fixed bug in Famicom importing - icarus: importing unappended SNES coprocessor firmware will now rename the firmware properly - hiro/GTK,Qt: WM_CLASS is now set correctly in `argv[0]`, so applications should show “higan”, “icarus” instead of “hiro” now Note: if you wish to run the BS-X town cartridge, the database currently lists the download RAM as type “PSRAM”. This needs to be changed to “RAM” in order to load properly. Otherwise, the emulator will bomb out on the load window, because BSC-1A5B9P-01 expects PSRAM to always be present, but it won't find it with the wrong memory type. I'll correct this in the database in a later release. For now, you can copy the game portion of the manifest to a new manifest.bml file and drop it into the gamepak folder until I fix the database.
2018-05-17 03:37:29 +00:00
auto firmware = string{rom["identifier"].text(), ".", rom["content"].text(), ".rom"}.trimLeft(".", 1L).downcase();
auto location = locate({"firmware/", firmware});
if(location && file::size(location) == size) {
write({target, name}, file::read(location));
} else {
Update to v106r21 release. byuu says: Changelog: - higan: target-tomoko has been renamed to target-higan - Super Famicom: event has been renamed to processor(architecture=uPD78214) - Super Famicom: SNES-EVENT supported once more; under board IDs EVENT-CC92 and EVENT-PF94 - Super Famicom: SNES-EVENT preliminarily set up to use DIP switch settings ala the Nintendo Super System (incomplete) - Super Famicom: MCC PSRAM moved inside the MCU, as it is remappable - Super Famicom: MCC emulation rewritten from scratch; it is now vastly more accurate than before - Super Famicom: added BSC-1A5B9P-01 board definition to database; corrected BS-MCC-RAM board definition - Super Famicom: moved SHVC-LN3B-01 RAM outside of processor(identifier=SDD1) - higan: when selecting a default game to load for a new system entry, it will change the system option to match the media type - higan: the load text box on the system entry window is now editable; can be used to erase entries - icarus: fixed bug in Famicom importing - icarus: importing unappended SNES coprocessor firmware will now rename the firmware properly - hiro/GTK,Qt: WM_CLASS is now set correctly in `argv[0]`, so applications should show “higan”, “icarus” instead of “hiro” now Note: if you wish to run the BS-X town cartridge, the database currently lists the download RAM as type “PSRAM”. This needs to be changed to “RAM” in order to load properly. Otherwise, the emulator will bomb out on the load window, because BSC-1A5B9P-01 expects PSRAM to always be present, but it won't find it with the wrong memory type. I'll correct this in the database in a later release. For now, you can copy the game portion of the manifest to a new manifest.bml file and drop it into the gamepak folder until I fix the database.
2018-05-17 03:37:29 +00:00
missingFiles.append(firmware);
}
continue;
}
write({target, name}, buffer.data() + offset, size);
Update to v104r07 release. byuu says: Changelog: - md/vdp: added VIP bit to status register; fixes Cliffhanger - processor/m68k/disassembler: added modes 7 and 8 to LEA address disassembly - processor/m68k/disassembler: enhanced ILLEGAL to display LINEA/LINEF $xxx variants - processor/m68k: ILLEGAL/LINEA/LINEF do not modify the stack register; fixes Caeser no Yabou II - icarus/sfc: request sgb1.boot.rom and sgb2.boot.rom separately; as they are different - icarus/sfc: removed support for external firmware when loading ROM images The hack to run Mega Drive Ballz 3D isn't in place, as I don't know if it's correct, and the graphics were corrupted anyway. The SGB boot ROM change is going to require updating the icarus database as well. I will add that in when I start dumping more cartridges here soon. Finally ... I explained this already, but I'll do so here as well: I removed icarus' support for loading SNES coprocessor firmware games with external firmware files (eg dsp1.program.rom + dsp1.data.rom in the same path as supermariokart.sfc, for example.) I realize most are going to see this as an antagonizing/stubborn move given the recent No-Intro discussion, and I won't deny that said thread is why this came to the forefront of my mind. But on my word, I honestly believe this was an ineffective solution for many reasons not related to our disagreements: 1. No-Intro distributes SNES coprocessor firmware as a merged file, eg "DSP1 (World).zip/DSP1 (World).bin" -- icarus can't possibly know about every ROM distribution set's naming conventions for firmware. (Right now, it appears GoodSNES and NSRT are mostly dead; but there may be more DATs in the future -- including my own.) 2. Even if the user obtains the firmware and tries to rename it, it won't work: icarus parses manifests generated by the heuristics module and sees two ROM files: dsp1.program.rom and dsp1.data.rom. icarus cannot identify a file named dsp1.rom as containing both of these sub-files. Users are going to have to know how to split files, which there is no way to do on stock Windows. Merging files, however, can be done via `copy /b supermariokart.sfc+dsp1.rom supermariokartdsp.sfc`; - and dsp1.rom can be named whatever now. I am not saying this will be easy for the average user, but it's easier than splitting files. 3. Separate firmware breaks icarus' database lookup. If you have pilotwings.sfc but without firmware, icarus will not find a match for it in the database lookup phase. It will then fall back on heuristics. The heuristics will pick DSP1B for compatibility with Ballz 3D which requires it. And so it will try to pull in the wrong firmware, and the game's intro will not work correctly. Furthermore, the database information will be unavailable, resulting in inaccurate mirroring. So for these reasons, I have removed said support. You must now load SNES coprocessor games into higan in one of two ways: 1) game paks with split files; or 2) SFC images with merged firmware. If and when No-Intro deploys a method I can actually use, I give you all my word I will give it a fair shot and if it's reasonable, I'll support it in icarus.
2017-08-28 12:46:14 +00:00
offset += size;
2015-08-21 11:29:53 +00:00
}
if(missingFiles) return failure({"ROM image is missing data: ", missingFiles.merge("; ")});
Update to v096r06 release. byuu says: This WIP finally achieves the vision I've had for icarus. I also fixed a mapping issue with Cx4 that, oddly enough, only caused the "2" from the Mega Man X2 title screen to disappear. [Editor's note - "the vision for icarus" was described in a separate, public forum post: http://board.byuu.org/phpbb3/viewtopic.php?p=20584 Quoting for posterity: icarus is now a full-fledged part of higan, and will be bundled with each higan WIP as well. This will ensure that in the future, the exact version of icarus you need to run higan will be included right along with it. As of this WIP, physical manifest files are now truly and entirely optional. From now on, you can associate your ROM image files with higan's main binary, or drop them directly on top of it, to load and play your games. Furthermore, there are two new menu options that appear under the library menu when icarus is present: - "Load ROM File ..." => gives you a single-file selection dialog to import (and if possible) run the game - "Import ROM Files ..." => gives you a multi-file import dialog with checkboxes to pull in multiple games at once Finally, as before, icarus can generate manifest.bml files for folders that lack them. For people who like the game folder and library system, nothing's changed. Keep using higan as you have been. For people who hate it, you can now use higan like your classic emulators. Treat the "Library->{System Name}" entries as your "favorites" list: the games you actually play. Treat the "Library->Load ROM" as your standard open file dialog in other emulators. And finally, treat "Advanced->Game Library" as your save data path for cheat codes, save states, save RAM, etc. ]
2016-01-13 10:47:45 +00:00
return success(target);
2015-08-21 11:29:53 +00:00
}