Hi,

I have built some smaller 6502 based projects in the past, but want to create something more advanced, like a "real" computer and thought about using the 65c816 since it would be easier to handle a lot of memory (and it's faster to).
I would like to create a simple multitasking OS, so it had been nice to have an MMU and I was thinking about how advanced it should be.

I only knows the basics about how an MMU and CPU interacts so I have some questions about what would be the best way (atleast for this kind of project) to handle it.

The easy solution is ofcourse to have some kind of SRAM so that I can remap the 24 address lines and divide the RAM into pages of a few kb. The question is if memory protection is needed or not, since that would increase the difficulty of the project a lot.
When a new program is loaded, the total amount of RAM it needs should be specified already (could be written in the header of the file for example), so I can just reserve the amount of pages this program needs and run it without problems that it would try and read / write to an illegal address.
If I understand it correctly you only need memory protection if the program can allocate memory during runtime that you can't know in advance. So in C language you can't use malloc in the program, but fixed arrays will be fine.

If I was attempting something similar, I would start with an existing (well-documented) design (like a IIgs or BDD's POC1 and POC2), study it, decide what I liked and disliked about it, and go from there. Your options are wide open ... you just need a place from which to start, IMO.

Mike B.

Firstly, welcome to our 6502 world. Be sure to stop by the "introduce yourself" topic and tell everyone about yourself.


An admonishment I often give to anyone wishing to build a homebrew computer as you wish to do is to first learn how to make a single-engine plane fly before building that four-engine jumbo jet. Memory management and protection can be complicated to implement and depending on the degree of functionality you desire, may entail the need for considerable hardware resources. Other than the ABORT input and MLB and VPB outputs, the 65C816 offers nothing that facilitates memory management and protection—you will have to provide the missing functionality using programmable logic. So before you launch into your project, you should develop a realistic set of features and goals for your new system, keeping in mind that the more complicated it gets the greater the likelihood that it will not get to an operational state.


That's what I did: I looked at what others had done and then went to work concocting a design.

When I designed my POC V1 unit I stayed intentionally simple but did make it possible to add on to it. My goal at the time was to fully understand what it would take to make the 65C816 work with non-65xx peripheral hardware and to refine my design to where the unit would run at relatively high clock speeds—I had set a goal of 8 MHz operation, which was achieved. What I was going to some lengths to avoid was a complicated design that would be difficult to debug should it not work. That strategy paid off, as POC V1.0 worked on the first attempt—after I fixed an assembly error.

If you do want to set up a protected environment with the 65C816 you will have to get complex logic involved. One of the circuit features that will be required will be that of handling the A16-A23 address component (the "bank" address), which can be done with discrete logic or with a CPLD, the latter being recommended. Using a sufficiently large CPLD, you can also incorporate the elements needed to implement memory protection as well as possibly trapping for illegal instructions (where "illegal" means whatever you want it to mean).

Linux and UNIX systems have long used a 4KB page size for allocating and protecting memory, which could be implemented with the 65C816. The problem will be in figuring out where to set up the necessary page tables, which could potentially have as many as 4096 entries for a maximally-sized system with 16 MB of RAM. You will also need to develop the logic required to implement an abort function should a process violate the memory boundaries assigned to it. In other words, you will be developing the functions that are built into modern x86 and 68K MPUs to manage system resources.

The other issue with which you will have to contend is the fact that the 65C816 directs all direct page and stack activity to bank $00, which can lead to contention between processes. In my POC V2 design, I am working toward an architecture that redirects direct page and stack accesses back to the bank in which the process is running. It's not a simple matter though, but entirely doable.

What I would suggest you do is start out with a basic design to get familiar with the 65C816, especially its 16 bit capabilities. Build it around a CPLD but initially only program enough into the CPLD to get the A16-A23 address component working, as well as such things as qualified read/write signals—in other words, the basic glue logic. Once that is up and running you can add code to the CPLD to handle I/O wait-stating, which will be necessary to be able to operate the 65C816 at maximum speed (20 MHz). Only after those items have addressed would I then work on the memory management and protection.

Succinctly stated, work in stages so you don't have to grapple with too many debugging problems at the same time. Once a stage is operating in a satisfactory manner then go on to a new feature. Before you know it, you will have a full featured unit that can compute.

Also, don't hesitate to ask lots of questions. We have more than a few very knowledgeable members and while no one individual is likely to be an expert on all facets of computer design, the combined expertise around here can be frightening at times. Please don't be shy about tapping into it.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

No, memory protection really needs to trap and translate the address of every instruction fetch, data read, and data write. Most MMUs nowadays distinguish these 3 situations as different protection bits per memory range.

Even if you never alloc, a buggy or malicious program can just start writing to random locations in memory. That's what you want to protect against, tripping an error before corruption occurs. Setting execution & read privileges helps with debugging and security concerns, but it's really the data write permissions that are the most critical to protect system integrity.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Yes ofcourse it would be best to take care of everything. The question is just how much more complicated would it be, compared to a more simple version that works in most cases.
You don't need an MMU or protection to run a multitasking OS. The AmigaOS or Magic, MultiTOS, Mint on Atari ST are all multitasking and on an CPU that has no MMU at all.

Right, certainly memory protection isn't necessary to run a multitasking OS. I'm simply saying that programs without alloc/sbrk/etc are not exempt from protection, if protection is enabled. Wild pointers can appear from anywhere.

However, outside of protection, the only other purpose of a MMU is to provide address translation. The 65816 already accomplishes a lot of that with its bank registers. If the OS notified processes of the range of banks they can use, that's simple and very low overhead (a couple of cycles whenever you change bank registers); whereas a hardware MMU adds bus latency every access, which may or may not be transparent in the timing windows. If the goal is a multitasking OS, you've already got the tools to run with.

Of course, if the goal is to build and use a simple MMU then by all means soldier on. It would allow stock binaries from compiled languages to work unchanged, assume they're using literal banks $00-xx instead of fully variable banks. The translation table just would need to be accessed in a way that well-behaved programs wouldn't accidentally stumble over it.

_________________
WFDis Interactive 6502 Disassembler
AcheronVM: A Reconfigurable 16-bit Virtual CPU for the 6502 Microprocessor

Zamuel, I assume you've seen Ruud's project by now (http://www.baltissen.org/newhtm/mmu.htm)?

More background on the /4LS612: http://www.baltissen.org/htm/74ls612.htm

Yes I have read his site, but since the 74LS612 is difficult to find and very slow, it's not really an option to use that one.

What do you want to achieve with the MMU? Only mapping or do you want to achieve process isolation? When you want to map memory, what is the number and size of pages?

Some discussion about operating the 65C816 in a protected environment has been kicked around here and there. It runs to a number of pages and perhaps you will get some ideas on which to expand.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!

Whether you use it or not, make sure you see André Fachat's page MMU for a 6502, Virtual Address space for 6502 Microprocessors. His page on context switching and thread synchronization, including on-demand mapping, might be of help too.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?