So after further investigation I've discovered a few things.
The reason the test app I wrote couldn't access the empty ram above 1.5 GB was due to the MMU.
I'm going to over simplify this a bit but I'm going to hit the pertinent parts.
Open Firmware Starts the machine and initialized a bunch of hardware.
The device tree defines the ram sockets and provides info as to what is installed in each socket. This is why you see 2 GB in about this mac.
This is also why apple profiler shows the correct amount of ram in each slot.
Next the rom is loaded and starts initializing a bunch of stuff.
The first thing that starts is the resource manager, then a bunch of other stuff get's initialized.
Then a simple memory manager get's started. This initializes the stack for the system components (this is what's sitting in the lower part of ram).
Now the last few things that happen during boot right before the finder is launched is where our issue starts to happen. Once extensions are all loaded the last thing that happens is the process manager is started. The simple memory manager from earlier calculates what has been allocated for the various system components and the system stack and heap and all that fun stuff. And then at the top of all that stuff is the start of ram allocated to the process manager. When the process manager get's loaded what ever loads it is setting it's limit to 1.5 gb - the system heap and stack. The process manager then starts it's own memory manager for allocating space to other apps with in it's heap. When the MMU is setup it maps the physical ram address to the virtual addresses. So virtual address 0x00000000 is physical address 0x00000000 of ram. The MMU's mapping end's the virtual ram address space at 1.5 gb which is why access above that is limited or not available. Where ever the MMU get's initialized during and after rom boot is the location of the code that needs to be patched.
This is why the access violation errors get thrown in my test program.
Okay so that's a bit rambly. But the point is when the heap get's allocated for the process manager is when the 1.5 gb limit is being set so it starts to narrow down the search and what needs to be modified to get this limit raised.
I also found another interesting tidbit in working through this. There is something mapped in the upper part of ram near the 4GB mark. This would be the absolute physical limit and as the MMU's in these machines are 32bit there will be no way to go above that. I'm suspecting that the stuff up by the 4gb limit are the address to the hardware registers (the ports and address of the graphics card for example).
I'll stop rambling now.
The reason the test app I wrote couldn't access the empty ram above 1.5 GB was due to the MMU.
I'm going to over simplify this a bit but I'm going to hit the pertinent parts.
Open Firmware Starts the machine and initialized a bunch of hardware.
The device tree defines the ram sockets and provides info as to what is installed in each socket. This is why you see 2 GB in about this mac.
This is also why apple profiler shows the correct amount of ram in each slot.
Next the rom is loaded and starts initializing a bunch of stuff.
The first thing that starts is the resource manager, then a bunch of other stuff get's initialized.
Then a simple memory manager get's started. This initializes the stack for the system components (this is what's sitting in the lower part of ram).
Now the last few things that happen during boot right before the finder is launched is where our issue starts to happen. Once extensions are all loaded the last thing that happens is the process manager is started. The simple memory manager from earlier calculates what has been allocated for the various system components and the system stack and heap and all that fun stuff. And then at the top of all that stuff is the start of ram allocated to the process manager. When the process manager get's loaded what ever loads it is setting it's limit to 1.5 gb - the system heap and stack. The process manager then starts it's own memory manager for allocating space to other apps with in it's heap. When the MMU is setup it maps the physical ram address to the virtual addresses. So virtual address 0x00000000 is physical address 0x00000000 of ram. The MMU's mapping end's the virtual ram address space at 1.5 gb which is why access above that is limited or not available. Where ever the MMU get's initialized during and after rom boot is the location of the code that needs to be patched.
This is why the access violation errors get thrown in my test program.
Okay so that's a bit rambly. But the point is when the heap get's allocated for the process manager is when the 1.5 gb limit is being set so it starts to narrow down the search and what needs to be modified to get this limit raised.
I also found another interesting tidbit in working through this. There is something mapped in the upper part of ram near the 4GB mark. This would be the absolute physical limit and as the MMU's in these machines are 32bit there will be no way to go above that. I'm suspecting that the stuff up by the 4gb limit are the address to the hardware registers (the ports and address of the graphics card for example).
I'll stop rambling now.