Does the world need a new single-board computer design with an MC68060 CPU?
I'm thinking about 4GB of DDR3 DRAM, one serial port, one M.2 slot for an NVMe SSD, and one Ethernet port (probably 1Gbps). Not intended to be software-compatible with any existing board or system.

Same question, but various 32-bit RISC processors? MC88110? Am29000/Am29050 (pin compatible)? Intel 80960KA/KB/MC/XA? TI TMS34020?
#retrocomputing

@brouhaha

wouldn't a coprocessor to to all the I/O make more sense, especially if it could do hardware debug of your cpu/memory ?

@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.

@brouhaha

Where do you put the RQDX3? (DEC MSCP controller for the QBus)

@bitsavers

@ChuckMcManis @bitsavers
The RQDX is a DMA master device, sort of like the Adaptec 1542 for PCs.

Not a channel, because systems that use channels have the channels as distinct functional block (though possibly not distinct physically), and use compatible channels for all devices (or at least all that do DMA), while an MSCP port is its own thing, unrelated to the DMA done by other kinds of PDP-11 and VAX peripherals (e.g., RH11/RH780/etc Massbus, RL11, RK11, etc.).

@brouhaha

That's helpful, I've got a more generalized definition of channel but yours works too.

@bitsavers

@ChuckMcManis @bitsavers
I admit that I'm picky about it. The System/360, /370 channels are my baseline for calling something a channel. Aside from a little-used "direct connection" optional facility on some CPUs, _ALL_ 360/370 I/O went through channels. That's one of the things that made virtualization on 360/67 and 370 systems a whole lot easier to implement and more robust than on x86, where I/O interfacing was a total wild-west free-for-all.
@ChuckMcManis @bitsavers
AFAIK, not a single mass-produced device existed that used the 360/370 direct interface option. It was intended for customer interfacing to things without actually having to design a controller to sit on a channel.

@brouhaha That is probably true, although when I interned with IBM on Diagonal Highway in Boulder, CO, they had a film printer connected to the direct interface I/O that was part of a small 370 dedicated to doing layout and fabrication of printed circuit boards.

@bitsavers