Re: Kernel uses only half of Mac IIci memory with built-in video
On Mon, 22 Mar 2021, Geert Uytterhoeven wrote:
> >
> > I know the head.S MMU code was completely rewritten around that time
> > to accommodate changes needed for the Mac port. What we used before on
> > Atari and Amiga bears little to no relation to what we have now. My
> > guess is that 030 (has transparent translation register) and 020 (does
> > not have tt1) used distinct code paths before the rewrite, but share
> > much of the code now.
>
> But the 68020 does have early termination pages, which map (IIRC) 2 MiB
> at once. In the early days, 2 MiB should have been fine to map the
> kernel. As that's the only mechanism used by head.S, perhaps the real
> reason for picking the largest chunk on Mac is that you cannot map
> contiguously using early termination pages a series of discontiguous 1
> MiB banks?
>
Perhaps other bootloaders make allowance for 1 MiB banks when running on
early MMUs but I don't think Penguin does.
Source/asm.a appears to disable the MMU before copying the kernel and
initrd into the first chunk of RAM. (On Mac II the lowest chunk is the
first one. On the other Mac models, the largest one is the first one.)
Anyway, surely this test for CPU_68020 in Source/mmu_support.c in Penguin
is bogus. This must have to do with some quirk of the Mac II logic board
and not the type of MMU or CPU.
So, why sort chunks by address on Mac II? Beats me. I guess I'll have to
dig out my Mac II and try EMILE, which doesn't have that hack.
Reply to: