Re: C64 MMU POC

From: Mia Magnusson <mia_at_plea.se>
Date: Mon, 8 Jul 2019 15:44:21 +0200
Message-ID: <20190708154421.0000104f_at_plea.se>
Den Mon, 8 Jul 2019 00:27:01 -0500 skrev Jim Brain <brain_at_jbrain.com>:
> 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)
>   * Where would be a good spot to put the config registers in the 64
>     memory map?
>   * 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?
>   * Any reason to have a "common" page that is the same in the case of
>     multiple maps?
>   * 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?
>   * Is there anything from the C128 MMU that makes sense to utilize
>     (PCRs, LCRs...)

A good thing about the C128 MMU is that it has two sets of registers.
One full set that sits in the general I/O area, and a smaller set that
sits in the $FFxx range (iirc). That way you can do a limited set of
operations even when the full register set is invisible.

Are regular non-MMU-aware C64 programs supposed to be able to run even
with the MMU active, or is it more intended for experimentation and
MMU-aware software? This would greatly affect how important it is or
isn't to be able to hide the MMU registers from unaware software.

I don't know of any C64 software that won't run on a C128. My
conclusion is that it should be safe to map registers in the I/O areas
that differs between a real C64 and a C128 in C64 mode.

-- 
(\_/) Copy the bunny to your mails to help
(O.o) him achieve world domination.
(> <) Come join the dark side.
/_|_\ We have cookies.
Received on 2020-05-29 21:45:07

Archive generated by hypermail 2.3.0.