Re: C64 MMU POC

4K seems like a good page size, and an 8-bit page register will get
you to a roomy 1MB memory to work with.  Not a lot by today's
standards but quite nice on a c-64 :)

The C64 256k expansion by Mäkelä and Pessi used 16k pages to keep the
logic simple and may be a reasonable study case too.

If you're designing new core logic I'd have a personal bias for 4k
pages as it improves allocation granularity and reasonably complex
tools written in 6502 assembly may fit well in 4k if assisted with an
external shared library.

Side note- if shared libraries are a consideration it may be a good
idea to be able to write-protect memory pages to avoid having a shared
code segment damaged by a malfunctioning program. :)

-David

On Mon, Jul 8, 2019 at 6:03 AM <afachat_at_gmx.de> wrote:
>
> Hi Jim,
>
> On Montag, 8. Juli 2019 07:27:01 CEST Jim Brain wrote:
> > I'd like to play around with MMU design on the C64, and wanted to ask
> > for additional thoughts:
> >
> > * What "page" size would folks recommend?  4K, 8K, 16K?  User defined
> > (much harder to implement, but maybe possible)
>
> I found 4k a good page size to use, but I may be biased. My use case mostly
> was mapping in small binaries in a multitasking system.
> It may be different when you want to use it for graphics, where 8k would
> probably be better.
>
> What use cases did you have in mind?
>
> > * Where would be a good spot to put the config registers in the 64
> > memory map?
>
> I would map them in the mirror area behind one of the existing chips (but
> maybe not the SID, considering there are multi-SID configurations around that
> already use it). So maybe $DC80
>
> > * If multiple mappings were possible, map them into a small space
> > (say, 16 bytes for the 4K page size, 16 pages for 64kB) and slide
> > that window to the specific map, or use one of the pages mapped into
> > the memory map as the place to store all the mappings?
>
> I don't think I understand. I gather, from the 4k example, you would map on
> page boundaries, i.e. a 4k page in the target (physical) address space would
> also be on page (4k) boundary, so you'd only have to remap the upper 4 address
> bits into 4+ new address bits.
>
> I _think_ I read that you have multiple mappings in mind. And that you are
> thinking not like memory mapped registers, but an MMU that fetches the mapping
> from memory when needed (or loaded)? I would not load "on demand", that seems
> to be rather complex. I'd rather go for an approach where the MMU is either
> loaded "manually" by the CPU (easiest), so no constraints on where to store a
> mapping.
>
> Or load a complete mapping from memory on request (say, by writing a mapping
> address register). Not that easy, but I think ok . Depending on the number of
> address bits you allow for the address, you are also flexible in where you
> store your mappings.
>
> > * Any reason to have a "common" page that is the same in the case of
> > multiple maps?
>
> Yes. Data exchange between programs in my case. "trampoline" code to switch
> execution (just look at the mess in the 6509....)....
>
> However, if you are using a paged mapping, there is no reason why two
> different mappings should not point to the same target (physical) address.
> So it's all to the software.
>
> > * Is it enough to allow the first page to be remapped to "move" zpage
> > and stack, or should it be possible to remap at the 256 byte
> > granularity in page 0?
>
> I guess that depends on your use case. If you, like me, want to page in
> executables, a 4k page at the bottom often suffices, that includes zp and
> stack.
> If you want to be able to just use "more zeropage", remapping zp (or even
> stack) separately maybe more what you want.
>
> If both are mapped separately, I'd suggest a two-staged approach. As we are
> "stuck" with the 6502/6510, there is no base page register, but that is
> something the MMU could simulate, to create a new page address for zp. This
> should then be fed into the page mapped MMU. So you can use one or both
> approaches independently.
>
> > * Is there anything from the C128 MMU that makes sense to utilize
> > (PCRs, LCRs...)
>
> Having a pre-stored mapping absolutely makes sense. It reduces the context
> switch times considerably, when you can just set one value to switch the
> mapping instead of the whole mapping.
>
> André
>
>
>