DISCLAIMER: I haven't yet looked into the 65816, how it works, how it handles the 24-bit address bus, how it's control signals works... I do have some basic knowledge, but I still need more work to fully understand it. So, expect some mistakes and misconceptions in this posts, maybe some competely impossible things.
As I plan to clock the CPU as fast as possible, and I also plan to have several potentially slow devices, wait-stating the CPU is mandatory in my design. This is something I've never done, and I think it needs to be in the core of my design.
I do know the following :
- The CPU will output the bank address (A16-A23) over the same pins as the Databus while PHI2 is low
- The RDY pin is problematic (Thanks BDD for viewtopic.php?f=4&t=5229)
- Streching the clock in PHI2 high phase is (I think) the most convenient solution
And so, this is my first attempt at the noVa64 core:
Code:
CPU MMU MAIN DRAM
+-------+ +-------------+ +-----------+
| |ADR+DATA| | | |
| +---+----+ +------+ |
| | | | | | |
| PHI2 <---+----+ | | |
| | | | | | |
+-------+ | +-^-----------+ +-----------+
| |
| | VIDEO VIDEO DRAM
| +-+----------+ +-----------+
| |HaltRq | | |
| | | | |
| | +-------+ |
+----+ | | |
| | | |
+------------+ +-----------+
Let's explore my idea. In the upper half of the diagram I have the CPU (Remember, WDC 65c816 CPU), along with the "MMU", and my 16 MB of DRAM. The MMU will need a better name, as you will see, as it is much more than a MMU. It probably doesn't even qualify as a MMU at all, but let's still with the name for now.
The MMU will be a FPGA, or a CPLD, whichever suits me best. It will generate PHI2 for the CPU, so it will have full control over it. It sits on the full Address+Data buses, directly from the CPU. It will handle then the Bank Address bits, and generate the full 24bit address bus. It will act as a DRAM controller, handling all DRAM control signals, refreshing, etc.
I'm not sure how fast I can have the DRAM respond. Inside the FPGA I'll have the decoding logic propagation delays, the delay added by the DRAM controller, and so on. It feels I won't be able to get single clock reads and writes from the DRAM, not always at least. It will be the MMU job to strech the clock during PHI2 high phase enough for this to work. Again, I still have no idea how to make this work, but sounds doable.
As the MMU sits on the full bus, it can also handle address decoding for other peripherals. This is not yet on the diagram, and the list is far from closed, but I'm thinking something like this :
- 65SPI (https://sbc.rictor.org/65spi2.html). Will be able to talk to plenty of devices with just this! The battery pack? USB controller? Storage?
- 6526/6522-ish device.
- RTC?
- Audio?
The MMU, if a FPGA is used, could also host a small Boot Rom. Enough to grab the SO from SD card and pump it inot memory.
Then, on the lower half of the diagram. The Video processor (Still, unnamed, I'm going to need a lot of names!) also sits on the full bus. It's also a FPGA/CPLD, and will have it's own Video RAM. How will it work?
In a very early phase of prototyping, I'm thinking for the VRAM to mirror the Main RAM. Writes will be handled by both the MMU and VIDEO. No reading from VRAM for now. I need to take as small as possible steps. But then, once I reach this point, the VRAM will be isolated. As the MMU can halt the CPU, it should be possible to have the MMU and Video move data over the bus. Some sort of DMA? With the CPU halted, and isolated from the bus (BE?) this sounds possible.
That's the purpose of the "HaltRq" (Halt Request) connection between Video and MMU. At some point, the Video ask the MMU for a block of ram. So the MMU stops the CPU, and fulfills the request.
So, I'm still hiding a ton of complexity on the MMU and Video Blocks, but this sounds plausible. Please feel free to point any issues you may spot here.
Cheers!