Hello, forum!

I have been thinking of a way to implement an MMU with data protection for the 816 CPU (sorry, I know that people look at 816 with rolled eyes here, but I decided to use it) as a fun project on an FPGA (I am still learning digital electronics, so please correct me if I am wrong somewhere ).

Because 816 CPU does not have native privilege levels like, for example 68000 family, I was thinking of doing this:

1. CPU starts in emulation mode, the E pin is pulled high, indicating that the system has just started. This puts the MMU into the “configuration” mode.
2. CPU executes the reset vector in emulation mode and starts to set up the MMU. MMU has it’s own section of ram dedicated to it that the CPU can only write to (possibly placed under the BIOS/Kernel/OS ROM for address space saving?). CPU writes necessary information to the MMU RAM, in order to tell the MMU which address range belongs to the fake “supervisor” mode. Any other address that does not fall into that range is treated as if it belongs to user mode.
3. After the CPU exits the emulation mode and the E pin is pulled low, the MMU exits the startup configuration mode until the next system reset.
4. MMU then monitors the reads and writes that the CPU and if there is any safety violation (for example writing to the MMU RAM from the code that resides in the “user” address space while not in startup configuration), it sends an interrupt to the CPU (I think the ABORT interrupt will be the best option?), allowing the BIOS/Kernel/OS/etc. to solve the violation issue.
5. Interrupt vectors are mapped to the Supervisor routines so they are executed in the supervisor mode. However, we can, for example put the COP vector address outside of the supervisor address range, setting it to execute in the user mode.
6. In case of a memory fault or invalid read/write, the Supervisor will decide what to do.
7. BRK or COP vectors can be for example used for OS (supervisor) calls from user mode application without violating the privilege level.
8. MMU monitors the CPU operations with the help of the VDA/VPA outputs to differentiate opcode fetch and to check if the eventual read/write is “not against the rules”. For example: If we have
Code:
LDA #$F8
instruction, the MMU will note the address of the last opcode (in this case LDA), and then check the next reads/writes until the LDA/VPA pins indicate an opcode fetch.
So if the allowed address space for the user mode application is, for example:
Code:
$010000 - $01FFFF
and the CPU is currently fetching an opcode at
Code:
$010005
then the MMU will save $010005 to it’s internal register. The MMU then watches what address CPU will read/write to until the next opcode fetch. So, if the instruction at $010005 was
Code:
LDA $02FFFF
(which is out of range for this user mode code (possibly also implement paging and let MMU check if the page is being occupied, exists, etc?)), then the MMU will sent an ABORT interrupt to the CPU, as the user mode violated the memory rules.

I would like to hear what you think about this and possibly (and most likely) what is the better way to go about different things in this implementation (or mb you know an already better theoretical or practical implementation).

This is my first time in attempting to work with a complex memory model on 65816 and implement an MMU. Prior to it I was mostly toying around with 6502 and 65816 with simple memory structures (no MMUs, no bank switching, etc. only memory devices connected to the address bus directly) and creating simple CPUs on fpgas, etc.

Thank you for reading trough my long post and not being bored by it in the middle

_________________
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?

Welcome, JustClaire.

It's an interesting topic you've chosen. And BTW Garth is right in saying many of us really like the '816!

I would like to see your MMU idea specified a little more clearly as you refine your thinking. For example, you'll need to decide...

• how many memory ranges will be recognized, and
• what attributes or privileges are specified.

Examples of the latter might include "Read Only," "No Execute".... and, well, I'm not sure what you have in mind! But these are some of the decisions you'll face.

I don't quite see why this is necessary. I thought the plan was to allow supervisor calls via COP and/or BRK. Can't these same calls accomplish the initial setup? Maybe I'm missing something.

We'd be happy to hear about your prior 65xx activity, too. (Put it in a different thread, though, please.)

cheers
Jeff

_________________
In 1988 my 65C02 got six new registers and 44 new full-speed instructions!
https://laughtonelectronics.com/Arcana/ ... mmary.html

Welcome - sounds interesting! For reasons of simplicity and efficiency I'd be inclined to protect pages or banks, rather than arbitrary ranges. So in your example bank 01 is allowed access, and an access to bank 02 is disallowed. But that's only a though, and I haven't considered the details, which is of course where all the pitfalls lie!

I'll chime in: I never personally felt the need for supervisor status or any of that. How about have a USB stick with your OS on it and the computer will run. Remove the USB stick, nothing. Or another version of your OS on another USB stick to give to a friend with preprogrammed stuff. Anything is possible nowadays with ultrafast boot up speeds. That's the MAIN reason I still develop 65xxx stuff. I hate waiting!

_________________
65Org16:https://github.com/ElEctric-EyE/verilog-6502

IMHO, you will need:
1: a Direct Page range, in bank 0, for indirecting through.
2: a Stack range, in bank 0.
3: conditional access to each I/O device. This may or may not be in bank 0.
4: outside of bank 0 and any I/O banks, assign entire banks for program, read-only data, and/or writable data access. Anything finer grained than this is optional.

You can use the /VP signal to detect when the CPU is taking an interrupt, whether hardware or software initiated. At this point the stack pushes will already have occurred. I suggest just setting a flag which permits full access by the kernel, and remember to reset that flag just before RTI. The tail end of your ISR will then need to be in the executable permission area, unless you specifically detect RTI opcodes on the bus.

In a CPU with actual privilege level support, the STP, SEI/CLI and maybe WAI instructions would be privileged, since they can disrupt operation of the whole machine if misused even if memory is protected, and would thus trap to an exception when in user mode. On the 65816 it's also difficult to prevent manipulating the I flag using SEP, REP or PLP. This really just goes to emphasise the difference between a single-user machine that may be multitasking capable, and a true multi-user capable machine.

Hmm...deja vu all over again. Also, here.

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

If an MMU was used for address translation, not just protection, then it would be a good way to access more RAM than the 16MB range. Many FPGA boards have 65MB SDRAM chips on them, with a MMU all of that could be accessible, but with a maximum of 16MB per process.

Which leads to the other issue here, MMU’s need operating system support. So if you are planning on building an MMU you’ll also need to write an operating system to use it. I’m assuming here that most of the reason for having a MMU is to support multi-tasking, and if that is the case then you’ll need to either manage direct page and the stack within the 64k of page zero, or page that out as well on a context switch.

And with that much RAM you’d need a lot of software to make use of it.

I think there's room for a practical level of protection, even if it has some holes in it. For example, if the idea is to protect against programming error, or corrupted programs, rather than protecting against hostile programs.

As I said above, déjà vu all over again. All of this has been discussed at length in past posts, including the concept of redirecting direct page and stack accesses back to the "page" in which the process is executing.

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