Consider that if guest 0x0 is actually in the middle of the host space, then some of the high guest space is actually less than it.
Basilisk ii add more memory code#
When I looked at the DIRECT code I wasn't sure if it could handle 32-bit wrap-around access properly. What we would want is to translate all of the addresses: the low system globals at 0x0, the special data areas, etc.
Basilisk ii add more memory mac os#
> I don't understand the JIT stuff enough yet though to see if this would workĮssentially that would be changing SheepShaver to use the same DIRECT mode as Basilisk II (if all addresses are shifted by the same offset), or Basilisk II's VIRTUAL mode, which currently is not in SheepShaver.īut since the Mac OS doesn't need to have the RAM and ROM at any particular address, simply shifting the host-to-guest RAM/ROM addresses doesn't buy us much. > *) Host2MacAddr - If we catch ROMBaseHost - 5MB, subtract ROMBaseHost > *) Host2MacAddr - If we catch RAMBaseHost - RAM Size, subtract RAMBaseHost > point it to the ROMBaseHost + mac offset > *) Mac2HostAddr - If we catch a RAM address (0 - 1GB) with Mac2HostAddr, > (which should be at least 1MB intervals) > 3) Set the ROMBaseHost to the start of the chunk of memory + RAM size > 2) Set the RAMBaseHost to the start of the chunk of memory > 1) Take a hunk of memory, allocate it large enough for RAM and ROM > Mac2HostAddr, Host2MacAddr can do address translation, so why not do the It doesn't matter if the host address is aligned. Remember it is the guest ROM rom address that needs to be aligned. > us to cherrypick whichever host memory we want to? (but we should make sure > the memory offsets at run time? (enabling > Given these limitations, can we put a wrapper around memory calls and adjust > DIRECT is implemented as described above. > penalty for doing an address shift, since it has > emulated, where it can just let the native > When running on PPC, REAL mode allows it to run virtualized instead of > This may explain some of the large emulation problems seen on newer gcc + Of course this is completely non-portable. > library address randomization (such as applying an upgrade) it invalidates But this only works if each user compiles > I don't know if anyone uses DIRECT in SheepShaver, because it has a fatal > supports REAL and DIRECT addressing modes, but > SheepShaver (at least the 32-bit version, I don't know about 64-bit) In DIRECT mode the memory is allocated at a fixed address (that in SS is determined at compile time), and then the addresses are translated so the guest sees RAM starting at zero. But once it is allocated, the address the guest sees is exactly the host address where the block was allocated. In REAL mode SS allocates the HOST block where ever it can. That's because first I was describing how the Basilisk II code works, from which SheepShaver is derived. > I haven't seen and references to VIRTUAL memory access mode though.
> REAL addressing, and at a fixed location > The UNIX code above seems to allocate the memory anywhere available with > These definitions seem to be swapped (as far as I can tell) It uses some kind of address translation logic. > VIRTUAL: The guest address space is broken down into banks, e.g. > block anywhere the host can find space, and then calculating the offset > runtime, by allocating the guest memory
> DIRECT: The addresses are shifted by a fixed offset. > REAL: The addresses seen inside the emulated machine are exactly the same > Basilisk II supports three types of memory access modes. > As far as I can tell (and I could be wrong).
> Inside Macintosh: Memory is available at On Jul 19, 2012, at 7:23 AM, Alexander von Gluck wrote:
0 kommentar(er)
