Page 1 of 1
Better way to WRITE/READ from CPU memory
Posted: Mon Aug 21, 2006 5:01 am
by dreampeppers99
Using java is better use this.
private static int[256][256] mem;
public void write(int adrs,byte dat)
{
mem[adrs>>8][adrs%256] = dat;
}
public byte read(int adrs)
{
return mem[adrs>>8][adrs%256];
}
Or this.
private static int[65536] mem;
public void write(int adrs,byte dat)
{
mem[adrs] = dat;
}
public byte read(int adrs)
{
return mem[adrs] ;
}
Posted: Mon Aug 21, 2006 5:40 am
by Quietust
First of all, in both places "mem" should be declared as byte, not int.
The first example only makes sense if each of the 256 slots in "mem" can be dynamically reassigned to new 256-byte arrays (equivalent to doing "unsigned char *mem[256];" in C). Even so, 256 bytes is rather small for a page size - 4096 bytes makes a bit more sense for CPU bank switching. Otherwise, the latter will be faster.
Posted: Mon Aug 21, 2006 5:52 am
by dreampeppers99
Quietust wrote:First of all, in both places "mem" should be declared as byte, not int.
The first example only makes sense if each of the 256 slots in "mem" can be dynamically reassigned to new 256-byte arrays (equivalent to doing "unsigned char *mem[256];" in C). Even so, 256 bytes is rather small for a page size - 4096 bytes makes a bit more sense for CPU bank switching. Otherwise, the latter will be faster.
thanks so much.
What is the advantage in use a banks of 4096 and not 256? I was thinking that i will need to make it equal to original NES.
It can help on the memory mappers? (on the latter)
Thanks again.
Posted: Mon Aug 21, 2006 6:04 pm
by tepples
dreampeppers99 wrote:What is the advantage in use a banks of 4096 and not 256?
I'm guessing that the known NES mapper with the smallest banks works in 4096 byte banks. Also, when you have a mapper write that switches the banks, you only need to update one to eight internal banks, not 16 to 128.