2011-10-02 10:05:45 +00:00
|
|
|
struct NES_SxROM : Board {
|
2011-09-29 12:44:49 +00:00
|
|
|
|
2011-10-01 12:06:48 +00:00
|
|
|
enum class Revision : unsigned {
|
|
|
|
|
SAROM,
|
|
|
|
|
SBROM,
|
|
|
|
|
SCROM,
|
|
|
|
|
SC1ROM,
|
|
|
|
|
SEROM,
|
|
|
|
|
SFROM,
|
|
|
|
|
SGROM,
|
|
|
|
|
SHROM,
|
|
|
|
|
SH1ROM,
|
|
|
|
|
SIROM,
|
|
|
|
|
SJROM,
|
|
|
|
|
SKROM,
|
|
|
|
|
SLROM,
|
|
|
|
|
SL1ROM,
|
|
|
|
|
SL2ROM,
|
|
|
|
|
SL3ROM,
|
|
|
|
|
SLRROM,
|
|
|
|
|
SMROM,
|
|
|
|
|
SNROM,
|
|
|
|
|
SOROM,
|
|
|
|
|
SUROM,
|
|
|
|
|
SXROM,
|
|
|
|
|
} revision;
|
|
|
|
|
|
|
|
|
|
MMC1 mmc1;
|
|
|
|
|
|
Update to v082r32 release.
byuu says:
Added delay to MMC1 register writes, to fix Bill & Ted's Godawful
Adventure.
Fixed up MMC5 RAM+fill mode, and added EXRAM mode support (8x8
tiles/attributes.)
Just Breed is fully playable now.
MMC5 is a total pain in the ass, the documentation on it is just
terrible. I basically just tried seven hundred variations until
something worked.
I still need to add MMC5 vertical split screen (for one single game's
attract screen, ugh), and the extra sound channels.
Would like to rework the NES APU first. Since the pulse channels are
identical sans sweep, it'd be nice to just inherit those and mask out
the sweep register bit writes.
So that probably won't make it into the first release, at least.
Still, overall I think it'll be an impressive showing of complex mappers
for a first release: MMC3, MMC5, VRC6 and 5B. The latter two with full
audio. The only other really, really hard bit is the VRC7 audio,
supposedly.
2011-10-08 07:34:16 +00:00
|
|
|
void main() {
|
|
|
|
|
return mmc1.main();
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
unsigned ram_addr(unsigned addr) {
|
|
|
|
|
unsigned bank = 0;
|
|
|
|
|
if(revision == Revision::SOROM) bank = (mmc1.chr_bank[0] & 0x08) >> 3;
|
|
|
|
|
if(revision == Revision::SUROM) bank = (mmc1.chr_bank[0] & 0x0c) >> 2;
|
|
|
|
|
if(revision == Revision::SXROM) bank = (mmc1.chr_bank[0] & 0x0c) >> 2;
|
|
|
|
|
return (bank << 13) | (addr & 0x1fff);
|
|
|
|
|
}
|
2011-10-01 12:06:48 +00:00
|
|
|
|
|
|
|
|
uint8 prg_read(unsigned addr) {
|
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((addr & 0xe000) == 0x6000) {
|
|
|
|
|
if(revision == Revision::SNROM) {
|
|
|
|
|
if(mmc1.chr_bank[0] & 0x10) return cpu.mdr();
|
|
|
|
|
}
|
|
|
|
|
if(mmc1.ram_disable) return 0x00;
|
|
|
|
|
return prgram.read(ram_addr(addr));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if(addr & 0x8000) {
|
|
|
|
|
addr = mmc1.prg_addr(addr);
|
|
|
|
|
if(revision == Revision::SXROM) {
|
|
|
|
|
addr |= ((mmc1.chr_bank[0] & 0x10) >> 4) << 18;
|
|
|
|
|
}
|
|
|
|
|
return prgrom.read(addr);
|
|
|
|
|
}
|
|
|
|
|
|
2011-10-01 12:06:48 +00:00
|
|
|
return cpu.mdr();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void prg_write(unsigned addr, uint8 data) {
|
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((addr & 0xe000) == 0x6000) {
|
|
|
|
|
if(revision == Revision::SNROM) {
|
|
|
|
|
if(mmc1.chr_bank[0] & 0x10) return;
|
2011-10-01 12:06:48 +00:00
|
|
|
}
|
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(mmc1.ram_disable) return;
|
|
|
|
|
return prgram.write(ram_addr(addr), data);
|
2011-10-01 12:06:48 +00:00
|
|
|
}
|
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(addr & 0x8000) return mmc1.mmio_write(addr, data);
|
2011-10-01 12:06:48 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint8 chr_read(unsigned addr) {
|
|
|
|
|
if(addr & 0x2000) return ppu.ciram_read(mmc1.ciram_addr(addr));
|
|
|
|
|
return Board::chr_read(mmc1.chr_addr(addr));
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void chr_write(unsigned addr, uint8 data) {
|
|
|
|
|
if(addr & 0x2000) return ppu.ciram_write(mmc1.ciram_addr(addr), data);
|
|
|
|
|
return Board::chr_write(mmc1.chr_addr(addr), data);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void power() {
|
|
|
|
|
mmc1.power();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void reset() {
|
|
|
|
|
mmc1.reset();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
void serialize(serializer &s) {
|
|
|
|
|
Board::serialize(s);
|
|
|
|
|
mmc1.serialize(s);
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
NES_SxROM(Markup::Node &document) : Board(document), mmc1(*this) {
|
2011-10-01 12:06:48 +00:00
|
|
|
revision = Revision::SXROM;
|
2011-09-29 12:44:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
};
|