Re: Kernel uses only half of Mac IIci memory with built-in video
On Tue, Mar 23, 2021 at 10:48:07AM +1300, Michael Schmitz wrote:
> As you said, there is no distinction made between 020 and 030 in that code,
> so the same hack should have been applied to 030. Maybe the MacII (were
> there other 020 Macs?) was the only one with RAM banks A and B spaced closer
> than 32 MB?
The only other 68020 mac is the Macintosh LC, but Apple didn't put a
socket for the 68851 on it like there is on the Mac II. That means that
there's no way to get a real MMU to run a normal Linux kernel.
The logic of the II, IIx, IIcx, and SE/30 are basically identical.
Obviously there are some differences (like the SE/30 leaving off a
bunch of the NuBus logic due to only having a PDS slot), but they
use the same basic addressing layout. The Guide to the Macintosh
Family Hardware explains how to control the GLUE chip which
determines what shows up at various addresses on these 4 models
(and specifically not on anything else). Bit 4 in VIA1 regA is
the vOverlay bit and can force the ROM to show up in place of the
RAM. Bits 6 and 7 in VIA2 regA tell GLUE where to map bank B,
although it's documented as specifying the size of the chips in
bank A. By using these bits (the four values are for 256kb, 1Mb,
4Mb, or 16Mb chips leading to offsets of 1MB, 4MB, 16MB, or 64MB).
The ROM will always have used this to pack the two banks together
in the physical address space.
Something amusing I noticed in the Guide when reading through the
description of memory mapping is that apparently they used an MMU
mapping to make the RBV video buffer (which it does say is fixed
at physical address 0x00000000) show up as if it was a NuBus slot,
although one that doesn't physically exist on a IIci and can't
be emulated by a PDS card or the NuBus adapter card in a IIsi.
The implication is that the official RBV driver pretends to be a
NuBus device driver.
Brad Boyer
flar@allandria.com
Reply to: