• Updated 2023-07-12: Hello, Guest! Welcome back, and be sure to check out this follow-up post about our outage a week or so ago.

Explanation of Macintosh II's memory limit

yuhong

Well-known member
(The original Apple technote is pretty misleading on this topic)

(This also applies to the Macintosh IIx, Macintosh IIcx, and Macintosh SE/30)

The original Macintosh II did not have a PMMU by default. It relied on the memory controller hardware to map the installed memory into a contiguous address space. This hardware had the restriction that the address space dedicated to bank A must be larger than those of bank B. Though this memory controller was designed to support up to 16MB 30-pin SIMMs for up to 128MB of RAM, the original Macintosh II ROMs had problems limiting the amount of RAM that can be installed to 8MB. The Macintosh IIx ROMs that also shipped with the FDHD upgrade fixed this problem, though still do not have a 32-bit Memory Manager and cannot boot into 32-bit addressing mode under Mac OS (without the assistance of MODE32). MODE32 contained a workaround that allowed larger SIMMs to be put in Bank B with the PMMU installed. In this case, the ROMs at boot think that the computer has 8MB or less of RAM. MODE32 then reprograms the memory controller to dedicate more address space to Bank A, allowing the additional memory in Bank B to be accessed. Since after that the physical address space is not contiguous, the PMMU is then use to remap the address space into a contiguous block.

 
Last edited by a moderator:

bigmessowires

Well-known member
That's interesting - what's the source of this info? As described, it sounds like this problem only applies to the Macintosh II and not the IIx, IIcx, or SE/30, since the IIx FDHD ROM fixed the problem?

 

unity

Well-known member
Not to mention the HMMU socket issue with earlier boards. The original socket was chip-pin specific. That is the socket only had pin holes for the original HMMU that were used. Unlike most socket chips that had all pins in place even though some were not used. This made upgrading to a PMMU impossible without a socket or board change as PMMUs came fully loaded with pins. Apple did swap board out due to this issue. I have not seen a board like this personally yet and the only way to know is to remove the HMMU. I have an early II board but the socket has all pin holes and interfaces with my DayStar card with an 030 - thus the PMMU chip is not even needed.

 

Gorgonops

Moderator
Staff member
I have an early II board but the socket has all pin holes and interfaces with my DayStar card with an 030 - thus the PMMU chip is not even needed.
Does your Daystar card require a special "dummy" chip to be inserted into the HMMU/PMMU socket? I know some of the upgrades for those machines needed you to do that.

 

yuhong

Well-known member
That's interesting - what's the source of this info? As described, it sounds like this problem only applies to the Macintosh II and not the IIx, IIcx, or SE/30, since the IIx FDHD ROM fixed the problem?
The way the memory controller works applies to all of them. 

 
Last edited by a moderator:

yuhong

Well-known member
Not to mention the HMMU socket issue with earlier boards. The original socket was chip-pin specific. That is the socket only had pin holes for the original HMMU that were used. Unlike most socket chips that had all pins in place even though some were not used. This made upgrading to a PMMU impossible without a socket or board change as PMMUs came fully loaded with pins. Apple did swap board out due to this issue. I have not seen a board like this personally yet and the only way to know is to remove the HMMU. I have an early II board but the socket has all pin holes and interfaces with my DayStar card with an 030 - thus the PMMU chip is not even needed.
That was just an manufacturing error I think.

 

tanaquil

Well-known member
Thanks for the explanation, that was very helpful. I wonder if that explains why I was able to install 4x16MB ram simms in bank B of my SE/30 but only if I put 4x1MB simms in bank A. Putting the larger simms in bank A got me a sad mac every time.

Once I got the computer to start up to a happy mac, I still had to install Mode 32 to get it to recognize more than 8MB of RAM.

 
Last edited by a moderator:

yuhong

Well-known member
Thanks for the explanation, that was very helpful. I wonder if that explains why I was able to install 4x16MB ram simms in bank B of my SE/30 but only if I put 4x1MB simms in bank A. Putting the larger simms in bank A got me a sad mac every time.

Once I got the computer to start up to a happy mac, I still had to install Mode 32 to get it to recognize more than 8MB of RAM.
You can check how much RAM the ROM code thinks it have by using "About the Macintosh" without MODE32 loaded. The info should show that most of the extra RAM beyond 8MB is allocated to the system if the ROM code thinks it has more.

(Technical details: the applicable lowmem globals are MemTop and BufPtr.)

 
Last edited by a moderator:

yuhong

Well-known member
Does your Daystar card require a special "dummy" chip to be inserted into the HMMU/PMMU socket? I know some of the upgrades for those machines needed you to do that.
On the accelerators, be aware that the original Mac II ROMs don't support the 68030 PMMU and will try to use the HMMU instead, which is bad of course.

 

unity

Well-known member
Does your Daystar card require a special "dummy" chip to be inserted into the HMMU/PMMU socket? I know some of the upgrades for those machines needed you to do that.
No, but maybe there is some interaction and the Mac II adapter card, which is needed for the Daystar card, plugs into the HMMU socket.

As for the ROMs, I can not say for sure on that. You are probably right and I am not sure which ROM set I have. There is very little RAM in it anyway.

 

jimjimx

Well-known member
 The Macintosh IIx ROMs that also shipped with the FDHD upgrade fixed this problem, though still do not have a 32-bit Memory Manager and cannot boot into 32-bit addressing mode under Mac OS (without the assistance of MODE32). MODE32 contained a workaround that allowed larger SIMMs to be put in Bank B with the PMMU installed. 
So... Are the stock ROMs in the Iix the same as the ROMs in the FDHD upgrade kit?

 
Last edited by a moderator:

Elfen

Well-known member
You mean an FDHD upgrade kit for the Mac II? No, I believe it should not. Reason being is that the II uses a '020 CPU and the IIx uses a '030 CPU. There are some differences at this point, even if one uses the PMMU.

 

yuhong

Well-known member
You mean an FDHD upgrade kit for the Mac II? No, I believe it should not. Reason being is that the II uses a '020 CPU and the IIx uses a '030 CPU. There are some differences at this point, even if one uses the PMMU.
It would be easy to support both with the same ROM code, and I believe that the ROMs are exactly the same.

 

ZaneKaminski

Well-known member
Yuhong! I have seen your comments on folklore.org. It is nice to see you here.

I have been looking for some clarification on this subject for some time, but I still have a question. I understand these machines to dedicate a total of 1 Gbyte of the 32-bit physical address map to memory, between 0x00000000 and 0x40000000. Based on what you have said, I understand that the region corresponding to bank A must not be contiguous with with the region corresponding to bank B. But where (in the physical address space) does bank A end, and where does bank B begin?

Also, I understand how to use the 68851 MMU or 68030 MMU to remap the address space to ensure the banks are contiguous, but does the Apple HMMU chip also do this? I imagine it must, otherwise I must be misunderstanding something.

For reference, here's a picture of the address map of the early Mac II series:

Screen Shot 2017-01-20 at 5.38.59 PM.png

Edit: also, does this relate to the stated 68 Mbyte memory limit of some of the later machines, for example the Quadra 700? 68 Mbytes suggests 64 Mbytes in one bank and 4 Mbytes in another. Of course, these 68040 machines use a different memory controller, but the similarity is curious.

 
Last edited by a moderator:

yuhong

Well-known member
Yuhong! I have seen your comments on folklore.org. It is nice to see you here.

I have been looking for some clarification on this subject for some time, but I still have a question. I understand these machines to dedicate a total of 1 Gbyte of the 32-bit physical address map to memory, between 0x00000000 and 0x40000000. Based on what you have said, I understand that the region corresponding to bank A must not be contiguous with with the region corresponding to bank B. But where (in the physical address space) does bank A end, and where does bank B begin?

Also, I understand how to use the 68851 MMU or 68030 MMU to remap the address space to ensure the banks are contiguous, but does the Apple HMMU chip also do this? I imagine it must, otherwise I must be misunderstanding something.

For reference, here's a picture of the address map of the early Mac II series:

attachicon.gif
Screen Shot 2017-01-20 at 5.38.59 PM.png

Edit: also, does this relate to the stated 68 Mbyte memory limit of some of the later machines, for example the Quadra 700? 68 Mbytes suggests 64 Mbytes in one bank and 4 Mbytes in another. Of course, these 68040 machines use a different memory controller, but the similarity is curious.
They are generally contiguous on pre-IIci machines. I believe that the IIci always dedicate 64MB to bank A and use the PMMU to remap.

 
Top