mem_map_funcs: Range overlaps about citra HOT 4 CLOSED

The way the emulator handles memory access (using VAddrs to control hardware access) is flawed, so I think that's where this inconsistency comes from. The page in 3dbrew has the ranges overlapping too, but note how it says that these mappings depend on the exheader. So fact is that different processes will have different things mapped in these addresses. We can't really resolve this unless we move to a proper virtual memory scheme, I think. For now we can probably just chop off the I/O range, since we shouldn't be using it directly.

from citra.

Yeah, as @yuriks said, our way of dealing with memory access is completely broken.
As it stands, our internal memory representation is based on virtual memory - hence we have things like the GSP memory as the "fundamental" objects representing FCRAM internally. All accesses to physical addresses first need to be reverse-translated to virtual addresses, and just hope that there are no clashes going on. This is critical because the addresses submitted in GPU command lists are physical ones.

Instead of the current implementation, we should IMO store physical memory regions internally, and implement a dummy MMU miming a memory layout like http://3dbrew.org/wiki/Virtual_address_mapping_FW0B (or some more recent FW version) to translate physical to virtual addresses.

from citra.

Small correction: The FW0B virtual address mapping of course is kernel address space, while we would rather want to hardcode the NATIVE_FIRM userland memory layout as described on http://3dbrew.org/wiki/Memory_layout#ARM11_User-land_memory_regions for now.

from citra.

This isn't an issue anymore considering this code was rewritten a while ago.

from citra.