Theoretical question - Multiple CPU's

[J64C]

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

[plasmo]

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

[channelmaniac]

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.

[drogon]

plasmo wrote:

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

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

[GARTHWILSON]

BigEd wrote:

Garth, your searching example is interesting, but I think it doesn't show an advantage. It's just as likely that the result will be found at the 45% point, in which case the dual-cpu system takes longer.

True— which is why the example was kind of a special case.

Quote:

(In the case of a binary search rather than a linear search, the single CPU system takes about half the time as the dual-CPU system, I think, but the dual CPU system has one CPU free to get on with the next search, so again it's a draw. Maybe!)

The example I saw was of something where the elements are not in order, so a binary search wouldn't work. IOW, instead of being like a dictionary where you don't know the length of various sections but at least words are in alphabetical order, it's more like the case of searching a page for a particular word or phrase which could be anywhere.

I remain a bit intrigued by the multi-processor idea, but it also remains a mystery to me how programming could be done for it to really take advantage. I also fail to see any benefit to having two processors each running half the speed of a single-processor system.