I think a bigger problem here is the DMA, not the MMU.
In your setup, all the MMU needs to do is to decode address lines into chip selection signals, which for 3 chips is likely going to take just a few NAND gates (or a single PLD).
DMA (direct memory access) to your RAM - i. e. reading/writing RAM by some other controller without involving your primary CPU - is a tricky thing, and it's been practiced a lot by people on these forums who want to add video output to their computers. Personally I didn't have enough guts nor experience for that..
I'm not too familiar with '816, so here are some of my personal thoughts as from someone who comes from '02:
Easiest way to go would probably be to use a dual-ported RAM - you don't need to worry about bus sharing, timings and signal propagation delays. Unfortunately, dual-ported RAM chips don't seem to be popular nowadays, which is a problem unless you're fine with using parts that have reached end-of-life and aren't manufactured anymore.
Slightly more complex method is sharing the bus by doing DMA while CPU Ф2 signal is low (this is easier to do with 65C02, since 65C816 will still drive the data bus during low phase of Ф2 to present address lines 16..23)/
Most complex method (although, in case of '816, it might be easier than previous one) is stalling the CPU, doing the DMA, and then resuming the CPU. The problem with this approach is that you cannot stall the CPU whenever you want: you must synchronize this with Ф2 signal to make sure CPU has time to finish what it's doing and release the buses for your DMA to take place. If your secondary controller is very timing-specific - e. g. if it needs to access RAM at very precise times to generate real-time video signal.
Some helpful posts:
-
viewtopic.php?f=4&t=2898-
viewtopic.php?f=4&t=2438EDIT: As Jeff mentioned - video is indeed hard, mostly due to its time-sensitive nature.
As for the pads - what exactly do you mean by those? If they are some input devices, you will definitely need additional components to handle them and possible generate interrupts whenever the input state changes.
EDIT 2: If you're trying to build your first SBC and would like to have some visual output - I highly recommend to start with a character LCD display. Those things are cheap and come in all shapes and sizes: 8x1, 8x2, 16x2, 20x4, 40x4 - just to name some. There are even OLED versions of those - I recently purchased one. All of them usually have 16-pin headers and use HD44780-compatible controllers. There are even bigger ones based on T6963C-compatible controllers (I have two, 240x64 & 240x128 pixels, and they also have built-in fonts).
Besides,
if you run your SBC on a relatively small speed - say, 1 MHz - you can interface the above-mentioned displays directly with your CPU without the need in additional parallel I/O ports. This means you can build an entire very simple SBC with just a handful of chips: CPU, RAM, ROM, address decoder, and a display itself!
_________________
/Andrew
deck65 - 6502 slab with screen and keyboard |
ПК-88 - SBC based on KM1810VM88 (Ukrainian i8088 clone) |
leo80 - simple Z80 SBC
nice65 - 6502 assembly linter |
My parts, footprints & 3D models for KiCad/FreeCAD