bsnes/higan/sfc/coprocessor/hitachidsp/hitachidsp.cpp

61 lines
1.0 KiB
C++
Raw Normal View History

#include <sfc/sfc.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
namespace SuperFamicom {
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
#include "memory.cpp"
#include "serialization.cpp"
HitachiDSP hitachidsp;
auto HitachiDSP::Enter() -> void {
while(true) scheduler.synchronize(), hitachidsp.main();
}
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
auto HitachiDSP::main() -> void {
if(mmio.dma) {
for(auto n : range(mmio.dma_length)) {
Update to v098r06 release. byuu says: Changelog: - emulation cores now refresh video from host thread instead of cothreads (fix AMD crash) - SFC: fixed another bug with leap year months in SharpRTC emulation - SFC: cleaned up camelCase on function names for armdsp,epsonrtc,hitachidsp,mcc,nss,sharprtc classes - GB: added MBC1M emulation (requires manually setting mapper=MBC1M in manifest.bml for now, sorry) - audio: implemented Emulator::Audio mixer and effects processor - audio: implemented Emulator::Stream interface - it is now possible to have more than two audio streams: eg SNES + SGB + MSU1 + Voicer-Kun (eventually) - audio: added reverb delay + reverb level settings; exposed balance configuration in UI - video: reworked palette generation to re-enable saturation, gamma, luminance adjustments - higan/emulator.cpp is gone since there was nothing left in it I know you guys are going to say the color adjust/balance/reverb stuff is pointless. And indeed it mostly is. But I like the idea of allowing some fun special effects and configurability that isn't system-wide. Note: there seems to be some kind of added audio lag in the SGB emulation now, and I don't really understand why. The code should be effectively identical to what I had before. The only main thing is that I'm sampling things to 48000hz instead of 32040hz before mixing. There's no point where I'm intentionally introducing added latency though. I'm kind of stumped, so if anyone wouldn't mind taking a look at it, it'd be much appreciated :/ I don't have an MSU1 test ROM, but the latency issue may affect MSU1 as well, and that would be very bad.
2016-04-22 13:35:51 +00:00
write(mmio.dma_target + n, read(mmio.dma_source + n));
step(2);
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
}
mmio.dma = false;
}
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
exec(mmio.program_offset);
step(1);
synchronizeCPU();
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
}
auto HitachiDSP::init() -> void {
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
}
auto HitachiDSP::load() -> void {
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
}
auto HitachiDSP::unload() -> void {
rom.reset();
ram.reset();
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
}
auto HitachiDSP::power() -> void {
mmio.dma = false;
mmio.dma_source = 0x000000;
mmio.dma_length = 0x0000;
mmio.dma_target = 0x000000;
mmio.r1f48 = 0x00;
mmio.program_offset = 0x000000;
mmio.r1f4c = 0x00;
mmio.page_number = 0x0000;
mmio.program_counter = 0x00;
mmio.r1f50 = 0x33;
mmio.r1f51 = 0x00;
mmio.r1f52 = 0x01;
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
}
auto HitachiDSP::reset() -> void {
create(HitachiDSP::Enter, Frequency);
HG51B::power();
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
}
}