As for having more than 16 MB, I think it can also be handled
directly in Hatari in memory.c, because we already do our own
translations (for example to map IO regs at $ffffxxxx to $00ffxxxx).
These translations are done at the memory_bank level, without
requiring an MMU, so it doesn't add any cost since that's the
generic mechanism when Hatari wants to translate a logical address
in ST space to the physical address in the PC space.
This is probably be best place to do it - but I suspect the 68030 PMMU
tree will not permit the CPU to 'see' that mapped memory, without
modifying it. It gets first chance at translation, and the default
translation is repeat-or-buserr, from $01000000 onwards, and then the
whole lot is repeated again, noncacheable (IIRC - may have mixed up a
couple of details).
Unless Hatari is getting between the 030 and its PMMU?
Still - it makes more sense for it to work that way, and perhaps use
software (AUTO folder) to modify PMMU on the emulation side to make it
visible?
I can dig out the TOS 4.04 PMMU memory map later and post it here if it
helps any.