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.
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?
Unbounded_Villain
Active member
I don’t understand why Apple didn’t just go with the IIsi and not release the LC. The LC was only $400 cheaper than the IIsi, and it was obvious from their push at the time they viewed the IIsi as the inexpensive computer for home users.
"Only" ? That's equivalent to over $900 today when you take into account 33 years of inflation, that's not insignificant money...
Snial
Well-known member
But the Portable and PB 100 supported up to 8MB of RAM and no 68K Mac had more than 512kB of ROM. So, any 68000 Mac could have easily supported up to 15MB of RAM without Function-code tricks and still provided plenty of space for PDS IO and even dedicated VRAM (64kB for the main video + 64kB for internal IO [VIA, SCC, SCSI, etc) + 256kB for PDS ROM and any memory-mapped IO it needed, e.g. 64kB of ROM for an second display + (A4 at 596x 842 = 64kB video). How much decoding is needed for that? 4-input AND for basic IO, then a 74LS138 would split the remaining 1MB into 128kB pages.
Also, of course on a 68000 Mac it'll boot from 0, so ROM needs to start there, and then later get remapped above RAM, so some kind of minimum MMU is needed (and in fact is provided on the early Macs).
cheesestraws
Well-known member
I don't think calling it even a minimal mmu is necessarily useful. At least to me, an MMU needs to be able to adapt its mappings in software, which the overlay system in early Macs cannot. All it can do is be turned on and off and aim certain accesses at the ROM. It's not a "mapping" in the sense of having a difference between physical and virtual addresses, it's rewiring physical addresses.
Snial
Well-known member
I thought it was an I/O bit in the VIA or something wasn't it? Oh yes, VIA Reg A, bit 4. I agree it's not an MMU in any conventional sense. I considered writing: PMU, but usually that stands for "Paged Memory Unit" or "Protected Memory Uni" or PMMU which was, I believe the term used for the Mac II's substitute for an MMU if it didn't have a 68451. There are also things called MMUs which are pretty crude, like the Z180's MMU, which splits the 64K memory into 3 segments on multiples of 4kB pages only 2 of which can be mapped. Classic Mac memory mapping is more like that on the Commodore 64's CPU, Apple ]['s language card or the Amstrad CPC 464's mechanism for paging out 16kB of ROM (or RAM) to gain access to the 16kB of video RAM.
Maybe the Classic Mac memory mapping, is better phrased as a Soft-Switch then ;-) .
Unbounded_Villain
Active member
That’s a false equivalency. Inflation doesn’t scale evenly across all goods, and electronics have actually continually become less expensive.
Example the Performa 600CD which came out 2 years later was only $2000 at launch.
However anyone spending Macintosh money in the 80’s and 90’s was not going to waffle over $500 for what was a much better computer. The LC mainly saw inroads in education, not least thanks to Apple creating the IIe card specifically for that PDS slot. If they’d made it exclusive to the IIsi, schools would have went with the IIsi.
Unbounded_Villain
Active member
AV Quadra ROMs were 2MB, according to Apple.
Macintosh Quadra 840AV: Technical Specifications - Apple Support
Snial
Well-known member
AV Quadra ROMs were 2MB, according to Apple.
Macintosh Quadra 840AV: Technical Specifications - Apple Support
support.apple.com
I meant all 68000 Macs had ≤512kB of ROM. The same rules don't apply to 68020 to 68040 Macs, because they can address more than 16MB in one Function Code space anyway and can support proper MMUs as per the earlier comment.
Snial
Well-known member
Just going back to this for a moment, because I always found FC codes confusing, but suddenly I'm a bit interested in finding out how much they could be exploited.
To summarise from the 1983 68000 data sheet, FC0 is low for program access, FC1 is low for data access and FC2 is low for user access.
So, at a simplistic level one could use FC2 to provide an additional 16MB of Supervisor address space?
The question is then, what counts as a data access vs program access. Obviously an instruction fetch, for all 16-bit words of an instruction count as program fetches? So, also an immediate mode EA is a program fetch. But what about other addressing modes? I'm guessing that also program counter with displacement and program counter with index reference a byte/word/long with FC0=0, because it wouldn't make sense to access PC relative memory with any address space other than program space?
If that's the case, then it's possible to perform any kind of data access, even to an absolute address, in program space.
Code:
PcRef:
LEA a0,-2(PC) ;a0=PcRef.
MOVE a1,#AbsAddr ;An Abs address I'm interested in.
SUB.L a0,a1;a1=AbsAdddr-PcRef
PcRef2:
MOVE.L PcRef-PcRef2-2(PC,a1,L),d0 ;d0=Mem[AbsAddr]Or something close to that. This gives even a basic 68000 a maximum of 64MB of address space to play with. Having said that it might just be easier to implement a bit of bank-switched memory, divide the 24-bit address space into 4x 4MB and then make each index an 4-bit bank. That would also give 64MB.
Is that correct then, PC+disp16 and PC+index+disp8 are the only other program space addressing modes?
@Snial Right. 68K Sun machines used the FC bits to switch MMU contexts (only supervisor mode could see the I/O hardware), and the SPARC CPUs basically copied the FC mechanism and filed off the "copyright Motorola" part for back compatibility.
Back to topic, the obvious answer is "the LC's designers wanted to one-up the Portable/PB100's 9 MB of RAM limit".
Back to topic, the obvious answer is "the LC's designers wanted to one-up the Portable/PB100's 9 MB of RAM limit".
