Simple Expandable MMU System for 6502 & Similar CPUs

[jmp(FFFA)]

Some time ago I looked into building a MMU for an 8-bit CPU like the 6502 and concluded that it would be a job best suited for a CPLD or FPGA. However, the problem was nagging at me for some time so thought about an extremely simple, but expandable system based on off-the-shelf logic chips and came up with the following four-chip solution (more if you replace the single GAL with discrete logic):

Simple Expandable VM System

VA15..VA0 ("virtual address") are the 16 CPU address lines. PA17..PA0 ("physical address") are the 18 physical address lines. D7..D0 is the 8-bit data bus.

The schematic is missing a few details, but the basic idea is, I think, fairly clear. To summarize:

Four 16K pages are mapped into 256K of physical memory for two separate tasks (unfortunately a necessary compromise for simplicity's sake). One task would ostensibly be the supervisor task and the other would be a user task. The MMU is disabled (1/2 of the 74HC244 is used to accomplish this) when the system is reset and remains this way until the operating system switches it on. A 74HC670 4x4 register file is used to manage the mapping for each task. Two tasks are supported in this system thus two HC670s are used. Finally, a GAL is used (a 16V8 is probably adequate) for the glue logic in order to keep the chip count down. It could probably be replaced with 2-3 standard logic chips but as I haven't worked out the exact input/output relationships yet I'm not exactly sure.

Since the GAL will have additional inputs available, the chip select line can be replaced with appropriate physical address lines and address decoding combined with the simple VM system in order to further reduce chip count. The key to the relative simplicity of the design is the dual ports on the 74HC670. It is unfortunate that nothing larger than 4x4 is available in the 7400 logic family.

Once upon a time there were some nice single-chip options available for this problem in the form of the MC6829 and the 74LS610 but I don't think those parts are generally available any more (if I'm wrong, please let me know as I'd love to get my hands on a couple of them).

My intent in presenting this outline here is not to present a complete tested working system (at least not yet) but rather to simply present the idea and hopefully generate some discussion about it. I noticed a couple of earlier threads on MMUs but didn't see any concrete designs other than suggestions to use a 65816 and rely on its segmented architecture (no thanks), or find a MC6829 or 74LS610 somewhere and use it.

The 74HC670s have a relatively low propagation delay which is typically under 15 nS so the impact of this particular design on the maximum system clock frequency should not be too bad.

[BigDumbDinosaur]

jmp(FFFA) wrote:

Some time ago I looked into building a MMU for an 8-bit CPU like the 6502 and concluded that it would be a job best suited for a CPLD or FPGA.

It is a job best suited for one of those devices. Aside from the consolidation of a lot of logic into one device, any reasonably good MMU scheme using discrete hardware is going to be slow and bulky. Your design is using 74HC hardware, which is no faster than 74LS. Readily available CPLDs and FPGAs are usually 10ns pin-to-pin or faster.

Quote:

I noticed a couple of earlier threads on MMUs but didn't see any concrete designs other than suggestions to use a 65816 and rely on its segmented architecture (no thanks)...

The 65C816's architecture is not segmented. It's banked, and the banking aspect is primarily a concern with executable code, not data—wrapping PC will not increment PB. Yes, direct page and the stack are confined to the first 64KB of memory, and some vector code has to be in that range as well to handle interrupts, but even that could be dealt with with sophisticated programmable logic. Data accesses can go anywhere in the addressable range without fiddling with DB, so they are generally bank-agnostic.

In any case, if the idea is to create a protected execution environment there will be much more to it than giving programs a nice, warm place to sleep. In that respect, the '816 has a sizable advantage over the 65C02. This is not to say that it can't be done with the 65C02, only that you will be moving mountains to plant a tomato garden.

[Rob Finch]

There's a second source for MC6829 compatible IC's that I found on Ebay one day. It's under a completely different part number which I can't recall at the moment but it does exist. The 6829's only a 1MHz part though.

If one is going to put an MMU or other logic on an FPGA, one might as well use it for the 6502 core as well. The 6502 core is small enough to fit in many smaller FPGA's. It's a bit of a slippery slope when one starts to use FPGA's to implement logic. Might as well put everything on the FPGA.

Quote:

It's banked, and the banking aspect is primarily a concern with executable code, not data—wrapping PC will not increment PB.

It's not a big concern though the PC is banked. One just has to watch out if coding in assembler not to cross a bank boundary with linear code. Most code isn't a single 64kB module, it's many much smaller routines. So the PC doesn't really need to increment much past 12 or 13 bits because one would be jumping to another code module.

Quote:

In any case, if the idea is to create a protected execution environment there will be much more to it than giving programs a nice, warm

Just plugging my own FT832 core, there's a some memory protection via a segmented architecture. Point is it's possible to get quite sophisticated with the logic using a modern PLD. It'd take many boards full of 74 series logic to replicate something that fits easily in an FPGA. Reminds me of watching the Vulcan-74 project with interest.

The 65816 is a decent upgrade to the 6502.

[jmp(FFFA)]

BigDumbDinosaur wrote:

It is a job best suited for one of those devices. Aside from the consolidation of a lot of logic into one device, any reasonably good MMU scheme using discrete hardware is going to be slow and bulky. Your design is using 74HC hardware, which is no faster than 74LS. Readily available CPLDs and FPGAs are usually 10ns pin-to-pin or faster.

The only delay of any real consequence in my design is that of the HC670 -- which is according to the datasheet has a propagation delay which is typically under 15 nS. Good enough for me. The GAL is available with a pin-to-pin delay as low as 5 nS, though it would not be a limiting factor in this scheme.

BigDumbDinosaur wrote:

In any case, if the idea is to create a protected execution environment there will be much more to it than giving programs a nice, warm place to sleep. In that respect, the '816 has a sizable advantage over the 65C02. This is not to say that it can't be done with the 65C02, only that you will be moving mountains to plant a tomato garden.

I think we had this discussion before with regard go implementing a UART on a PIC. I can't say that I'm unhappy with my results.

In any event, the purpose for this MMU is not just for a 6502, it is for other 8-bit CPUs with a 16-bit address bus like the 6309/6809 as well. The above MMU is also capable of providing a protected execution environment. Since all chip selects in the system are derived from physical addresses the mapping can be arranged by the O.S. so that only task 0 will have access to hardware devices. Task 0 will be the supervisor process.

While there is much to be said for working with FPGAs, I'm not trying to build a product here so I'm not concerned with making the best use of available technology in terms of performance, cost, or efficiency. Instead, I'd like to build something simple and understandable. You know, like the 6502 itself. Something that doesn't require sophisticated tools with steep learning curves to master, something that can be used to assemble a working computer on a breadboard over a course of a few evenings in order to learn and play with concepts. The GAL is a bit of a quandary, but it can be replaced with discrete logic chips if desired.

[jmp(FFFA)]

Rob Finch wrote:

There's a second source for MC6829 compatible IC's that I found on Ebay one day. It's under a completely different part number which I can't recall at the moment but it does exist. The 6829's only a 1MHz part though.

If you think of the part number, let me know. Always nice to have in my growing collection of antique ICs.

Rob Finch wrote:

If one is going to put an MMU or other logic on an FPGA, one might as well use it for the 6502 core as well. The 6502 core is small enough to fit in many smaller FPGA's. It's a bit of a slippery slope when one starts to use FPGA's to implement logic. Might as well put everything on the FPGA.

Yes, and switching from physical parts to virtual parts on an FPGA completely changes the experience for me. I get enough of that at work and would prefer to do something significantly different at home.

Rob Finch wrote:

The 65816 is a decent upgrade to the 6502.

So is the 6309/6809, especially with an MMU.

[richardc64]

The '612 can be found on Ebay in both LS and HCT. Currently the '610 can also be had in LS.

I am working on a scheme to put up to 512K inside a VIC-20 using a 74HCT612. The Mapper will be used slightly differently from as intended. Any 8K chunk of memory can occupy any of VIC's eight 8K Blocks (except BLK4, where I/O is, and BLK0, which is shared with the Vid controller), including "shadowing" of the System O.S. and Basic Interpreter ROMs. Any 8K of RAM can be Write Protected and banked with any external memory, if present.

Since the '612 has 16 Map Registers and I'll need only 8 at any given time, I should be able to change the entire map by changing a single bit in a separate Configuration Register, which already exists in a modification I did decades ago. Another bit in said config. reg. would disable Mapping until auto-starting code in an EEPROM in BLK5 initializes the '612 registers.

Another possibility is to use a dual-port RAM, which shouldn't be as hard to find as a Memory Mapper. I abandoned this idea because it seemed pricey considering that only 16 locations out of 1024 would be used.

[BigDumbDinosaur]

Rob Finch wrote:

Quote:

It's banked, and the banking aspect is primarily a concern with executable code, not data—wrapping PC will not increment PB.

It's not a big concern though the PC is banked. One just has to watch out if coding in assembler not to cross a bank boundary with linear code. Most code isn't a single 64kB module, it's many much smaller routines. So the PC doesn't really need to increment much past 12 or 13 bits because one would be jumping to another code module.

That's an important point. 65xx programs are not huge like what you see in the x86 arena. I've written some really big 65xx programs over the years, but only once or twice exceeded 16KB code size.

[sark02]

I like the idea of using a stock 65c02 and attaching a CPLD or FPGA to it. Like a 70s/80s home computer design - with custom chips doing the custom work. A few days ago I stumbled upon a link around here on a project that uses external logic and documented unused opcodes in the 65c02 in order to implement custom instructions. A single instruction Forth NEXT was one of them. Sorry, I can't find the link now.

Still, the point being that you could use the FPGA to implement an MMU and, as extra credit, custom instructions to manage it (as opposed to having a memory mapped interface). All with a stock 65c02.

Which ever way you go, it sounds like a fun little project. Good luck!

[BigDumbDinosaur]

richardc64 wrote:

The '612 can be found on Ebay in both LS and HCT. Currently the '610 can also be had in LS.

In lieu of the '612, I suppose one could use an EPROM to emulate the '612's behavior. The fastest EPROMs currently available (e.g., the AMD 27C256-55) are well beyond the performance requirements of a 1 MHz machine like the VIC-20. Even faster is the Atmel 27C256 PROM, which is rated at 45ns (I have one in POC V1 right now). Also possible, I would think, would be synthesizing the function of the '612 in a 22V10 GAL.

The trouble with using old silicon like the '612 is performance tends to be lackluster, fanout may be weak and the available sources may be dubious in nature. In particular, buying chips off eBay runs the risk of being sold a counterfeit.

[BigDumbDinosaur]

sark02 wrote:

A few days ago I stumbled upon a link around here on a project that uses external logic and documented unused opcodes in the 65c02 in order to implement custom instructions. A single instruction Forth NEXT was one of them.

Was that Jeff Laughton's (Dr. Jeffyl) KimKlone perchance?

[sark02]

BigDumbDinosaur wrote:

sark02 wrote:

A few days ago I stumbled upon a link around here on a project that uses external logic and documented unused opcodes in the 65c02 in order to implement custom instructions. A single instruction Forth NEXT was one of them.

Was that Jeff Laughton's (Dr. Jeffyl) KimKlone perchance?

Yes! It's such a clever design.

http://laughtonelectronics.com/Arcana/K ... intro.html

[BigDumbDinosaur]

sark02 wrote:

BigDumbDinosaur wrote:

sark02 wrote:

A few days ago I stumbled upon a link around here on a project that uses external logic and documented unused opcodes in the 65c02 in order to implement custom instructions. A single instruction Forth NEXT was one of them.

Was that Jeff Laughton's (Dr. Jeffyl) KimKlone perchance?

Yes! It's such a clever design.

http://laughtonelectronics.com/Arcana/K ... intro.html

Yes it is.

[Aslak3]

jmp(FFFA) wrote:

Rob Finch wrote:

The 65816 is a decent upgrade to the 6502.

So is the 6309/6809, especially with an MMU.

Seconded. Though I suspect we are in the minority here. That's fine.

My project (PCB stage) includes a 6809 and a couple of Altera Flex10K to implement a bus stealing DMA controller and a simple 4K/16 page MMU, as well as other functions. I am consciously limiting myself to through-hole, 5V parts.

jmp(FFFA): I agree with a lot of what you've said. Part of the attraction with using a discrete, "retro" CPU with a modern PLD is to replicate what a state of the retro-art 1980s micro would have achieved with a bunch of ASICs. Something like the Sam Coupe, C64, or even the Amiga. Working on a similar design with everything embedded in a contemporary FPGA feels quite different to me.

[Dr Jefyll]

BigDumbDinosaur wrote:

sark02 wrote:

BigDumbDinosaur wrote:

sark02 wrote:

A few days ago I stumbled upon a link around here on a project that uses external logic and documented unused opcodes in the 65c02 in order to implement custom instructions. A single instruction Forth NEXT was one of them.

Was that Jeff Laughton's (Dr. Jeffyl) KimKlone perchance?

Yes! It's such a clever design.

http://laughtonelectronics.com/Arcana/K ... intro.html

Yes it is.

Thanks, fellas. sark02 linked to a somewhat long-winded description, so anyone who prefers a short summary should try here instead. There's also a forum thread here.

BTW the KK uses hc670's! Terrific little chip. I started a thread about them, too!

[jmp(FFFA)]

richardc64 wrote:

The '612 can be found on Ebay in both LS and HCT. Currently the '610 can also be had in LS.

Thanks! Just found a couple of them there. Performance is disappointing (75 nS worst case access time) but it should be adequate for speeds up to 4-5 MHz assuming one uses relatively fast memory with it).

richardc64 wrote:

I am working on a scheme to put up to 512K inside a VIC-20 using a 74HCT612. The Mapper will be used slightly differently from as intended. Any 8K chunk of memory can occupy any of VIC's eight 8K Blocks (except BLK4, where I/O is, and BLK0, which is shared with the Vid controller), including "shadowing" of the System O.S. and Basic Interpreter ROMs. Any 8K of RAM can be Write Protected and banked with any external memory, if present.

That is a bit different from what I had in mind, but it makes sense if you want to maintain compatibility on a retro system that was never designed to be used with an MMU.

richardc64 wrote:

Another possibility is to use a dual-port RAM, which shouldn't be as hard to find as a Memory Mapper. I abandoned this idea because it seemed pricey considering that only 16 locations out of 1024 would be used.

That is more-or-less what the 74HC670 is. You still need some additional logic to go with it to build an MMU, but that's the heart of it. Which dual-port RAM were you looking at?