bsnes/higan/sfc/memory/memory.cpp

62 lines
1.5 KiB
C++
Raw Normal View History

#include <sfc/sfc.hpp>
#define MEMORY_CPP
namespace SuperFamicom {
Bus bus;
void Bus::map(
MapMode mode,
Update to v074r03 release. byuu says: You guys are going to hate the hell out of this one. It's twenty hours of non-stop work, no exaggeration at all. Started at 4AM, just wrapped up now at 8PM. I rewrote the entire memory subsystem. Old system: 65536 pages that map 256 bytes each Mapping a new page overwrites old page Granularity capped at 256 bytes minimum, requiring ST-001x to map 60:0000-00ff instead of 60:0000,0001 Classes inherit from MMIO and Memory, forcing only one mappable function per class, and fixed names MMIO sub-mapper inside memory: 00-3f:2000-5fff for one-byte granularity Can dynamically change the map at run-time, MMC register settings perform dynamic remapping New system: XML mapping is still based around banklo-bankhi:addrlo-addrhi, as that shapes almost everything on the SNES very well Internally, 2048 pages that map 8192 bytes each Pages are vectors, scans O(n) from last to first (O(log n) would not help, n is never > 3) Can multi-cast writes, but not reads [for the obvious reason of: which read do you return?] Can map reads and writes separately Granularity of one for entire 24-bit address range, no need for MMIO - whatever is in XML is exactly what you get Read/Write tables bind function callbacks, so I can have any number of functions with any names from any classes with no inheritance (no more uPD7725DR, uPD7725SR helpers, etc) Less memory usage overall due to less tables [ I tried 16 million tables and it used 2GB of RAM >_o ] Cannot dynamically change the map at run-time, MMC read/write functions perform address translation [worse average case speed, better worst case speed] Now the hate me part, functors can't beat virtual functions for speed. There are speed penalties involved: -4.5% on average games -11% on SuperFX games (SFX has its own bus) -15% on SA-1 games (SA-1 has two buses) Of course the two that need the speed the most get the biggest hits. I'm afraid there's really not a lot of wiggle room to boost speed back up. I suppose one bright spot is that we can much more easily try out entirely new mapping systems now, since the dynamic portions have been eliminated.
2011-01-15 04:30:29 +00:00
unsigned bank_lo, unsigned bank_hi,
unsigned addr_lo, unsigned addr_hi,
const function<uint8 (unsigned)> &rd,
const function<void (unsigned, uint8)> &wr,
unsigned base, unsigned length
) {
Update to v074r03 release. byuu says: You guys are going to hate the hell out of this one. It's twenty hours of non-stop work, no exaggeration at all. Started at 4AM, just wrapped up now at 8PM. I rewrote the entire memory subsystem. Old system: 65536 pages that map 256 bytes each Mapping a new page overwrites old page Granularity capped at 256 bytes minimum, requiring ST-001x to map 60:0000-00ff instead of 60:0000,0001 Classes inherit from MMIO and Memory, forcing only one mappable function per class, and fixed names MMIO sub-mapper inside memory: 00-3f:2000-5fff for one-byte granularity Can dynamically change the map at run-time, MMC register settings perform dynamic remapping New system: XML mapping is still based around banklo-bankhi:addrlo-addrhi, as that shapes almost everything on the SNES very well Internally, 2048 pages that map 8192 bytes each Pages are vectors, scans O(n) from last to first (O(log n) would not help, n is never > 3) Can multi-cast writes, but not reads [for the obvious reason of: which read do you return?] Can map reads and writes separately Granularity of one for entire 24-bit address range, no need for MMIO - whatever is in XML is exactly what you get Read/Write tables bind function callbacks, so I can have any number of functions with any names from any classes with no inheritance (no more uPD7725DR, uPD7725SR helpers, etc) Less memory usage overall due to less tables [ I tried 16 million tables and it used 2GB of RAM >_o ] Cannot dynamically change the map at run-time, MMC read/write functions perform address translation [worse average case speed, better worst case speed] Now the hate me part, functors can't beat virtual functions for speed. There are speed penalties involved: -4.5% on average games -11% on SuperFX games (SFX has its own bus) -15% on SA-1 games (SA-1 has two buses) Of course the two that need the speed the most get the biggest hits. I'm afraid there's really not a lot of wiggle room to boost speed back up. I suppose one bright spot is that we can much more easily try out entirely new mapping systems now, since the dynamic portions have been eliminated.
2011-01-15 04:30:29 +00:00
assert(bank_lo <= bank_hi && bank_lo <= 0xff);
assert(addr_lo <= addr_hi && addr_lo <= 0xffff);
unsigned id = idcount++;
assert(id < 255);
reader[id] = rd;
writer[id] = wr;
Update to v074r03 release. byuu says: You guys are going to hate the hell out of this one. It's twenty hours of non-stop work, no exaggeration at all. Started at 4AM, just wrapped up now at 8PM. I rewrote the entire memory subsystem. Old system: 65536 pages that map 256 bytes each Mapping a new page overwrites old page Granularity capped at 256 bytes minimum, requiring ST-001x to map 60:0000-00ff instead of 60:0000,0001 Classes inherit from MMIO and Memory, forcing only one mappable function per class, and fixed names MMIO sub-mapper inside memory: 00-3f:2000-5fff for one-byte granularity Can dynamically change the map at run-time, MMC register settings perform dynamic remapping New system: XML mapping is still based around banklo-bankhi:addrlo-addrhi, as that shapes almost everything on the SNES very well Internally, 2048 pages that map 8192 bytes each Pages are vectors, scans O(n) from last to first (O(log n) would not help, n is never > 3) Can multi-cast writes, but not reads [for the obvious reason of: which read do you return?] Can map reads and writes separately Granularity of one for entire 24-bit address range, no need for MMIO - whatever is in XML is exactly what you get Read/Write tables bind function callbacks, so I can have any number of functions with any names from any classes with no inheritance (no more uPD7725DR, uPD7725SR helpers, etc) Less memory usage overall due to less tables [ I tried 16 million tables and it used 2GB of RAM >_o ] Cannot dynamically change the map at run-time, MMC read/write functions perform address translation [worse average case speed, better worst case speed] Now the hate me part, functors can't beat virtual functions for speed. There are speed penalties involved: -4.5% on average games -11% on SuperFX games (SFX has its own bus) -15% on SA-1 games (SA-1 has two buses) Of course the two that need the speed the most get the biggest hits. I'm afraid there's really not a lot of wiggle room to boost speed back up. I suppose one bright spot is that we can much more easily try out entirely new mapping systems now, since the dynamic portions have been eliminated.
2011-01-15 04:30:29 +00:00
if(length == 0) length = (bank_hi - bank_lo + 1) * (addr_hi - addr_lo + 1);
unsigned offset = 0;
for(unsigned bank = bank_lo; bank <= bank_hi; bank++) {
for(unsigned addr = addr_lo; addr <= addr_hi; addr++) {
unsigned destaddr = (bank << 16) | addr;
if(mode == MapMode::Linear) destaddr = mirror(base + offset++, length);
if(mode == MapMode::Shadow) destaddr = mirror(base + destaddr, length);
lookup[(bank << 16) | addr] = id;
target[(bank << 16) | addr] = destaddr;
Update to v074r03 release. byuu says: You guys are going to hate the hell out of this one. It's twenty hours of non-stop work, no exaggeration at all. Started at 4AM, just wrapped up now at 8PM. I rewrote the entire memory subsystem. Old system: 65536 pages that map 256 bytes each Mapping a new page overwrites old page Granularity capped at 256 bytes minimum, requiring ST-001x to map 60:0000-00ff instead of 60:0000,0001 Classes inherit from MMIO and Memory, forcing only one mappable function per class, and fixed names MMIO sub-mapper inside memory: 00-3f:2000-5fff for one-byte granularity Can dynamically change the map at run-time, MMC register settings perform dynamic remapping New system: XML mapping is still based around banklo-bankhi:addrlo-addrhi, as that shapes almost everything on the SNES very well Internally, 2048 pages that map 8192 bytes each Pages are vectors, scans O(n) from last to first (O(log n) would not help, n is never > 3) Can multi-cast writes, but not reads [for the obvious reason of: which read do you return?] Can map reads and writes separately Granularity of one for entire 24-bit address range, no need for MMIO - whatever is in XML is exactly what you get Read/Write tables bind function callbacks, so I can have any number of functions with any names from any classes with no inheritance (no more uPD7725DR, uPD7725SR helpers, etc) Less memory usage overall due to less tables [ I tried 16 million tables and it used 2GB of RAM >_o ] Cannot dynamically change the map at run-time, MMC read/write functions perform address translation [worse average case speed, better worst case speed] Now the hate me part, functors can't beat virtual functions for speed. There are speed penalties involved: -4.5% on average games -11% on SuperFX games (SFX has its own bus) -15% on SA-1 games (SA-1 has two buses) Of course the two that need the speed the most get the biggest hits. I'm afraid there's really not a lot of wiggle room to boost speed back up. I suppose one bright spot is that we can much more easily try out entirely new mapping systems now, since the dynamic portions have been eliminated.
2011-01-15 04:30:29 +00:00
}
}
}
void Bus::map_reset() {
function<uint8 (unsigned)> reader = [](unsigned) { return cpu.regs.mdr; };
function<void (unsigned, uint8)> writer = [](unsigned, uint8) {};
idcount = 0;
map(MapMode::Direct, 0x00, 0xff, 0x0000, 0xffff, reader, writer);
}
void Bus::map_xml() {
for(auto &m : cartridge.mapping) {
Update to v074r03 release. byuu says: You guys are going to hate the hell out of this one. It's twenty hours of non-stop work, no exaggeration at all. Started at 4AM, just wrapped up now at 8PM. I rewrote the entire memory subsystem. Old system: 65536 pages that map 256 bytes each Mapping a new page overwrites old page Granularity capped at 256 bytes minimum, requiring ST-001x to map 60:0000-00ff instead of 60:0000,0001 Classes inherit from MMIO and Memory, forcing only one mappable function per class, and fixed names MMIO sub-mapper inside memory: 00-3f:2000-5fff for one-byte granularity Can dynamically change the map at run-time, MMC register settings perform dynamic remapping New system: XML mapping is still based around banklo-bankhi:addrlo-addrhi, as that shapes almost everything on the SNES very well Internally, 2048 pages that map 8192 bytes each Pages are vectors, scans O(n) from last to first (O(log n) would not help, n is never > 3) Can multi-cast writes, but not reads [for the obvious reason of: which read do you return?] Can map reads and writes separately Granularity of one for entire 24-bit address range, no need for MMIO - whatever is in XML is exactly what you get Read/Write tables bind function callbacks, so I can have any number of functions with any names from any classes with no inheritance (no more uPD7725DR, uPD7725SR helpers, etc) Less memory usage overall due to less tables [ I tried 16 million tables and it used 2GB of RAM >_o ] Cannot dynamically change the map at run-time, MMC read/write functions perform address translation [worse average case speed, better worst case speed] Now the hate me part, functors can't beat virtual functions for speed. There are speed penalties involved: -4.5% on average games -11% on SuperFX games (SFX has its own bus) -15% on SA-1 games (SA-1 has two buses) Of course the two that need the speed the most get the biggest hits. I'm afraid there's really not a lot of wiggle room to boost speed back up. I suppose one bright spot is that we can much more easily try out entirely new mapping systems now, since the dynamic portions have been eliminated.
2011-01-15 04:30:29 +00:00
map(m.mode, m.banklo, m.bankhi, m.addrlo, m.addrhi, m.read, m.write, m.offset, m.size);
}
}
Bus::Bus() {
lookup = new uint8 [16 * 1024 * 1024];
target = new uint32[16 * 1024 * 1024];
}
Bus::~Bus() {
delete[] lookup;
delete[] target;
}
}