Re: Kernel uses only half of Mac IIci memory with built-in video
On Mon, Mar 15, 2021 at 02:33:26PM +1300, Michael Schmitz wrote:
> On 15/03/21 10:13 am, Brad Boyer wrote:
> >I believe one of the headaches is that the address is non-programmable
> >and requires the framebuffer not just to be in bank A, but to start at
> >address 0 which means we can't put the kernel at address 0. So we
> >instead put it at the beginning of bank B if RBV video is going to be
> >used. The RBV chip doesn't have a way to specify the buffer address
> >(the official Apple documentation is quite clear that RBV has no
> >control over the framebuffer location). The other chip that does that
> >part is also the main memory mapping logic for all onboard devices and
> >has a completely static mapping for this sort of thing as far as I know.
> >The documentation I've found never explicitly says the address 0 is
> >hard-coded, but it never says it can be changed either.
> Only leaves the option of using a dedicated pool of ioremapped memory and a
> special allocator. That is, unless someone manages to rewrite the m68k MMU
> code to allow RAM chunks to be listed and mapped in any order. We now use a
> memory model that should allow that, but the code that maps virtual
> addresses to physical addresses and vice versa (without walking the page
> tables) isn't there yet. It's been a while since I looked though ...
OK. Today it's kind of implied because macfb.c passes whatever address
it got from Penguin to ioremap. Perhaps we could find some other use
for the rest of the RAM in that bank (a IIsi has a fixed 1MB there,
but it was possible to put a lot more than that in bank A on a IIci).
I do remember some of that mapping code being very simple in the past,
but I haven't looked much at the code as it is today.
> >in that case, not as generic memory. I'm not sure of anything else we
> >have on a Mac that would be able to use that sort of thing.
>
> The only other use is for DMA buffers (floppy and SCSI controllers, probably
> also DMA for the sound chip). DMA on Macs is weird (though can probably
> address the entire memory, not just the low 24 address bits, so the problem
> never arose on MAC as far as I recall).
I don't believe there are any working sound drivers for m68k macs,
and the only working floppy driver we have is swim.c which is not
capable of doing DMA (no model it supports can do DMA to floppy).
The only SCSI drivers we have (mac_scsi and mac_esp) don't support
DMA even though some models (not including the RBV systems) have
that capability.
The only drivers I found using DMA on m68k macs are the on-board
ethernet ports (macmace.c and macsonic.c). Both appear to allow
arbitrary DMA buffers. The SCSIDMA chip (only in the IIfx) should
allow 32-bit addresses, but we don't support using real DMA (the
driver only knows how to do PDMA). The AV models (the ones with
PSC) have 9 DMA channels, but we don't support real DMA for
anything other than ethernet. The other channels are for things
that are supported without DMA (serial and SCSI) or are not
supported at all (floppy and sound - these models have a floppy
controller and sound chip not found on any other model). None of
that hardware can be present on a system with RBV.
At one point Apple even wrote a technote claiming that it was a
good thing none of their hardware could do DMA. It was titled
"I was a teenage DMA junkie", but I don't think it's available
online these days.
Brad Boyer
flar@allandria.com
Reply to: