Re: NadaNet and AppleCrate

[mjmahon@aol.com (Michael J. Mahon)]

Rich wrote:

>mjmahon@aol.com (Michael J. Mahon) wrote in message
>news:<20040711142758.04915.00001069@mb-m24.aol.com>...
>> The NadaNet
>
>
>from Bob Bishop's P.A.C.K. vol 2 
>chapter 5:fun with the cassette ports 
>PG 29:
>
>"
>
>The Cassette Network
>
>The idea of a cassette network first occured to me in 1976 
>when I was playing with my apple I.  It would have been 
>nice if the cassette-in of one computer could be directly 
>plugged into the cassette-ot of another, allowing the two 
>machines to communicate with each other.  I envisioned a 
>ring of Apple computers, each receiving its cassett-in 
>signals from the machine on the left,and sending its
>cassete-out signals to the machine on the right.  
>Unfortunately the Apple's cassette-out signal is not
>strong enough to directly drive the cassette-in port 
>of another machine.
>
>Over the subsequent years the idea of such a network 
>still continued to intrigue m and from time to time I 
>would again actively consider the possibility. Finally, 
>in February of 1985, I was at last able to successfully 
>demonstrate the cassette network as an actual 
>functioning entity.
>
>"
>
>the PACK volume 2 mentions a game called GOBBLERS which would allow
>you to play a four player game each player on a seperate computer.
>
>the text mentions pushing the data-transfer rate to the
>max using the cassette ports.  I don't have the disk that
>came with the text.

I'm not surprised that others have thought of doing something
like this.  I have not heard of anyone else building a bus-based
network like NadaNet.

In the early days, when the cassette port was used a lot more,
many people thought of directly piping the cassette output of one
machine into another (whose output was usually piped back into
the first machine--a ring of two machines).  As Bishop notes, this
cannot be done passively, since the Apple II cassette output has
an attenuator to reduce the levels so that they are suitable for the
microphone input of a cassette deck.

However, machines can be connected if a suitable amplifier is
provided.  A cassette deck in "record monitor" mode is quite
useful for "saving" programs from one computer to another, for
example.

I would be very interested in learning more about Bob's use of
the cassette port with other than the built-in cassette read/write
routines.  (There is an added complication in using the cassette
input with waveforms of widely varying duty cycles, since it is
capacitively coupled.)

BTW, I have updated the description on my web site to include
the interface circuits that I use, as well as the code and the
protocol documentation.

I have been testing a parallel application simulator, which builds
a queue of tasks of varying lengths to be done, and collects the
results from another queue.

One of the slave machines is dedicated as a message server
to support the queues and the asynchronous communication,
while the other seven slaves run an Applesoft program which
gets work from the job queue, does the work, and returns the
results to the result queue.

It all works quite smoothly, even with all the asynchronous
communication over the network.  And watching the show
of "executing" and "sending" lights on the slaves is very cool,
as is watching the queue lengths vary on the message server
in monitor mode.  ;-)

Then, using the simulator as a schema, I modified it to do a
distributed Mandelbrot computation, where each job was the
computation of a single HGR line of points, and the master
machine collects the lines onto a single display.

So far, the granularity of my "jobs" has been from about 200
milliseconds (with the work simulator) to about 120 seconds
(with each Mandelbrot line).  At this level of granularity, the
network overhead for scheduling is small (~10 milliseconds),
so the throughput of the AppleCrate is scaling linearly with the
degree of parallelism (which I can adjust easily in the master
program by deciding how many jobs to queue in advance of
results).

So far, everything is working as well under load as it did in
testing, so I'm quite pleased.  ;-)  One of the trickier things
I had to figure out was how to initialize Applesoft and then
get it to run a program that I PEEKed into the slaves'
memories.  Clearly. Applesoft was not designed to be called
as a subroutine.  ;-)

I'm now thinking about some remote debugging tools, to allow
me to sit at the keyboard of the master machine and have
monitor-like capabilities on whichever slave I select.  Or having
the ability to interact with an Applesoft program running on a
slave through the keyboard and display of the master...  Or
defining a file server that processes file accesses requested
through a message server queue...

This is too much fun!

-michael

Check out parallel computing for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/