OK, never mind. I figured it out.
I laid down with GTTMFH last night for about an hour.
The GLUE chip in the SE/30 decodes any address in which bits 30 & 31 are b00 as directed to the RAM. Then it ignores bits [29:27] leaving bits [26:0] to decode as a memory address.
The effect this has is that bits [29:27] can be anything, and you'll still get an address down in b000[26:0]. So, it appears to anything else on the bus as if the (hardware) memory image is repeated throughout the address space allocated to RAM, because an address which begins (most significant bits) with b0000 1 looks just like b0000 0 and so on for b0001 0, b0001 1, b0010 0, b0010 1, b0011 0, and b0011 1.
Any of those patterns in the most significant five bits of the address will be decoded by the GLUE chip in the SE/30 (or Mac II family) as pointing to the same 128M addresses which are really at b0000 0[26:0].
Of course GTTMFH doesn't do anything so helpful as clearly stating this. I found one spot where it mentioned that the RAM image was repeated throughout the 0x0000 0000 - 0x3fff ffff address space and read the rest of the material on how the GLUE works. I think there was some mention of only looking at the upper two address bits when deciding whether something was addressed to the RAM.
So now I wonder if one can program the MMU in the 68030 to redirect access of 0x0000 0000 - 0x3FFF FFFF to some of the slot space. That should accomplish the same goal of being able to install very fast memory in the PDS slot and have it respond to the CPU without any wait states, usually.
Of course, if there are applications or (gasp) OS routines which are counting on those three bits [29:27] being don't cares, it might break them. In other words, there may be applications which expect to access the same memory location when it uses b0010 1[26:0] as when it accesses b0000 0[26:0] for example. If those two address ranges suddenly become distinct, then teh application wouldn't get or write to the memory location it expects some times.
Is there anything in the OS or in the Toolbox that would prevent the machine from addressing 1 GB of RAM, if it was available and addressable in the hardware?
I laid down with GTTMFH last night for about an hour.
The GLUE chip in the SE/30 decodes any address in which bits 30 & 31 are b00 as directed to the RAM. Then it ignores bits [29:27] leaving bits [26:0] to decode as a memory address.
The effect this has is that bits [29:27] can be anything, and you'll still get an address down in b000[26:0]. So, it appears to anything else on the bus as if the (hardware) memory image is repeated throughout the address space allocated to RAM, because an address which begins (most significant bits) with b0000 1 looks just like b0000 0 and so on for b0001 0, b0001 1, b0010 0, b0010 1, b0011 0, and b0011 1.
Any of those patterns in the most significant five bits of the address will be decoded by the GLUE chip in the SE/30 (or Mac II family) as pointing to the same 128M addresses which are really at b0000 0[26:0].
Of course GTTMFH doesn't do anything so helpful as clearly stating this. I found one spot where it mentioned that the RAM image was repeated throughout the 0x0000 0000 - 0x3fff ffff address space and read the rest of the material on how the GLUE works. I think there was some mention of only looking at the upper two address bits when deciding whether something was addressed to the RAM.
So now I wonder if one can program the MMU in the 68030 to redirect access of 0x0000 0000 - 0x3FFF FFFF to some of the slot space. That should accomplish the same goal of being able to install very fast memory in the PDS slot and have it respond to the CPU without any wait states, usually.
Of course, if there are applications or (gasp) OS routines which are counting on those three bits [29:27] being don't cares, it might break them. In other words, there may be applications which expect to access the same memory location when it uses b0010 1[26:0] as when it accesses b0000 0[26:0] for example. If those two address ranges suddenly become distinct, then teh application wouldn't get or write to the memory location it expects some times.
Is there anything in the OS or in the Toolbox that would prevent the machine from addressing 1 GB of RAM, if it was available and addressable in the hardware?