Mac II Family Memory Controller Addressing and Address Space Decoding

1 reply [Last post]
Offline
Joined: Dec 20 2003
Posts: 57

According to Apple documentation, the first 1G of address space in the Mac II family is allocated to RAM. The most any of the machines can physically accept is 128 MB. But, in theory, it should be possible to insert a card that decodes the other 872 M of address space and provides read and write access to some fast modern memory there.

Even better would be to only install 512K or 1MB in the host machine and provide 1023MB of fast RAM in that address space.

The first problem I see is that there's a memory controller on the logic board which is presumably decoding those addresses and if there are not enough SIMMs to provide memory in those addresses, then it might be issuing a /BERR if anything tries to address that space, regardless of what kind of card might be installed in the machine trying to respond to those addresses.

Obviously, the (built-in) memory controller must be able to decode the first 128M because there could be physical memory there. Anyone know if the memory controller decodes the rest of the RAM address space, or is that just left swinging in the breeze with nothing decoding it (IOW, available for an expansion card)?

So, anyone know what addresses the memory controller chip is actively decoding/responding to? The first 128M? The whole 1G? Only the amount of address space for which physical RAM is installed?

Also, how does the Mac determine how much memory is installed at boot time? Does the CPU perform a test? Or does the memory controller have a state machine that tests it and stores the result in a register for the CPU to read?

I know the ROM gets echoed throughout it's available address space, but the book I was reading last night did not say that is done with the RAM. I was reading "Designing Cards and Drivers...". I guess I should also check "Guide to the Macintosh Family Hardware".

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Offline
Joined: Dec 20 2003
Posts: 57
Re: Mac II Family Memory Controller Addressing and Address ...

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?