bsnes/sfc/chip/hitachidsp/serialization.cpp

35 lines
809 B
C++
Raw Normal View History

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
#ifdef HITACHIDSP_CPP
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> HitachiDSP::firmware() {
vector<uint8> buffer;
if(cartridge.has_hitachidsp() == false) return buffer;
buffer.reserve(1024 * 3);
for(unsigned n = 0; n < 1024; n++) {
buffer.append(dataROM[n] >> 0);
buffer.append(dataROM[n] >> 8);
buffer.append(dataROM[n] >> 16);
}
return buffer;
}
void HitachiDSP::serialize(serializer& s) {
HG51B::serialize(s);
Thread::serialize(s);
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
s.integer(mmio.dma);
s.integer(mmio.dma_source);
s.integer(mmio.dma_length);
s.integer(mmio.dma_target);
s.integer(mmio.r1f48);
s.integer(mmio.program_offset);
s.integer(mmio.r1f4c);
s.integer(mmio.page_number);
s.integer(mmio.program_counter);
s.integer(mmio.r1f50);
s.integer(mmio.r1f51);
s.integer(mmio.r1f52);
s.array(mmio.vector);
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
}
#endif