‘020 and ‘030 accelerators for 68000 Macs—what’s the memory map?

[ZaneKaminski]

As we all know, 68k Mac compacts have a hardware RAM limit of 4MB. However, there exist accelerators (e.g. Radius Accelerator 16) which extend the memory capacity to 16MB using onboard SIMMs. Presumably 8MB of this RAM is accessible in 24-bit mode.

So my question is, what’s the typical memory map when running on such an accelerator? Is it like the Mac II machines? How are the base addresses changed for the VIA, etc.? Is it as simple as changing the relevant global variables (e.g. viabase)?

 

[techknight]

Interesting as I wondered the same. 

The address decoders on the logic board itself cant be changed, ROM is where it is, and where its ever going to be. Same with everything else. So that makes me wonder if the Accelerator's Specific driver sets up the MMU a special way where it makes the memory map appear to the OS as a continuous line of RAM, with the ROM located somewhere else than where it physically is. 

 

[DBJ314]

It probably sticks the RAM anywhere in the address space it fits, without worrying about keeping it together. The Virtual Memory Manager does this when in 24-bit mode to fit as much RAM as possible in a limited address space. The accelerator might use a similar trick.

Here's page 3-7 of Inside Macintosh: Memory.

[SIZE=10pt]When 24-bit addressing is in operation and virtual memory is available, the Virtual Memory Manager uses, as part of the addressable application memory, any 1 MB segments not assigned to a NuBus card. For example, if a Macintosh computer has three NuBus expansion cards installed, that computer can address at most 11 MB of virtual memory. The maximum amount of virtual memory possible in a 24-bit environment is 14 MB (that is, 8 MB of physical RAM + 6 MB of additional space previously reserved for the NuBus); this maximum is achievable only on a computer with no NuBus expansion cards installed.[/SIZE]

 

[ZaneKaminski]

Wow, that’s interesting about the virtual memory manager. I didn’t realize it did that. But what about the need to keep an application’s RAM contiguous? Surely the VMM can’t split an application partition across multiple 1MB chunks—or can it, and then just suffer the resulting fragmentation, as if there was a big nonrelocatable block in the way?

See, I don’t think it works this way because this kind of behavior reflects a big change to the memory manager. It’s doubtful that the accelerator vendors would have rewritten the memory manager to do that, and the traditional 68k Mac memory map would only give you 4MB of contiguous RAM before ROM gets in the way, so you still can’t have a 4MB contiguous app partition anyway. 

In order to get 8MB of contiguous RAM, ROM and the 5380 SCSI chip have to get moved to above 0x800000. Is the ROM all relocatable code? Clearly the boot stuff can be relocated to address 0 after reset, but is everything in ROM relocatable? If so then we could make an accelerator that changes the high-order address bits to move the ROM to 0x800000-8FFFFFF. To be clear, what I mean is that when the 68030 on an accelerator accesses 0x8XXXXX, the accelerator hardware drives the address 0x4XXXXX to the Mac board below.

If the ROM really is all relocatable, then all that’s needed is to change the 5380’s address in the same way as the ROM and change the SCSIbase global variable. That would give a hypothetical accelerator with this memory map 8MB of contiguous RAM, which would be a pretty good enhancement for an SE or Plus. 

 

[DBJ314]

The easy way to use discontiguous RAM is to have the MultiFinder/Process Manager put different Application Heaps in different RAM blocks. Applications don't care about where their heap is, so it's nice and simple.

The hard way is to allow a single Application Heap to exist in several RAM blocks at once. To do that, you would need some Memory Manager magic to get it to work at all.

In theory, the hard way can be accomplished without directly modifying the Memory Manager. With some very creative non-relocatable block allocations, you could end up with a pointer block covering the "dead" region of the heap.

It would be very helpful if these techniques could be made to work on the 9.2.2 Process Manager and Memory Manager. There's some annoying NanoKernel data structures around the 1.5GB mark in the address space that keeps 2GB machines from using all their RAM.

 

[Dog Cow]

 Applications don't care about where their heap is, so it's nice and simple.

Unless you're Microsoft Word, Excel, Chart.... etc, who all do non-standard things with the Memory Manager and must be located within the first 1 MB of RAM. The Macintosh OS was special-cased for years to handle Microsoft's applications.