Finally got back around to looking at this 1.5 GB limit we are stuck with.
I'll just pre-empt this with the following statement.
No real progress has been made, I've just been starting to dig into again and thought I'd share a few things.
Some of this info may be known to some and some if it may be new. This may turn into a bit of a ramble, but just want to share.
Just a little info for those that don't know (I think many people here will know this little bit).
32 Bit systems have a 32 bit address space meaning they can address 4 GB of information. I say information as the address space is 4GB in size, but due to limitations in the memory controller (not the MMU mind you) a CPU may not get access to 4 GB of RAM. So keep that in mind that having a 4 GB address range does not equal access to 4 GB of RAM.
G4 systems (not all of them) do have a memory controller capable of accessing up to 2 GB of RAM.
To access hardware devices some of the 4 GB address space is used for IO so the MMU (Memory Management Unit) Maps Addresses from the 4 GB space to the hardware's addresses.
Mac OS 9 like many other OS's uses the highest range of address space for the IO mapping.
For instance on my clamshell G3 iBook there is 16 MB of the address space allocated to IO. Since that machine has an 8 MB AGP video card in, 8 MB of that 16 MB is actually video RAM while the other 8 is there for all the other devices IO.
I wrote a little utility to read from arbitrary address ranges and dump it to a file. So I was able to read the full IO address range and dump everything it read to a file. Nothing special there or exciting really. Though I did find it fun when It got to the addresses for the optical drive that it started to spin up and read the drive.
Back to the address range though. So on my iBook the address range 0xFF000000 - 0xFFFFFFFF is used for IO that is the top 16 MB up to the 4 GB top of the address range.
Again as previously stated this is probably not new info to some of you, but some people here may find this interesting.
Now let's move down a little further in the address space.
Quick disclaimer. I was doing most of this so far on my iBook which has only 320 MB of RAM installed. I don't have any of my G4 systems set up at the moment as I had to put them away to make room for my day job when I was working from home for a while.
I'll get them back set up and run through some of this on those machines soon so that I can get actual details off a G4 machine.
After poking around the various addresses around 1.5 GB I couldn't find anything mapped there.
We do know the 68K Emulator is up in that sort of range and that has always seemed to be the most likely reason we have the limit that we do. There's been various theories and ideas discussing how we can deal with that already on this forum so I'm not going to get into that here. What I will mention is that I got curious as to how the emulator is loaded into RAM and what it looks like once it's loaded.
The 68k emulator is contained within 1 MB of address space from 0x68000000 - 0x680FFFFF
So I did a dump of that range and started to review it. I haven't gone through it in depth yet, but I did review the dump and did find some fun strings in there nothing unexpected but a few strings at least. I did find it neat that the string "newworld" showed up in the emulator. Not sure why that excited me, but it did. One thing that jumped out to me was the amount of empty space in RAM for the emulator. Over half the space was empty. I would expect a large chunk of empty space to exist for a stack for the emulator, but what struck me as odd about it as it seemed to be divided up into three sort of areas. (again I haven't fully analyzed this yet).
Moving on now. I've found that looking through documentation especial old version and then comparing to newer versions sometimes provides answers to why things changed. Some times it leaves me more confused.
So I pulled up the Inside Macintosh documentation on memory. Now keep in mind that this documentation mainly applies to 680x0 Macintosh machines. In the sections regarding the addressing modes (24 bit vs 32 bit) it explains some interesting limitations.
This talks about how the 24 bit addressing mode has a max addressable range of 16 MB and that the top 8 are reserved for the OS and I0 And the remaining 8 MB are for application use. So depending on the amount of RAM installed you could have a max application partition of 8 MB. This all makes sense to me. Now switch over to 32 bit addressing and you have a max addressable range of 4GB. The 8 MB reservation for IO and OS still exist, but there is a limit on the max size of an application partition of 1 GB. Keep in mind this is on a 68K machine. Why this exists as 1 GB, I don't know.
Now let's flip over to the PPC side of things. I haven't found what the max limitation is for a single application is on PPC in OS 9, but in looking through the header files in MPW I did find something that I did thing was odd.
There is a value defined for the maximum size of a single memory block that can be requested by an application.
The limit is 2GB. So at some point in moving to PPC the application limit was raised and I assume to 2 GB or greater since you can request a block of memory of up to 2GB. Now this header file is also used in early versions of X (I think 10.0) so it's possible that that 2GB limit is an OS X limit and not a 9 one. But if it is a limit in OS 9 then how the hell is that to ever succeed if we are limited to a total of 1.5 GB system memory being mapped and usable? This is what I need to investigate more as now I'm just curious and confused.
I'm at the office right now so I don't have the memory dumps with me, but I'll try to upload a dump of the emulator and the IO space of my machine if anyone is interested and wants to look at it. Not that it's overly exciting.
Topic: More RAM Please, like 2GB or so? (Read 2991 times)