Menu
▾
▴
Re: [B2-devel] Macintosh memory information?
|
From: Alexander v. G. <kal...@un...> - 2012-07-19 12:23:17
|
On 18.07.2012 23:01, Michael Schmitt wrote: > Inside Macintosh: Memory is available at > > <http://developer.apple.com/legacy/mac/library/#documentation/mac/Memory/Memory-2.html> > > As far as I can tell (and I could be wrong)... > > Basilisk II supports three types of memory access modes. Which one to use > is selected at compile time: > > REAL: The addresses seen inside the emulated machine are exactly the same > as the host memory address. > > DIRECT: The addresses are shifted by a fixed offset. It calculates it at > runtime, by allocating the guest memory > block anywhere the host can find space, and then calculating the offset > between the guest and host addresses. > > VIRTUAL: The guest address space is broken down into banks, e.g. the RAM, > ROM and frame buffer are handled > separately. It uses some kind of address translation logic. These definitions seem to be swapped (as far as I can tell) https://github.com/kallisti5/sheepshear/blob/master/src/platform/Unix/main_unix.cpp#L944 The UNIX code above seems to allocate the memory anywhere available with REAL addressing, and at a fixed location with DIRECT addressing. I haven't seen and references to VIRTUAL memory access mode though. > SheepShaver (at least the 32-bit version, I don't know about 64-bit) > supports REAL and DIRECT addressing modes, but > not VIRTUAL. > > I don't know if anyone uses DIRECT in SheepShaver, because it has a fatal > flaw. Unlike Basilisk II, the offset is > calculated at *compile* time. But this only works if each user compiles > the code! And if something changes the > library address randomization (such as applying an upgrade) it invalidates > the compiled-in offset. You would need to > keep recompiling it. Of course this is completely non-portable. This may explain some of the large emulation problems seen on newer gcc + x86_64 > That leaves REAL mode. > > When running on PPC, REAL mode allows it to run virtualized instead of > emulated, where it can just let the native > processor loose on the code. Running on Intel there shouldn't be a > penalty for doing an address shift, since it has > to emulate the CPU and anyway. But it doesn't shift it, due to the way > DIRECT is implemented as described above. Given these limitations, can we put a wrapper around memory calls and adjust the memory offsets at run time? (enabling us to cherrypick whichever host memory we want to? (but we should make sure it is aligned to 1MB)) Example: Mac2HostAddr, Host2MacAddr can do address translation, so why not do the following: 1) Take a hunk of memory, allocate it large enough for RAM and ROM (aligned) for easy debugging 2) Set the RAMBaseHost to the start of the chunk of memory 3) Set the ROMBaseHost to the start of the chunk of memory + RAM size (which should be at least 1MB intervals) *) Mac2HostAddr - If we catch a RAM address (0 - 1GB) with Mac2HostAddr, point it to RAMBaseHost + mac offset *) Mac2HostAddr - If we catch a ROM address (0x40800000 - 0x40D00000), point it to the ROMBaseHost + mac offset *) Host2MacAddr - If we catch RAMBaseHost - RAM Size, subtract RAMBaseHost *) Host2MacAddr - If we catch ROMBaseHost - 5MB, subtract ROMBaseHost I don't understand the JIT stuff enough yet though to see if this would work with it. Thoughts? -- Alex > > On Jul 18, 2012, at 7:20 AM, Alexander von Gluck wrote: > >> Does anyone have any documentation on the memory layout of the old world >> Macintosh? (Performa 6400 era) >> >> I've been looking to rework how SheepShear manages memory and it's not >> completely clear to me how it does >> it's memory translation. Most of the bugs I've seen on x86_64 are due to >> the exact memory mapping on emulated >> powerpc systems (eg, hard coded memory addresses we *have* to map for >> things >> to function) and something getting mangled >> on x86_64. >> https://github.com/kallisti5/sheepshear/issues/15#issuecomment-7045089 >> >> I see memory maps for the really early Mac's, but am failing to find >> anything for the later old world machines >> online or in the old Macintosh service manuals. >> >> Here is what I know for a fact looking at the code: >> >> Low memory area, - 0x0 - 0x3000 (static 1:1 host:guest location) >> RAM, 0x0 - (memory size selected less then 1GB) >> ROM, 0x40800000 - 0x40C00000 (4MB mac rom) (static 1:1 >> host:guest location) >> >> Real addressing == "normal" allocation where memory locations are >> dynamic, >> and we translate addresses to match >> Direct addressing == memory is directly addressed, mostly used on native >> PowerPC? >> Nat_mem offset == ???, guessing it's for native PowerPC >> >> It looks given the code below that the Macintosh has to be patched to use >> the host memory >> addresses vs the emulator doing the memory translation (SheepShear acting >> as >> a mmu to the guest) >> >> https://github.com/kallisti5/sheepshear/blob/master/src/kpx_cpu/src/cpu/vm.hpp#L185 >> >> The reason I ask here is because these changes could be pulled upstream >> to >> SheepShaver. >> >> -- Thanks! >> Alex >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> _______________________________________________ >> basilisk-devel mailing list >> bas...@li... >> https://lists.sourceforge.net/lists/listinfo/basilisk-devel > > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > _______________________________________________ > basilisk-devel mailing list > bas...@li... > https://lists.sourceforge.net/lists/listinfo/basilisk-devel |
