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

578 lines
17 KiB
C++
Raw Normal View History

Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
#ifdef CARTRIDGE_CPP
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
void Cartridge::parse_markup(const char* markup) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
auto document = BML::unserialize(markup);
Update to v092 release. In the release thread, byuu says: The first official release of higan has been posted. higan is the new name for bsnes, and it continues with the latter's version numbering. Note that as of now, bsnes still exists. It's a module distributed inside of higan. bsnes is now specific to my SNES emulator. Due to last minute changes to the emulator interface, and missing support in ananke, I wasn't able to include Cydrak's Nintendo DS emulator dasShiny in this build, but I hope to do so in the next release. http://code.google.com/p/higan/downloads/list For both new and experienced users, please read the higan user guide first: http://byuu.org/higan/user-guide In the v091 WIP thread, byuu says: r15->r16: - BS-X MaskROM handling (partial ... need to split bsx/flash away from sfc/chip, restructure code - it requires tagging the base cart markup for now, but it needs to parse the slotted cart markup) - phoenixflags / phoenixlink += -m32 - nall/sort stability - if(input.poll(scancode[activeScancode]) == false) return; - MSU1 / USART need to use interface->path(1) - MSU1 needs to use Markup::Document, not XML::Document - case-insensitive folder listings - remove nall/emulation/system.hpp files (move to ananke) - remove rom/ram id= checks with indexing X have cores ask for manifest.bml (skipped for v092's release, too big a change) - rename compatibility profile to balanced (so people don't assume it has better compatibility than accuracy)
2013-01-14 12:10:20 +00:00
information.title.cartridge = document["information/title"].text();
Update to higan v091r14 and ananke v00r03 releases. byuu says: higan changelog: - generates title displayed in emulator window by asking the core - core builds title solely from "information/title" ... if it's not there, you don't get a title at all - sub-system load menu is gone ... since there are multiple revisions of the SGB, this never really worked well anyway - to load an SGB, BS-X or ST cartridge, load the base cartridge first - "File->Load Game" moved to "Load->Import Game" ... may cause a bit of confusion to new users, but I don't like having a single-item menu, we'll just have to explain it to new users - browser window redone to look like ananke - home button here goes to ~/Emulation rather than just ~ like ananke, since this is the home of game folders - game folder icon is now the executable icon for the Tango theme (orange diamond), meant to represent a complete game rather than a game file or archive ananke changelog: - outputs GBC games to "Game Boy Color/" instead of "Game Boy/" - adds the file basename to "information/title" Known issues: - using ananke to load a GB game trips the Super Famicom SGB mode and fails (need to make the full-path auto-detection ignore non-bootable systems) - need to dump and test some BS-X media before releasing - ananke lacks BS-X Satellaview cartridge support - v092 isn't going to let you retarget the ananke/higan game folder path of ~/Emulation, you will have to wait for a future version if that bothers you so greatly [Later, after the v092 release, byuu posted this additional changelog: - kill laevateinn - add title() - add bootable, remove load - combine file, library - combine [][][] paths - fix SFC subtype handling XML->BML - update file browser to use buttons - update file browser keyboard handling - update system XML->BML - fix sufami turbo hashing - remove Cartridge::manifest ]
2012-12-25 05:31:55 +00:00
auto cartridge = document["cartridge"];
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
region = cartridge["region"].text() != "PAL" ? Region::NTSC : Region::PAL;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v091r11 release. byuu says: This release refines HSU1 support as a bidirectional protocol, nests SFC manifests as "release/cartridge" and "release/information" (but release/ is not guaranteed to be finalized just yet), removes the database integration, and adds support for ananke. ananke represents inevitability. It's a library that, when installed, higan can use to load files from the command-line, and also from a new File -> Load Game menu option. I need to change the build rules a bit for it to work on Windows (need to make phoenix a DLL, basically), but it works now on Linux. Right now, it only takes *.sfc file names, looks them up in the included database, converts them to game folders, and returns the game folder path for higan to load. The idea is to continue expanding it to support everything we can that I don't want in the higan core: - load *.sfc, *.smc, *.swc, *.fig files - remove SNES copier headers - split apart merged firmware files - pull in external firmware files (eg dsp1b.rom - these are staying merged, just as SPC7110 prg+dat are merged) - load *.zip and *.7z archives - prompt for selection on multi-file archives - generate manifest files based on heuristics - apply BPS patches The "Load" menu option has been renamed to "Library", to represent games in your library. I'm going to add some sort of suffix to indicate unverified games, and use a different folder icon for those (eg manifests built on heuristics rather than from the database.) So basically, to future end users: File -> Load Game will be how they play games. Library -> (specific system) can be thought of as an infinitely-sized recent games list. purify will likely become a simple stub that invokes ananke's functions. No reason to duplicate all that code.
2012-11-05 08:22:50 +00:00
mapping.reset();
parse_markup_cartridge(cartridge);
parse_markup_icd2(cartridge["icd2"]);
parse_markup_bsx(cartridge["bsx"]);
Update to v092r02 release. byuu says: Changelog: - merged AWJ's hires color blending improvements (most notably: fixes Marvelous' text) - created sfc/base/ to store base unit (expansion port device) emulation - synchronized the markup of Satellaview and Sufami Turbo cartridge slots in the board markup - fixed "Initializing ..." typo in timing settings If at all possible, I'd really like to have heavy testing of games that use hires graphics to check for any regressions. I trust AWJ's code, and all of the test ROMs I have thrown at it all appear to work great. But better safe than sorry. Same deal for any core changes, it's a lot better to catch it now than after v093 is released.
2013-01-23 08:28:35 +00:00
parse_markup_satellaview(cartridge["satellaview"]);
parse_markup_sufamiturbo(cartridge["sufamiturbo[0]"], 0);
parse_markup_sufamiturbo(cartridge["sufamiturbo[1]"], 1);
Update to v091r11 release. byuu says: This release refines HSU1 support as a bidirectional protocol, nests SFC manifests as "release/cartridge" and "release/information" (but release/ is not guaranteed to be finalized just yet), removes the database integration, and adds support for ananke. ananke represents inevitability. It's a library that, when installed, higan can use to load files from the command-line, and also from a new File -> Load Game menu option. I need to change the build rules a bit for it to work on Windows (need to make phoenix a DLL, basically), but it works now on Linux. Right now, it only takes *.sfc file names, looks them up in the included database, converts them to game folders, and returns the game folder path for higan to load. The idea is to continue expanding it to support everything we can that I don't want in the higan core: - load *.sfc, *.smc, *.swc, *.fig files - remove SNES copier headers - split apart merged firmware files - pull in external firmware files (eg dsp1b.rom - these are staying merged, just as SPC7110 prg+dat are merged) - load *.zip and *.7z archives - prompt for selection on multi-file archives - generate manifest files based on heuristics - apply BPS patches The "Load" menu option has been renamed to "Library", to represent games in your library. I'm going to add some sort of suffix to indicate unverified games, and use a different folder icon for those (eg manifests built on heuristics rather than from the database.) So basically, to future end users: File -> Load Game will be how they play games. Library -> (specific system) can be thought of as an infinitely-sized recent games list. purify will likely become a simple stub that invokes ananke's functions. No reason to duplicate all that code.
2012-11-05 08:22:50 +00:00
parse_markup_nss(cartridge["nss"]);
parse_markup_event(cartridge["event"]);
parse_markup_sa1(cartridge["sa1"]);
parse_markup_superfx(cartridge["superfx"]);
parse_markup_armdsp(cartridge["armdsp"]);
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
parse_markup_hitachidsp(cartridge["hitachidsp"], cartridge["board/type"].text().match("2DC*") ? 2 : 1);
Update to v091r11 release. byuu says: This release refines HSU1 support as a bidirectional protocol, nests SFC manifests as "release/cartridge" and "release/information" (but release/ is not guaranteed to be finalized just yet), removes the database integration, and adds support for ananke. ananke represents inevitability. It's a library that, when installed, higan can use to load files from the command-line, and also from a new File -> Load Game menu option. I need to change the build rules a bit for it to work on Windows (need to make phoenix a DLL, basically), but it works now on Linux. Right now, it only takes *.sfc file names, looks them up in the included database, converts them to game folders, and returns the game folder path for higan to load. The idea is to continue expanding it to support everything we can that I don't want in the higan core: - load *.sfc, *.smc, *.swc, *.fig files - remove SNES copier headers - split apart merged firmware files - pull in external firmware files (eg dsp1b.rom - these are staying merged, just as SPC7110 prg+dat are merged) - load *.zip and *.7z archives - prompt for selection on multi-file archives - generate manifest files based on heuristics - apply BPS patches The "Load" menu option has been renamed to "Library", to represent games in your library. I'm going to add some sort of suffix to indicate unverified games, and use a different folder icon for those (eg manifests built on heuristics rather than from the database.) So basically, to future end users: File -> Load Game will be how they play games. Library -> (specific system) can be thought of as an infinitely-sized recent games list. purify will likely become a simple stub that invokes ananke's functions. No reason to duplicate all that code.
2012-11-05 08:22:50 +00:00
parse_markup_necdsp(cartridge["necdsp"]);
parse_markup_epsonrtc(cartridge["epsonrtc"]);
parse_markup_sharprtc(cartridge["sharprtc"]);
parse_markup_spc7110(cartridge["spc7110"]);
parse_markup_sdd1(cartridge["sdd1"]);
parse_markup_obc1(cartridge["obc1"]);
parse_markup_msu1(cartridge["msu1"]);
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
//
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
void Cartridge::parse_markup_map(Mapping& m, Markup::Node map) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
m.addr = map["address"].text();
m.size = map["size"].decimal();
m.base = map["base"].decimal();
m.mask = map["mask"].decimal();
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
void Cartridge::parse_markup_memory(MappedRAM& ram, Markup::Node node, unsigned id, bool writable) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
string name = node["name"].text();
unsigned size = node["size"].decimal();
Update to v089r07 release. byuu says: Not even purify makes compatible images for this WIP. Unless you want to figure it out yourself, I'd suggest waiting for an updated tool before using subsequent WIPs. Changelog: - MSU1 initializes data port + audio track to 0 - MSU1 implements audio track error flag on $2000.d3 - manifest.xml now controls file names for cartridge folders ... mostly Regressions: - Super Game Boy support is broken - Sufami Turbo support is broken So, basically Emulator::Interface() now has: void load(const string &manifest); void save(); The first one will analyze the manifest, and call all the ROM + RAM loadRequest() commands necessary to run the game. The second one will call saveRequest() commands on all writable and non-volatile storage (basically if it's a RAM type and has a filename specified, it gets saved to disk.) save() shrinks the size of Emulator::Interface() by hiding information one is unlikely to care about. It also makes it much easier to save. The core auto-calls this when you unload a game as well. So the only time you ever have to worry about it is if you want to save RAM files mid-game (in case you want to do periodic backups in case of a crash.)
2012-05-26 08:18:42 +00:00
ram.map(allocate<uint8>(size, 0xff), size);
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(name) {
Update to v089r07 release. byuu says: Not even purify makes compatible images for this WIP. Unless you want to figure it out yourself, I'd suggest waiting for an updated tool before using subsequent WIPs. Changelog: - MSU1 initializes data port + audio track to 0 - MSU1 implements audio track error flag on $2000.d3 - manifest.xml now controls file names for cartridge folders ... mostly Regressions: - Super Game Boy support is broken - Sufami Turbo support is broken So, basically Emulator::Interface() now has: void load(const string &manifest); void save(); The first one will analyze the manifest, and call all the ROM + RAM loadRequest() commands necessary to run the game. The second one will call saveRequest() commands on all writable and non-volatile storage (basically if it's a RAM type and has a filename specified, it gets saved to disk.) save() shrinks the size of Emulator::Interface() by hiding information one is unlikely to care about. It also makes it much easier to save. The core auto-calls this when you unload a game as well. So the only time you ever have to worry about it is if you want to save RAM files mid-game (in case you want to do periodic backups in case of a crash.)
2012-05-26 08:18:42 +00:00
interface->loadRequest(id, name);
if(writable) memory.append({id, name});
}
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
//
Update to v091r11 release. byuu says: This release refines HSU1 support as a bidirectional protocol, nests SFC manifests as "release/cartridge" and "release/information" (but release/ is not guaranteed to be finalized just yet), removes the database integration, and adds support for ananke. ananke represents inevitability. It's a library that, when installed, higan can use to load files from the command-line, and also from a new File -> Load Game menu option. I need to change the build rules a bit for it to work on Windows (need to make phoenix a DLL, basically), but it works now on Linux. Right now, it only takes *.sfc file names, looks them up in the included database, converts them to game folders, and returns the game folder path for higan to load. The idea is to continue expanding it to support everything we can that I don't want in the higan core: - load *.sfc, *.smc, *.swc, *.fig files - remove SNES copier headers - split apart merged firmware files - pull in external firmware files (eg dsp1b.rom - these are staying merged, just as SPC7110 prg+dat are merged) - load *.zip and *.7z archives - prompt for selection on multi-file archives - generate manifest files based on heuristics - apply BPS patches The "Load" menu option has been renamed to "Library", to represent games in your library. I'm going to add some sort of suffix to indicate unverified games, and use a different folder icon for those (eg manifests built on heuristics rather than from the database.) So basically, to future end users: File -> Load Game will be how they play games. Library -> (specific system) can be thought of as an infinitely-sized recent games list. purify will likely become a simple stub that invokes ananke's functions. No reason to duplicate all that code.
2012-11-05 08:22:50 +00:00
void Cartridge::parse_markup_cartridge(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
parse_markup_memory(rom, root["rom"], ID::ROM, false);
parse_markup_memory(ram, root["ram"], ID::RAM, true);
Update to v089r07 release. byuu says: Not even purify makes compatible images for this WIP. Unless you want to figure it out yourself, I'd suggest waiting for an updated tool before using subsequent WIPs. Changelog: - MSU1 initializes data port + audio track to 0 - MSU1 implements audio track error flag on $2000.d3 - manifest.xml now controls file names for cartridge folders ... mostly Regressions: - Super Game Boy support is broken - Sufami Turbo support is broken So, basically Emulator::Interface() now has: void load(const string &manifest); void save(); The first one will analyze the manifest, and call all the ROM + RAM loadRequest() commands necessary to run the game. The second one will call saveRequest() commands on all writable and non-volatile storage (basically if it's a RAM type and has a filename specified, it gets saved to disk.) save() shrinks the size of Emulator::Interface() by hiding information one is unlikely to care about. It also makes it much easier to save. The core auto-calls this when you unload a game as well. So the only time you ever have to worry about it is if you want to save RAM files mid-game (in case you want to do periodic backups in case of a crash.)
2012-05-26 08:18:42 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "rom") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m(rom);
parse_markup_map(m, node);
if(m.size == 0) m.size = rom.size();
mapping.append(m);
}
Update to v089r07 release. byuu says: Not even purify makes compatible images for this WIP. Unless you want to figure it out yourself, I'd suggest waiting for an updated tool before using subsequent WIPs. Changelog: - MSU1 initializes data port + audio track to 0 - MSU1 implements audio track error flag on $2000.d3 - manifest.xml now controls file names for cartridge folders ... mostly Regressions: - Super Game Boy support is broken - Sufami Turbo support is broken So, basically Emulator::Interface() now has: void load(const string &manifest); void save(); The first one will analyze the manifest, and call all the ROM + RAM loadRequest() commands necessary to run the game. The second one will call saveRequest() commands on all writable and non-volatile storage (basically if it's a RAM type and has a filename specified, it gets saved to disk.) save() shrinks the size of Emulator::Interface() by hiding information one is unlikely to care about. It also makes it much easier to save. The core auto-calls this when you unload a game as well. So the only time you ever have to worry about it is if you want to save RAM files mid-game (in case you want to do periodic backups in case of a crash.)
2012-05-26 08:18:42 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "ram") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m(ram);
parse_markup_map(m, node);
if(m.size == 0) m.size = ram.size();
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_icd2(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v088r11 release. byuu says: Changelog: - phoenix has added Window::setModal(bool modal = true); - file dialog is now modal. This allows emulation cores to request data and get it immediately before continuing the loading process - save data is hooked up for most systems, still need to handle subsystem slot saves (Sufami Turbo, basically.) - toggle fullscreen key binding added (Alt+Enter for now. I think F11 is probably better though, Enter is often mapped to game start button.) - video scaling is in (center, scale, stretch), works the same in windowed and fullscreen mode (stretch hides resize window option), all in the settings menu now - enough structure to map all saved paths for the browser and to load BS-X slotted carts, BS-X carts, single Sufami Turbo carts Caveats / Missing: - Super Game Boy input doesn't work yet (due to change in callback binding) - doesn't load secondary Sufami Turbo slot yet - BS-X BIOS isn't show the data pack games to load for some reason (ugh, I hate the shit out of debugging BS-X stuff ...) - need mute audio, sync audio+video toggle, save/load state menu and quick keys, XML mapping information window - need cheat editor and cheat database - need state manager - need to sort subsystems below main systems in load menu (basically just see if media.slot.size() > 0) - need video shaders (will probably leave off filters for the time being ... due to that 24/30-bit thing) - need video adjustments (contrast etc, overscan masks) - need audio adjustments (frequency, latency, resampler, volume, per-system frequency) - need driver selection and input focus policy (driver crash detection would be nice too) - need NSS DIP switch settings (that one will be really fun) - need to save and load window geometry settings - need to hook up controller selection (won't be fun), create a map to hide controllers with no inputs to reassign
2012-05-03 12:36:47 +00:00
has_gb_slot = true;
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
icd2.revision = max(1, root["revision"].decimal());
Update to v088r11 release. byuu says: Changelog: - phoenix has added Window::setModal(bool modal = true); - file dialog is now modal. This allows emulation cores to request data and get it immediately before continuing the loading process - save data is hooked up for most systems, still need to handle subsystem slot saves (Sufami Turbo, basically.) - toggle fullscreen key binding added (Alt+Enter for now. I think F11 is probably better though, Enter is often mapped to game start button.) - video scaling is in (center, scale, stretch), works the same in windowed and fullscreen mode (stretch hides resize window option), all in the settings menu now - enough structure to map all saved paths for the browser and to load BS-X slotted carts, BS-X carts, single Sufami Turbo carts Caveats / Missing: - Super Game Boy input doesn't work yet (due to change in callback binding) - doesn't load secondary Sufami Turbo slot yet - BS-X BIOS isn't show the data pack games to load for some reason (ugh, I hate the shit out of debugging BS-X stuff ...) - need mute audio, sync audio+video toggle, save/load state menu and quick keys, XML mapping information window - need cheat editor and cheat database - need state manager - need to sort subsystems below main systems in load menu (basically just see if media.slot.size() > 0) - need video shaders (will probably leave off filters for the time being ... due to that 24/30-bit thing) - need video adjustments (contrast etc, overscan masks) - need audio adjustments (frequency, latency, resampler, volume, per-system frequency) - need driver selection and input focus policy (driver crash detection would be nice too) - need NSS DIP switch settings (that one will be really fun) - need to save and load window geometry settings - need to hook up controller selection (won't be fun), create a map to hide controllers with no inputs to reassign
2012-05-03 12:36:47 +00:00
Update to v093r06 release. byuu says: Changelog: - Windows port should compile out-of-the-box - InputManager::scancode[] initialized at startup - Library menu shows item for each bootable media type (notably Game Boy Color) - Display Emulation menu selection fix - LibraryManager load button works now - Added hotkey to show library manager (defaults to L) - Added color emulation to video settings (missing on GBA for now) - SFC loading SGB without GB cartridge no longer segfaults - GB/GBC system.load() after cartridge.load() - GB/GBC BG-over-OAM fix - GB/GBC disallow up+down and left+right
2013-12-07 09:12:37 +00:00
GameBoy::cartridge.load_empty(GameBoy::System::Revision::SuperGameBoy);
Update to v089r08 release. byuu says: Changelog: - Super Game Boy, BS-X Satellaview and Sufami Turbo cartridges all load manifests that specify their file names, and they all work - Sufami Turbo can now properly handle carts without RAM, or empty slots entirely - Emulator::Interface structures no longer specify any file names, ever - exposed "capability.(cheats,states)" now. So far, this just means the GBA doesn't show the cheat editor, since it doesn't support cheat codes yet - as such, state manager and cheat editor windows auto-hide (may be a tiny bit inconvenient, but it makes not having to sync them or deal with input when no cart is loaded easier) - added "AbsoluteInput" type, which returns mouse coordinates from -32767,-32767 (top left) to +32767,+32767 (bottom right) or -32768,-32768 (offscreen) AbsoluteInput is just something I'm toying with. Idea is to support eg Super Scope or Justifier, or possibly some future Famicom controllers that are absolute-indexed. The coordinates are scaled, so the bigger your window, the more precise they are. But obviously you can't get more precise than the emulated system, so 1x scale will behave the same anyway. I haven't hooked it up yet, need to mess with the idea of custom cursors via phoenix for that first. Also not sure if it will feel smoother or not ... if you resize the window, your mouse will seem to move slower. Still, not having to capture the mouse for SS/JS may be nicer yet. But we'll see ... just experimenting for now.
2012-05-27 23:50:50 +00:00
interface->loadRequest(ID::SuperGameBoy, "Game Boy", "gb");
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
string bootROMName = root["rom/name"].text();
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
interface->loadRequest(ID::SuperGameBoyBootROM, bootROMName);
Update to v089r16 release. byuu says: Changelog: - eliminated <mmio>, <mcu> tags [they are merged to their parent nodes now] - added <ram name= size=> tag to EpsonRTC, SharpRTC - added <firmware> tag to DSP-n, ST-01n, ST-018, Cx4 - interface->path(0) now returns the system folder, which can be used for storage now - as a fun proof-of-concept, I've simulated SNES warm power cycles by saving and loading work RAM (same effect if you instantly swapped carts) - long-term, I'm not sure how I want to do this. The power menu option makes no sense with warm RAM - I like the idea of decaying RAM based on timestamp from last play; and power can just force the timestamp to 0 (which will corrupt all RAM) - Interface::firmware is gone. The cores now load firmware inside their boot up routines - you now get a message on the screen if the emulator can't find firmware, should help with "I just get a black screen" messages I'd like to start preparing for a v090 release. I think we're almost there now. Have to update nall/cartridge and purify to handle XML changes first.
2012-07-15 09:47:35 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&ICD2::read, &icd2}, {&ICD2::write, &icd2});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_bsx(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
has_bs_cart = true;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_bs_slot = true;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v089r08 release. byuu says: Changelog: - Super Game Boy, BS-X Satellaview and Sufami Turbo cartridges all load manifests that specify their file names, and they all work - Sufami Turbo can now properly handle carts without RAM, or empty slots entirely - Emulator::Interface structures no longer specify any file names, ever - exposed "capability.(cheats,states)" now. So far, this just means the GBA doesn't show the cheat editor, since it doesn't support cheat codes yet - as such, state manager and cheat editor windows auto-hide (may be a tiny bit inconvenient, but it makes not having to sync them or deal with input when no cart is loaded easier) - added "AbsoluteInput" type, which returns mouse coordinates from -32767,-32767 (top left) to +32767,+32767 (bottom right) or -32768,-32768 (offscreen) AbsoluteInput is just something I'm toying with. Idea is to support eg Super Scope or Justifier, or possibly some future Famicom controllers that are absolute-indexed. The coordinates are scaled, so the bigger your window, the more precise they are. But obviously you can't get more precise than the emulated system, so 1x scale will behave the same anyway. I haven't hooked it up yet, need to mess with the idea of custom cursors via phoenix for that first. Also not sure if it will feel smoother or not ... if you resize the window, your mouse will seem to move slower. Still, not having to capture the mouse for SS/JS may be nicer yet. But we'll see ... just experimenting for now.
2012-05-27 23:50:50 +00:00
interface->loadRequest(ID::Satellaview, "BS-X Satellaview", "bs");
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
parse_markup_memory(bsxcartridge.rom, root["rom"], ID::BsxROM, false);
parse_markup_memory(bsxcartridge.ram, root["ram"], ID::BsxRAM, true);
parse_markup_memory(bsxcartridge.psram, root["psram"], ID::BsxPSRAM, true);
Update to v089r15 release. byuu says: Changelog: - SuperFX has its own ROM and RAM - Cx4 has its own ROM - SPC7110 has its own ProgramROM, DataROM and RAM - OBC1 has its own RAM - BsxCartridge has its own ROM, RAM and PSRAM - mapping changes to accommodate the above
2012-07-09 11:40:23 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "rom"
|| node["id"].text() == "ram") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&BSXCartridge::mcu_read, &bsxcartridge}, {&BSXCartridge::mcu_write, &bsxcartridge});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&BSXCartridge::mmio_read, &bsxcartridge}, {&BSXCartridge::mmio_write, &bsxcartridge});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
}
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
}
Update to v092r02 release. byuu says: Changelog: - merged AWJ's hires color blending improvements (most notably: fixes Marvelous' text) - created sfc/base/ to store base unit (expansion port device) emulation - synchronized the markup of Satellaview and Sufami Turbo cartridge slots in the board markup - fixed "Initializing ..." typo in timing settings If at all possible, I'd really like to have heavy testing of games that use hires graphics to check for any regressions. I trust AWJ's code, and all of the test ROMs I have thrown at it all appear to work great. But better safe than sorry. Same deal for any core changes, it's a lot better to catch it now than after v093 is released.
2013-01-23 08:28:35 +00:00
void Cartridge::parse_markup_satellaview(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
has_bs_slot = true;
interface->loadRequest(ID::Satellaview, "BS-X Satellaview", "bs");
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "rom") {
Update to higan v092r01, ananke v02r01 and purify v03r01 releases. byuu says: higan changelog: - compiler is set to g++-4.7, subst(cc,++) rule is gone, C files compile with $(compiler) -x c - make throws an error when you specify an invalid profile or compile on an unsupported platform (instead of hanging forever) - added unverified.png to resources (causes too big of a speed hit to actually check for folder/unverified file ... so disabled for now) - fixed default browser paths for Game Boy, Sufami Turbo and BS-X Satellaview (have to delete paths.cfg to see this) - browser home button seeks to configpath()/higan/library.cfg - settings->driver is now settings->advanced, and it adds game library path setting and profile information - emulation cores now load manifest files internally, manifest.bml is not required for a game folder to be recognized by higan as such - BS-X Satellaview and Sufami Turbo slot cartridge handling moved out of sfc/chip and into sfc/slot - Video::StartFullScreen only sets fullscreen when a game is specified on the command-line purify and ananke changelog: - library output path shown in purify window - added button to change library path - squelch firmware warning windows to prevent multi-threading crash, but only via purify (they show up in higan still)
2013-01-21 12:27:15 +00:00
if(satellaviewcartridge.memory.size() == 0) continue;
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Update to higan v092r01, ananke v02r01 and purify v03r01 releases. byuu says: higan changelog: - compiler is set to g++-4.7, subst(cc,++) rule is gone, C files compile with $(compiler) -x c - make throws an error when you specify an invalid profile or compile on an unsupported platform (instead of hanging forever) - added unverified.png to resources (causes too big of a speed hit to actually check for folder/unverified file ... so disabled for now) - fixed default browser paths for Game Boy, Sufami Turbo and BS-X Satellaview (have to delete paths.cfg to see this) - browser home button seeks to configpath()/higan/library.cfg - settings->driver is now settings->advanced, and it adds game library path setting and profile information - emulation cores now load manifest files internally, manifest.bml is not required for a game folder to be recognized by higan as such - BS-X Satellaview and Sufami Turbo slot cartridge handling moved out of sfc/chip and into sfc/slot - Video::StartFullScreen only sets fullscreen when a game is specified on the command-line purify and ananke changelog: - library output path shown in purify window - added button to change library path - squelch firmware warning windows to prevent multi-threading crash, but only via purify (they show up in higan still)
2013-01-21 12:27:15 +00:00
Mapping m(satellaviewcartridge);
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
parse_markup_map(m, node);
mapping.append(m);
}
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
}
}
Update to v092r02 release. byuu says: Changelog: - merged AWJ's hires color blending improvements (most notably: fixes Marvelous' text) - created sfc/base/ to store base unit (expansion port device) emulation - synchronized the markup of Satellaview and Sufami Turbo cartridge slots in the board markup - fixed "Initializing ..." typo in timing settings If at all possible, I'd really like to have heavy testing of games that use hires graphics to check for any regressions. I trust AWJ's code, and all of the test ROMs I have thrown at it all appear to work great. But better safe than sorry. Same deal for any core changes, it's a lot better to catch it now than after v093 is released.
2013-01-23 08:28:35 +00:00
void Cartridge::parse_markup_sufamiturbo(Markup::Node root, bool slot) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_st_slots = true;
Update to v092r02 release. byuu says: Changelog: - merged AWJ's hires color blending improvements (most notably: fixes Marvelous' text) - created sfc/base/ to store base unit (expansion port device) emulation - synchronized the markup of Satellaview and Sufami Turbo cartridge slots in the board markup - fixed "Initializing ..." typo in timing settings If at all possible, I'd really like to have heavy testing of games that use hires graphics to check for any regressions. I trust AWJ's code, and all of the test ROMs I have thrown at it all appear to work great. But better safe than sorry. Same deal for any core changes, it's a lot better to catch it now than after v093 is released.
2013-01-23 08:28:35 +00:00
if(slot == 0) {
//load required slot A (will request slot B if slot A cartridge is linkable)
interface->loadRequest(ID::SufamiTurboSlotA, "Sufami Turbo - Slot A", "st");
}
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
SufamiTurboCartridge& cart = (slot == 0 ? sufamiturboA : sufamiturboB);
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "rom") {
Update to v092r02 release. byuu says: Changelog: - merged AWJ's hires color blending improvements (most notably: fixes Marvelous' text) - created sfc/base/ to store base unit (expansion port device) emulation - synchronized the markup of Satellaview and Sufami Turbo cartridge slots in the board markup - fixed "Initializing ..." typo in timing settings If at all possible, I'd really like to have heavy testing of games that use hires graphics to check for any regressions. I trust AWJ's code, and all of the test ROMs I have thrown at it all appear to work great. But better safe than sorry. Same deal for any core changes, it's a lot better to catch it now than after v093 is released.
2013-01-23 08:28:35 +00:00
if(cart.rom.size() == 0) continue;
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Update to v092r02 release. byuu says: Changelog: - merged AWJ's hires color blending improvements (most notably: fixes Marvelous' text) - created sfc/base/ to store base unit (expansion port device) emulation - synchronized the markup of Satellaview and Sufami Turbo cartridge slots in the board markup - fixed "Initializing ..." typo in timing settings If at all possible, I'd really like to have heavy testing of games that use hires graphics to check for any regressions. I trust AWJ's code, and all of the test ROMs I have thrown at it all appear to work great. But better safe than sorry. Same deal for any core changes, it's a lot better to catch it now than after v093 is released.
2013-01-23 08:28:35 +00:00
Mapping m(cart.rom);
parse_markup_map(m, node);
if(m.size == 0) m.size = cart.rom.size();
if(m.size) mapping.append(m);
}
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "ram") {
Update to v092r02 release. byuu says: Changelog: - merged AWJ's hires color blending improvements (most notably: fixes Marvelous' text) - created sfc/base/ to store base unit (expansion port device) emulation - synchronized the markup of Satellaview and Sufami Turbo cartridge slots in the board markup - fixed "Initializing ..." typo in timing settings If at all possible, I'd really like to have heavy testing of games that use hires graphics to check for any regressions. I trust AWJ's code, and all of the test ROMs I have thrown at it all appear to work great. But better safe than sorry. Same deal for any core changes, it's a lot better to catch it now than after v093 is released.
2013-01-23 08:28:35 +00:00
if(cart.ram.size() == 0) continue;
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Update to v092r02 release. byuu says: Changelog: - merged AWJ's hires color blending improvements (most notably: fixes Marvelous' text) - created sfc/base/ to store base unit (expansion port device) emulation - synchronized the markup of Satellaview and Sufami Turbo cartridge slots in the board markup - fixed "Initializing ..." typo in timing settings If at all possible, I'd really like to have heavy testing of games that use hires graphics to check for any regressions. I trust AWJ's code, and all of the test ROMs I have thrown at it all appear to work great. But better safe than sorry. Same deal for any core changes, it's a lot better to catch it now than after v093 is released.
2013-01-23 08:28:35 +00:00
Mapping m(cart.ram);
parse_markup_map(m, node);
if(m.size == 0) m.size = cart.ram.size();
if(m.size) mapping.append(m);
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_nss(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_nss_dip = true;
nss.dip = interface->dipSettings(root);
Update to v089r14 release. byuu says: Changelog: - NSS emulation improvement (DIP is 8-bits, not 16-bits; can be remapped via XML now like all the other chips) - SA-1 memory map improvements (IRAM and BWRAM can be saved; ROM, IRAM and BWRAM are separate from Cartridge::ROM, RAM; no MCU) - S-DD1 memory map improvements (ROM, RAM inside mapping; no MCU) - SPC7110 memory map improvements (ROM, RAM inside mapping; no MCU; not finished yet [have to handle 8mbit expansion somehow now) I have tried multiple times now to get the SuperFX core to use internal ROM and RAM (separate from Cartridge::ROM, RAM) to no avail. Not sure what the hell is going on there. Trace logs of 430MB are not enticing ... So right now: SuperFX, SPC7110 and BS-X cheat by mapping stuff to Cartridge::ROM, RAM still. They need to not do that.
2012-07-08 02:57:34 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&NSS::read, &nss}, {&NSS::write, &nss});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v089r14 release. byuu says: Changelog: - NSS emulation improvement (DIP is 8-bits, not 16-bits; can be remapped via XML now like all the other chips) - SA-1 memory map improvements (IRAM and BWRAM can be saved; ROM, IRAM and BWRAM are separate from Cartridge::ROM, RAM; no MCU) - S-DD1 memory map improvements (ROM, RAM inside mapping; no MCU) - SPC7110 memory map improvements (ROM, RAM inside mapping; no MCU; not finished yet [have to handle 8mbit expansion somehow now) I have tried multiple times now to get the SuperFX core to use internal ROM and RAM (separate from Cartridge::ROM, RAM) to no avail. Not sure what the hell is going on there. Trace logs of 430MB are not enticing ... So right now: SuperFX, SPC7110 and BS-X cheat by mapping stuff to Cartridge::ROM, RAM still. They need to not do that.
2012-07-08 02:57:34 +00:00
}
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_event(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
has_event = true;
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("rom")) {
unsigned id = node["id"].decimal();
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
if(id > 3) continue;
parse_markup_memory(event.rom[id], node, ID::EventROM0 + id, false);
}
parse_markup_memory(event.ram, root["ram"], ID::EventRAM, true);
event.board = Event::Board::CampusChallenge92;
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(root["name"].text() == "Campus Challenge '92") event.board = Event::Board::CampusChallenge92;
if(root["name"].text() == "Powerfest '94") event.board = Event::Board::Powerfest94;
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
event.revision = root["revision"].text() == "B" ? 2 : 1;
lstring part = root["timer"].text().split<1>(":");
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
if(part.size() == 1) event.timer = decimal(part(0));
if(part.size() == 2) event.timer = decimal(part(0)) * 60 + decimal(part(1));
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "rom") {
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
Mapping m({&Event::rom_read, &event}, [](unsigned, uint8) {});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "ram") {
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
Mapping m({&Event::ram_read, &event}, {&Event::ram_write, &event});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "dr") {
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
Mapping m([](unsigned) -> uint8 { return cpu.regs.mdr; }, {&Event::dr, &event});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "sr") {
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
Mapping m({&Event::sr, &event}, [](unsigned, uint8) {});
parse_markup_map(m, node);
mapping.append(m);
}
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_sa1(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
has_sa1 = true;
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
auto rom = root.find("rom");
auto ram = root.find("ram");
parse_markup_memory(sa1.rom, rom(0), ID::SA1ROM, false);
parse_markup_memory(sa1.bwram, ram(0), ID::SA1BWRAM, true);
parse_markup_memory(sa1.iram, ram(1), ID::SA1IRAM, true);
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SA1::mmio_read, &sa1}, {&SA1::mmio_write, &sa1});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "rom") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SA1::mmcrom_read, &sa1}, {&SA1::mmcrom_write, &sa1});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "bwram") {
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
Mapping m({&SA1::mmcbwram_read, &sa1}, {&SA1::mmcbwram_write, &sa1});
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "iram") {
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
Mapping m(sa1.cpuiram);
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
parse_markup_map(m, node);
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
if(m.size == 0) m.size = sa1.cpuiram.size();
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_superfx(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_superfx = true;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
auto rom = root.find("rom");
auto ram = root.find("ram");
parse_markup_memory(superfx.rom, rom(0), ID::SuperFXROM, false);
parse_markup_memory(superfx.ram, ram(0), ID::SuperFXRAM, true);
Update to v089r15 release. byuu says: Changelog: - SuperFX has its own ROM and RAM - Cx4 has its own ROM - SPC7110 has its own ProgramROM, DataROM and RAM - OBC1 has its own RAM - BsxCartridge has its own ROM, RAM and PSRAM - mapping changes to accommodate the above
2012-07-09 11:40:23 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SuperFX::mmio_read, &superfx}, {&SuperFX::mmio_write, &superfx});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "rom") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m(superfx.cpurom);
parse_markup_map(m, node);
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
if(m.size == 0) m.size = superfx.rom.size();
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "ram") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m(superfx.cpuram);
parse_markup_map(m, node);
if(m.size == 0) m.size = superfx.ram.size();
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_armdsp(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_armdsp = true;
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
auto rom = root.find("rom");
auto ram = root.find("ram");
string programROMName = rom(0)["name"].text();
string dataROMName = rom(1)["name"].text();
string dataRAMName = ram(0)["name"].text();
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
interface->loadRequest(ID::ArmDSPPROM, programROMName);
interface->loadRequest(ID::ArmDSPDROM, dataROMName);
if(dataRAMName.empty() == false) {
interface->loadRequest(ID::ArmDSPRAM, dataRAMName);
memory.append({ID::ArmDSPRAM, dataRAMName});
}
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&ArmDSP::mmio_read, &armdsp}, {&ArmDSP::mmio_write, &armdsp});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
}
}
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
void Cartridge::parse_markup_hitachidsp(Markup::Node root, unsigned roms) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
has_hitachidsp = true;
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
auto rom = root.find("rom");
auto ram = root.find("ram");
parse_markup_memory(hitachidsp.rom, rom(0), ID::HitachiDSPROM, false);
parse_markup_memory(hitachidsp.ram, ram(0), ID::HitachiDSPRAM, true);
Update to v092 release. In the release thread, byuu says: The first official release of higan has been posted. higan is the new name for bsnes, and it continues with the latter's version numbering. Note that as of now, bsnes still exists. It's a module distributed inside of higan. bsnes is now specific to my SNES emulator. Due to last minute changes to the emulator interface, and missing support in ananke, I wasn't able to include Cydrak's Nintendo DS emulator dasShiny in this build, but I hope to do so in the next release. http://code.google.com/p/higan/downloads/list For both new and experienced users, please read the higan user guide first: http://byuu.org/higan/user-guide In the v091 WIP thread, byuu says: r15->r16: - BS-X MaskROM handling (partial ... need to split bsx/flash away from sfc/chip, restructure code - it requires tagging the base cart markup for now, but it needs to parse the slotted cart markup) - phoenixflags / phoenixlink += -m32 - nall/sort stability - if(input.poll(scancode[activeScancode]) == false) return; - MSU1 / USART need to use interface->path(1) - MSU1 needs to use Markup::Document, not XML::Document - case-insensitive folder listings - remove nall/emulation/system.hpp files (move to ananke) - remove rom/ram id= checks with indexing X have cores ask for manifest.bml (skipped for v092's release, too big a change) - rename compatibility profile to balanced (so people don't assume it has better compatibility than accuracy)
2013-01-14 12:10:20 +00:00
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
for(auto& word : hitachidsp.dataROM) word = 0x000000;
for(auto& word : hitachidsp.dataRAM) word = 0x00;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
hitachidsp.Frequency = root["frequency"].decimal();
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
if(hitachidsp.Frequency == 0) hitachidsp.frequency = 20000000;
hitachidsp.Roms = roms;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
string dataROMName = rom(1)["name"].text();
string dataRAMName = ram(1)["name"].text();
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
interface->loadRequest(ID::HitachiDSPDROM, dataROMName);
if(dataRAMName.empty() == false) {
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
interface->loadRequest(ID::HitachiDSPDRAM, dataRAMName);
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&HitachiDSP::dsp_read, &hitachidsp}, {&HitachiDSP::dsp_write, &hitachidsp});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "rom") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&HitachiDSP::rom_read, &hitachidsp}, {&HitachiDSP::rom_write, &hitachidsp});
parse_markup_map(m, node);
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
if(m.size == 0) m.size = hitachidsp.rom.size();
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
mapping.append(m);
}
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "ram") {
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
Mapping m({&HitachiDSP::ram_read, &hitachidsp}, {&HitachiDSP::ram_write, &hitachidsp});
parse_markup_map(m, node);
if(m.size == 0) m.size = hitachidsp.ram.size();
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_necdsp(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_necdsp = true;
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
for(auto& word : necdsp.programROM) word = 0x000000;
for(auto& word : necdsp.dataROM) word = 0x0000;
for(auto& word : necdsp.dataRAM) word = 0x0000;
Update to v086r08 release. byuu says: Contains the fledgling beginnings of an ARM CPU core, which can execute the first three and a half instructions of the ST-0018. It's a start, I guess.
2012-02-26 07:59:44 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
necdsp.frequency = root["frequency"].decimal();
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
if(necdsp.frequency == 0) necdsp.frequency = 8000000;
necdsp.revision
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
= root["model"].text() == "uPD7725" ? NECDSP::Revision::uPD7725
: root["model"].text() == "uPD96050" ? NECDSP::Revision::uPD96050
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
: NECDSP::Revision::uPD7725;
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
auto rom = root.find("rom");
auto ram = root.find("ram");
string programROMName = rom(0)["name"].text();
string dataROMName = rom(1)["name"].text();
string dataRAMName = ram(0)["name"].text();
Update to v086r08 release. byuu says: Contains the fledgling beginnings of an ARM CPU core, which can execute the first three and a half instructions of the ST-0018. It's a start, I guess.
2012-02-26 07:59:44 +00:00
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
if(necdsp.revision == NECDSP::Revision::uPD7725) {
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
interface->loadRequest(ID::Nec7725DSPPROM, programROMName);
interface->loadRequest(ID::Nec7725DSPDROM, dataROMName);
if(dataRAMName.empty() == false) {
interface->loadRequest(ID::Nec7725DSPRAM, dataRAMName);
memory.append({ID::Nec7725DSPRAM, dataRAMName});
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
if(necdsp.revision == NECDSP::Revision::uPD96050) {
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
interface->loadRequest(ID::Nec96050DSPPROM, programROMName);
interface->loadRequest(ID::Nec96050DSPDROM, dataROMName);
if(dataRAMName.empty() == false) {
interface->loadRequest(ID::Nec96050DSPRAM, dataRAMName);
memory.append({ID::Nec96050DSPRAM, dataRAMName});
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
Update to v088r11 release. byuu says: Changelog: - phoenix has added Window::setModal(bool modal = true); - file dialog is now modal. This allows emulation cores to request data and get it immediately before continuing the loading process - save data is hooked up for most systems, still need to handle subsystem slot saves (Sufami Turbo, basically.) - toggle fullscreen key binding added (Alt+Enter for now. I think F11 is probably better though, Enter is often mapped to game start button.) - video scaling is in (center, scale, stretch), works the same in windowed and fullscreen mode (stretch hides resize window option), all in the settings menu now - enough structure to map all saved paths for the browser and to load BS-X slotted carts, BS-X carts, single Sufami Turbo carts Caveats / Missing: - Super Game Boy input doesn't work yet (due to change in callback binding) - doesn't load secondary Sufami Turbo slot yet - BS-X BIOS isn't show the data pack games to load for some reason (ugh, I hate the shit out of debugging BS-X stuff ...) - need mute audio, sync audio+video toggle, save/load state menu and quick keys, XML mapping information window - need cheat editor and cheat database - need state manager - need to sort subsystems below main systems in load menu (basically just see if media.slot.size() > 0) - need video shaders (will probably leave off filters for the time being ... due to that 24/30-bit thing) - need video adjustments (contrast etc, overscan masks) - need audio adjustments (frequency, latency, resampler, volume, per-system frequency) - need driver selection and input focus policy (driver crash detection would be nice too) - need NSS DIP switch settings (that one will be really fun) - need to save and load window geometry settings - need to hook up controller selection (won't be fun), create a map to hide controllers with no inputs to reassign
2012-05-03 12:36:47 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
Mapping m({&NECDSP::read, &necdsp}, {&NECDSP::write, &necdsp});
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
parse_markup_map(m, node);
mapping.append(m);
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
necdsp.Select = node["select"].decimal();
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "ram") {
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
Mapping m({&NECDSP::ram_read, &necdsp}, {&NECDSP::ram_write, &necdsp});
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
parse_markup_map(m, node);
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_epsonrtc(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_epsonrtc = true;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
string name = root["ram/name"].text();
Update to v089r07 release. byuu says: Not even purify makes compatible images for this WIP. Unless you want to figure it out yourself, I'd suggest waiting for an updated tool before using subsequent WIPs. Changelog: - MSU1 initializes data port + audio track to 0 - MSU1 implements audio track error flag on $2000.d3 - manifest.xml now controls file names for cartridge folders ... mostly Regressions: - Super Game Boy support is broken - Sufami Turbo support is broken So, basically Emulator::Interface() now has: void load(const string &manifest); void save(); The first one will analyze the manifest, and call all the ROM + RAM loadRequest() commands necessary to run the game. The second one will call saveRequest() commands on all writable and non-volatile storage (basically if it's a RAM type and has a filename specified, it gets saved to disk.) save() shrinks the size of Emulator::Interface() by hiding information one is unlikely to care about. It also makes it much easier to save. The core auto-calls this when you unload a game as well. So the only time you ever have to worry about it is if you want to save RAM files mid-game (in case you want to do periodic backups in case of a crash.)
2012-05-26 08:18:42 +00:00
interface->loadRequest(ID::EpsonRTC, name);
memory.append({ID::EpsonRTC, name});
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&EpsonRTC::read, &epsonrtc}, {&EpsonRTC::write, &epsonrtc});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_sharprtc(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_sharprtc = true;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
string name = root["ram/name"].text();
Update to v089r07 release. byuu says: Not even purify makes compatible images for this WIP. Unless you want to figure it out yourself, I'd suggest waiting for an updated tool before using subsequent WIPs. Changelog: - MSU1 initializes data port + audio track to 0 - MSU1 implements audio track error flag on $2000.d3 - manifest.xml now controls file names for cartridge folders ... mostly Regressions: - Super Game Boy support is broken - Sufami Turbo support is broken So, basically Emulator::Interface() now has: void load(const string &manifest); void save(); The first one will analyze the manifest, and call all the ROM + RAM loadRequest() commands necessary to run the game. The second one will call saveRequest() commands on all writable and non-volatile storage (basically if it's a RAM type and has a filename specified, it gets saved to disk.) save() shrinks the size of Emulator::Interface() by hiding information one is unlikely to care about. It also makes it much easier to save. The core auto-calls this when you unload a game as well. So the only time you ever have to worry about it is if you want to save RAM files mid-game (in case you want to do periodic backups in case of a crash.)
2012-05-26 08:18:42 +00:00
interface->loadRequest(ID::SharpRTC, name);
memory.append({ID::SharpRTC, name});
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SharpRTC::read, &sharprtc}, {&SharpRTC::write, &sharprtc});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_spc7110(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
has_spc7110 = true;
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
auto rom = root.find("rom");
auto ram = root.find("ram");
parse_markup_memory(spc7110.prom, rom(0), ID::SPC7110PROM, false);
parse_markup_memory(spc7110.drom, rom(1), ID::SPC7110DROM, false);
parse_markup_memory(spc7110.ram, ram(0), ID::SPC7110RAM, true);
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SPC7110::read, &spc7110}, {&SPC7110::write, &spc7110});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "rom") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SPC7110::mcurom_read, &spc7110}, {&SPC7110::mcurom_write, &spc7110});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "ram") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SPC7110::mcuram_read, &spc7110}, {&SPC7110::mcuram_write, &spc7110});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_sdd1(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r06 release. byuu says: Changelog: - renamed SRTC -> SharpRTC - renamed RTC4513 -> EpsonRTC (consistent with DSP naming schema) - full emulation of invalid BCD values for EpsonRTC - fixed EpsonRTC IRQ mask Remaining SPC7110 tasks: - RTC: test 30-second adjust with all values from 00-7f - RTC: hold is supposed to tick the clock one second after being released? - RTC: wait times are too long (need to use >32KHz oscillation to simulate it properly) - Data Port: test $4818 more thoroughly (not too important) - Decompression: test $480c more thoroughly (very important) - Decompression: perform some tests on DMA transferring data, especially with $4807 set Write-offs, at least for now: - Decompression: emulation of the crash/glitch behavior seen on the real chip when fed invalid data - Decompression: I can find no use of $4808 - ALU: Booth cycles for MUL/DIV (this could actually be rather important if the game reads simpler values quickly [some shoddy games did this with the CPU ALU]) - RTC: delay after hold release for $4841 accesses - RTC: 125uS delay after 30-second adjust that will screw with registers in odd ways if your read or write too soon - RTC: psychotic behavior of reading too early returning port address - 1
2012-05-22 12:10:00 +00:00
has_sdd1 = true;
Update to v089r05 release. byuu says: I split the RTC-4513 code from the SPC7110 code (and obviously in the XML mapping as well), since they are separate chips on the FEoEZ PCB. In this way, you can use just the RTC-4513 in homebrew now if you want. It's a bit nicer than the Sharp RTC from Dai Kaijuu Monogatari II. This was needed anyway, it has an internal oscillator that's not divisible by the SNES clock used by the SPC7110; and both the RTC and decompression code need to be running their own threads anyway. In the process, I rewrote the way variables are stored to use named integers rather than a block of memory. Makes the code a lot easier on the eyes, and more importantly, will make emulating bad BCD values a whole lot easier.
2012-05-21 10:56:48 +00:00
Update to v094r18 release. byuu says: Okay yeah, lots of SNES coprocessor games were horribly broken. They should be fixed now with the below changes: Old syntax: auto programROM = root["rom[0]/name"].text(); auto dataROM = root["rom[1]/name"].text(); load_memory(root["ram[0]"]); New syntax: auto rom = root.find("rom"); auto ram = root.find("ram"); auto programROM = rom(0)["name"].text(); auto dataROM = rom(1)["name"].text(); load_memory(ram(0)); Since I'm now relying on the XShm driver, which is multi-threaded, I'm now compiling higan with -fopenmp. On FreeBSD, this requires linking with -Wl,-rpath=/usr/local/lib -Wl,-rpath=/usr/local/lib/gcc49 to get the right version of GOMP. This gives a pretty nice speed boost for XShm, I go from around 101fps to 111fps at 4x scale on the accuracy profile. The combination of inlining the accuracy-PPU and parallelizing the XShm renderer about evenly compensates now for the ~20% CPU overclock I gave up a while ago. The WIP also has some other niceties from the newer version of nall. Most noticeably, cheat code database searching is now instantaneous. No more 3-second stall.
2015-05-16 07:37:13 +00:00
auto rom = root.find("rom");
auto ram = root.find("ram");
parse_markup_memory(sdd1.rom, rom(0), ID::SDD1ROM, false);
parse_markup_memory(sdd1.ram, ram(0), ID::SDD1RAM, true);
Update to v089r14 release. byuu says: Changelog: - NSS emulation improvement (DIP is 8-bits, not 16-bits; can be remapped via XML now like all the other chips) - SA-1 memory map improvements (IRAM and BWRAM can be saved; ROM, IRAM and BWRAM are separate from Cartridge::ROM, RAM; no MCU) - S-DD1 memory map improvements (ROM, RAM inside mapping; no MCU) - SPC7110 memory map improvements (ROM, RAM inside mapping; no MCU; not finished yet [have to handle 8mbit expansion somehow now) I have tried multiple times now to get the SuperFX core to use internal ROM and RAM (separate from Cartridge::ROM, RAM) to no avail. Not sure what the hell is going on there. Trace logs of 430MB are not enticing ... So right now: SuperFX, SPC7110 and BS-X cheat by mapping stuff to Cartridge::ROM, RAM still. They need to not do that.
2012-07-08 02:57:34 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SDD1::read, &sdd1}, {&SDD1::write, &sdd1});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "rom") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SDD1::mcurom_read, &sdd1}, {&SDD1::mcurom_write, &sdd1});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(node["id"].text() == "ram") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&SDD1::mcuram_read, &sdd1}, {&SDD1::mcuram_write, &sdd1});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v089r14 release. byuu says: Changelog: - NSS emulation improvement (DIP is 8-bits, not 16-bits; can be remapped via XML now like all the other chips) - SA-1 memory map improvements (IRAM and BWRAM can be saved; ROM, IRAM and BWRAM are separate from Cartridge::ROM, RAM; no MCU) - S-DD1 memory map improvements (ROM, RAM inside mapping; no MCU) - SPC7110 memory map improvements (ROM, RAM inside mapping; no MCU; not finished yet [have to handle 8mbit expansion somehow now) I have tried multiple times now to get the SuperFX core to use internal ROM and RAM (separate from Cartridge::ROM, RAM) to no avail. Not sure what the hell is going on there. Trace logs of 430MB are not enticing ... So right now: SuperFX, SPC7110 and BS-X cheat by mapping stuff to Cartridge::ROM, RAM still. They need to not do that.
2012-07-08 02:57:34 +00:00
}
Update to v089r05 release. byuu says: I split the RTC-4513 code from the SPC7110 code (and obviously in the XML mapping as well), since they are separate chips on the FEoEZ PCB. In this way, you can use just the RTC-4513 in homebrew now if you want. It's a bit nicer than the Sharp RTC from Dai Kaijuu Monogatari II. This was needed anyway, it has an internal oscillator that's not divisible by the SNES clock used by the SPC7110; and both the RTC and decompression code need to be running their own threads anyway. In the process, I rewrote the way variables are stored to use named integers rather than a block of memory. Makes the code a lot easier on the eyes, and more importantly, will make emulating bad BCD values a whole lot easier.
2012-05-21 10:56:48 +00:00
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_obc1(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
has_obc1 = true;
Update to v089r15 release. byuu says: Changelog: - SuperFX has its own ROM and RAM - Cx4 has its own ROM - SPC7110 has its own ProgramROM, DataROM and RAM - OBC1 has its own RAM - BsxCartridge has its own ROM, RAM and PSRAM - mapping changes to accommodate the above
2012-07-09 11:40:23 +00:00
parse_markup_memory(obc1.ram, root["ram"], ID::OBC1RAM, true);
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&OBC1::read, &obc1}, {&OBC1::write, &obc1});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Update to v091r09 release. [r07 and r08 were not posted to the WIP thread. -Ed.] byuu says: I'd appreciate it if you guys wouldn't mind testing out the database functionality. Save this file as database.bml (remove the date) inside ~/.config/higan/Super Famicom.sfc/ or %APPDATA%/higan/Super Famicom.sfc/ http://byuu.org/snes/database/database_2012-10-21.bml Now load any of the 20 games in the database from the file dialog. They need to be named *.sfc, have no copier header, and have firmware appended (for Mario Kart only so far.) If anyone actually does test it, please let me know how it goes for you and what you think. Note that future versions of higan will have the database.bml file included with the release.
2012-10-22 22:45:18 +00:00
void Cartridge::parse_markup_msu1(Markup::Node root) {
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
if(!root) return;
Update to v089r09 release. byuu says: Changelog: - SPC7110 data port emulation greatly improved - SPC7110 $480b.d1 emulated (but $4805-4806 does not work right for mode 2 decompression yet) - MSU1 audio output will be muted when the S-DSP FLG ($6c).d6 (mute) flag is set - MSU1 will read filenames from manifest now (defaults to msu1.rom and track-#.pcm if missing ... for now) - bugfixes with MSU1 load state and track seek (and $4804 was wrapping into $4805 to change the track#) - Link coprocessor removed (it was meant for ST018 HLE, which never happened) Notes for things I forgot but need to address: - $4813 needs to be uint7 for the set_data_offset() to not allow reading A23 as set ever (or we can mask) - AbsoluteInput when window doesn't have focus should return -32768, not 0 - need to support input ID lists that aren't linear (0-7), but arbitrary (0,1,6,7 or whatever)
2012-05-29 12:20:46 +00:00
has_msu1 = true;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
Update to v094r17 release. byuu says: This updates higan to use the new Markup::Node changes. This is a really big change, and one slight typo anywhere could break certain classes of games from playing. I don't have ananke hooked up again yet, so I don't have the ability to test this much. If anyone with some v094 game folders wouldn't mind testing, I'd help out a great deal. I'm most concerned about testing one of each SNES special chip game. Most notably, systems like the SA-1, HitachiDSP and NEC-DSP were using the fancier lookups, eg node["rom[0]/name"], which I had to convert to a rather ugly node["rom"].at(0)["name"], which I'm fairly confident won't work. I'm going to blame that on the fumes from the shelves I just stained >.> Might work with node.find("rom[0]/name")(0) though ...? But so ugly ... ugh. That aside, this WIP adds the accuracy-PPU inlining, so the accuracy profile should run around 7.5% faster than before.
2015-05-02 13:05:46 +00:00
for(auto node : root.find("map")) {
if(node["id"].text() == "io") {
Update to v089r17 release. byuu says: This implements the spec from the XML part 3 thread: http://board.byuu.org/viewtopic.php?f=16&t=2998 It's also propagated the changes to nall and purify, so you can test this one. This is basically it, after years of effort I feel I finally have a fully consistent and logical XML board format. The only things left to change will be: modifications if emulation turns out to be incorrect (eg we missed some MMIO mirrors, or mirrored too much), and new additions. And of course, I'm giving it a bit of time for good arguments against the format. Other than that, this release removes linear_vector and pointer_vector, as vector is better than linear_vector and I've never used pointer_vector. vector also gets move(), which is a way to use move-semantics across types. It lets you steal the underlying memory pool, effectively destroying the vector without a copy. This works really nicely with the move for read() functions to return vector<uint8> instead of taking (uint8_t*&, unsigned&) parameters.
2012-07-15 13:02:27 +00:00
Mapping m({&MSU1::mmio_read, &msu1}, {&MSU1::mmio_write, &msu1});
parse_markup_map(m, node);
mapping.append(m);
}
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
}
Cartridge::Mapping::Mapping() {
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
size = base = mask = 0;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
Cartridge::Mapping::Mapping(SuperFamicom::Memory& memory) {
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
reader = {&SuperFamicom::Memory::read, &memory};
writer = {&SuperFamicom::Memory::write, &memory};
size = base = mask = 0;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
Update to v092r09 release. byuu says: This will be another massive diff from the previous version. All of higan was updated to use the new foo& bar syntax, and I also updated switch statements to be consistent as well (but not in the disassemblers, was starting to get an RSI just from what I already did.) phoenix/{windows, cocoa, qt} need to be updated to use "string foo" instead of "const string& foo", and after that, the major diffs should be finished. This archive is the first time I'm posting my copy-on-write, size+capacity nall::string class, so any feedback on that is welcome as well.
2013-05-05 09:21:30 +00:00
Cartridge::Mapping::Mapping(const function<uint8 (unsigned)>& reader, const function<void (unsigned, uint8)>& writer) {
Update to v091r05 release. [No prior releases were posted to the WIP thread. -Ed.] byuu says: Super Famicom mapping system has been reworked as discussed with the mask= changes. offset becomes base, mode is gone. Also added support for comma-separated fields in the address fields, to reduce the number of map lines needed. <?xml version="1.0" encoding="UTF-8"?> <cartridge region="NTSC"> <superfx revision="2"> <rom name="program.rom" size="0x200000"/> <ram name="save.rwm" size="0x8000"/> <map id="io" address="00-3f,80-bf:3000-32ff"/> <map id="rom" address="00-3f:8000-ffff" mask="0x8000"/> <map id="rom" address="40-5f:0000-ffff"/> <map id="ram" address="00-3f,80-bf:6000-7fff" size="0x2000"/> <map id="ram" address="70-71:0000-ffff"/> </superfx> </cartridge> Or in BML: cartridge region=NTSC superfx revision=2 rom name=program.rom size=0x200000 ram name=save.rwm size=0x8000 map id=io address=00-3f,80-bf:3000-32ff map id=rom address=00-3f:8000-ffff mask=0x8000 map id=rom address=40-5f:0000-ffff map id=ram address=00-3f,80-bf:6000-7fff size=0x2000 map id=ram address=70-71:0000-ffff As a result of the changes, old mappings will no longer work. The above XML example will run Super Mario World 2: Yoshi's Island. Otherwise, you'll have to write your own. All that's left now is to work some sort of database mapping system in, so I can start dumping carts en masse. The NES changes that FitzRoy asked for are mostly in as well. Also, part of the reason I haven't released a WIP ... but fuck it, I'm not going to wait forever to post a new WIP. I've added a skeleton driver to emulate Campus Challenge '92 and Powerfest '94. There's no actual emulation, except for the stuff I can glean from looking at the pictures of the board. It has a DSP-1 (so SR/DR registers), four ROMs that map in and out, RAM, etc. I've also added preliminary mapping to upload high scores to a website, but obviously I need the ROMs first.
2012-10-09 08:25:32 +00:00
this->reader = reader;
this->writer = writer;
size = base = mask = 0;
Update to v082r29 release. byuu says: I doubt anyone is going to like these changes, but oh well. The base height output for NES+SNES is now always 256x240. The Enable Overscan option blanks out borders around the screen. This eliminates the need for an overscan software filter. For NES, it's 16px from the top and bottom, and 8px from the left and right. Anything less and you get scrolling artifacts in countless games. For the SNES, it's only 16px from the top and bottom. Main point is that most NTSC SNES games are 224-height games, so you'll have black borders. Oh well, hack the source if you want. Game Boy overscan option does nothing. Everything except for the cheats.xml file now uses BML markup. I need to write a converter for cheats.xml still. Cut the SNES board parsing code in half, 30KB->16KB. Much cleaner now. Took the opportunity to fix a mistake I made back with the XML spec: all numbers are integers, but can be prefixed with 0x to become hexadecimal. Before, offset/size values defaulted to hex-mode even without a prefix, unlike frequency/etc values. The XML shaders have gone in their own direction anyway, with most being multi-pass and incompatible with bsnes. So that said, please don't extend the BML functionality from your end. But f eel free to add to the XML spec, since other emulators now use that as well. And don't misunderstand, I love the work that's being done there. It's pretty awesome to see multi-pass shader capabilities, and the RAM watching stuff is just amazing. If there are any really awesome single-pass shaders that people would like, I can convert it from XML and include it with future releases. On that topic, I removed the watercolor/hdr-tv ones from the binary packages (still in the source archive) ... they are neat, but not very useful for actual gaming. If we had more than one, I'd remove the Direct3D sepia one. Not going to use shaders from a certain bipolar manic, because I'd never hear the end of it if I did :/ Oh, one change I think people will like: MSU1 no longer requires a memory map specification, so MSU1 authors won't have to keep updating to my newer revisions of board markups. Basically, if there's not a board with an msu1 section, it'll check if "gamename.msu" exists. If it does, MSU1 gets mapped to 00-3f,80-bf:2000-2007. If all you want is music, make a blank, zero-byte gamename.msu file.
2011-10-04 11:55:39 +00:00
}
#endif