Nice, a topic about something I've been fantasizing about for a while now.
But damn, 2007. Didn't realize how old this topic is!

I don't have any logic designed yet, only a written concept so I'll just throw it in here and see if I do something with it in the future one day.

Registers: (W = write only, RW = read/write)
XSRT - Execute segment start (16-bit, W)
XEND - Execute segment end (16-bit, W)
DSRT - Data segment start (16-bit, W)
DEND - Data segment end (16-bit, W)
ZBNK - Zero Bank (8-bit, W)
SCTR - Status/Control register (8-bit, RW)

MMU part:
Whenever Bank 0 is accessed (and VPB is not asserted) the contents of ZBNK are used for the upper 8 bits of the address bus. This only counts for data accesses (VDA & !VPA), instruction/operand fetches are not redirected, this is done to allow for interrupts to work properly.

MPU part:
Depending on the state of VPA and VDA the upper 16-bits of the address are checked against either the X (execution) or D (data) registers.
(For bank 0 redirected data accesses, the address is checked after the upper 8-bits are replaced by ZBNK).

When an address is detected outside the bounds of either the X or D registers (and VPB is not asserted), the current instruction will be aborted.

Once the CPU asserts VPB (or an access violation is detected) the MPU part is disabled and the CPU can freely access all of memory.
Because execution and vectors are not redirected from Bank 0, the CPU will handle the interrupt normally (though the stack and DP an still be somewhere else)
you could in theory fill all of Bank 0 with ROM to make decoding simpler, but you would need to set ZBNK to 0 to access data from it.

The status/control register can be read to see if the MPU if it aborted because of an execution or data access violation.

To re-enable the MPU part, the CPU has to write to the status/control register. After doing that the MPU will monitor the address bus and wait for the CPU to do an instruction fetch within the bounds of the X registers, only then will the MPU part be enabled again.

This is to allow the CPU to take it's time to return to the user program without having to worry about returning within a set amount of cycles.

.

So yea that's the main concept. There are probably some edge cases that would break this. Or ways you could optimize it to use fewer registers or have a faster propagation delay, but I can't think of anything on the spot. So any ideas and criticism would be welcome.
(On a side note there is no IO protection because I would assume IO to be located somewhere outside the user program segments so that it doesn't need any extra logic to be protected.

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

hmm, disallowing instructions requires the MMU/MPU to actively snoop the data bus along side the address bus (during opcode fetches, aka "VPA & !VDA"). adds a bit of complexity but there aren't a lot of instructions that you would need to check for.
like you said STP is one that would be useful to disallow as it puts the CPU into a state that cannot be recovered from without resetting it. but i don't see why you would want to disallow RTI. it's almost the same thing as an RTL instruction except the address is a bit different and it also pulls the status register. there is not really any reason why


i'm personally not a fan of the "activating x cycles after writing to the MPU-enable register/bit" because you need to start counting cycles when writing code to make sure you return fast enough to be in-bounds when it's active again but also not too fast to allow the user program to execute a few instructions still in supervisor mode/without memory protection.
which is why i would instead do this: writing to the re-activation register/bit puts the MPU into a state where it waits for the first opcode fetch within the bounds of the user program's memory area and only then re-active the memory protection/switch to user mode.
this avoids the need for having to count cycles or similar.

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

When I have thought about this in the past - and I actually did half-design a memory protection capable MMU for the 65C02, but I had trouble getting WinCUPL to cooperate with my design - I didn't consider protecting the P register and/or the I bit therein terribly important, because I'd put the Task Switching routine on NMI. Obviously its not ideal if all tasks disable their interrupt bit, but the interrupts will still get serviced during the OS's jiffy interrupt on NMI.

Stopping STP is very important though, and as I recall I also had it prevent a handful of other instructions though I do not recall what they are off the top of my head. I'd have to go and look at the design docs in my archive...

_________________
Want to design a PCB for your project? I strongly recommend KiCad. Its free, its multiplatform, and its easy to learn!
Also, I maintain KiCad libraries of Retro Computing and Arduino components you might find useful.

I Agree that NMI should be used for the periodic interrupt and task switching instead of IRQ.
exactly because it avoids having to keep track of the Interrupt flag and instructions that modify it, like RTI, REP/SEP, CLI/SEI, etc.
IRQ could be used for device interrupts or similar, where it doesn't matter if they get handled immediately or not.


not always, if you have wait states for ROM accesses but not RAM it would take a different amount of cycles to execute RTI. especially if the instruction can be found in both ROM and RAM. so you would need to make the counter run long enough to account for that (like maybe 10-ish cycles or something).
or in case of clock stretching you could use the CPU's clock for the counter instead of the global one. which would keep it in sync with the instruction cycles.


though it can obviously happen, i wouldn't expect a system function to corrupt it's own stack.
if you go that direction then you could also argue that a counter (or anything) doesn't protect against a system function being bugged and never writing to the MPU register in the first place.

anyways i think both ways of returning to user mode have their pros and cons. a counter is simplier to implement but probably also uses more logic. i think it would be fair to just try out both. (maybe even at the same time, have a counter as a fall back, if the CPU wasn't detected in the user program within x cycles, abort directly).

In our 6809+MMU thinking, we had the idea of a read-only MMU register which returns the value of an RTS (or in this case perhaps an RTL) - the idea is that you don't need a counter, you just jump or branch to the register location, and as a side-effect the MMU does the necessary thing such that the RTS lands back in user space. (You need to cater for the dummy read at the next location up, of course.) It feels to me that this approach is fairly minimal, but it's enough.

hmm, that is an interesting option. though wouldn't an RTI instruction make more sense in the context of returning to a user task?
you would likely still need to account for potential wait states, so maybe it should have a 1 or 2 cycle delay after the CPU fetched the instruction from the MMU before re-enabling memory protection.

on another note, can you even abort a STP instruction? the datasheet lists it as having "3 cycles" which i interpret as the CPU needing 2 cycles after fetching the instruction to actually go into low-power mode.
if that's the case then it is possible to fire an abort signal fast enough, but will the CPU actually process it?
of course you could have the MMU between the CPU and the rest of the system to capture the STP opcode and send a NOP to the CPU instead. but that is way more complicated, needs more logic, and likely drags the maximum clock speed down a lot... compared to just reading the data bus during opcode fetches and sending an abort signal if it matches STP.

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

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

This is the kind of thinking which leads to ever-increasing project scope, projects which never finish, and sometimes even to projects which never get started. "You might as well" is a danger sign - start things simple.

In the case of an MMU, I think it's well worth thinking through what the aims are, and what they could be reduced to. Relocation is very useful indeed. Protection between tasks, or between a user task and physical devices, could be handy. Absolute safety in the presence of malicious applications, somewhere near the end of the list. Note that the Macintosh, the Amiga, the Communicator, and probably the QL, are all multi-tasking without being perfectly safe, and they were all shipped and useful. Two of them were successful! We don't know how many products never shipped because of scope creep or perfectionism.

Indeed - and there is also a version of Linux designed to run on microcontrollers without MMU too.

https://en.wikipedia.org/wiki/%CE%9CClinux

My own 65xx project - (now) an OS written in BCPL running on the '816 is multi-tasking (but not multi-user) and it performs very well. Of-course there is nothing to stop a program writing all over RAM, but my own use with it coding, editing, etc. on it have shown it to be quite robust as long as you adopt defensive programming techniques - e.g. my system equivalent of malloc & free include "guard" words either side of the allocated memory to free() can determine if a program has overrun - similarly there is an option to check the stack usage (although that does slow things down a little). So it's all very possible.

I could go much further because the system is running a bytecode VM and I could, if I wanted to, include MMU code inside the bytecode interpreter (it's commonly done in emulators for e.g. RISC-V) but that would me it slower than it already is.

So effort vs. reward? Would it be nice to have a little bolt on MMU for the 6502/816? Yes - is the effort worth it? Only you can decide that one - afterall, these are all hobby projects and if we enjoy it then we should carry on...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

I would have loved to have the ABORT feature back in the day when I designed my computer.

The CPU board uses an MMU that provides mapping of 16 4k pages from a 1M physical address space. I used it in GeckOS for remapping memory for each parallel task.

The MMU can detect access to unmapped pages, write to read-only pages, or trying to execute code in no-execute pages.

However, without ABORT I was only able to stop the CPU, and actually have a second CPU take over the bus, to remap pages, or NMI the main CPU after that opcode. You could also do single stepping and tracing the main CPU using this feature.

With an ABORT I could have just aborted the main CPU instead. Now, with the 816 the need for an MMU becomes less important though.

Here's my CPU board,: http://www.6502.org/users/andre/csa/cpu/index.html

André

_________________
Author of the GeckOS multitasking operating system, the usb65 stack, designer of the Micro-PET and many more 6502 content: http://6502.org/users/andre/

well that's not really necessary as in that case the NMI would fire periodically instead of at a press of a button, making it functionally almost the same, but automated. so if a task gets stuck in a loop the whole system isn't brought to a halt.
(that also makes me wonder, how would an OS detect if a task is stuck in a loop?)


seems perfect to me if you have nothing else on the board using NMI. plus it could be routed through the MMU to only allow NMIs to pass when the system is in user-mode. meaning the system won't receive another NMI while it's already handling one. effectly turning it into an IRQ but not in control of the CPU itself, making it easier to protect against user tasks compared to the internal interrupt flag.


this assumes the interrupt source would keep the NMI line low instead of just pulsing it, in which case yes, additional NMIs coming in wouldn't be recognized.
but if i were to design a board around a 65816 with an MMU i would have exactly 1 device on the NMI line, the jiffy timer, to avoid ambiguity and this issue above.
but that's just how i would design it. if you build the timer around the IRQ instead then you either need a more sophisticated MMU (or HMU) to avoid interrupt flag changing instructions or just trust user programs to not mess with the i flag and simply deal with accidents that mess with it anyways.


and i do agree with BigEd. feature creep is a slippery slope!
so i'll just lock down the MMU/MPU idea i had to just be simple 2 segment memory protection, with bank 0 relocation, interrupt detection to switch into a supervisor mode, and a counter-delayed swich back to user mode when writing to a specific IO register.
it won't ptotect against STP or messing with the interrupt flag, but that's good enough.

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