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

487 lines
12 KiB
C++
Raw Normal View History

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 {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
auto main() -> void {
Update to v097r13 release. byuu says: I refactored my schedulers. Added about ten lines to each scheduler, and removed about 100 lines of calling into internal state in the scheduler for the FC,SFC cores and about 30-40 lines for the other cores. All of its state is now private. Also reworked all of the entry points to static auto Enter() and auto main(). Where Enter() handles all the synchronization stuff, and main() doesn't need the while(true); loop forcing another layer of indentation everywhere. Took a few hours to do, but totally worth it. I'm surprised I didn't do this sooner. Also updated icarus gmake install rule to copy over the database.
2016-02-09 11:51:12 +00:00
//scanline() resets this; if no scanlines detected, enter video blanking period
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
cpu.irqLine(irqEnable && irqPending);
Update to v097r13 release. byuu says: I refactored my schedulers. Added about ten lines to each scheduler, and removed about 100 lines of calling into internal state in the scheduler for the FC,SFC cores and about 30-40 lines for the other cores. All of its state is now private. Also reworked all of the entry points to static auto Enter() and auto main(). Where Enter() handles all the synchronization stuff, and main() doesn't need the while(true); loop forcing another layer of indentation everywhere. Took a few hours to do, but totally worth it. I'm surprised I didn't do this sooner. Also updated icarus gmake install rule to copy over the database.
2016-02-09 11:51:12 +00:00
tick();
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
auto accessPRG(bool write, uint addr, uint8 data = 0x00) -> uint8 {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
uint bank;
if((addr & 0xe000) == 0x6000) {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
bank = (ramSelect << 2) | ramBank;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
addr &= 0x1fff;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
} else if(prgMode == 0) {
bank = prgBank[3] & ~3;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
addr &= 0x7fff;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
addr &= 0x3fff;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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]);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
addr &= 0x1fff;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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 {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(prgramWriteProtect[0] == 2 && prgramWriteProtect[1] == 1) {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
auto readPRG(uint addr) -> uint8 {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
if((addr & 0xfc00) == 0x5c00) {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(exramMode >= 2) return exram[addr & 0x03ff];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
if(addr >= 0x6000) {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
return accessPRG(0, addr);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
switch(addr) {
case 0x5204: {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
uint8 result = (irqPending << 7) | (inFrame << 6);
irqPending = false;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
auto writePRG(uint addr, uint8 data) -> void {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
if((addr & 0xfc00) == 0x5c00) {
//writes 0x00 *during* Vblank (not during screen rendering ...)
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
if(addr >= 0x6000) {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
accessPRG(1, addr, data);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
switch(addr) {
case 0x2000:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
sprite8x16 = data & 0x20;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
case 0x5100: prgMode = data & 3; break;
case 0x5101: chrMode = data & 3; break;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
case 0x5102: prgramWriteProtect[0] = data & 3; break;
case 0x5103: prgramWriteProtect[1] = data & 3; break;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
case 0x5104:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
exramMode = data & 3;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5105:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5106:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
fillmodeTile = data;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5107:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
fillmodeColor = data & 3;
fillmodeColor |= fillmodeColor << 2;
fillmodeColor |= fillmodeColor << 4;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5113:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
ramSelect = data & 0x04;
ramBank = data & 0x03;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
case 0x5130:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
chrBankHi = data & 3;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5200:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
vsEnable = data & 0x80;
vsSide = data & 0x40;
vsTile = data & 0x1f;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5201:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
vsScroll = data;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5202:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
vsBank = data;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5203:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
irqLine = data;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
break;
case 0x5204:
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
irqEnable = data & 0x80;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
auto chrSpriteAddr(uint addr) -> uint {
if(chrMode == 0) {
auto bank = chrSpriteBank[7];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
return (bank * 0x2000) + (addr & 0x1fff);
}
Update to v083r06 release. byuu says: All cores: Video classes have internal->{RGB30,24,16,15} palette generation support All cores: video output is now RGB24, all filters except HQ2x were updated to reflect this (HQ2x will be very hard) NES: MMC5 CHR mapping fixes (Bandit Kings, RTK2, Uchuu Keibitai SDF) [Cydrak] NES: MMC5 vertical split screen support (Uchuu Keibitai SDF) [Cydrak] Game Boy + Game Boy Color: fixed a potential freezing bug when loading save states (re-create cothreads on state load; was implied when using SGB mode.) Game Boy Color: fixed freezing bug with Zelda: LA opening (SVBK is readable.) Game Boy Color: more accurate colors (better than GiiBii, probably worse than KiGB) SNES: luminance of zero is no longer pure black, as on real hardware. This is possible thanks to using RGB888 output now. The current major problems I'd like to solve: - Zelda: Link's Awakening music when Link first wakes up in the house is atrociously bad - Shin Megami Tensei: Devil Children - White Book (Shiro no Sho) plays music at 50% speed; yet Black Book (Kuro no Sho) does not ... one of my favorite games, so it'd be great to fix it
2011-10-27 13:30:19 +00:00
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(chrMode == 1) {
auto bank = chrSpriteBank[(addr / 0x1000) * 4 + 3];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(chrMode == 2) {
auto bank = chrSpriteBank[(addr / 0x0800) * 2 + 1];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(chrMode == 3) {
auto bank = chrSpriteBank[(addr / 0x0400)];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
auto chrBGAddr(uint addr) -> uint {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(chrMode == 0) {
auto bank = chrBGBank[3];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
}
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(chrMode == 1) {
auto bank = chrBGBank[3];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(chrMode == 2) {
auto bank = chrBGBank[(addr / 0x0800) * 2 + 1];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(chrMode == 3) {
auto bank = chrBGBank[(addr / 0x0400)];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
}
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
auto blank() -> void {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
}
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
auto scanline() -> void {
hcounter = 0;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(inFrame == false) {
inFrame = true;
irqPending = false;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
vcounter = 0;
} else {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
if(vcounter == irqLine) irqPending = true;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
vcounter++;
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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];
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
switch(nametableMode[(addr >> 10) & 3]) {
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
2016-06-26 08:54:12 +00:00
case 0: return ppu.readCIRAM(0x0000 | (addr & 0x03ff));
case 1: return ppu.readCIRAM(0x0400 | (addr & 0x03ff));
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
//detect two unused nametable fetches at end of each scanline
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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));
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
bool bgFetch = (hcounter < 256 || hcounter >= 320);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
uint8 result = 0x00;
if((hcounter & 7) == 0) {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
result = readCIRAM(addr);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
exbank = (chrBankHi << 6) | (exram[addr & 0x03ff] & 0x3f);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
exattr = exram[addr & 0x03ff] >> 6;
exattr |= exattr << 2;
exattr |= exattr << 4;
} else if((hcounter & 7) == 2) {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
result = readCIRAM(addr);
if(bgFetch && exramMode == 1) result = exattr;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
} else {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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));
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
}
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
auto writeCHR(uint addr, uint8 data) -> void {
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
if(addr & 0x2000) {
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
switch(nametableMode[(addr >> 10) & 3]) {
Update to v099r10 release. byuu says: Changelog: - higan/profile/ => higan/systems/ [temporary; unless we can't think of a better base folder name] - god-damn-better-have fixed the input polling bug - re-added command-line and drag-and-drop loading - command-line loading can now load multiple folders at once (SGB+GB game; Sufami Turbo+Slot A+Slot B; etc) - if you load just the base cart, it'll present you with a dialog to optionally load slotted cart(s) - MSU1 now goes through nall/vfs instead of directly accessing the filesystem - Famicom Cartridge, PPU cores updated to newer programming style - there's countless opportunity for BitField and .bits() in the PPU ... but I'm worried about breaking things If anyone has a working MSU1 game and can test the changes out, that'd be appreciated. I still don't have a test ROM on my dev box. I wouldn't worry too much about extensively testing the Famicom PPU changes just yet ... I'm still struggling with what to name the structs inside the classes between all of my emulators, and the BitField/.bits() changes will be much more important to test at a later date. The only use case left for Emulator::Interface::path(uint id) is for 21fx emulation. This peripheral loads a DLL/SO via LoadLibrary/dlopen, which do not have any official ways to open a file in RAM. I'm very hesitant to use the portable trick of writing the memory to a temporary file, loading it, and deleting the temporary file once done ... it's a real waste of disk activity. I might make something like vfs::file::isVirtual->bool,path()->string to get around this. But even once I do, the underlying LoadLibrary/dlopen call is still going to be direct disk access.
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);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
}
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
auto power() -> void {
for(auto& n : exram) n = 0xff;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
multiplicand = 0;
multiplier = 0;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
cpuCycleCounter = 0;
irqCounter = 0;
irqPending = 0;
inFrame = 0;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
vcounter = 0;
hcounter = 0;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
}
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
auto serialize(serializer& s) -> void {
s.array(exram);
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
s.integer(multiplicand);
s.integer(multiplier);
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
s.integer(cpuCycleCounter);
s.integer(irqCounter);
s.integer(irqPending);
s.integer(inFrame);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
s.integer(vcounter);
s.integer(hcounter);
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
for(auto& n : chrAccess) s.integer(n);
s.integer(chrActive);
s.integer(sprite8x16);
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
s.integer(exbank);
s.integer(exattr);
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
}
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
uint8 exram[1024];
Update to v083r06 release. byuu says: All cores: Video classes have internal->{RGB30,24,16,15} palette generation support All cores: video output is now RGB24, all filters except HQ2x were updated to reflect this (HQ2x will be very hard) NES: MMC5 CHR mapping fixes (Bandit Kings, RTK2, Uchuu Keibitai SDF) [Cydrak] NES: MMC5 vertical split screen support (Uchuu Keibitai SDF) [Cydrak] Game Boy + Game Boy Color: fixed a potential freezing bug when loading save states (re-create cothreads on state load; was implied when using SGB mode.) Game Boy Color: fixed freezing bug with Zelda: LA opening (SVBK is readable.) Game Boy Color: more accurate colors (better than GiiBii, probably worse than KiGB) SNES: luminance of zero is no longer pure black, as on real hardware. This is possible thanks to using RGB888 output now. The current major problems I'd like to solve: - Zelda: Link's Awakening music when Link first wakes up in the house is atrociously bad - Shin Megami Tensei: Devil Children - White Book (Shiro no Sho) plays music at 50% speed; yet Black Book (Kuro no Sho) does not ... one of my favorite games, so it'd be great to fix it
2011-10-27 13:30:19 +00:00
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
Update to v083r06 release. byuu says: All cores: Video classes have internal->{RGB30,24,16,15} palette generation support All cores: video output is now RGB24, all filters except HQ2x were updated to reflect this (HQ2x will be very hard) NES: MMC5 CHR mapping fixes (Bandit Kings, RTK2, Uchuu Keibitai SDF) [Cydrak] NES: MMC5 vertical split screen support (Uchuu Keibitai SDF) [Cydrak] Game Boy + Game Boy Color: fixed a potential freezing bug when loading save states (re-create cothreads on state load; was implied when using SGB mode.) Game Boy Color: fixed freezing bug with Zelda: LA opening (SVBK is readable.) Game Boy Color: more accurate colors (better than GiiBii, probably worse than KiGB) SNES: luminance of zero is no longer pure black, as on real hardware. This is possible thanks to using RGB888 output now. The current major problems I'd like to solve: - Zelda: Link's Awakening music when Link first wakes up in the house is atrociously bad - Shin Megami Tensei: Devil Children - White Book (Shiro no Sho) plays music at 50% speed; yet Black Book (Kuro no Sho) does not ... one of my favorite games, so it'd be great to fix it
2011-10-27 13:30:19 +00:00
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
//status registers
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
uint cpuCycleCounter;
uint irqCounter;
bool irqPending;
bool inFrame;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
2015-12-05 05:44:49 +00:00
uint vcounter;
uint hcounter;
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
2016-06-27 13:07:57 +00:00
uint16 chrAccess[4];
bool chrActive;
bool sprite8x16;
Update to v095r09 release. byuu says: Changelog: - all of fc/ ported to "auto function() -> return;" syntax - (includes all of cartridge/board and cartridge/chip as well; even though they're all deprecated) - sfc balanced profile ported to "auto function() -> return;" syntax - sfc balanced and performance profiles compile again - Linux always gets -ldl - removed arch=x86 logic from nall/GNUmakefile, as TDM/GCC64 can't produce bug-free 32-bit binaries anyway The only code that continues to use the old function syntax is the SFC performance core, obscure parts of nall that higan doesn't use, and the pieces of code that weren't written by me (blargg's SFC-DSP, Ryphecha's sinc resampler, and OV2's xaudio2 header file.) I was too burned out to finish it tonight. The above was about four hours straight of non-stop typing. Really can't wait to be done with this once and for all.
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
Update to v099r11 release. byuu says: Changelog: - NES PPU core updated to use BitFields (absolutely massive improvement in code readability) - NES APU core updated to new coding style - NES cartridge/board and cartridge/chip updated to new coding style - pushed NES PPU rendering one dot forward (doesn't fix King's Quest V yet, sadly) - fixed SNES PPU BG tilemask for 128KiB VRAM mode (doesn't fix Yoshi's Island, though) So ... I kind of went overboard with the fc/cartridge changes. This WIP diff is 185KiB >_> I didn't realize it was going to be as big a task as it was, but once I started everything broke in a chain reaction, so I had to do it all at once. There's a massive chance we've broken a bunch of NES things. Any typos in this WIP are going to be absolutely insidious to track down =( But ... supposing I pulled it off, this means the Famicom core is now fully converted to the new coding style as well. That leaves only the GB and GBA cores. Once those are finished, then we'll finally be free of these gigantic hellspawn diffs.
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
};