[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: NadaNet and AppleCrate
"Michael J. Mahon" <mjmahon@aol.com> wrote in message
20040715221312.03890.00001361@mb-m19.aol.com">news:20040715221312.03890.00001361@mb-m19.aol.com...
> 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/
Hey keep up the good work!
Plus i'm trying to see if i can snag a few discarded apple II LS (uknown if
that's correct) to create my own applecrate if i can...
--
Visit my website located at: http://earth.prohosting.com/dsilver/
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.717 / Virus Database: 473 - Release Date: 7/8/04