I'm not sure that a microcontroller is the right thing to put in between the 680x0 and the DDR. For a coupl edifferent reasons.
First is that you need enough IO pins to look at the 680x0 bus and to control the DDR and read/write data.
Second, I'm not sure you can do that, even with enough IO pins, in the timing required. The 680x0 bus runs at a certain speed. The microcontroller needs to run fast enough to sample that side IO, do whatever magic you need it to do, talk to the DDR at DDR bus speeds, then send stuff back to the 680x0 side again in amounts of time legal to both the DDR and 680x0 sides. I'm not sure a regular microcontroler has a chance of that. Perhaps an XMOS, which is essentially a microcontroller designed to have a lot of IOs and guarantee certain things in timing. I don't know if it's fast enough for DDR, but it's probably fast enough for 68020 in an A1200.
I'd think of an FPGA for a memory controller out of habit. perhaps XMOS can do it too, look into that more. But an ARM, which I understand to be on there? I don't think so. I once implemented an ARM APB bus over a couple 32bit parallel IO ports to play with in simulation. It was pretty slow that way. I don't think it would be useful in the real world. We ended up not using it in our simulation situation either. It might be fun to play with, but not practically useful for anything.
Keep in mind that WinUAE does not talk to memory hardware. It talks to Windows or Linux or whatever. So it doesn't know how to talk to DDR. probably the only thing that does in that situation is the Northbridge chip, or the CPU if it's recent enough to have the memory controller moved there. I don' tthink that even Windows knows about how to talk to DDR on a DDR protocol chip pin level. I can't imagine why it would need to know that anyway.
Minimig Verilog code is probably more relevant to your project, but you'd need to port that to whatever kind of language works in your design.
You'd need to look at DDR specs. Signal levels, timing, chip pinouts, and bus protocol from the specs for the memory chips. That's what you need to talk to on that side of the microcontroller/XMOS/FPGA. Then you need to look at the 68020 specs from Freescale, and learn how the pins and bus protocol for that work. You'll be looking at waveforms, and trying to respond to and to generate those waveforms in your memory controller design. (ARM software, VHDL FPGA circuit, whatever)
Heck, start with the DIMM and 68020 pinouts. Do you have enough controllable IOs for that?
Hmmm. OK, if ARM chip has its own memory on the board, perhaps you only need to talk to the 68020 side, and ARM software of your design stores things in ARM memory as if it is ARM data, and sends that back out when 68k reads from it. Doesn't let you use a DIMM, but perhaps saves you a lot as well. Still don't know if that's fast enough to make the 68020 happy.
The last issue I can think of is signal integrity. Not sure how fast your DDR would run, but consider the DDR PCB layout whitepapers from Freescale and others. They make suggestions to keep signals clean. Can you keep signals clean enough on a breadboard for this?
I'd like to learn more about the accelerator takign over the motherboard CPU too. What little I've heard about this says to tie motherboard CPU halt signal to the halt value, and CPU stops doing stuff.
