Re: C64 MMU POC

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é