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

40 lines
766 B
C++
Raw Normal View History

Update to v087r08 release. byuu says: Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr 000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write(). Also moved the Hitachi HG51B core to processor/, and split it apart from the snes/chip/hitachidsp implementation. This one actually worked really well. Very clean split between MMIO/DMA and the processor core. I may move a more generic DMA function inside the core, not sure yet. I still believe the HG51B169 to be a variant of the HG51BS family, but given they're meant to be incredibly flexible microcontrollers, it's possible that each variant gets its own instruction set. So, who knows. We'll worry about it if we ever find another HG51B DSP, I guess. GBA BIOS is constantly reading from 04000300, but it never writes. If I return prng()&1, I can get it to proceed until it hits a bad opcode (stc opcode, which the GBA lacks a coprocessor so ... bad codepath.) Without it, it just reads that register forever and keeps resetting the system, or something ... I guess we're going to have to try and get ARMwrestler working, because the BIOS seems to need too much emulation code to do anything at all.
2012-03-24 07:52:36 +00:00
struct HitachiDSP : Processor::HG51B, Coprocessor {
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
unsigned Frequency;
unsigned Roms;
Update to v089r15 release. byuu says: Changelog: - SuperFX has its own ROM and RAM - Cx4 has its own ROM - SPC7110 has its own ProgramROM, DataROM and RAM - OBC1 has its own RAM - BsxCartridge has its own ROM, RAM and PSRAM - mapping changes to accommodate the above
2012-07-09 11:40:23 +00:00
MappedRAM rom;
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
MappedRAM ram;
Update to v089r15 release. byuu says: Changelog: - SuperFX has its own ROM and RAM - Cx4 has its own ROM - SPC7110 has its own ProgramROM, DataROM and RAM - OBC1 has its own RAM - BsxCartridge has its own ROM, RAM and PSRAM - mapping changes to accommodate the above
2012-07-09 11:40:23 +00:00
Update to v087r08 release. byuu says: Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr 000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write(). Also moved the Hitachi HG51B core to processor/, and split it apart from the snes/chip/hitachidsp implementation. This one actually worked really well. Very clean split between MMIO/DMA and the processor core. I may move a more generic DMA function inside the core, not sure yet. I still believe the HG51B169 to be a variant of the HG51BS family, but given they're meant to be incredibly flexible microcontrollers, it's possible that each variant gets its own instruction set. So, who knows. We'll worry about it if we ever find another HG51B DSP, I guess. GBA BIOS is constantly reading from 04000300, but it never writes. If I return prng()&1, I can get it to proceed until it hits a bad opcode (stc opcode, which the GBA lacks a coprocessor so ... bad codepath.) Without it, it just reads that register forever and keeps resetting the system, or something ... I guess we're going to have to try and get ARMwrestler working, because the BIOS seems to need too much emulation code to do anything at all.
2012-03-24 07:52:36 +00:00
#include "mmio.hpp"
Update to v079r04 release. byuu says: Back from vacation. We were successful in emulating the Cx4 using LLE during my vacation. We finished on June 15th. And now that I'm back, I've rewritten the code and merged it into bsnes official. With that, the very last HLE emulation code in bsnes has now been purged. [...] The emulation is as minimal as possible. If I don't see an opcode or feature actually used, I don't implement it. The one exception being that I do support the vector override functionality. And there are also dummy handlers for ld ?,$2e + loop, so that the chip won't stall out. But things like "byte 4" on rdram/wrram, the two-bit destination selections for all but ld, etc are treated as invalid opcodes, since we aren't 100% sure if they are there and work as we hypothesize. I also only map in known registers into the 256-entry register list. This leaves 90% of the map empty. The chip runs at 20MHz, and it will disable the ROM while running. DMA does transfer one byte at a time against the clock and also locks out the ROM. rdbus won't fetch from IRAM, only from ROM. DMA transfer only reads from ROM, and only writes to RAM. Unless someone verifies that they can do more, I'll leave it that way. I don't yet actually buffer the program ROM into the internal program RAM just yet, but that is on the to-do list. We aren't entirely sure how that works either, but my plan is to just lock the Cx4 CPU and load in 512-bytes. There's still a few unknown registers in $7f40-5f that I don't do anything with yet. The secondary chip disable is going to be the weirdest one, since MMX3 only has one chip. I'd really rather not have to specify the ROM mapping as two separate chips on MMX2 and as one on MMX3 just to support this, so I don't know yet. Save state support is of course there already. Speed hit is 118fps HLE -> 109fps LLE in most scenes. Not bad, honestly.
2011-06-22 13:27:55 +00:00
static void Enter();
void enter();
void init();
void load();
void unload();
void power();
void reset();
Update to v087r08 release. byuu says: Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr 000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write(). Also moved the Hitachi HG51B core to processor/, and split it apart from the snes/chip/hitachidsp implementation. This one actually worked really well. Very clean split between MMIO/DMA and the processor core. I may move a more generic DMA function inside the core, not sure yet. I still believe the HG51B169 to be a variant of the HG51BS family, but given they're meant to be incredibly flexible microcontrollers, it's possible that each variant gets its own instruction set. So, who knows. We'll worry about it if we ever find another HG51B DSP, I guess. GBA BIOS is constantly reading from 04000300, but it never writes. If I return prng()&1, I can get it to proceed until it hits a bad opcode (stc opcode, which the GBA lacks a coprocessor so ... bad codepath.) Without it, it just reads that register forever and keeps resetting the system, or something ... I guess we're going to have to try and get ARMwrestler working, because the BIOS seems to need too much emulation code to do anything at all.
2012-03-24 07:52:36 +00:00
//HG51B read/write
uint8 bus_read(uint24 addr);
void bus_write(uint24 addr, uint8 data);
Update to v079r04 release. byuu says: Back from vacation. We were successful in emulating the Cx4 using LLE during my vacation. We finished on June 15th. And now that I'm back, I've rewritten the code and merged it into bsnes official. With that, the very last HLE emulation code in bsnes has now been purged. [...] The emulation is as minimal as possible. If I don't see an opcode or feature actually used, I don't implement it. The one exception being that I do support the vector override functionality. And there are also dummy handlers for ld ?,$2e + loop, so that the chip won't stall out. But things like "byte 4" on rdram/wrram, the two-bit destination selections for all but ld, etc are treated as invalid opcodes, since we aren't 100% sure if they are there and work as we hypothesize. I also only map in known registers into the 256-entry register list. This leaves 90% of the map empty. The chip runs at 20MHz, and it will disable the ROM while running. DMA does transfer one byte at a time against the clock and also locks out the ROM. rdbus won't fetch from IRAM, only from ROM. DMA transfer only reads from ROM, and only writes to RAM. Unless someone verifies that they can do more, I'll leave it that way. I don't yet actually buffer the program ROM into the internal program RAM just yet, but that is on the to-do list. We aren't entirely sure how that works either, but my plan is to just lock the Cx4 CPU and load in 512-bytes. There's still a few unknown registers in $7f40-5f that I don't do anything with yet. The secondary chip disable is going to be the weirdest one, since MMX3 only has one chip. I'd really rather not have to specify the ROM mapping as two separate chips on MMX2 and as one on MMX3 just to support this, so I don't know yet. Save state support is of course there already. Speed hit is 118fps HLE -> 109fps LLE in most scenes. Not bad, honestly.
2011-06-22 13:27:55 +00:00
Update to v087r08 release. byuu says: Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr 000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write(). Also moved the Hitachi HG51B core to processor/, and split it apart from the snes/chip/hitachidsp implementation. This one actually worked really well. Very clean split between MMIO/DMA and the processor core. I may move a more generic DMA function inside the core, not sure yet. I still believe the HG51B169 to be a variant of the HG51BS family, but given they're meant to be incredibly flexible microcontrollers, it's possible that each variant gets its own instruction set. So, who knows. We'll worry about it if we ever find another HG51B DSP, I guess. GBA BIOS is constantly reading from 04000300, but it never writes. If I return prng()&1, I can get it to proceed until it hits a bad opcode (stc opcode, which the GBA lacks a coprocessor so ... bad codepath.) Without it, it just reads that register forever and keeps resetting the system, or something ... I guess we're going to have to try and get ARMwrestler working, because the BIOS seems to need too much emulation code to do anything at all.
2012-03-24 07:52:36 +00:00
//CPU ROM read/write
Update to v079r04 release. byuu says: Back from vacation. We were successful in emulating the Cx4 using LLE during my vacation. We finished on June 15th. And now that I'm back, I've rewritten the code and merged it into bsnes official. With that, the very last HLE emulation code in bsnes has now been purged. [...] The emulation is as minimal as possible. If I don't see an opcode or feature actually used, I don't implement it. The one exception being that I do support the vector override functionality. And there are also dummy handlers for ld ?,$2e + loop, so that the chip won't stall out. But things like "byte 4" on rdram/wrram, the two-bit destination selections for all but ld, etc are treated as invalid opcodes, since we aren't 100% sure if they are there and work as we hypothesize. I also only map in known registers into the 256-entry register list. This leaves 90% of the map empty. The chip runs at 20MHz, and it will disable the ROM while running. DMA does transfer one byte at a time against the clock and also locks out the ROM. rdbus won't fetch from IRAM, only from ROM. DMA transfer only reads from ROM, and only writes to RAM. Unless someone verifies that they can do more, I'll leave it that way. I don't yet actually buffer the program ROM into the internal program RAM just yet, but that is on the to-do list. We aren't entirely sure how that works either, but my plan is to just lock the Cx4 CPU and load in 512-bytes. There's still a few unknown registers in $7f40-5f that I don't do anything with yet. The secondary chip disable is going to be the weirdest one, since MMX3 only has one chip. I'd really rather not have to specify the ROM mapping as two separate chips on MMX2 and as one on MMX3 just to support this, so I don't know yet. Save state support is of course there already. Speed hit is 118fps HLE -> 109fps LLE in most scenes. Not bad, honestly.
2011-06-22 13:27:55 +00:00
uint8 rom_read(unsigned addr);
void rom_write(unsigned addr, uint8 data);
Update to v091r13 release, and ananke v00r01. byuu says (about higan): - dropped release/ root node for individual games (still there in ananke's database.) - Memory export uses smarter names (vram.rwm -> video.ram, etc.) - cheat database moved from XML to BML (3.1MB to 1.9MB file size.) - cheat codes moved from XML to BML - resource manifest moved from XML to BML What can I say, I like consistency. But I'll leave the shaders alone until I get around to shader folders. byuu says (about ananke): Works with higan v091r13. Only does SNES stuff so far.
2012-11-22 10:28:01 +00:00
//CPU RAM read/write
uint8 ram_read(unsigned addr);
void ram_write(unsigned addr, uint8 data);
Update to v087r08 release. byuu says: Added some more ARM opcodes, hooked up MMIO. Bind it with mmio[(addr 000-3ff)] = this; inside CPU/PPU/APU, goes to read(), write(). Also moved the Hitachi HG51B core to processor/, and split it apart from the snes/chip/hitachidsp implementation. This one actually worked really well. Very clean split between MMIO/DMA and the processor core. I may move a more generic DMA function inside the core, not sure yet. I still believe the HG51B169 to be a variant of the HG51BS family, but given they're meant to be incredibly flexible microcontrollers, it's possible that each variant gets its own instruction set. So, who knows. We'll worry about it if we ever find another HG51B DSP, I guess. GBA BIOS is constantly reading from 04000300, but it never writes. If I return prng()&1, I can get it to proceed until it hits a bad opcode (stc opcode, which the GBA lacks a coprocessor so ... bad codepath.) Without it, it just reads that register forever and keeps resetting the system, or something ... I guess we're going to have to try and get ARMwrestler working, because the BIOS seems to need too much emulation code to do anything at all.
2012-03-24 07:52:36 +00:00
//CPU MMIO read/write
Update to v079r04 release. byuu says: Back from vacation. We were successful in emulating the Cx4 using LLE during my vacation. We finished on June 15th. And now that I'm back, I've rewritten the code and merged it into bsnes official. With that, the very last HLE emulation code in bsnes has now been purged. [...] The emulation is as minimal as possible. If I don't see an opcode or feature actually used, I don't implement it. The one exception being that I do support the vector override functionality. And there are also dummy handlers for ld ?,$2e + loop, so that the chip won't stall out. But things like "byte 4" on rdram/wrram, the two-bit destination selections for all but ld, etc are treated as invalid opcodes, since we aren't 100% sure if they are there and work as we hypothesize. I also only map in known registers into the 256-entry register list. This leaves 90% of the map empty. The chip runs at 20MHz, and it will disable the ROM while running. DMA does transfer one byte at a time against the clock and also locks out the ROM. rdbus won't fetch from IRAM, only from ROM. DMA transfer only reads from ROM, and only writes to RAM. Unless someone verifies that they can do more, I'll leave it that way. I don't yet actually buffer the program ROM into the internal program RAM just yet, but that is on the to-do list. We aren't entirely sure how that works either, but my plan is to just lock the Cx4 CPU and load in 512-bytes. There's still a few unknown registers in $7f40-5f that I don't do anything with yet. The secondary chip disable is going to be the weirdest one, since MMX3 only has one chip. I'd really rather not have to specify the ROM mapping as two separate chips on MMX2 and as one on MMX3 just to support this, so I don't know yet. Save state support is of course there already. Speed hit is 118fps HLE -> 109fps LLE in most scenes. Not bad, honestly.
2011-06-22 13:27:55 +00:00
uint8 dsp_read(unsigned addr);
void dsp_write(unsigned addr, uint8 data);
Update to v091r11 release. byuu says: This release refines HSU1 support as a bidirectional protocol, nests SFC manifests as "release/cartridge" and "release/information" (but release/ is not guaranteed to be finalized just yet), removes the database integration, and adds support for ananke. ananke represents inevitability. It's a library that, when installed, higan can use to load files from the command-line, and also from a new File -> Load Game menu option. I need to change the build rules a bit for it to work on Windows (need to make phoenix a DLL, basically), but it works now on Linux. Right now, it only takes *.sfc file names, looks them up in the included database, converts them to game folders, and returns the game folder path for higan to load. The idea is to continue expanding it to support everything we can that I don't want in the higan core: - load *.sfc, *.smc, *.swc, *.fig files - remove SNES copier headers - split apart merged firmware files - pull in external firmware files (eg dsp1b.rom - these are staying merged, just as SPC7110 prg+dat are merged) - load *.zip and *.7z archives - prompt for selection on multi-file archives - generate manifest files based on heuristics - apply BPS patches The "Load" menu option has been renamed to "Library", to represent games in your library. I'm going to add some sort of suffix to indicate unverified games, and use a different folder icon for those (eg manifests built on heuristics rather than from the database.) So basically, to future end users: File -> Load Game will be how they play games. Library -> (specific system) can be thought of as an infinitely-sized recent games list. purify will likely become a simple stub that invokes ananke's functions. No reason to duplicate all that code.
2012-11-05 08:22:50 +00:00
vector<uint8> firmware();
Update to v079r04 release. byuu says: Back from vacation. We were successful in emulating the Cx4 using LLE during my vacation. We finished on June 15th. And now that I'm back, I've rewritten the code and merged it into bsnes official. With that, the very last HLE emulation code in bsnes has now been purged. [...] The emulation is as minimal as possible. If I don't see an opcode or feature actually used, I don't implement it. The one exception being that I do support the vector override functionality. And there are also dummy handlers for ld ?,$2e + loop, so that the chip won't stall out. But things like "byte 4" on rdram/wrram, the two-bit destination selections for all but ld, etc are treated as invalid opcodes, since we aren't 100% sure if they are there and work as we hypothesize. I also only map in known registers into the 256-entry register list. This leaves 90% of the map empty. The chip runs at 20MHz, and it will disable the ROM while running. DMA does transfer one byte at a time against the clock and also locks out the ROM. rdbus won't fetch from IRAM, only from ROM. DMA transfer only reads from ROM, and only writes to RAM. Unless someone verifies that they can do more, I'll leave it that way. I don't yet actually buffer the program ROM into the internal program RAM just yet, but that is on the to-do list. We aren't entirely sure how that works either, but my plan is to just lock the Cx4 CPU and load in 512-bytes. There's still a few unknown registers in $7f40-5f that I don't do anything with yet. The secondary chip disable is going to be the weirdest one, since MMX3 only has one chip. I'd really rather not have to specify the ROM mapping as two separate chips on MMX2 and as one on MMX3 just to support this, so I don't know yet. Save state support is of course there already. Speed hit is 118fps HLE -> 109fps LLE in most scenes. Not bad, honestly.
2011-06-22 13:27:55 +00:00
void serialize(serializer&);
};
extern HitachiDSP hitachidsp;