Hi,
I want to create an simple MMU to a 6502 system and maybe it will stay as a basic mapper like the 74LS610 circuit or might be improved in the future (the mapper will be in a programmable IC so it can be improved).
One idea I had, which maybe is not working at all, would be to control the CPU clock from the MMU, so that it can be halted if an memory page that isn't assigned yet is accessed. Normally the 6502 can't handle this situation and I have seen solutions with 2 6502s or using a 65816 instead, but if I halt the processor clock after it outputs the address (so I know were it wants to read/write), then I could reserve the new page and let the processor continue without knowing anything has happened. Or am I missing something?

You could do this - so long as your circuit is glitch-free, and you can decide to stop the clock ideally while it's still low, it should be workable.

As Ed said, it ought to work. The MMU would have to be sufficiently fast to reserve the page before Ø2 rises, as outright stopping of Ø2 with the NMOS 6502 may cause it to lose register content.

What you'd like to do would be much easier, I'd think, with the WDC 65C02, as its static core makes it possible to completely halt Ø2 with no loss of data. That would give your MMU more time to set up the new page. Carrying that a step farther, the WDC 65C02 will respond to the RDY input during a write cycle, so you could control the MPU with RDY, which should be more elegant and less complicated than fiddling with Ø2. The WDC 65C02 is a drop-in replacement for the NMOS 6502 (with a minor caveat), and offers better performance, new instructions and new addressing modes for existing instructions.

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

Yes I planned to use the newest 6502 from WDC so it would have a static core. I'm not sure I understand the RDY pin 100%, but is it halting the processor in the middle of the operation or will it finish it first? I need to halt the processor in the middle of the command so that the address is output on the bus, but not doing anything else.

When RDY is pulled low the MPU stops on the next rise of Ø2 and remains halted until RDY is brought high again. The response to RDY is immediate. If, for example, the MPU is fetching an opcode when RDY is pulled low the MPU will remain in the opcode fetch state. The state of RWB and the address and data buses when the MPU is halted in this fashion will be maintained. Hence your MMU logic can handle a page fault and once the fault has been resolved, restart the MPU with absolutely no loss of function.

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

Aren't page faults normally resolved by the CPU though, say to load blocks from the disk, at least for major faults. But even minor faults involve CPU time, I think? Can someone explain how the MMU hardware can bring pages into play? Why wouldn't these pages simply always be mapped when a "procees" is started?

I really hope this kind of technique is possible, since it sounds extremely cool. I'd love to hear what pieces I'm missing.

_________________
8 bit fun and games: https://www.aslak.net/

I only knows the basics about how an MMU works, so it had been nice to make a project with one to learn more about it.
From what I understand, when a page fault is found, the MMU send an IRQ to the processor and the processor must deal with it and reserve a memory page and after that continue on with the operation that generated the fault. For that to work, the CPU must be able to hold the operation and do stuff the 6502 can't do.

If the MMU is smart instead and can handle the memory operation and reserve new pages, when it wouldn't matter if the CPU isn't so intelligent and it would make everything much easier.

One thing I am not sure about is if handling page faults are just to handle programming errors or is it used for "everything". For example if I have an 8kb program and use 4kb pages. When I load the program and store it in memory it will generate an page fault after I tries to write the byte after the first 4k. But since I already know the program is 8kb I could have reserved two pages for it at the beginning and wouldn't get any page faults.
If this is the case, when dealing with faults wouldn't be so important on an simple 6502 computer to make simple multitasking operations.

It's up to you how much you want the MMU to do! There's a whole range of possibilities
- just additional memory
- relocation
- read-only memory
- execute-only memory
- supervisor access only memory
- protection between tasks in a multitasking system
- detection of out of bounds accesses
- filling and spilling RAM to a storage device

I would guess that almost all 6502 systems with banked memory are using it purely to allow for more than 64k of memory in the system. Some of those allow only for data access and others allow for execution too. There are also some multitasking systems, some of which might use banked memory and some which won't, some of which will offer protection between tasks and some which won't.

I would go further and say most 6502 systems with banked memory have no concept of a fault: it's the program's responsibility to set up and adjust the MMU memory map ahead of the intended use, and if the setup isn't done then the program will access the wrong data. In most 6502 systems, it's possible to access an address which has no hardware behind it, in which case something unexpected will happen - again, no concept of an address fault. In some systems the values read from unmapped addresses are predictable enough that software will rely on the behaviour of reading those addresses.

That's where the 65C816 has the advantage. The ABORT interrupt was designed to do exactly what you describe: interrupt the MPU so the page fault can be corrected and then re-execute the last instruction.


In most virtual memory systems—which is what you are describing, any access to a non-existent page is a fault, be it an opcode fetch, operand fetch or data access. Your paging methodology shouldn't have to "know" the difference, insofar as how to map in a non-existent page. Where it would matter if it's an opcode/operand fetch or a data access would be in the realm of memory protection. Your MMU could impose a rule that prohibits data accesses into program space. That would cause a different fault: a memory access violation, which is usually fatal to the running program.

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

Yes I understand the 65C816 is better to use, but when I guess there are other processors that are even better to use and finally you have design a modern PC

I like the idea of making an advanced 8 bit computer, unless there is to much work involved so that's why I thought making the MMU smart and handle what the CPU usually does would be much easier. I plan to use a PIC32MZ microcontroller as MMU since I am very familiar with them (A CPLD or FPGA could probably work too). Since the PIC32 can run at 200MHz it would be a lot faster than the 6502 and could handle simple MMU operations very quickly. It could keep track of memory faults and other stuff so it should be simple to use.

I'm an eccentric individual, and I understand the "mental exercise" part of this ... so I'm rooting for you, although I am struggling to imagine a practical use for virtual memory on a processor with only 16-bits of native addressing (or even 24-bits, for that matter), with RAM prices being what they are. The other points Ed listed for MMU functionality seem like interesting exercises too, so I don't want my comment to be mistaken as negative. Let 'er rip!

Best wishes,

Mike B.

[Edit: Have you seen Ruud's write-up? http://www.baltissen.org/newhtm/mmu.htm ]

My comment was in the context of this project being built on 65xx hardware, which is why I mentioned the 65C816's support for the concept of instruction re-execution following a page fault.


I'm sure a big-enough CPLD could do the job with some adroit programming. Also, the hardware interface vis a vis the 6502 would be less onerous to work out. Doing this with a PIC could prove to be a challenge in working out the timing, since both the 6502 and the PIC would have to be bus masters on a cooperative basis.


I can't speak to the PIC's performance, as I've not explored using one in any situation. However, commentary by others has suggested to me that the PIC's throughput is not all that great relative to clock speed.

Good luck with your project.

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

I have it on good authority that a PIC32MZ clocked at 14 MHz will run circles around a 65816 running at 14 MHz.

But if you want some hard numbers:

ARM Cortex M4: 1.25 MIPS/MHz (see https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures)
ARM Cortex M7: 2.14 MIPS/MHz (see https://en.wikipedia.org/wiki/List_of_ARM_microarchitectures)
PIC32MZ: 1.65 MIPS/MHz (see http://www.microchip.com/pagehandler/en-us/family/32bit/)

Of course if the OP wants to use a PIC32MZ as an MMU for the 6502, I'd suggest just emulating the 6502 directly. I've little doubt that a 200 MHz PIC32MZ will emulate a 65c02 a lot faster than 14 MHz, even if the entire emulator were written in C. Adding an MMU in this case would be an interesting exercise in programming. With 512 kB of built-in RAM, you'd have plenty of memory to play with as well.

jmp(FFFA), BDD's comment about microcontroller speed was with reference to using it as glue logic and more-sophisticated logic (an MMU in this case) to support a 6502/816. In a recent topic, I figured a 25MIPS PIC (100MHz in that case) was marginally fast enough to substitute for glue logic for a 1.79MHz '02, where the PIC has to run several instructions per half cycle of the '02, and it cannot start the sequence immediately at the fall of phase 2 (because the processor doesn't have the address and R/W\ out yet), and it has to be finished well before phase 2 rises (to give peripheral ICs some setup time), and the PIC does not have time to use any interrupts, and really can't have any branching other than to re-start the loop.

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

(Be sure to check out Fuzix, a unix-like OS suitable for 8-bit machines with a 16-bit address space and suitable banked memory. Rather than porting an OS to a machine, there's an opportunity here to build a machine suited to an OS! See https://github.com/EtchedPixels/FUZIX)

We seem to have had a few discussions recently about using microcontrollers to act as glue and to provide added services like I/O or bootstrap code, or, in this case, paging. If the 6502 runs at full speed then there's a need for the microcontroller to run significantly faster. On the other hand, if the micro controls the 6502's clock, or has a way to stall the clock or to use RDY, it need not be so fast. It only has to be just quick enough to bring the machine to a rolling stop when something interesting happens. A very simple case would be to watch A15 - any activity in the low half of memory proceeds at full pace, any activity in the high half causes the supporting microcontroller to call a time out and have a quick think about whether or not to intervene.

So, as ever, there are several possible approaches - and whoever feels moved to have a go with one approach or another should feel encouraged to see the project through.