I appreciate that DMAC's have their place. I've built many of them, more than I can count, largely due to memory failure, over the years. It's true that a DMAC can relieve the CPU from monitoring a process in progress and accomplish data <=> memory transfers at a rate syncrhonous with the process in question better than a CPU can. Memory bandwidth isn't the problem in an 805x either. It's the stupid, Stupid, STUPID way in which the timer/counter(s) and UART(s) are integrated into the "I/O space" which is actually the SFR set. What I'm trying to do is to make the measly 128-byte I/O space useful in a general sense, and not leave definitions tied to the stupid, Stupid, STUPID thing that Intel did back when nobody knew better.

I won't argue the matter of DMA as a concept, at this time, BUT, from the standpoint of implementation, it requires, not only that there be a good deal of additional logic, BUT, that there be a good deal of additional logic interposed between the CPU core and all its resources, in order to give the DMAC access to the same pins (both internal and external) that the CPU core uses to access those same resources. Just how much performance are you willing to sacrifice through the additional levels of logic, which impacts the rate at which EVERYTHING occurs? It amounts, in a general sense, to the addition of another CPU and the logic to arbitrate between the two. I'd guess, from where I sit, that the performance impact will be a reduction of at least 50%, possibly 75%. That's a reduction from 80 mips to 20 mips. I'm not even slightly interested in a device that doesn't exceed 50 mips in a low-end FPGA. There are too many out-of-the-box commercial implementations that reach that level.

The 805x is a tiny, itty-bitty microcontroller. There is no sense in trying to use a add features making it a jet plane just to do what a bicycle should do just fine.

RE