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.
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.