Discrete mmu?

[nonanon]

Hey all,

I've been thinking, any cpu that supports interrupts should easily be able to connect to an external mmu, 68451-style... right? Anyone ever tried to make an external mmu out of 74xx parts for a 6502/other cpu?

[BigEd]

For demand paging, you need more than an MMU with interrupts, you need a way to abort and rerun an instruction.

But for banking, you need the MMU but you don't need an interrupt (I think.) In this case, you can make something simple out of 74 series, for sure.

[GARTHWILSON]

nonanon wrote:

Anyone ever tried to make an external mmu out of 74xx parts for a 6502/other cpu?

and

nonanon wrote:

For demand paging, you need more than an MMU with interrupts, you need a way to abort and rerun an instruction

which the 6502/65c02 doesn't have but the 65816 does have.

[Rob Finch]

Quote:

Anyone ever tried to make an external mmu out of 74xx parts for a 6502/other cpu?

I haven't actually gone beyond a few rough schematics for 74xx parts, but I've implemented a 6829 like mmu in an FPGA.
A 74HCT612 might be useful to start with.
If the system is big and complex enough to require anything beyond simple bank switching it's probably best to use an mmu IC rather than a boatload of 74xx parts.

Quote:

For demand paging, you need more than an MMU with interrupts, you need a way to abort and rerun an instruction.

It's not impossible to do demand paging on a cpu without being able to abort and rerun but it ain't easy.
One might be able to use the trick of two cpu's running the same code with one cpu delayed by several cycles from the other. Then when there's a need rerun an instruction the delayed cpu become the primary cpu, and the primary cpu is reset. I've heard of this type of thing in a 68k system.

[Tor]

Rob Finch wrote:

One might be able to use the trick of two cpu's running the same code with one cpu delayed by several cycles from the other. Then when there's a need rerun an instruction the delayed cpu become the primary cpu, and the primary cpu is reset. I've heard of this type of thing in a 68k system.

This was done in some early systems, yes. The problem with the 68000 was that it had restartable instructions, but there were some exceptions..
The 68010 fixed this, and was what the 68000 should have been in the first place.
As for the 65816 abort instruction - isn't that one somewhat similar to the 68k case? Not able to restart every instruction all the time?

[ttlworks]

@nonanon:
The interesting question here is, whether you want to "resume" code
that had caused a protection\segmentation fault or not.

If you want to "resume" code, to implement virtual memory and such,
I think you need to re_run an instruction, what calls for a fully sized MMU
and a 65816.

If it's _only_ about security,
like terminating programs that had caused a protection\segmentation fault,
a "Memory protection unit" might do. That's simpler to implement than a MMU.
The trick would be to define a certain area of code\data\stack in memory
that a certain piece of code is allowed to use...
then to make "creative use" of 7485 comparators or such.

[BigEd]

(Some stories about trying to run big OS on small CPUs:
https://news.ycombinator.com/item?id=7684824
which sheds just a little light on the 68000 problem.)

[cbscpe]

Considering the addressspace of a 6502 (64kbytes) and the typical prices for a 512kbyte SRAM demand paging is not required in my opinion. Give each process it's dedicated 64kbytes is probably the simplest mapping. So a simple bank register is enough. Only the kernal needs to access other address spaces. Giving the kernal a window into the other ranges using another register that is e.g. used when addressing a certain range like $8000 to $8FFF will serve this. Now you need only some Glue to decode the user and kernal mode and select the appropriate mapping register and support to switch between user and kernal mode. I would say that's all you need as a MMU. 512kbyte would allow to run up to seven user addressspaces and one kernal addressspace. I would make a read vector the signal to enter kernal mode. VPB on a W65C02 could be used for that. Entering user mode needs some more thinking.

[BigEd]

It's easier if you don't worry too much about those user programs somehow accessing things they shouldn't. I'd recommend starting simple, as ever.

[BigDumbDinosaur]

cbscpe wrote:

I would make a read vector the signal to enter kernal mode. VPB on a W65C02 could be used for that.

Something I plan on doing when I build a POC iteration with the necessary resources.

Quote:

Entering user mode needs some more thinking.

Assuming all kernal calls are finished with an RTI to return to the (user mode) caller, the glue logic, which would be sniffing the data bus during opcode fetches, would detect $40 and use that as the signal to switch out of supervisor (kernel) mode.

[cbscpe]

BigEd wrote:

It's easier if you don't worry too much about those user programs somehow accessing things they shouldn't. I'd recommend starting simple, as ever.

Of course it is easier, but this is not the topic here, the topic is to have a MMU.

BigDumbDinosaur wrote:

Assuming all kernal calls are finished with an RTI to return to the (user mode) caller, the glue logic, which would be sniffing the data bus during opcode fetches, would detect $40 and use that as the signal to switch out of supervisor (kernel) mode.

Good point, I would then combine it with a flag that can be set in kernal mode. So switching back to user mode only happens when fetching a RTI instruction and this flag is set.

Edit: Strange I always used the QUOTE button and did not check the names inserted, sorry!

[BigEd]

(I was only intending to say that an MMU can do a multitude of things, and an initial implementation needn't try to do all of them. Implementing a kernel and user mode is one of those things, making that totally secure is another.)

Edit: I think your quoted texts there are mis-attributed!

[BigDumbDinosaur]

BigEd wrote:

(I was only intending to say that an MMU can do a multitude of things, and an initial implementation needn't try to do all of them. Implementing a kernel and user mode is one of those things, making that totally secure is another.)

Edit: I think your quoted texts there are mis-attributed!

I didn't realize I had switched identities! Must be one of those shape-shifting things.

[BigDumbDinosaur]

cbscpe wrote:

BigDumbDinosaur wrote:

Assuming all kernal calls are finished with an RTI to return to the (user mode) caller, the glue logic, which would be sniffing the data bus during opcode fetches, would detect $40 and use that as the signal to switch out of supervisor (kernel) mode.

Good point, I would then combine it with a flag that can be set in kernal mode. So switching back to user mode only happens when fetching a RTI instruction and this flag is set.

My thought train runs along the line of using COP (65C816) or BRK (65C02) for all kernel calls. During the final cycles of the software interrupt processing, the detection of VPB going low would set a latch in the CPLD/FPGA saying that the system is currently in supervisor mode, relaxing protection rules and making it possible to change the memory map (as well as other things you might define as needed). Upon executing the RTI needed to return to the caller, the latch would be released, returning the system to user mode. It would be incumbent on the operating system to make sure the caller's memory map is in context before the return.

In the case of the 65C816, supervisor mode could allow the direct page and stack pointers to be changed to point at private kernel locations for internal processing purposes. It would also be advantageous to know where the user-mode stack is located so the kernel internals can access it to grab elements in an API call stack frame, as well as rewrite said elements for return to the caller. DP and SP would have to be restored to their entry values before returning, since it would be the user-mode stack on which the registers and return address would be saved at the time of the API call. This is all relatively simple programming with the '816.

The same procedure would be applicable to hardware interrupt processing, since that would be a supervisor mode scenario.

[cbscpe]

I fully agree, but still as I said I want to combine it with a flag as not necessary all RTI return to the user (nested interrupts or the NMI occurs during processing of a system call). So it is more or less the same I was discussing here viewtopic.php?f=1&t=4141 only there I still thought about using a 74LS610/12 but in this discussion it came to my mind that a simpler mapping is as good as having a 74LS610, so indeed as you mentioned in the other thread, this certainly can be implemented in a CPLD (e.g. ATF1508AS) as soon as you only have very few mapping registers. Which on the other hand would allow a very fast (10MHz or higher) system as the ATF1508AS would account only for about 10ns delay.

As for the protection rules. Each user only sees "his" 64kbyte RAM and nothing else. It is more separation than protection. The only way for the user to exit it's jail is to use break (jail-break becomes a completely differnt meaning here ). I'm thinking about a very simple mapping

Code: Select all

User: $0000..3FFF Page 0
      $4000..7FFF Page 1
      $8000..FFFF Page 2 

Kernal: $0000..3FFF physical RAM $00000..003FFF
        $4000..7FFF a window that can be mapped anywhere in physical RAM using a dedicated MMU register mainly to access the user space
        $8000..BFFF IO
        $C000..FFFF physical RAM $00C000..00FFFF No ROM (bootstrap like in my other project Romulus 1st) 

You may ask why only 3 User Pages of un-equal size. The answer is I want to use only one Macro Cell per physical memory address line in the ATF1504AS to select the physical address and I have only 5 Product Terms per Macro Cell. This saves resources and minimizes propagation delay.