Mac OS 9.2.2 Memory Limit of 1.5 GB... Some Answers

[nanopico]

So you install 2 GB of ram and OS 9.  Then you go to about this mac and you see that hey the system recognizes that there is 2GB of ram!!! And you get all excited until you notice that Mac OS takes up 512-540 MB (give or take) 
This is not new I know.  DieHard pointed the out to me and directed me towards this discussion
http://macos9lives.com/smforum/index.php?topic=2101.msg10905#msg10905

I've posted elsewhere some theory's I had while examining memory.
So using an iBook with 320 MB of ram I found that the system heap and stack along with some rom space and some other system stuff sits at the bottom of ram (starting at or around address 00002800).  Once the process manager starts it claims the rest of the memory for it's heap except for a little bit at the top which it is allocated for it's stack.
For those of you who don't know, the heap is the working memory where your data is stored and the stack is the memory where the actually executable code is stored.  Because os 9 does not have protected memory you can write apps that pretty much read anything.  With protected memory apps are usually given a virtual address space so it thinks it starts at address 0 the os then translate that to physical addresses.  The heap for the app is then marked as non-executable though on some systems you can override that ins some creative ways.
Back on track though.  So when the system boots it get's the ram size information from Open Firmware.  The memory manager I believe starts before the process manager (don't quote me on that as I haven't confirmed this yet). So the os is fully aware at this point of the 2 GB installed.  Depending on which starts first will be where the ram get's allocated to the process manager. When about this mac shows that MacOS takes 540 MB it's actually not really true.
Looking at the heaps and stack allocations, the system files are still only taking 30-40 or whatever your system uses depending on extensions and what not.
For MacOS memory usage (which is not handled by the process manager) it takes the total ram installed and subtracts what is allocated to the process manager, and assumes what is left is allocated to the system.
So that is where the number comes from.
So poking around with MacsBug you can look at what is in the ram above 1.5 gb.  Guys what there is nothing (no surprise there).  It's all initialized to zero.
So next step is to write a program to put data into memory addresses above the 1.GB limit.
Then use MacsBug to verify it is there.  If that works then it tells us that the memory is addressable and the potential of some sort of ram disk up there is possible (though not necessarily easy in any way).
Just thought I'd share this bit of info.

[DieHard]

Wow.... you kinda remind me of iMic's brother... you are going where nobody went before.. Awesome work !

[nanopico]

Thanks. I just hope I can actually produce something with all my findings.

[Philgood]

Let's get started!
Will 2016 be the year of somewhat bigger for our beloved OS9...maybe we can get the attention of some former Apple engineers to help us

[MacTron]

For MacOS memory usage (which is not handled by the process manager) it takes the total ram installed and subtracts what is allocated to the process manager, and assumes what is left is allocated to the system.
So that is where the number comes from.
So poking around with MacsBug you can look at what is in the ram above 1.5 gb.  Guys what there is nothing (no surprise there).  It's all initialized to zero.
So next step is to write a program to put data into memory addresses above the 1.GB limit.
Then use MacsBug to verify it is there.  If that works then it tells us that the memory is addressable and the potential of some sort of ram disk up there is possible (though not necessarily easy in any way).
Just thought I'd share this bit of info.

This is becoming into something really interesting ... 

[greatinterface]

lets get those 2 gigs working ,just picked up a lovely 23 inch apple display for $50 on craigs list ,bad news my scripts did not copy properly on the boot disc for my "drive cloning"  aka restore project ,will have to try unstuffing on different machine

[nanopico]

Another fun update.
A. I'm still not sure how the hardware MMU plays into this whole thing.  Not sure if OS 9 initializes that differently than OS x or it has something odd to do with maybe it's using a signed int for memory address (that would be odd and not fun to break). I only mention this because hardware is also placed with in the address space accessed by the MMU and you should keep that in mind with the next part.

B.  I have a fun utility/crude app I wrote to do some memory test from with in the OS.
  I'm going to share it with anyone who want's to play with it, but first some disclaimers.
1.  It's a very crude, basic app with no error checking/handling.  Yes it's easy to crash it (and actually that's part of the intent for what I'm doing with it.
2.  The user has control of the memory it accesses. So if you put in an address that is mapped to firmware, video card, any other hardware, then it will write some data to it and it very well could break things.  Just so you know.

So this app doesn't directly cause harm unless the user enters and address that could corrupt things.

So here's what it does. 
When it loads it loads with a heap size between 512K and 1MB.
Once loaded it try's to allocated a chunk of memory that is 10 MB in size.  This is using built in system calls for memory.  Since the heap is way under 10 MB this allocation request fails which is exactly what it should do.
Next it asks the you for a memory address.  You must enter it in hexadecimal.  There is no error checking on that so if you enter a non-hex value it will probably crash on that. Since this is fairly useless of an app and more of a test I'm not going to fix that.
After you provide it an address it starts at that address and writes a 32bit integer to the address, moves to the next address writes an integer 1 larger than the previous, ...etc  until it has done this for 10 mb.
If the memory is addressed that test will pass and it will move on to read that data and compare it to what it put in.  If something doesn't match it will give you the address it didn't match.
That's it.  For memory with in the 1.5 gb range and that isn't allocated to anything this all passes as it should (being that the first one fails intentionaly. 
All this really does is determine if a specific memory address is accessible from an application without using the OS memory/process manager routines. 

So in using it I've found that with in the 1.5 GB limit or what the max ram of your machine is, all this works.   Trying to access ram above 1.5 gb fails.  Not sure why yet, but it flat out failed. So from within an application that extra 512 mb is not accessible, yet.

Also just a few other disclaimers.
Putting addresses below 60 mb or so will crash/lock up your system.  On some of my test it grey screened and locked up, some froze the display and then locked up.  In both cases it messed up macsbug enough that I couldn't even enter it.  So please use caution when using this.  I am absolutely not responsible if you brick your system using this. 

Have fun.

[DieHard]

Gonna have to fire up a G4 this weekend and crash it a bunch of times, sounds like fun, thanks nanopico

[nanopico]

One address I can say don't use is 0x10 (16 decimal) 
It didn't really screw anything up major, but it took a few reboots before my iBook would boot up.  Have fun with it.

[nanopico]

One small correction.
I stated that the little utility I posted tried to write 10 MB of data to a place of your choosing.
That was wrong.  The first version I wrote used a 8 bit pointer so it did write 10 MB.  The version I posted uses a 32 bit pointer, so it writes 40 MB.
Just wanted to clarify that for any one trying it.

[nanopico]

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.

[GaryN]

Ramble on anytime, man. Possibly a few of us blockheads might learn something!

[mrhappy]

Yes indeed!!

[nanopico]

Except some of my ramblings are incorrect while I figure this stuff out. (though they are getting more accurate the further down the rabbit hole I go).

Ramble on anytime, man. Possibly a few of us blockheads might learn something!

I think I might have a possible explanation for the 1.5 GB limit.
By the time any machines could physically handle 2GB of ram, OS X was already in the works.
It was probably though as a low priority to re-write/patch the memory manager/process manager to allow more ram.  Why there was a limit in the first place is beyond me.
But what lead me to the 1.5 GB limit reason is the 9600.  Even though official support was 756 MB apple was probably aware that it could handle 1.5 GB. At that time any of the next generation OS's where in such early stages there was no foreseeable future.  Customers would probably complain if they couldn't use all the ram so the parts of the os that handle that would have been updated and the 1.5 GB limit was probably chosen for that reason.

Again just speculation, but after having worked on all sorts of dev project the past 15 years I can say these things do happen a lot with out much forward thought.

[nanopico]

So I've been studying the CPU registers that control the MMU (memory management unit).
So the Block Address Translation tables are pointed to by CPU registers. These control the mapping of the addresses from what applications see to physical hardware address. They are only accessible from code executing in the Supervisory context of the processor (usually this is the os) and the guest process (user programs) as some access to this.  Not all OS's use the guest process for running applications though.  This might actually be the case with the Mac OS as that is usually needed to provide protected memory (which will all know is non-existent in OS 9) but I really don't know right now the reality of this.  At a minimum I can read most of those.  So next step is reading in these tables and seeing what's mapped where and this will give a more definitive idea of what is located where in memory.

One small kill joy though.  The PPC spec that explains the MMU registers does have some notes about 64bit cpu's (the G5).  So some of the Opcodes for accessing the registers are explicitly not supported on 64bit cpus even if the cpu is running in 32 bit mode.  In OS X the memory management routines probably account for this which is why on the G5 you could have more than 4GB of ram in a 32bit os.  OS 9 probably did depend on some if not all of these 32bit only opcodes and registers.  So we now have two major hardware roadblocks to overcome if there is ever any hope of G5 support.  1. the mmu opcodes/registers and 2. the UniNorth 3 bridge.

Also in looking through this I looked more at the PVR and PIR registers.  (these are the Processor ID and Processor Version).
The cpu upgrades that update open firmware through nvram scripts to get newer g4 cpus working, are modifying these.
So now that I know the registers I can find where Mac OS checks those registers.  Then it should help in looking for the list of values the register is compared against to update that to get more cpu's support with out nvram scripts or changing values in open firmware.

[DieHard]

I live for these updates on the progress, and appreciate all the details

Thanks...

[nanopico]

I live for these updates on the progress, and appreciate all the details

Thanks...

Thanks.  I'm starting to get to the point where it is shifting from theoretical to actual.  I'm definitely running into things that I have a hard time understanding the reasoning for, which make's it a little hard to explain.  But man this is getting to be real fun.

[nanopico]

Tiny update  here.

Macsbug thinks there is no mmu installed on g3's and g4's. This would indicate that it might not be running in the supervisor level of the cpu (though as a low level debugger I find that kind of hard to believe).  This makes it kind of hard to use to view the mmu registers which control all the pages and maps and segments and fun stuff.  It might just be that macsbug (being that it was originally for the 68k macs) just doesn't know the instructions or how to access the mmu on powerpc's.

So now I have to write some assembly code to read the mmu registers and dump them out.
Once I have something working there I might ask if any one can run it on their machines and provide me the output so I can see how different configurations are mapped?  I have several machines I will run it on, but the more the merrier right?

[Protools5LEGuy]

Count with me for any test in my 867 dual with 2Gigs of RAM

[Veneteaou]

I've can throw in:

- G3 Clamshell iBook 300MHZ
- G4 867MHz Powerbook G4
- G3 800/900MHZ iBook
- G3 350MHz Blue & White tower

I can test it on all of those.