[Coco] CoCo Supercomputer Idea

[Andrew]

I was just going to post about the AppleCrate project, but Steven H. 
beat me to it, I guess.

Ever since I ran across that project, I knew that it could be done on 
the CoCo in some manner, and have given it a bit of thought myself as a 
project to play with in the future (though I don't own many CoCos myself).

The speed of the interconnect would be important if a real task on such 
a clustered machine (which is what this would be - as we all know, 
calling it a supercomputer would be a stretch).

So - maybe we should call it something different - I'll propose the 
"CoCoCluster" (alternatively, "C-Cube", "C-Cubed", "C^3"). I'm not 
expecting it to stick, and it isn't very inspired, but it is something 
to work on.

As far as the interconnect is concerned, unless this machine is being 
meant to really push the hardware, I vote for the "simple-is-better" 
approach.

To that end, something using the bit-banger serial port, perhaps in 
conjunction with the cassette port, might be best. I can't recall if 
that "unused pin" on the bit-banger can be read or written from, but if 
so, perhaps it could be toggled to provide a read/write state. In that 
case, there could be a master machine, then a bunch of slave machines 
hanging off, and that line could toggle to say "I am reading" or "I am 
writing" - and, along with some logic to randomize in the event of 
collisions or such, all machine would be listening for the master - and 
any machine to machine comms could go to the master, or maybe there 
could be multiple masters - or something.

It would be a very fast interconnect, but it would be easy to construct. 
Or, maybe something like a BlackNet could be made:

http://www.romanblack.com/blacknet/blacknet.htm

That's meant for 5 volt microcontrollers, so it should fit OK with the 
bit-banger serial port (IIRC - it's a 5 volt TTL serial?).

If anything faster was wanted, it would have to go thru the cartridge 
slot, of course. Blue-skying an idea here: Could floppy drive 
controllers be re-purposed in some manner (perhaps with some kind of 
intelligent back-plane)? Alternatively, you could hang a PIC or ATMega 
off that port, and use it as an intelligent buffer - and connect 
everything with SPI (or even some kind of parallel interconnect).

I also do like the idea of the ESP8266 being used - or drivewire with a 
PC handling routing or something.

As far as software is concerned - NitrOS9 or using machine code (like in 
the 'Crate) should be OK. I don't think that would be the issue.

The issue - should this thing be built - would be the same question 
faced by every cluster builder: "What do I use it for?"

It has to be something a cluster is good at; that means any problems or 
tasks need to be (in effect) able to be highly parallelized in 
structure. It also needs to be something that the CoCo can do, that we 
know it can do, and that will provide something demonstrable (perhaps to 
show its capabilities against a single CoCo). So, again, I am going to 
make a couple of proposals:

1. Mandelbrot Set (or almost any fractal system)
2. Ray-tracing

There are problems with both of these, in that they are both very 
floating-point intensive. Still, by breaking up the problem space into 
chunks that can be easily doled out to each machine, there should be 
some improvement (depending on the interconnect, of course - which could 
render the whole thing slower than a single CoCo). Both tasks are 
considered somewhat "standard benchmark" tasks for clusters (and other 
vector machines), and they both provide an immediate graphical display 
to bystanders for understanding what is happening (especially if 
presented alongside another singular CoCo). We also have code available 
for the CoCo that does both (well - I know that there are more than a 
few Mandelbrot Set generators out there; for ray tracing, I'm not sure 
what exists - but if nothing does, I do have the source code to a simple 
QB4.5 version, as well as one for javascript - which might make a base 
to translate from).

Or, maybe something else could be done with it; regardless, there has to 
be an application for the cluster, otherwise it is almost pointless to 
construct. It isn't whether it can be done (we know it can), but more of 
what we will do with it, once it is constructed. Provided the software 
is architected properly (to keep the communications part modularized 
from the rest), the software could be set up to work whether its on one 
machine or many. There just needs to be a "master controller" app (which 
would dole out the work chunks, and get the results back and re-assemble 
them in the "solution"), and a "worker" app (which takes its work task 
as a portion of the whole problem, gets and answer, and sends the 
results back to the master).

There is a bit of a chicken-and-egg problem - but as long as it is known 
how the API interface to the comms is to be done (regardless of what 
happens inside those routines), the rest of the app (worker or master) 
can be constructed without needing to wait for the hardware (as the 
comms interface is abstracted from the rest of the software). Once the 
hardware is done, then any test code for the comms could probably be 
used as the base to construct the remaining comms API for the master and 
worker apps.

As far as language to code these app in? I'm not sure - my gut says to 
use C or assembler, but a bit of me says "BASIC-09". Maybe it could be a 
mix, or maybe it could be something else entirely.

-- 
Andrew L. Ayers
Glendale, Arizona