I believe some Commodore drive already had two processors identical to the main processor of the computer -- effectively giving the drive more processing power than the actual computer :)
That machine was a real monster - I had a bridge-board in it: the A2000 had both ISA and Zorro-II (Amiga proprietary) buses, with one ISA and one Zorro-II slot in line so that you could buy a bridge-board that held an 8086 etc. on it to basically give you a "PC in a window" on your Amiga.
I'd then bolted a 286 accelerator board onto it, and a 68020 accelerator board onto the Amiga-side (I think both were of the type that slotted into the CPU socket andwhere you re-seated the CPU in the accelerator in case you wanted to switch to the slower CPU for compatibility reasons)
On top of that the Amiga 2000 and Amiga 500's used an 6502-compatible SOC with onboard RAM and PROM as their keyboard controllers.
So that one machine had a 68000 (though not usually running), 68020, 8086 (not usually running), 80286, Z80 and a 6502-compatible. I found it quite pleasing to have one machine with representatives of four of the most common CPU families at the time in it.
> Which is why I've never really understood people who focus on one chip to "define" a system, it really is about all the parts playing in harmony.
It was about identity in a sense when so much was done in assembler on the main CPU, and most people are never aware of those auxiliary CPU's.
Yes the speed of your computer is more than just the CPU, but the CPU, the RAM, and GPU are far more influential that what speed your disk's controller runs at.
In today's language, one was the application processor running DOS and the other was a DSP that did the low level hardware monkeying; they were connected up to a shared data bus. Because the 6502 only does bus accesses on one phase of the clock, by inverting the clock for one processor, it was safe to connect them both up to the bus simultaneously with no loss of speed...
The really fun thing about these was that you could actually download code to them and run it, so if you did have code that was small enough and CPU intensive enough and required little enough IO, you could in fact use them as an accelerator of sorts (but limited by a slow serial port and 2KB(?) I think of RAM on the drive)
I know of various code that downloaded code to it, but usually loaders or just to do things like blink the leds - I've never seen code that actually used the extra CPU for anything serious. I'm really curious if any exists.
http://www.pagetable.com/?p=647
http://www.pagetable.com/?p=656
From the second article:
It worked by transferring the "live" GCR-encoded data from the 1541's disk head to the C64 and simultaneously doing a fast checksum. Part of the checksumming was done on the 1541, part was done on the C64. There simply weren't enough cycles left on either side! Most of the transfer happened asynchronously by adjusting for the slightly different CPU frequencies and with only a minimum number of handshakes. This meant meticulous cycle counting and use of some odd tricks.
http://www.linusakesson.net/programming/gcr-decoding/index.p...
GPUs do, like most peripherals, contain additional CPUs that control them -- in the case of GPUs these are proprietary architectures specifically designed just for scheduling and sequencing tasks on the GPU and are said to be quite potent, for a device control processor.
Similarly hard drives had multi-core MIPS and ARM processors for quite a while (ditto for SSDs, in both cases they are ASICs, the actual data juggling isn't done by the CPU cores), and they even have quite a bit of RAM -- the cache -- that they'd normally share with the DMA engine, plus some of their own...
The control processors in most other peripherals are usually much weaker, though. They're pretty much just microcontrollers.
https://www.google.com/#q=%22La+Costena%22+laserwriter
Care to share any more details?