6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Wed Nov 13, 2024 1:19 am

All times are UTC




Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: Discrete mmu?
PostPosted: Sun Jun 12, 2016 5:45 pm 
Offline

Joined: Wed Dec 09, 2015 6:17 am
Posts: 17
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Sun Jun 12, 2016 6:39 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Sun Jun 12, 2016 6:59 pm 
Online
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8540
Location: Southern California
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.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Mon Jun 13, 2016 7:39 am 
Offline
User avatar

Joined: Sun Dec 29, 2002 8:56 pm
Posts: 460
Location: Canada
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.

_________________
http://www.finitron.ca


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Mon Jun 13, 2016 8:12 am 
Offline

Joined: Sun Apr 10, 2011 8:29 am
Posts: 597
Location: Norway/Japan
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Mon Jun 13, 2016 8:52 am 
Offline
User avatar

Joined: Fri Nov 09, 2012 5:54 pm
Posts: 1431
@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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Mon Jun 13, 2016 9:31 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
(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.)


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Thu Jun 16, 2016 7:41 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Thu Jun 16, 2016 8:41 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Thu Jun 16, 2016 8:54 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Fri Jun 17, 2016 9:48 am 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
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!


Last edited by cbscpe on Fri Jun 17, 2016 5:18 pm, edited 1 time in total.

Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Fri Jun 17, 2016 9:52 am 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10977
Location: England
(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!


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Fri Jun 17, 2016 2:56 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
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. :lol:

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


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Fri Jun 17, 2016 3:11 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8483
Location: Midwestern USA
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.

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


Top
 Profile  
Reply with quote  
 Post subject: Re: Discrete mmu?
PostPosted: Fri Jun 17, 2016 5:56 pm 
Offline
User avatar

Joined: Sun Oct 13, 2013 2:58 pm
Posts: 491
Location: Switzerland
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 http://forum.6502.org/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 :lol: ). I'm thinking about a very simple mapping

Code:
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 22 posts ]  Go to page 1, 2  Next

All times are UTC


Who is online

Users browsing this forum: No registered users and 6 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to: