How does the CPU know, on return, that it jumps into supervisor mode?
Is it because the return address is flagged as supervisor? How do you prevent the user from manipulating the stack and this way 'jump' anywhere into supervisor memory?

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

JBANK represents the memory bank/block that you are goint to JMP to (when you set the next entry with the MMJ instruction).

To make the thought process easier, lets focus on the 64K-mode. Thus, every bank is 64KB in size and the JBANK equals the 4 most significant bits (MSB) of the 20-bit memory address. Now, you don't utilize the stack during the JMP instructions so its not so interesting in that regard, but if you jump with an JSR, the 65C02 pushes its 16-bit address onto its internal stack in the normal way. But the address is 20-bit here, so what do you do with the upper 4 bits?

To answer that, the upper 4 bits represents the bank number and they are pushed onto the JBANK stack which is a separate internal stack of the MMU. It is handled the same way during an RTS: The MMU will pull the last entry from the JBANK stack and use that as the 4 MSB of the 20-bit address when it returns to the location of the JSR. So you get back to the correct 20-bit address as the 65C02 CPU pulls its 16-bit address from the normal stack, and everyone gets happy (=you return to the same 20-bit address from which you initiated the JSR instruction).



The CPU doesn't know about supervisor or user mode, it's fully handled by the MMU. It is also only available in the 64K-mode for a number of reasons (which I won't discuss now). E.g. with 64KB memory blocks.

Lets define supervisor mode as the "normal mode" of the 65C02 CPU. Supervisor memory is all the memory in the system as it can all be read in supervisor mode. If you have for example 1MB, that is 16 memory blocks/banks of 64KB each. Through normal 65C02 CPU instructions and MMU instructions you can read (and run programs) within all of the 1MB of memory.

"User mode" on the other hand can only read "user memory". The MMU prevents any memory access to supervisor memory in the user mode. If one 64KB memory block/bank is user memory, programs running in that bank will not see the rest of the memory (even through MMU instructions).

In 64K-mode the MMB instruction gets another function once the PROTECTED_MEMORY flag is turned on. One can then set an "access key" for each memory block. The key is only possible to set in supervisor mode, and it can be set to a value between 0 and 255. If set to a number>0, the memory block will be user memory. If, on the other hand it is reset back to zero, that memory block/bank is going to be supervisor memory.

The user mode is triggered once a JSR happens into a memory block with access key>0 (e.g. the PC points to user memory). A program in this memory block won't be able to read other memory blocks unless the access key of that memory block is the same as for the current memory. So there is no way to read supervisor memory or supervisor stack from user mode, and no way to "jump" to supervisor memory either. The program running in user mode simply doesn't see supervisor memory or other user memory blocks (with different access keys).

The only way to exit "user mode" is through a RTS instruction or an interrupt. Once a RTS instruction is coutered, the MMU pulls the return bank from the JBANK stack and the CPU pulls the return address from the 65C02 stack in supervisor memory. If an interrupt occurs, the MMU pushes current user memory bank into the JBANK stack (while the 65C02 pushes the current address into its stack) before it pulls either IBANK (IRQ) or NBANK (NMI). It then uses that as the memory bank before it pulls the interrupt address vector and jumps to that. IRQ and NMI interrupt routines can reside at different memory banks.
At RTI, the MMU will pull the JBANK stack again and return to the address that the interrupt occured at (by pulling the 65C02 stack at in that bank).

So its all pretty secure. There is simply no way for a program in user memory to access data in supervisor memory. You can't set access keys in the user mode either, so its totally isolated.

I have alot of macros to handle the 20-bit addressing. I will add those to the next version of the manual since I think it makes it easier to use (you won't have to think about MMU instructions in that way).

Ah, so it is a stack in the MMU... I think it would help a lot to have some kind of block diagram of the MMU.

In 64K-mode the block diagram should look something like this:

In 4K-mode, the MMU simply takes over more of the address bus (A12-A19).

Hrrm, the MMU is still a black box there. What would help me is seeing what the internal state is, what internal computations are being done, if any. For example, it wasn't clear that there's an internal stack for long subroutine calls.

I second Ed. More internal view would be great.

How is the MMU internal jbank stack affected when the user manipulates the normal CPU stack or just the stack pointer? Is there an internal stack pointer on the jbsnk stack that can be manipulated?

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

I’m afraid thats the best I can do. My drawing skills are limited.

There is a flag (BANK_REG_MEM) that exposes the JBANK stack in the $0100-$01FF area and the internal registers from $0000 and upwards. E.g. you can read and write to it directly as you please.
With code it would be
to switch the BANK_REG_MEM on and make it visible
to switch the BANK_REG_MEM off and make the zeropage and normal stack visible again.

kakemoms: I think you are being trolled. I find it incredulous that fachat, the designer of a 4KB MMU has difficulty understanding the design of your 4KB MMU. I've had similar negativity after distilling the results of fruitful experiments into a form which can be replicated. In your case, your superior design, which does not require obsolete parts, has significantly higher throughput and does not suffer the case where the MMU banks out its own registers. Furthermore, I had no difficulty understanding your design after reading your first message on the subject - without looking at diagrams or your extensive accompanying documentation.

I get the impression that the MMU is intended to work in a manner similar to the popular Commodore64 REU memory expansion, without the pregnant pause of block copying, with a more conventional 4KB page size, and without excluding a mode to access linear arrays exceeding 64KB. It is disappointing that you have received repeated attempts at feigned ignorance from the designer of a scheme which is more similar to MIL-STD-1750A 16*4KB banking. Indeed, it is possible that you weren't tag-teamed by BigDumbDinosaur ("Every so often, I bite...hard.") because you have a working implementation - and superior knowledge of FPGA.

I thought you'd get complaints about the window size. There is no definite size which covers all cases but such ambiguity offers plenty of scope for prevarication. Dr Jefyll advocates 64KB banking and has considered this problem a while longer than many of us. Whereas, personally, I'd prefer multiple windows which are larger *and* smaller than 4KB; partly because there are relatively obscure cases where splitting a pointer is slightly faster if the boundary is nearer to 8 bit boundary. Regardless, your 4KB mode and 64KB mode are a very good hedge. They cover multiple common scenarios and if this is not sufficient then people can tweak a derivative of a derivative of the most popular open source 6502 FPGA core.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!

Please don't act in bad faith - accusations of trolling here are not welcome, and not constructive.

There are a few issues with the current code and its still quite buggy. I have to think through the logic of the MMU stack, but its apparent that the stack memory needs to be moved out of the core. Currently it slows everything down.

I am also looking into how to disenable the MMU during compilation (making it a WDC 6502 compatible core without the MMU overhead).

Since its still in beta, don’t use it for anything other than testing. Features may change.

@sheep64 I'm not trolling. I know what a 4k page MMU does and I get the different registers.
What I have trouble with is the design of JBANK stack and how it is supposed to be as secure as promised. Especially when I think about the many possibilities a programmer has manipulating the (user) stack and stack pointer.

For example. I assume the OS will call into a program in user memory, so will put a return address on the stack and a return bank on the jstack. Now the programmer does a PLA:PLA to pull the return address and then does an RTS. Which return address and bank will the CPU pick?
What about programs that push a return address on the stack and then do an RTS (like many progs do like monitors after identifying the command). What jbank value is pulled from the MMU stack? If the programmer has to take care of that, fine, that is a new programming model. But it will not be compatible with the original, at least not for such types of programs, which are common for the 6502

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

Sorry for the slow reply here, too much other stuff going on.

Its secure because the current active stack is not what RTS use for the return address. Jbank stack is separate and only used for bits 16 and above, while bits 15-0 are pulled from the stack of the return bank. If you only had one stack this would not work, but you can have as many stacks as you want (well, currently limited to 256, but that will change in the future)

Example (without opcodes and with 64KB banks for simplicity)

1. Set protected memory mode
2. Set JBANK[JSP+1]=1
3. Set JBANK=1 memory key to $12 (or whatever)
4. JSR $2345 (pushes return address into current stack and jumps to $012345)

Now if you pull the stack, you are going to pull a value from $0101xx, but the return address into bank $00 (were you started) is in $0001xx.
Since the memory key of bank $01 is not zero, you are not going to be able to read outside or jump out of bank $01. Only way to leave bank $01 is to use an RTS or trigger an interrupt. An exception is if another bank has the same memory key, then you could jump or read/write into that.