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

61 lines
1.1 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.dmaLength)) {
write(mmio.dmaTarget + n, read(mmio.dmaSource + n));
step(2);
Update to v100r14 release. byuu says: (Windows: compile with -fpermissive to silence an annoying error. I'll fix it in the next WIP.) I completely replaced the time management system in higan and overhauled the scheduler. Before, processor threads would have "int64 clock"; and there would be a 1:1 relationship between two threads. When thread A ran for X cycles, it'd subtract X * B.Frequency from clock; and when thread B ran for Y cycles, it'd add Y * A.Frequency from clock. This worked well and allowed perfect precision; but it doesn't work when you have more complicated relationships: eg the 68K can sync to the Z80 and PSG; the Z80 to the 68K and PSG; so the PSG needs two counters. The new system instead uses a "uint64 clock" variable that represents time in attoseconds. Every time the scheduler exits, it subtracts the smallest clock count from all threads, to prevent an overflow scenario. The only real downside is that rounding errors mean that roughly every 20 minutes, we have a rounding error of one clock cycle (one 20,000,000th of a second.) However, this only applies to systems with multiple oscillators, like the SNES. And when you're in that situation ... there's no such thing as a perfect oscillator anyway. A real SNES will be thousands of times less out of spec than 1hz per 20 minutes. The advantages are pretty immense. First, we obviously can now support more complex relationships between threads. Second, we can build a much more abstracted scheduler. All of libco is now abstracted away completely, which may permit a state-machine / coroutine version of Thread in the future. We've basically gone from this: auto SMP::step(uint clocks) -> void { clock += clocks * (uint64)cpu.frequency; dsp.clock -= clocks; if(dsp.clock < 0 && !scheduler.synchronizing()) co_switch(dsp.thread); if(clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread); } To this: auto SMP::step(uint clocks) -> void { Thread::step(clocks); synchronize(dsp); synchronize(cpu); } As you can see, we don't have to do multiple clock adjustments anymore. This is a huge win for the SNES CPU that had to update the SMP, DSP, all peripherals and all coprocessors. Likewise, we don't have to synchronize all coprocessors when one runs, now we can just synchronize the active one to the CPU. Third, when changing the frequencies of threads (think SGB speed setting modes, GBC double-speed mode, etc), it no longer causes the "int64 clock" value to be erroneous. Fourth, this results in a fairly decent speedup, mostly across the board. Aside from the GBA being mostly a wash (for unknown reasons), it's about an 8% - 12% speedup in every other emulation core. Now, all of this said ... this was an unbelievably massive change, so ... you know what that means >_> If anyone can help test all types of SNES coprocessors, and some other system games, it'd be appreciated. ---- Lastly, we have a bitchin' new about screen. It unfortunately adds ~200KiB onto the binary size, because the PNG->C++ header file transformation doesn't compress very well, and I want to keep the original resource files in with the higan archive. I might try some things to work around this file size increase in the future, but for now ... yeah, slightly larger archive sizes, sorry. The logo's a bit busted on Windows (the Label control's background transparency and alignment settings aren't working), but works well on GTK. I'll have to fix Windows before the next official release. For now, look on my Twitter feed if you want to see what it's supposed to look like. ---- EDIT: forgot about ICD2::Enter. It's doing some weird inverse run-to-save thing that I need to implement support for somehow. So, save states on the SGB core probably won't work with this WIP.
2016-07-30 03:56:12 +00:00
synchronize(cpu);
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.programOffset);
step(1);
Update to v100r14 release. byuu says: (Windows: compile with -fpermissive to silence an annoying error. I'll fix it in the next WIP.) I completely replaced the time management system in higan and overhauled the scheduler. Before, processor threads would have "int64 clock"; and there would be a 1:1 relationship between two threads. When thread A ran for X cycles, it'd subtract X * B.Frequency from clock; and when thread B ran for Y cycles, it'd add Y * A.Frequency from clock. This worked well and allowed perfect precision; but it doesn't work when you have more complicated relationships: eg the 68K can sync to the Z80 and PSG; the Z80 to the 68K and PSG; so the PSG needs two counters. The new system instead uses a "uint64 clock" variable that represents time in attoseconds. Every time the scheduler exits, it subtracts the smallest clock count from all threads, to prevent an overflow scenario. The only real downside is that rounding errors mean that roughly every 20 minutes, we have a rounding error of one clock cycle (one 20,000,000th of a second.) However, this only applies to systems with multiple oscillators, like the SNES. And when you're in that situation ... there's no such thing as a perfect oscillator anyway. A real SNES will be thousands of times less out of spec than 1hz per 20 minutes. The advantages are pretty immense. First, we obviously can now support more complex relationships between threads. Second, we can build a much more abstracted scheduler. All of libco is now abstracted away completely, which may permit a state-machine / coroutine version of Thread in the future. We've basically gone from this: auto SMP::step(uint clocks) -> void { clock += clocks * (uint64)cpu.frequency; dsp.clock -= clocks; if(dsp.clock < 0 && !scheduler.synchronizing()) co_switch(dsp.thread); if(clock >= 0 && !scheduler.synchronizing()) co_switch(cpu.thread); } To this: auto SMP::step(uint clocks) -> void { Thread::step(clocks); synchronize(dsp); synchronize(cpu); } As you can see, we don't have to do multiple clock adjustments anymore. This is a huge win for the SNES CPU that had to update the SMP, DSP, all peripherals and all coprocessors. Likewise, we don't have to synchronize all coprocessors when one runs, now we can just synchronize the active one to the CPU. Third, when changing the frequencies of threads (think SGB speed setting modes, GBC double-speed mode, etc), it no longer causes the "int64 clock" value to be erroneous. Fourth, this results in a fairly decent speedup, mostly across the board. Aside from the GBA being mostly a wash (for unknown reasons), it's about an 8% - 12% speedup in every other emulation core. Now, all of this said ... this was an unbelievably massive change, so ... you know what that means >_> If anyone can help test all types of SNES coprocessors, and some other system games, it'd be appreciated. ---- Lastly, we have a bitchin' new about screen. It unfortunately adds ~200KiB onto the binary size, because the PNG->C++ header file transformation doesn't compress very well, and I want to keep the original resource files in with the higan archive. I might try some things to work around this file size increase in the future, but for now ... yeah, slightly larger archive sizes, sorry. The logo's a bit busted on Windows (the Label control's background transparency and alignment settings aren't working), but works well on GTK. I'll have to fix Windows before the next official release. For now, look on my Twitter feed if you want to see what it's supposed to look like. ---- EDIT: forgot about ICD2::Enter. It's doing some weird inverse run-to-save thing that I need to implement support for somehow. So, save states on the SGB core probably won't work with this WIP.
2016-07-30 03:56:12 +00:00
synchronize(cpu);
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.dmaSource = 0x000000;
mmio.dmaLength = 0x0000;
mmio.dmaTarget = 0x000000;
mmio.r1f48 = 0x00;
mmio.programOffset = 0x000000;
mmio.r1f4c = 0x00;
mmio.pageNumber = 0x0000;
mmio.programCounter = 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
}
}