I was initially thinking of going quad CPU’s

But, there is method to my madness as to why I’ll limit it to two right now. I’ll update my “The J64C” thread in ‘hardware’ as I progress (or regress as the case may turn out ).

I built the dual-port based multi processor based on the notion that cheap co-processor can replace dedicated I/O devices. A collection of co-processor can bit-bang slow I/O interfaces (audio, serial port, I2C, keyboard) and communicate to main processor via dual port memory. For I/O-bound problems, such collection of slow processors may be more efficient than one fast processor.
Bill

If they have different tasks to perform you can divide those out and communicate between the 2 via shared RAM.

Namco did that for Galaga/Bosconian using 3 Z80 CPUs and some dedicated microcontrollers for speech / explosions. They did it with 3 6809 CPUs for all the games on the System 1 hardware (http://system16.com/hardware.php?id=524) and Taito did Bubble Bobble in a similar way with Z80 CPUs.

One to coordinate and handle I/O, one for graphics, and one for sound. Schematics are available online.

Hm. I'd not considered a co-processor system in the context of this thread, however my Ruby board does more or less the same; I have an ATmega that shares (in a mutuality exclusive manner rather than dual-port RAM) a small area of RAM (256 bytes) with the main CPU (65C02 or '816). The ATmega boots the CPU (no ROM), does serial, SD card and filing system as well as acting as an IEEE754 floating point co-processor (and it also does 32-bit multiply & divide). It's original main purpose was 320x240x1 graphics - which it did well, but generating composite video requires some 60-70% of all it's CPU cycles, so left little else and because of that, and other reasons I abandoned video from it.

I have plans for another to offload SPI and I2C at some point too.

What I can't easily do is effectively parallelise the ATmega and '816 - although serial is fine as I can transfer 128 bytes at a time and tell the ATmega to "get on with it". For all other options the '816 sits on a WAI instruction and waits for an NMI to wake it up. There is an independent IRQ from the ATmega to the '816 which I could use in the future though - the issue, as always, is finding something for the '816 to do while the ATmega is doing it's thing... Not always easy...

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?