bsnes/higan/fc/cartridge/board/board.cpp

204 lines
7.3 KiB
C++
Raw Normal View History

#include "bandai-fcg.cpp"
#include "konami-vrc1.cpp"
#include "konami-vrc2.cpp"
#include "konami-vrc3.cpp"
#include "konami-vrc4.cpp"
#include "konami-vrc6.cpp"
#include "konami-vrc7.cpp"
#include "nes-axrom.cpp"
#include "nes-bnrom.cpp"
#include "nes-cnrom.cpp"
Update to v082r31 release. byuu says: Enable Overscan->Mask Overscan [best I'm doing] Video settings -> Overscan mask: (horizontal, vertical: 0-16 on each side) [only works on NES+SNES] BPS patching works for NES+SNES+GB; note that long-term I want BPS to only patch headerless PRG+CHR files, but we'll need a database / completed board mapping system first. MMC1 splits the board/chip markups a bit better. My attempts to emulate the extra CHR bits per hardware fail repeatedly. Docs do not explain how it works at all. Emulated enough of the MMC5 to play Castlevania 3. The MMC5 is easily the most complicated mapper the NES has to offer, and of course, has the most pitifully vague and difficult documentation of any mapper around. It seems the only way anyone is able to emulate this chip is empirically. Everyone else apparently hooks the MMC5 right into the PPU core, which I of course cannot do. So I had to come up with my own (probably wrong) way to synchronize the PPU simply by observing CHR bus accesses. I must say, I over-estimated how well fleshed out the NES hardware documentation was. Shit hits the fan right after MMC3. It's miles beyond the GB scene, but I find myself wanting for someone with the technical writing ability of anomie. I can't find anything at all on how we're supposed to support the $2007 port reads/writes without it extra-clocking the PPU's bus, which could throw off mapper timing. Absolutely nothing at all on the subject anywhere, something everybody is required to do for all cycle-based emulators and ... nada. Anyway, I'd like to refine the MMC5 a bit, getting Just Breed playable even without sound would be really nice (it's a fun game.) Then we need to get libsnes building again (ugh, getting worn out in backporting changes to it.) Once v083 is public, we can start discussing a new API for multiple emulators.
2011-10-06 09:53:16 +00:00
#include "nes-exrom.cpp"
#include "nes-fxrom.cpp"
#include "nes-gxrom.cpp"
#include "nes-hkrom.cpp"
#include "nes-nrom.cpp"
#include "nes-pxrom.cpp"
#include "nes-sxrom.cpp"
#include "nes-txrom.cpp"
#include "nes-uxrom.cpp"
#include "sunsoft-5b.cpp"
Board::Board(Markup::Node& document) {
cartridge.board = this;
Update to higan and icarus v095r15 release. r13 and r14 weren't posted as individual releases, but their changelogs were posted. byuu says about r13: I'm not going to be posting WIPs for r13 and above for a while. The reason is that I'm working on the major manifest overhaul I've discussed previously on the icarus subforum. I'm recreating my boards database from scratch using the map files and the new map analyzer. The only games that will load are ones I've created board definitions for, and updated sfc/cartridge/markup.cpp to parse. Once I've finished all the boards, then I'll update the heuristics. Then finally, I'll sync the syntax changes over to the fc, gb, gba cores. Once that's done, I'll start posting WIPs again, along with a new build of icarus. But I'll still post changelogs as I work through things. Changelog (r13): - preservation: created new database-builder tool (merges region-specific databases with boards) - icarus: support new, external database format (~/.config/icarus/Database/(Super Famicom.bml, ...) - added 1A3B-(10,11,12); 1A3B-20 byuu says about r14: r14 work: I successfully created mappings for every board used in the US set. I also updated icarus' heuristics to use the new mappings, and created ones there for the boards that are only in the JP set. Then I patched icarus to support pulling games out of the database when it's used on a game folder to generate a manifest file. Then I updated a lot of code in higan/sfc to support the new mapping syntax. sfc/cartridge/markup.cpp is about half the size it used to be with the new mappings, and I was able to kill off both map/id and map/select entirely. Then I updated all four emulated systems (and both subsystems) to use "board" as the root node, and harmonized their syntax (made them all more consistent with each other.) Then I added a manifest viewer to the tools window+menu. It's kind of an advanced user feature, but oh well. No reason to coddle people when the feature is very useful for developers. The viewer will show all manifests in order when you load multi-cart games as well. Still not going to call any syntax 100% done right now, but thankfully with the new manifest-free folders, nobody will have to do anything to use the new format. Just download the new version and go. The Super Famicom Event stuff is currently broken (CC92/PF94 boards). That's gonna be fun to support. byuu says about r15: EDIT: small bug in icarus with heuristics. Edit core/super-famicom.cpp line 27: if(/*auto*/ markup = cartridge.markup) { Gotta remove that "auto" so that it returns valid markup. Resolved the final concerns I had with the new manifest format. Right now there are two things that are definitely broken: MCC (BS-X Town cart) and Event (CC '92 and PF'94). And there are a few things that are untested: SPC7110, EpsonRTC, SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
2015-12-19 08:52:34 +00:00
auto board = document["board"];
Update to higan and icarus v095r15 release. r13 and r14 weren't posted as individual releases, but their changelogs were posted. byuu says about r13: I'm not going to be posting WIPs for r13 and above for a while. The reason is that I'm working on the major manifest overhaul I've discussed previously on the icarus subforum. I'm recreating my boards database from scratch using the map files and the new map analyzer. The only games that will load are ones I've created board definitions for, and updated sfc/cartridge/markup.cpp to parse. Once I've finished all the boards, then I'll update the heuristics. Then finally, I'll sync the syntax changes over to the fc, gb, gba cores. Once that's done, I'll start posting WIPs again, along with a new build of icarus. But I'll still post changelogs as I work through things. Changelog (r13): - preservation: created new database-builder tool (merges region-specific databases with boards) - icarus: support new, external database format (~/.config/icarus/Database/(Super Famicom.bml, ...) - added 1A3B-(10,11,12); 1A3B-20 byuu says about r14: r14 work: I successfully created mappings for every board used in the US set. I also updated icarus' heuristics to use the new mappings, and created ones there for the boards that are only in the JP set. Then I patched icarus to support pulling games out of the database when it's used on a game folder to generate a manifest file. Then I updated a lot of code in higan/sfc to support the new mapping syntax. sfc/cartridge/markup.cpp is about half the size it used to be with the new mappings, and I was able to kill off both map/id and map/select entirely. Then I updated all four emulated systems (and both subsystems) to use "board" as the root node, and harmonized their syntax (made them all more consistent with each other.) Then I added a manifest viewer to the tools window+menu. It's kind of an advanced user feature, but oh well. No reason to coddle people when the feature is very useful for developers. The viewer will show all manifests in order when you load multi-cart games as well. Still not going to call any syntax 100% done right now, but thankfully with the new manifest-free folders, nobody will have to do anything to use the new format. Just download the new version and go. The Super Famicom Event stuff is currently broken (CC92/PF94 boards). That's gonna be fun to support. byuu says about r15: EDIT: small bug in icarus with heuristics. Edit core/super-famicom.cpp line 27: if(/*auto*/ markup = cartridge.markup) { Gotta remove that "auto" so that it returns valid markup. Resolved the final concerns I had with the new manifest format. Right now there are two things that are definitely broken: MCC (BS-X Town cart) and Event (CC '92 and PF'94). And there are a few things that are untested: SPC7110, EpsonRTC, SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
2015-12-19 08:52:34 +00:00
information.type = board["id"].text();
information.battery = (bool)board["prg/ram/name"];
Update to higan and icarus v095r15 release. r13 and r14 weren't posted as individual releases, but their changelogs were posted. byuu says about r13: I'm not going to be posting WIPs for r13 and above for a while. The reason is that I'm working on the major manifest overhaul I've discussed previously on the icarus subforum. I'm recreating my boards database from scratch using the map files and the new map analyzer. The only games that will load are ones I've created board definitions for, and updated sfc/cartridge/markup.cpp to parse. Once I've finished all the boards, then I'll update the heuristics. Then finally, I'll sync the syntax changes over to the fc, gb, gba cores. Once that's done, I'll start posting WIPs again, along with a new build of icarus. But I'll still post changelogs as I work through things. Changelog (r13): - preservation: created new database-builder tool (merges region-specific databases with boards) - icarus: support new, external database format (~/.config/icarus/Database/(Super Famicom.bml, ...) - added 1A3B-(10,11,12); 1A3B-20 byuu says about r14: r14 work: I successfully created mappings for every board used in the US set. I also updated icarus' heuristics to use the new mappings, and created ones there for the boards that are only in the JP set. Then I patched icarus to support pulling games out of the database when it's used on a game folder to generate a manifest file. Then I updated a lot of code in higan/sfc to support the new mapping syntax. sfc/cartridge/markup.cpp is about half the size it used to be with the new mappings, and I was able to kill off both map/id and map/select entirely. Then I updated all four emulated systems (and both subsystems) to use "board" as the root node, and harmonized their syntax (made them all more consistent with each other.) Then I added a manifest viewer to the tools window+menu. It's kind of an advanced user feature, but oh well. No reason to coddle people when the feature is very useful for developers. The viewer will show all manifests in order when you load multi-cart games as well. Still not going to call any syntax 100% done right now, but thankfully with the new manifest-free folders, nobody will have to do anything to use the new format. Just download the new version and go. The Super Famicom Event stuff is currently broken (CC92/PF94 boards). That's gonna be fun to support. byuu says about r15: EDIT: small bug in icarus with heuristics. Edit core/super-famicom.cpp line 27: if(/*auto*/ markup = cartridge.markup) { Gotta remove that "auto" so that it returns valid markup. Resolved the final concerns I had with the new manifest format. Right now there are two things that are definitely broken: MCC (BS-X Town cart) and Event (CC '92 and PF'94). And there are a few things that are untested: SPC7110, EpsonRTC, SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
2015-12-19 08:52:34 +00:00
auto prom = board["prg/rom"];
auto pram = board["prg/ram"];
auto crom = board["chr/rom"];
auto cram = board["chr/ram"];
prgrom.size = prom["size"].natural();
prgram.size = pram["size"].natural();
chrrom.size = crom["size"].natural();
chrram.size = cram["size"].natural();
if(prgrom.size) prgrom.data = new uint8[prgrom.size]();
if(prgram.size) prgram.data = new uint8[prgram.size]();
if(chrrom.size) chrrom.data = new uint8[chrrom.size]();
if(chrram.size) chrram.data = new uint8[chrram.size]();
if(auto name = prom["name"].text()) interface->loadRequest(ID::ProgramROM, name, true);
if(auto name = pram["name"].text()) interface->loadRequest(ID::ProgramRAM, name, false);
if(auto name = crom["name"].text()) interface->loadRequest(ID::CharacterROM, name, true);
if(auto name = cram["name"].text()) interface->loadRequest(ID::CharacterRAM, name, false);
if(auto name = pram["name"].text()) Famicom::cartridge.memory.append({ID::ProgramRAM, name});
if(auto name = cram["name"].text()) Famicom::cartridge.memory.append({ID::CharacterRAM, name});
prgram.writable = true;
chrram.writable = true;
}
auto Board::Memory::read(uint addr) const -> uint8 {
Update to v082r31 release. byuu says: Enable Overscan->Mask Overscan [best I'm doing] Video settings -> Overscan mask: (horizontal, vertical: 0-16 on each side) [only works on NES+SNES] BPS patching works for NES+SNES+GB; note that long-term I want BPS to only patch headerless PRG+CHR files, but we'll need a database / completed board mapping system first. MMC1 splits the board/chip markups a bit better. My attempts to emulate the extra CHR bits per hardware fail repeatedly. Docs do not explain how it works at all. Emulated enough of the MMC5 to play Castlevania 3. The MMC5 is easily the most complicated mapper the NES has to offer, and of course, has the most pitifully vague and difficult documentation of any mapper around. It seems the only way anyone is able to emulate this chip is empirically. Everyone else apparently hooks the MMC5 right into the PPU core, which I of course cannot do. So I had to come up with my own (probably wrong) way to synchronize the PPU simply by observing CHR bus accesses. I must say, I over-estimated how well fleshed out the NES hardware documentation was. Shit hits the fan right after MMC3. It's miles beyond the GB scene, but I find myself wanting for someone with the technical writing ability of anomie. I can't find anything at all on how we're supposed to support the $2007 port reads/writes without it extra-clocking the PPU's bus, which could throw off mapper timing. Absolutely nothing at all on the subject anywhere, something everybody is required to do for all cycle-based emulators and ... nada. Anyway, I'd like to refine the MMC5 a bit, getting Just Breed playable even without sound would be really nice (it's a fun game.) Then we need to get libsnes building again (ugh, getting worn out in backporting changes to it.) Once v083 is public, we can start discussing a new API for multiple emulators.
2011-10-06 09:53:16 +00:00
return data[mirror(addr, size)];
}
auto Board::Memory::write(uint addr, uint8 byte) -> void {
if(writable) data[mirror(addr, size)] = byte;
Update to v082r31 release. byuu says: Enable Overscan->Mask Overscan [best I'm doing] Video settings -> Overscan mask: (horizontal, vertical: 0-16 on each side) [only works on NES+SNES] BPS patching works for NES+SNES+GB; note that long-term I want BPS to only patch headerless PRG+CHR files, but we'll need a database / completed board mapping system first. MMC1 splits the board/chip markups a bit better. My attempts to emulate the extra CHR bits per hardware fail repeatedly. Docs do not explain how it works at all. Emulated enough of the MMC5 to play Castlevania 3. The MMC5 is easily the most complicated mapper the NES has to offer, and of course, has the most pitifully vague and difficult documentation of any mapper around. It seems the only way anyone is able to emulate this chip is empirically. Everyone else apparently hooks the MMC5 right into the PPU core, which I of course cannot do. So I had to come up with my own (probably wrong) way to synchronize the PPU simply by observing CHR bus accesses. I must say, I over-estimated how well fleshed out the NES hardware documentation was. Shit hits the fan right after MMC3. It's miles beyond the GB scene, but I find myself wanting for someone with the technical writing ability of anomie. I can't find anything at all on how we're supposed to support the $2007 port reads/writes without it extra-clocking the PPU's bus, which could throw off mapper timing. Absolutely nothing at all on the subject anywhere, something everybody is required to do for all cycle-based emulators and ... nada. Anyway, I'd like to refine the MMC5 a bit, getting Just Breed playable even without sound would be really nice (it's a fun game.) Then we need to get libsnes building again (ugh, getting worn out in backporting changes to it.) Once v083 is public, we can start discussing a new API for multiple emulators.
2011-10-06 09:53:16 +00:00
}
auto Board::mirror(uint addr, uint size) -> uint {
uint base = 0;
if(size) {
uint mask = 1 << 23;
while(addr >= size) {
while(!(addr & mask)) mask >>= 1;
addr -= mask;
if(size > mask) {
size -= mask;
base += mask;
}
mask >>= 1;
}
base += addr;
}
return base;
}
auto Board::main() -> void {
cartridge.clock += 12 * 4095;
tick();
}
auto Board::tick() -> void {
cartridge.clock += 12;
if(cartridge.clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread);
}
auto Board::chr_read(uint addr) -> uint8 {
if(chrram.size) return chrram.data[mirror(addr, chrram.size)];
if(chrrom.size) return chrrom.data[mirror(addr, chrrom.size)];
return 0u;
}
auto Board::chr_write(uint addr, uint8 data) -> void {
if(chrram.size) chrram.data[mirror(addr, chrram.size)] = data;
}
auto Board::power() -> void {
}
auto Board::reset() -> void {
}
auto Board::serialize(serializer& s) -> void {
if(prgram.size) s.array(prgram.data, prgram.size);
if(chrram.size) s.array(chrram.data, chrram.size);
}
auto Board::load(string manifest) -> Board* {
auto document = BML::unserialize(manifest);
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
cartridge.information.title = document["information/title"].text();
2013-01-14 12:10:20 +00:00
Update to higan and icarus v095r15 release. r13 and r14 weren't posted as individual releases, but their changelogs were posted. byuu says about r13: I'm not going to be posting WIPs for r13 and above for a while. The reason is that I'm working on the major manifest overhaul I've discussed previously on the icarus subforum. I'm recreating my boards database from scratch using the map files and the new map analyzer. The only games that will load are ones I've created board definitions for, and updated sfc/cartridge/markup.cpp to parse. Once I've finished all the boards, then I'll update the heuristics. Then finally, I'll sync the syntax changes over to the fc, gb, gba cores. Once that's done, I'll start posting WIPs again, along with a new build of icarus. But I'll still post changelogs as I work through things. Changelog (r13): - preservation: created new database-builder tool (merges region-specific databases with boards) - icarus: support new, external database format (~/.config/icarus/Database/(Super Famicom.bml, ...) - added 1A3B-(10,11,12); 1A3B-20 byuu says about r14: r14 work: I successfully created mappings for every board used in the US set. I also updated icarus' heuristics to use the new mappings, and created ones there for the boards that are only in the JP set. Then I patched icarus to support pulling games out of the database when it's used on a game folder to generate a manifest file. Then I updated a lot of code in higan/sfc to support the new mapping syntax. sfc/cartridge/markup.cpp is about half the size it used to be with the new mappings, and I was able to kill off both map/id and map/select entirely. Then I updated all four emulated systems (and both subsystems) to use "board" as the root node, and harmonized their syntax (made them all more consistent with each other.) Then I added a manifest viewer to the tools window+menu. It's kind of an advanced user feature, but oh well. No reason to coddle people when the feature is very useful for developers. The viewer will show all manifests in order when you load multi-cart games as well. Still not going to call any syntax 100% done right now, but thankfully with the new manifest-free folders, nobody will have to do anything to use the new format. Just download the new version and go. The Super Famicom Event stuff is currently broken (CC92/PF94 boards). That's gonna be fun to support. byuu says about r15: EDIT: small bug in icarus with heuristics. Edit core/super-famicom.cpp line 27: if(/*auto*/ markup = cartridge.markup) { Gotta remove that "auto" so that it returns valid markup. Resolved the final concerns I had with the new manifest format. Right now there are two things that are definitely broken: MCC (BS-X Town cart) and Event (CC '92 and PF'94). And there are a few things that are untested: SPC7110, EpsonRTC, SharpRTC, SDD1+RAM, SufamiTurbo, BS-X slotted carts.
2015-12-19 08:52:34 +00:00
string type = document["board/id"].text();
if(type == "BANDAI-FCG" ) return new BandaiFCG(document);
if(type == "KONAMI-VRC-1") return new KonamiVRC1(document);
if(type == "KONAMI-VRC-2") return new KonamiVRC2(document);
if(type == "KONAMI-VRC-3") return new KonamiVRC3(document);
if(type == "KONAMI-VRC-4") return new KonamiVRC4(document);
if(type == "KONAMI-VRC-6") return new KonamiVRC6(document);
if(type == "KONAMI-VRC-7") return new KonamiVRC7(document);
if(type == "NES-AMROM" ) return new NES_AxROM(document);
if(type == "NES-ANROM" ) return new NES_AxROM(document);
if(type == "NES-AN1ROM" ) return new NES_AxROM(document);
if(type == "NES-AOROM" ) return new NES_AxROM(document);
if(type == "NES-BNROM" ) return new NES_BNROM(document);
if(type == "NES-CNROM" ) return new NES_CNROM(document);
if(type == "NES-EKROM" ) return new NES_ExROM(document);
if(type == "NES-ELROM" ) return new NES_ExROM(document);
if(type == "NES-ETROM" ) return new NES_ExROM(document);
if(type == "NES-EWROM" ) return new NES_ExROM(document);
Update to v082r31 release. byuu says: Enable Overscan->Mask Overscan [best I'm doing] Video settings -> Overscan mask: (horizontal, vertical: 0-16 on each side) [only works on NES+SNES] BPS patching works for NES+SNES+GB; note that long-term I want BPS to only patch headerless PRG+CHR files, but we'll need a database / completed board mapping system first. MMC1 splits the board/chip markups a bit better. My attempts to emulate the extra CHR bits per hardware fail repeatedly. Docs do not explain how it works at all. Emulated enough of the MMC5 to play Castlevania 3. The MMC5 is easily the most complicated mapper the NES has to offer, and of course, has the most pitifully vague and difficult documentation of any mapper around. It seems the only way anyone is able to emulate this chip is empirically. Everyone else apparently hooks the MMC5 right into the PPU core, which I of course cannot do. So I had to come up with my own (probably wrong) way to synchronize the PPU simply by observing CHR bus accesses. I must say, I over-estimated how well fleshed out the NES hardware documentation was. Shit hits the fan right after MMC3. It's miles beyond the GB scene, but I find myself wanting for someone with the technical writing ability of anomie. I can't find anything at all on how we're supposed to support the $2007 port reads/writes without it extra-clocking the PPU's bus, which could throw off mapper timing. Absolutely nothing at all on the subject anywhere, something everybody is required to do for all cycle-based emulators and ... nada. Anyway, I'd like to refine the MMC5 a bit, getting Just Breed playable even without sound would be really nice (it's a fun game.) Then we need to get libsnes building again (ugh, getting worn out in backporting changes to it.) Once v083 is public, we can start discussing a new API for multiple emulators.
2011-10-06 09:53:16 +00:00
if(type == "NES-FJROM" ) return new NES_FxROM(document);
if(type == "NES-FKROM" ) return new NES_FxROM(document);
if(type == "NES-GNROM" ) return new NES_GxROM(document);
if(type == "NES-MHROM" ) return new NES_GxROM(document);
if(type == "NES-HKROM" ) return new NES_HKROM(document);
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(type == "NES-NROM" ) return new NES_NROM(document);
if(type == "NES-NROM-128") return new NES_NROM(document);
if(type == "NES-NROM-256") return new NES_NROM(document);
if(type == "NES-PEEOROM" ) return new NES_PxROM(document);
if(type == "NES-PNROM" ) return new NES_PxROM(document);
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(type == "NES-SAROM" ) return new NES_SxROM(document);
if(type == "NES-SBROM" ) return new NES_SxROM(document);
if(type == "NES-SCROM" ) return new NES_SxROM(document);
if(type == "NES-SC1ROM" ) return new NES_SxROM(document);
if(type == "NES-SEROM" ) return new NES_SxROM(document);
if(type == "NES-SFROM" ) return new NES_SxROM(document);
if(type == "NES-SFEXPROM") return new NES_SxROM(document);
if(type == "NES-SGROM" ) return new NES_SxROM(document);
if(type == "NES-SHROM" ) return new NES_SxROM(document);
if(type == "NES-SH1ROM" ) return new NES_SxROM(document);
if(type == "NES-SIROM" ) return new NES_SxROM(document);
if(type == "NES-SJROM" ) return new NES_SxROM(document);
if(type == "NES-SKROM" ) return new NES_SxROM(document);
if(type == "NES-SLROM" ) return new NES_SxROM(document);
if(type == "NES-SL1ROM" ) return new NES_SxROM(document);
if(type == "NES-SL2ROM" ) return new NES_SxROM(document);
if(type == "NES-SL3ROM" ) return new NES_SxROM(document);
if(type == "NES-SLRROM" ) return new NES_SxROM(document);
if(type == "NES-SMROM" ) return new NES_SxROM(document);
if(type == "NES-SNROM" ) return new NES_SxROM(document);
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(type == "NES-SOROM" ) return new NES_SxROM(document);
if(type == "NES-SUROM" ) return new NES_SxROM(document);
if(type == "NES-SXROM" ) return new NES_SxROM(document);
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(type == "NES-TBROM" ) return new NES_TxROM(document);
if(type == "NES-TEROM" ) return new NES_TxROM(document);
if(type == "NES-TFROM" ) return new NES_TxROM(document);
if(type == "NES-TGROM" ) return new NES_TxROM(document);
if(type == "NES-TKROM" ) return new NES_TxROM(document);
if(type == "NES-TKSROM" ) return new NES_TxROM(document);
if(type == "NES-TLROM" ) return new NES_TxROM(document);
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(type == "NES-TL1ROM" ) return new NES_TxROM(document);
if(type == "NES-TL2ROM" ) return new NES_TxROM(document);
if(type == "NES-TLSROM" ) return new NES_TxROM(document);
if(type == "NES-TNROM" ) return new NES_TxROM(document);
if(type == "NES-TQROM" ) return new NES_TxROM(document);
if(type == "NES-TR1ROM" ) return new NES_TxROM(document);
if(type == "NES-TSROM" ) return new NES_TxROM(document);
if(type == "NES-TVROM" ) return new NES_TxROM(document);
if(type == "NES-UNROM" ) return new NES_UxROM(document);
if(type == "NES-UOROM" ) return new NES_UxROM(document);
if(type == "SUNSOFT-5B" ) return new Sunsoft5B(document);
return nullptr;
}