Re: mmu for 65c02

From: A. Fachat (
Date: 2005-04-20 14:00:04

Hi Gabor,

interesting idea - not that I haven't done that before.... :-)

First of all, you may want to have a look at
and there under CS/A65, GeckOS and OS/A65, which describe
hardware an software that implement a similar system.
Of course it's more fun to do things like that yourself :-)

Gabor Lenart wrote:

>space, I mean every page (256 bytes of memory starting at a 256 byte aligned
>address) can be assigned to let's say any of 65536 possible 256 byte sized
IMHO using 16 bit values for remapping is a substantial overhead as 
compared to 8 bit values
(in terms of context switch time, process table size - remember, with 
your mapping, a process
table contains 512 byte of memory mapping (256 pages à 16 bit mapping 
info each)

CS/A65 uses 16 pages á 4 kByte, that can be mapped
out of 256 pages making a total of 1 MByte of memory. But the
CPU has to reload the mapping tables each time on a context switch.

>page (that's 16Mbyte). Also, there would some hardware support for task
>switching (so we're talking about multitasking system), there would be
You mean, the mapping table would be set in hardware instead of having 
the CPU reload the
mapping each time? Interresting idea!

>several mappings, one for each task (can be process or a thread). "task
>switching" would be only a selection of a mapping to use (well, for real
>it's more complex, you should also save registers etc). As you can see,
>you can even share memory between two (or more) tasks by mapping the same
>physical (from the 16Mbyte memory space) page into two (or more) address
>space mapping for 65c02. The whole story is a software based 65c02 simulation
>of course. Other stuffs like syscalls, 'kernel' vs 'user' space is not
>mentioned here, btw.
The 6502 has not distinction between "User" and "Kernel" space. You 
would have to invent
a thing like this yourself. E.g. by hardware-monitoring the address lines

>The problem is about threads. If we're talking separated processes, each
>can have its own memory space. Threads can be implemented easily as normal
>processes but with the same memory context. Of course the stack cannot be
>shared, so page #1 (stack) should be private for each processes. 
In GeckOS I have several methods of "stack sharing":
1) Systems without MMU can share the actual page1, by using different 
parts of the page.
Of course stack size per process/thread is limited then.
2) Systems without MMU can copy-share page, where on a context switch 
from one
thread/process to another the stack is copied to a thread-specific safe-area
3) On Systems with MMU, the page 1 is simply replaced by a new memory 
when processes are switched. (Don't remember though what happens when 
are switched)

>This whole long story is about only one thing: what's about zero page?
In GeckOS I share the zeropage between threads (with MMU) and between 
threads and
processes (without MMU) using a memory management software. When code is 
into memory, it is relocated by the loader to use unused parts of the 
zeropage (which is
requested from teh memory management software).


       Message was sent through the cbm-hackers mailing list

Archive generated by hypermail pre-2.1.8.