@bitsavers @brouhaha
FWIW a "co-processor to all the I/O" is generally referred to as a "channel controller" per the IBM 360 architecture 😃 One of the more fun things about the Intel "systems" architecture that ran over Multibus was that every multibus card had its own processor to do the function of the card, the bus was basically two 32 bit parallel ports and some control lines.

@ChuckMcManis
A channel is just a fancy DMA controller.
What @bitsavers and I are talking about (I think) is much different than a channel. It's using a processor to act as everything from the electrical bus interface of the target CPU chip up, which could potentially include channels, but most of it wouldn't "be" a channel.
This has been done using e.gm Arduinos for many 8- and 16-bit processors, but I haven't heard of any for 32-bit, possibly due to the large number of GPIO required.

@ChuckMcManis @bitsavers
Doing this with a processor is great to experiment with the target CPU bus interface and such, but would generally run slower than typical target CPU speed.
What I proposed was to use an FPGA, but have a "service processor" in that, which could potentially implement some of the bus protocol for debug purposes, but otherwise would mainly be for system management and debug.

@ChuckMcManis @bitsavers
Mostly I want "actual hardware" in the FPGA, so that once the hardware is intitialized, it can run with little or no support from the service processor. However, the flexibility of the FPGA definitely offers a lot of potential for debugging.

@ChuckMcManis @bitsavers
I've been working on target designs like this for several different obscure processors (not the "common" ones I listed) for ages, and because I'm an idiot, it only recently occurred to me that I could do it as a single, more general platform usable for multiple of the processors that interest me.