[Coco] CoCo Supercomputer Idea

Sun Jan 10 19:36:43 EST 2016

I was going to stay out of this, but the idea does intrigue me. My vision would be several Coco 3s, running Nitros9. They would be connected by whaterver fast comm system we could come up with running a propriety protocol. One Coco would be master, sending out several channels (16 works well in an 8 bit system, hence MIDI being 8 bit) of data, each slave paying attention to only the info for it's own channel. One slave running graphics, one could be running stereo 8 bit sound through orch90 pak or 16 channels of midi. One slave would be doing "tracking maintainence" in keeping up with bad guy, npcs, and general "what happens next", sending code back to the main to distribute for graphics and sound. A 2nd sound slave could be used for background sounds. This could go on and on, but if the right method of communication was used, it could be done.
Knowing the MIDI spec and protocol well and knowing the Coco has no problem with this, let's me know the Coco could do this. Midi controls multiple midi machines at real time through one data stream. Coco handles this without a sweat and I've done it myself. I have had as many as 9 midi devices plugged into a midi splitter and controled all machines in real time with one Coco 3 running Nitros9 and Ultimuse3 playing 16 voices of 128th note flurries at a fast tempo while sending system exclusive, FX, and controlling the midi recorder on my PC as well as keeping my Fender cyber twin guitar amp controled (Cyber twin is Midi controled) on one data stream, all at the same time (midi entails much more than just synths).
So I know the coco could handle the load, it's just getting a comm port fast enough.

Bill Pierce
"Charlie stole the handle, and the train it won't stop going, no way to slow down!" - Ian Anderson - Jethro Tull

My Music from the Tandy/Radio Shack Color Computer 2 & 3
https://sites.google.com/site/dabarnstudio/
Co-Contributor, Co-Editor for CocoPedia
http://www.cocopedia.com/wiki/index.php/Main_Page
Global Moderator for TRS-80/Tandy Color Computer Forums
http://www.tandycoco.com/forum/

E-Mail: ooogalapasooo at aol.com

-----Original Message-----
From: Andrew <keeper63 at cox.net>
To: coco <coco at maltedmedia.com>
Sent: Sun, Jan 10, 2016 5:53 pm
Subject: Re: [Coco] CoCo Supercomputer Idea

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.htmThat'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-tracingThere 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. AyersGlendale, Arizona-- Coco mailing listCoco at maltedmedia.comhttps://pairlist5.pair.net/mailman/listinfo/coco