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
|
|
|
struct MMC5 : Chip {
|
2015-12-05 05:44:49 +00:00
|
|
|
MMC5(Board& board) : Chip(board) {
|
|
|
|
revision = Revision::MMC5;
|
|
|
|
}
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
auto main() -> void {
|
2016-02-09 11:51:12 +00:00
|
|
|
//scanline() resets this; if no scanlines detected, enter video blanking period
|
2016-06-27 13:07:57 +00:00
|
|
|
if(++cpuCycleCounter >= 200) blank(); //113-114 normal; ~2500 across Vblank period
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
cpu.irqLine(irqEnable && irqPending);
|
2016-02-09 11:51:12 +00:00
|
|
|
tick();
|
2015-12-05 05:44:49 +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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
auto scanline(uint y) -> void {
|
|
|
|
//used for testing only, to verify MMC5 scanline detection is accurate:
|
|
|
|
//if(y != vcounter && y <= 240) print(y, " vs ", vcounter, "\n");
|
|
|
|
}
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto accessPRG(bool write, uint addr, uint8 data = 0x00) -> uint8 {
|
2015-12-05 05:44:49 +00:00
|
|
|
uint bank;
|
|
|
|
|
|
|
|
if((addr & 0xe000) == 0x6000) {
|
2016-06-27 13:07:57 +00:00
|
|
|
bank = (ramSelect << 2) | ramBank;
|
2015-12-05 05:44:49 +00:00
|
|
|
addr &= 0x1fff;
|
2016-06-27 13:07:57 +00:00
|
|
|
} else if(prgMode == 0) {
|
|
|
|
bank = prgBank[3] & ~3;
|
2015-12-05 05:44:49 +00:00
|
|
|
addr &= 0x7fff;
|
2016-06-27 13:07:57 +00:00
|
|
|
} else if(prgMode == 1) {
|
|
|
|
if((addr & 0xc000) == 0x8000) bank = (prgBank[1] & ~1);
|
|
|
|
if((addr & 0xe000) == 0xc000) bank = (prgBank[3] & ~1);
|
2015-12-05 05:44:49 +00:00
|
|
|
addr &= 0x3fff;
|
2016-06-27 13:07:57 +00:00
|
|
|
} else if(prgMode == 2) {
|
|
|
|
if((addr & 0xe000) == 0x8000) bank = (prgBank[1] & ~1) | 0;
|
|
|
|
if((addr & 0xe000) == 0xa000) bank = (prgBank[1] & ~1) | 1;
|
|
|
|
if((addr & 0xe000) == 0xc000) bank = (prgBank[2]);
|
|
|
|
if((addr & 0xe000) == 0xe000) bank = (prgBank[3]);
|
2015-12-05 05:44:49 +00:00
|
|
|
addr &= 0x1fff;
|
2016-06-27 13:07:57 +00:00
|
|
|
} else if(prgMode == 3) {
|
|
|
|
if((addr & 0xe000) == 0x8000) bank = prgBank[0];
|
|
|
|
if((addr & 0xe000) == 0xa000) bank = prgBank[1];
|
|
|
|
if((addr & 0xe000) == 0xc000) bank = prgBank[2];
|
|
|
|
if((addr & 0xe000) == 0xe000) bank = prgBank[3];
|
2015-12-05 05:44:49 +00:00
|
|
|
addr &= 0x1fff;
|
|
|
|
}
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
bool rom = bank & 0x80;
|
|
|
|
bank &= 0x7f;
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
if(write == false) {
|
|
|
|
if(rom) {
|
|
|
|
return board.prgrom.read((bank << 13) | addr);
|
|
|
|
} else {
|
|
|
|
return board.prgram.read((bank << 13) | addr);
|
|
|
|
}
|
|
|
|
} else {
|
|
|
|
if(rom) {
|
|
|
|
board.prgrom.write((bank << 13) | addr, data);
|
|
|
|
} else {
|
2016-06-27 13:07:57 +00:00
|
|
|
if(prgramWriteProtect[0] == 2 && prgramWriteProtect[1] == 1) {
|
2015-12-05 05:44:49 +00:00
|
|
|
board.prgram.write((bank << 13) | addr, data);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
return 0x00;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto readPRG(uint addr) -> uint8 {
|
2015-12-05 05:44:49 +00:00
|
|
|
if((addr & 0xfc00) == 0x5c00) {
|
2016-06-27 13:07:57 +00:00
|
|
|
if(exramMode >= 2) return exram[addr & 0x03ff];
|
2015-12-05 05:44:49 +00:00
|
|
|
return cpu.mdr();
|
|
|
|
}
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
if(addr >= 0x6000) {
|
2016-06-27 13:07:57 +00:00
|
|
|
return accessPRG(0, addr);
|
2015-12-05 05:44:49 +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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
switch(addr) {
|
|
|
|
case 0x5204: {
|
2016-06-27 13:07:57 +00:00
|
|
|
uint8 result = (irqPending << 7) | (inFrame << 6);
|
|
|
|
irqPending = false;
|
2015-12-05 05:44:49 +00:00
|
|
|
return result;
|
|
|
|
}
|
|
|
|
case 0x5205: return (multiplier * multiplicand) >> 0;
|
|
|
|
case 0x5206: return (multiplier * multiplicand) >> 8;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto writePRG(uint addr, uint8 data) -> void {
|
2015-12-05 05:44:49 +00:00
|
|
|
if((addr & 0xfc00) == 0x5c00) {
|
|
|
|
//writes 0x00 *during* Vblank (not during screen rendering ...)
|
2016-06-27 13:07:57 +00:00
|
|
|
if(exramMode == 0 || exramMode == 1) exram[addr & 0x03ff] = inFrame ? data : (uint8)0x00;
|
|
|
|
if(exramMode == 2) exram[addr & 0x03ff] = data;
|
2015-12-05 05:44:49 +00:00
|
|
|
return;
|
|
|
|
}
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
if(addr >= 0x6000) {
|
2016-06-27 13:07:57 +00:00
|
|
|
accessPRG(1, addr, data);
|
2015-12-05 05:44:49 +00:00
|
|
|
return;
|
|
|
|
}
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
switch(addr) {
|
|
|
|
case 0x2000:
|
2016-06-27 13:07:57 +00:00
|
|
|
sprite8x16 = data & 0x20;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x2001:
|
|
|
|
//if BG+sprites are disabled; enter video blanking period
|
|
|
|
if((data & 0x18) == 0) blank();
|
|
|
|
break;
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
case 0x5100: prgMode = data & 3; break;
|
|
|
|
case 0x5101: chrMode = data & 3; break;
|
2015-12-05 05:44:49 +00:00
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
case 0x5102: prgramWriteProtect[0] = data & 3; break;
|
|
|
|
case 0x5103: prgramWriteProtect[1] = data & 3; break;
|
2015-12-05 05:44:49 +00:00
|
|
|
|
|
|
|
case 0x5104:
|
2016-06-27 13:07:57 +00:00
|
|
|
exramMode = data & 3;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5105:
|
2016-06-27 13:07:57 +00:00
|
|
|
nametableMode[0] = (data & 0x03) >> 0;
|
|
|
|
nametableMode[1] = (data & 0x0c) >> 2;
|
|
|
|
nametableMode[2] = (data & 0x30) >> 4;
|
|
|
|
nametableMode[3] = (data & 0xc0) >> 6;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5106:
|
2016-06-27 13:07:57 +00:00
|
|
|
fillmodeTile = data;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5107:
|
2016-06-27 13:07:57 +00:00
|
|
|
fillmodeColor = data & 3;
|
|
|
|
fillmodeColor |= fillmodeColor << 2;
|
|
|
|
fillmodeColor |= fillmodeColor << 4;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5113:
|
2016-06-27 13:07:57 +00:00
|
|
|
ramSelect = data & 0x04;
|
|
|
|
ramBank = data & 0x03;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
case 0x5114: prgBank[0] = data; break;
|
|
|
|
case 0x5115: prgBank[1] = data; break;
|
|
|
|
case 0x5116: prgBank[2] = data; break;
|
|
|
|
case 0x5117: prgBank[3] = data | 0x80; break;
|
|
|
|
|
|
|
|
case 0x5120: chrSpriteBank[0] = (chrBankHi << 8) | data; chrActive = 0; break;
|
|
|
|
case 0x5121: chrSpriteBank[1] = (chrBankHi << 8) | data; chrActive = 0; break;
|
|
|
|
case 0x5122: chrSpriteBank[2] = (chrBankHi << 8) | data; chrActive = 0; break;
|
|
|
|
case 0x5123: chrSpriteBank[3] = (chrBankHi << 8) | data; chrActive = 0; break;
|
|
|
|
case 0x5124: chrSpriteBank[4] = (chrBankHi << 8) | data; chrActive = 0; break;
|
|
|
|
case 0x5125: chrSpriteBank[5] = (chrBankHi << 8) | data; chrActive = 0; break;
|
|
|
|
case 0x5126: chrSpriteBank[6] = (chrBankHi << 8) | data; chrActive = 0; break;
|
|
|
|
case 0x5127: chrSpriteBank[7] = (chrBankHi << 8) | data; chrActive = 0; break;
|
|
|
|
|
|
|
|
case 0x5128: chrBGBank[0] = (chrBankHi << 8) | data; chrActive = 1; break;
|
|
|
|
case 0x5129: chrBGBank[1] = (chrBankHi << 8) | data; chrActive = 1; break;
|
|
|
|
case 0x512a: chrBGBank[2] = (chrBankHi << 8) | data; chrActive = 1; break;
|
|
|
|
case 0x512b: chrBGBank[3] = (chrBankHi << 8) | data; chrActive = 1; break;
|
2015-12-05 05:44:49 +00:00
|
|
|
|
|
|
|
case 0x5130:
|
2016-06-27 13:07:57 +00:00
|
|
|
chrBankHi = data & 3;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5200:
|
2016-06-27 13:07:57 +00:00
|
|
|
vsEnable = data & 0x80;
|
|
|
|
vsSide = data & 0x40;
|
|
|
|
vsTile = data & 0x1f;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5201:
|
2016-06-27 13:07:57 +00:00
|
|
|
vsScroll = data;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5202:
|
2016-06-27 13:07:57 +00:00
|
|
|
vsBank = data;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5203:
|
2016-06-27 13:07:57 +00:00
|
|
|
irqLine = data;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5204:
|
2016-06-27 13:07:57 +00:00
|
|
|
irqEnable = data & 0x80;
|
2015-12-05 05:44:49 +00:00
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5205:
|
|
|
|
multiplicand = data;
|
|
|
|
break;
|
|
|
|
|
|
|
|
case 0x5206:
|
|
|
|
multiplier = data;
|
|
|
|
break;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto chrSpriteAddr(uint addr) -> uint {
|
|
|
|
if(chrMode == 0) {
|
|
|
|
auto bank = chrSpriteBank[7];
|
2015-12-05 05:44:49 +00:00
|
|
|
return (bank * 0x2000) + (addr & 0x1fff);
|
|
|
|
}
|
2011-10-27 13:30:19 +00:00
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
if(chrMode == 1) {
|
|
|
|
auto bank = chrSpriteBank[(addr / 0x1000) * 4 + 3];
|
2015-12-05 05:44:49 +00:00
|
|
|
return (bank * 0x1000) + (addr & 0x0fff);
|
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
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
if(chrMode == 2) {
|
|
|
|
auto bank = chrSpriteBank[(addr / 0x0800) * 2 + 1];
|
2015-12-05 05:44:49 +00:00
|
|
|
return (bank * 0x0800) + (addr & 0x07ff);
|
|
|
|
}
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
if(chrMode == 3) {
|
|
|
|
auto bank = chrSpriteBank[(addr / 0x0400)];
|
2015-12-05 05:44:49 +00:00
|
|
|
return (bank * 0x0400) + (addr & 0x03ff);
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto chrBGAddr(uint addr) -> uint {
|
2015-12-05 05:44:49 +00:00
|
|
|
addr &= 0x0fff;
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
if(chrMode == 0) {
|
|
|
|
auto bank = chrBGBank[3];
|
2015-12-05 05:44:49 +00:00
|
|
|
return (bank * 0x2000) + (addr & 0x0fff);
|
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
|
|
|
}
|
2015-12-05 05:44:49 +00:00
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
if(chrMode == 1) {
|
|
|
|
auto bank = chrBGBank[3];
|
2015-12-05 05:44:49 +00:00
|
|
|
return (bank * 0x1000) + (addr & 0x0fff);
|
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
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
if(chrMode == 2) {
|
|
|
|
auto bank = chrBGBank[(addr / 0x0800) * 2 + 1];
|
2015-12-05 05:44:49 +00:00
|
|
|
return (bank * 0x0800) + (addr & 0x07ff);
|
|
|
|
}
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
if(chrMode == 3) {
|
|
|
|
auto bank = chrBGBank[(addr / 0x0400)];
|
2015-12-05 05:44:49 +00:00
|
|
|
return (bank * 0x0400) + (addr & 0x03ff);
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto chrVSAddr(uint addr) -> uint {
|
|
|
|
return (vsBank * 0x1000) + (addr & 0x0ff8) + (vsVpos & 7);
|
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
|
|
|
}
|
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
auto blank() -> void {
|
2016-06-27 13:07:57 +00:00
|
|
|
inFrame = false;
|
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
|
|
|
}
|
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
auto scanline() -> void {
|
|
|
|
hcounter = 0;
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
if(inFrame == false) {
|
|
|
|
inFrame = true;
|
|
|
|
irqPending = false;
|
2015-12-05 05:44:49 +00:00
|
|
|
vcounter = 0;
|
|
|
|
} else {
|
2016-06-27 13:07:57 +00:00
|
|
|
if(vcounter == irqLine) irqPending = true;
|
2015-12-05 05:44:49 +00:00
|
|
|
vcounter++;
|
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
cpuCycleCounter = 0;
|
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
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto readCIRAM(uint addr) -> uint8 {
|
|
|
|
if(vsFetch && (hcounter & 2) == 0) return exram[vsVpos / 8 * 32 + vsHpos / 8];
|
|
|
|
if(vsFetch && (hcounter & 2) != 0) return exram[vsVpos / 32 * 8 + vsHpos / 32 + 0x03c0];
|
2015-12-05 05:44:49 +00:00
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
switch(nametableMode[(addr >> 10) & 3]) {
|
2016-06-26 08:54:12 +00:00
|
|
|
case 0: return ppu.readCIRAM(0x0000 | (addr & 0x03ff));
|
|
|
|
case 1: return ppu.readCIRAM(0x0400 | (addr & 0x03ff));
|
2016-06-27 13:07:57 +00:00
|
|
|
case 2: return exramMode < 2 ? exram[addr & 0x03ff] : (uint8)0x00;
|
|
|
|
case 3: return (hcounter & 2) == 0 ? fillmodeTile : fillmodeColor;
|
2015-12-05 05:44:49 +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
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto readCHR(uint addr) -> uint8 {
|
|
|
|
chrAccess[0] = chrAccess[1];
|
|
|
|
chrAccess[1] = chrAccess[2];
|
|
|
|
chrAccess[2] = chrAccess[3];
|
|
|
|
chrAccess[3] = addr;
|
2015-12-05 05:44:49 +00:00
|
|
|
|
|
|
|
//detect two unused nametable fetches at end of each scanline
|
2016-06-27 13:07:57 +00:00
|
|
|
if((chrAccess[0] & 0x2000) == 0
|
|
|
|
&& (chrAccess[1] & 0x2000)
|
|
|
|
&& (chrAccess[2] & 0x2000)
|
|
|
|
&& (chrAccess[3] & 0x2000)) scanline();
|
|
|
|
|
|
|
|
if(inFrame == false) {
|
|
|
|
vsFetch = false;
|
|
|
|
if(addr & 0x2000) return readCIRAM(addr);
|
|
|
|
return board.chrrom.read(chrActive ? chrBGAddr(addr) : chrSpriteAddr(addr));
|
2015-12-05 05:44:49 +00:00
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
bool bgFetch = (hcounter < 256 || hcounter >= 320);
|
2015-12-05 05:44:49 +00:00
|
|
|
uint8 result = 0x00;
|
|
|
|
|
|
|
|
if((hcounter & 7) == 0) {
|
2016-06-27 13:07:57 +00:00
|
|
|
vsHpos = hcounter >= 320 ? hcounter - 320 : hcounter + 16;
|
|
|
|
vsVpos = vcounter + vsScroll;
|
|
|
|
vsFetch = vsEnable && bgFetch && exramMode < 2
|
|
|
|
&& (vsSide ? vsHpos / 8 >= vsTile : vsHpos / 8 < vsTile);
|
|
|
|
if(vsVpos >= 240) vsVpos -= 240;
|
2015-12-05 05:44:49 +00:00
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
result = readCIRAM(addr);
|
2015-12-05 05:44:49 +00:00
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
exbank = (chrBankHi << 6) | (exram[addr & 0x03ff] & 0x3f);
|
2015-12-05 05:44:49 +00:00
|
|
|
exattr = exram[addr & 0x03ff] >> 6;
|
|
|
|
exattr |= exattr << 2;
|
|
|
|
exattr |= exattr << 4;
|
|
|
|
} else if((hcounter & 7) == 2) {
|
2016-06-27 13:07:57 +00:00
|
|
|
result = readCIRAM(addr);
|
|
|
|
if(bgFetch && exramMode == 1) result = exattr;
|
2015-12-05 05:44:49 +00:00
|
|
|
} else {
|
2016-06-27 13:07:57 +00:00
|
|
|
if(vsFetch) result = board.chrrom.read(chrVSAddr(addr));
|
|
|
|
else if(sprite8x16 ? bgFetch : chrActive) result = board.chrrom.read(chrBGAddr(addr));
|
|
|
|
else result = board.chrrom.read(chrSpriteAddr(addr));
|
|
|
|
if(bgFetch && exramMode == 1) result = board.chrrom.read(exbank * 0x1000 + (addr & 0x0fff));
|
2015-12-05 05:44:49 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
hcounter += 2;
|
|
|
|
return result;
|
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
|
|
|
}
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
auto writeCHR(uint addr, uint8 data) -> void {
|
2015-12-05 05:44:49 +00:00
|
|
|
if(addr & 0x2000) {
|
2016-06-27 13:07:57 +00:00
|
|
|
switch(nametableMode[(addr >> 10) & 3]) {
|
2016-06-26 08:54:12 +00:00
|
|
|
case 0: return ppu.writeCIRAM(0x0000 | (addr & 0x03ff), data);
|
|
|
|
case 1: return ppu.writeCIRAM(0x0400 | (addr & 0x03ff), data);
|
2015-12-05 05:44:49 +00:00
|
|
|
case 2: exram[addr & 0x03ff] = data; break;
|
|
|
|
}
|
|
|
|
}
|
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
|
|
|
}
|
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
auto power() -> void {
|
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
|
|
|
}
|
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
auto reset() -> void {
|
|
|
|
for(auto& n : exram) n = 0xff;
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
prgMode = 3;
|
|
|
|
chrMode = 0;
|
|
|
|
for(auto& n : prgramWriteProtect) n = 0;
|
|
|
|
exramMode = 0;
|
|
|
|
for(auto& n : nametableMode) n = 0;
|
|
|
|
fillmodeTile = 0;
|
|
|
|
fillmodeColor = 0;
|
|
|
|
ramSelect = 0;
|
|
|
|
ramBank = 0;
|
|
|
|
prgBank[0] = 0x00;
|
|
|
|
prgBank[1] = 0x00;
|
|
|
|
prgBank[2] = 0x00;
|
|
|
|
prgBank[3] = 0xff;
|
|
|
|
for(auto& n : chrSpriteBank) n = 0;
|
|
|
|
for(auto& n : chrBGBank) n = 0;
|
|
|
|
chrBankHi = 0;
|
|
|
|
vsEnable = 0;
|
|
|
|
vsSide = 0;
|
|
|
|
vsTile = 0;
|
|
|
|
vsScroll = 0;
|
|
|
|
vsBank = 0;
|
|
|
|
irqLine = 0;
|
|
|
|
irqEnable = 0;
|
2015-12-05 05:44:49 +00:00
|
|
|
multiplicand = 0;
|
|
|
|
multiplier = 0;
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
cpuCycleCounter = 0;
|
|
|
|
irqCounter = 0;
|
|
|
|
irqPending = 0;
|
|
|
|
inFrame = 0;
|
2015-12-05 05:44:49 +00:00
|
|
|
vcounter = 0;
|
|
|
|
hcounter = 0;
|
2016-06-27 13:07:57 +00:00
|
|
|
for(auto& n : chrAccess) n = 0;
|
|
|
|
chrActive = 0;
|
|
|
|
sprite8x16 = 0;
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
exbank = 0;
|
|
|
|
exattr = 0;
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
vsFetch = 0;
|
|
|
|
vsVpos = 0;
|
|
|
|
vsHpos = 0;
|
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
|
|
|
}
|
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
auto serialize(serializer& s) -> void {
|
|
|
|
s.array(exram);
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
s.integer(prgMode);
|
|
|
|
s.integer(chrMode);
|
|
|
|
for(auto& n : prgramWriteProtect) s.integer(n);
|
|
|
|
s.integer(exramMode);
|
|
|
|
for(auto& n : nametableMode) s.integer(n);
|
|
|
|
s.integer(fillmodeTile);
|
|
|
|
s.integer(fillmodeColor);
|
|
|
|
s.integer(ramSelect);
|
|
|
|
s.integer(ramBank);
|
|
|
|
for(auto& n : prgBank) s.integer(n);
|
|
|
|
for(auto& n : chrSpriteBank) s.integer(n);
|
|
|
|
for(auto& n : chrBGBank) s.integer(n);
|
|
|
|
s.integer(chrBankHi);
|
|
|
|
s.integer(vsEnable);
|
|
|
|
s.integer(vsSide);
|
|
|
|
s.integer(vsTile);
|
|
|
|
s.integer(vsScroll);
|
|
|
|
s.integer(vsBank);
|
|
|
|
s.integer(irqLine);
|
|
|
|
s.integer(irqEnable);
|
2015-12-05 05:44:49 +00:00
|
|
|
s.integer(multiplicand);
|
|
|
|
s.integer(multiplier);
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
s.integer(cpuCycleCounter);
|
|
|
|
s.integer(irqCounter);
|
|
|
|
s.integer(irqPending);
|
|
|
|
s.integer(inFrame);
|
2015-12-05 05:44:49 +00:00
|
|
|
|
|
|
|
s.integer(vcounter);
|
|
|
|
s.integer(hcounter);
|
2016-06-27 13:07:57 +00:00
|
|
|
for(auto& n : chrAccess) s.integer(n);
|
|
|
|
s.integer(chrActive);
|
|
|
|
s.integer(sprite8x16);
|
2015-12-05 05:44:49 +00:00
|
|
|
|
|
|
|
s.integer(exbank);
|
|
|
|
s.integer(exattr);
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
s.integer(vsFetch);
|
|
|
|
s.integer(vsVpos);
|
|
|
|
s.integer(vsHpos);
|
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
|
|
|
}
|
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
enum class Revision : uint {
|
|
|
|
MMC5,
|
|
|
|
MMC5B,
|
|
|
|
} revision;
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
uint8 exram[1024];
|
2011-10-27 13:30:19 +00:00
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
//programmable registers
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
uint2 prgMode; //$5100
|
|
|
|
uint2 chrMode; //$5101
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
uint2 prgramWriteProtect[2]; //$5102,$5103
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
uint2 exramMode; //$5104
|
|
|
|
uint2 nametableMode[4]; //$5105
|
|
|
|
uint8 fillmodeTile; //$5106
|
|
|
|
uint8 fillmodeColor; //$5107
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
bool ramSelect; //$5113
|
|
|
|
uint2 ramBank; //$5113
|
|
|
|
uint8 prgBank[4]; //$5114-5117
|
|
|
|
uint10 chrSpriteBank[8]; //$5120-5127
|
|
|
|
uint10 chrBGBank[4]; //$5128-512b
|
|
|
|
uint2 chrBankHi; //$5130
|
2011-10-27 13:30:19 +00:00
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
bool vsEnable; //$5200
|
|
|
|
bool vsSide; //$5200
|
|
|
|
uint5 vsTile; //$5200
|
|
|
|
uint8 vsScroll; //$5201
|
|
|
|
uint8 vsBank; //$5202
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
uint8 irqLine; //$5203
|
|
|
|
bool irqEnable; //$5204
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
uint8 multiplicand; //$5205
|
|
|
|
uint8 multiplier; //$5206
|
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
|
|
|
|
2015-12-05 05:44:49 +00:00
|
|
|
//status registers
|
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
uint cpuCycleCounter;
|
|
|
|
uint irqCounter;
|
|
|
|
bool irqPending;
|
|
|
|
bool inFrame;
|
2015-12-05 05:44:49 +00:00
|
|
|
|
|
|
|
uint vcounter;
|
|
|
|
uint hcounter;
|
2016-06-27 13:07:57 +00:00
|
|
|
uint16 chrAccess[4];
|
|
|
|
bool chrActive;
|
|
|
|
bool sprite8x16;
|
2015-12-05 05:44:49 +00:00
|
|
|
|
|
|
|
uint8 exbank;
|
|
|
|
uint8 exattr;
|
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
|
|
|
|
2016-06-27 13:07:57 +00:00
|
|
|
bool vsFetch;
|
|
|
|
uint8 vsVpos;
|
|
|
|
uint8 vsHpos;
|
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
|
|
|
};
|