The Macintosh Portable can address 9MB of RAM despite only having 24bit addressing. I don't think the 8MB "limit" was any sort of hard and fast limit on Macs. The 24-bit Amigas were limited to 8MB of Fast RAM, but that was because of a hardware limit in the Zorro II bus. Looking at the 32-bit Amigas, they have a ceiling at $80000000 (2GB). Anything past that can't be addressed by the OS.
-
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.
Technical explanation of why the LC, LC II, and Classic II have a 10MB RAM limit
- Thread starter David Cook
- Start date
Woohoo!
The LC and LC II are the same logic board with a CPU and ROM swap. In MAME, 7.0.1 says they're both an LC, but 7.1.1 correctly distinguishes them.
The Color Classic does not have extra address lines going to Spice. Here, have the real Apple schematics.
WOW, thanks Arbee! These will be very useful going forward!
Phipli
Well-known member
Yeah, 16MB is the 24bit limit, but I think the discussion was more about what was normal on a mac. Generally it was 4MB on 68000 compacts, 8 on mac IIs... and then all over the place for other things.
cheesestraws
Well-known member
David Cook
Well-known member
Awesome!
Hmm... The LC schematic says C9 is 47uF.
That doesn't look like 47uF to me. : )
Just having fun. I know this was to compensate for a bug in its first Egret.
Regarding memory map and addressable amount of memory...
The memory map is just a convention established by the system designer to simplify many aspects of the design, and ensure that everything should work as intended. For instance, on 68000-based systems that have no MMU, the physical memory space is much easier to use if it is contiguous. That's why 68000-based macs tend to have only one bank of memory. Once a MMU is in the system, then the virtual space will be remapped to the physical space anyway - so even for 'non-virtual-memory' operating like System 7 (w/o VM enabled, obviously), Macintoshes can use discontinuous physical space made up of two or more banks of almost arbitrary size - that'swhy the IIsi can use an extra 240 MiB from a IIsiFPGA: it's just remapped to be contiguous after the soldered memory and the SIMM bank.
The memory map for the LC has 10 MiB reserved for memory (DCDMF3 p310), and is for 24-bits mode. Using more than 10 MIB would require many changes in the ROM and/or operating system.
The memory map for e.g. the SE/30 is designed for 32-bits mode and reserves 1 GIB for memory (DCDMF3 p342). For 24-bits mode, the MMU is setup differently to remap the 24-bits memory addresses to the 32-bits physical space, which effectively create a 24-bits memory map. That one only reserves 8 MiB for memory (DCDMF3 p350).
As for the 16 MIB limit on the 68000 due to the 24 address signals (2^24 == 16*(1024^2)), it is also a matter of design to some extent - you *can* have more than 16 MIB addressable by a 68000, provided you're willing to deal with the software for it. The 68000 defines address spaces exposed to the outside world by the FC (function codes) signals. Those can be used to distinguish the types of access. So you can build a 68000 system with up to 16 MIB for user data, 16 MIB of user program, and whatever else mapped in supervisor mode only. You probably don't want to, but you can System with split memory for program and data were built, I own an Xterminal based on the 88000 (not 68000!) that has 4 MiB for program and 8 MIB for data. In that system, firmware load the Xserver from the network using tftp into the program area, and the 88k cannot alter it during use as it's in read-only program memory.
It's a lot easier on the 68040 than for it's predecessors to address a lot of memory, are you can store 2 bits of extra data in the MMU mapping and those will be exposed via the UPA lines. Those can be used for many things (though practically aren't, they're not even connected to the PDS slot of Quadras for instance), including as a couple extra bits of physical addressing. So you could have up to 16 GiB of 'physical stuff' accessible through the MMU. Each program is still limited to 4 GiB of virtual space though. Also, why you would want to connect a dozen GiB of memory to a 68040 is an open question
The memory map is just a convention established by the system designer to simplify many aspects of the design, and ensure that everything should work as intended. For instance, on 68000-based systems that have no MMU, the physical memory space is much easier to use if it is contiguous. That's why 68000-based macs tend to have only one bank of memory. Once a MMU is in the system, then the virtual space will be remapped to the physical space anyway - so even for 'non-virtual-memory' operating like System 7 (w/o VM enabled, obviously), Macintoshes can use discontinuous physical space made up of two or more banks of almost arbitrary size - that'swhy the IIsi can use an extra 240 MiB from a IIsiFPGA: it's just remapped to be contiguous after the soldered memory and the SIMM bank.
The memory map for the LC has 10 MiB reserved for memory (DCDMF3 p310), and is for 24-bits mode. Using more than 10 MIB would require many changes in the ROM and/or operating system.
The memory map for e.g. the SE/30 is designed for 32-bits mode and reserves 1 GIB for memory (DCDMF3 p342). For 24-bits mode, the MMU is setup differently to remap the 24-bits memory addresses to the 32-bits physical space, which effectively create a 24-bits memory map. That one only reserves 8 MiB for memory (DCDMF3 p350).
As for the 16 MIB limit on the 68000 due to the 24 address signals (2^24 == 16*(1024^2)), it is also a matter of design to some extent - you *can* have more than 16 MIB addressable by a 68000, provided you're willing to deal with the software for it. The 68000 defines address spaces exposed to the outside world by the FC (function codes) signals. Those can be used to distinguish the types of access. So you can build a 68000 system with up to 16 MIB for user data, 16 MIB of user program, and whatever else mapped in supervisor mode only. You probably don't want to, but you can
System with split memory for program and data were built, I own an Xterminal based on the 88000 (not 68000!) that has 4 MiB for program and 8 MIB for data. In that system, firmware load the Xserver from the network using tftp into the program area, and the 88k cannot alter it during use as it's in read-only program memory.It's a lot easier on the 68040 than for it's predecessors to address a lot of memory, are you can store 2 bits of extra data in the MMU mapping and those will be exposed via the UPA lines. Those can be used for many things (though practically aren't, they're not even connected to the PDS slot of Quadras for instance), including as a couple extra bits of physical addressing. So you could have up to 16 GiB of 'physical stuff' accessible through the MMU. Each program is still limited to 4 GiB of virtual space though. Also, why you would want to connect a dozen GiB of memory to a 68040 is an open question
Jockelill
Well-known member
Awesome with the drawings! Very helpful!!! You don't happen to have the IIvi/IIvx/Pf600? These are also lost somehow, and 840AV?
Similar threads
