Re: NadaNet 3.1 Released

["Michael J. Mahon" <mjmahon@aol.com>]

Hi, Matt!

mdj wrote:
> On May 28, 5:36 am, "Michael J. Mahon" <mjma...@aol.com> wrote:
>
> > NadaNet was designed to require very little hardware to implement
> > (originally none, or "nada", but Apple changed the //e so that a
> > simple buffer is needed).  My hope was that many Apple II enthusiasts,
> > having more than one Apple II anyway, would be enticed by the quantum
> > leap in functionality and the low barrier to entry to jump in and start
> > experimenting--with parallel computing, client-server computing, or
> > what-have-you, all in Applesoft.
> >
> > Apparently, I was wrong.  Whether it's because it's a "programmer's
> > platform" or because it requires some simple adapters for the game port
> > (or maybe because I'm no good at marketing ;-), very few people have
> > actually hooked up a NadaNet.  (Or maybe they have, and are having
> > great fun with it in secret.  ;-)
>
> With a community as small as ours, it's conceivable that each
> individual occupies a near-unique point on the "sub-interest"
> demographic :-( Unfortunately this means that only projects that
> extend the Apple II in very generic ways (accelerators and storage
> adapters for instance) will have broad enough appeal to create
> anything resembling a group.

Very true--a couple hundred of "active" members seems likely--less
than a single user group in the early- to mid-1980s.

> > It also occurred to me that the AppleCrate made something of a
> > splash, and, since it is a bigger project, the simplicity of NadaNet
> > that made it possible is lost behind the apparent complexity of the
> > 'Crate.
>
> The AppleCrate (+ synth) has *by far* the greatest wow factor of any
> project in the Apple II hobbyist world in my memory, and the only real
> barriers preventing me from experimenting are time, plus an existing
> backlog of personal projects. At the current rate, that probably means
> I'll get to NadaNet sometime in my retirement :-(
>
> (Of course, another barrier is having enough 'spare' Apple IIe
> motherboards to build a 'Crate; I rationalised my collection and
> probably want to keep the remaining IIe's 'intact'. If I happen upon
> an auction for a large set and can bare the shipping expense, I'll add
> them to (yet another) box.)

It's worth underscoring the fact that it is not necessary to disassemble
Apple II's to use them as part of a logical 'Crate.  NadaNet connects
all machines on the net as peers, and any can serve as a "board" of an
AppleCrate, if you will.

In fact, the AppleCrate is *only* a convenient mechanical packaging of
a number of //e machines.  It does make it necessary to deal with the
*inconvenience* of not having any attached I/O (except NadaNet) by
requiring that NadaNet boot ROMs be installed!  None of this is needed
for a "normal" Apple II.

Any Apple II with a game port can participate in a NadaNet as a full
peer simply by booting a NadaNet startup disk.  (It can then continue
to be used separately as a normal //e, participating in the network
only when: 1) a NadaNet command is entered manually or executed as part
of a program, or 2) the "service loop" is started on the machine so
that other machines can talk to it.

> Without wanting to be in any way critical (at least for negative uses
> of the term), there are issues with having CrateSynth as the primary
> "marketing tool" for NadaNet. From an end-user perspective it's a
> "passive" application; it plays at you rather than you playing with
> it, and you can enjoy its fruits straight from your website without
> ever having to build one yourself ;-)

;-)  It's a demo!  ;-)

> From a developers perspective, which I think is the more pertinent,
> CrateSynth is an "embarassingly parallel" application. By virtue of
> the Apple II's deterministic timing, the workers only have to
> rendezvous at the start of playback. This is of course very important
> to demonstrate since parallel deterministic processes is NadaNet's
> most unique quality, but it doesn't serve as an inspiration to
> developers who may be considering problems that aren't embarrassingly
> parallel.

True.  In fact, there are a wealth of embarrassingly parallel problems,
so one still has lots of choices...  But, of course, problems with the
most interest are those in which the parallelism must be organized
carefully to minimize communication, and those are not the easy ones!

> As we've discussed at length over the years, parallel programming
> really is the new frontier in software development, and the vast
> majority of the programming fraternity remains hopelessly unable to
> exploit the potential power. This includes, unfortunately, current
> consumer class machines that contain 2-8 processing units with shared
> fast memory! Having the technology available to begin to experiment
> has resulted in very little software in the wild having anything more
> than 'token' support multiple procesors (embarrassingly parallel
> problems excluded), so the adoption issues you're suffering from
> certainly aren't unique to NadaNet.

Amen to that.   As we've discussed, that problem is perhaps a generation
away from a sweet solution (likely involving new programmers to write
the new programs ;-).

> Since sequential programming already demands so much of our spatial
> reasoning, I guess it shouldn't come as a surprise that there's so
> little left over to consider time as a two dimensional quantity. My
> own experience with parallel application development over the years
> has taught me that even the most innocuous looking construct, say
> using a mutex to serialise access to a resource (the proverbial
> critical section) is fraught with hidden complexity.

Absolutely.  Most people underestimate the growth rate of N squared,
let alone N factorial!  The number of possible things that can happen
at even a mutex grows very rapidly with contention, and the best
algorithms for handling sequential re-use change, too.

> Given that, I think it would probably beneficial to provide a small
> collection of contrived examples. How do we implement serialised
> access to a resource? What about many readers but only one writer? A
> NadaNet equivalent of the Dining Philosophers, etc.

The Message Server is a very simple mechanism for dealing with queuing,
with single or multiple writers and single or multiple readers.  The
messages are limited to 255 bytes, but only a few bytes are needed to
orchestrate exclusive serial re-use, or even more complex interactions.

For those who are willing to trade the simplicity of message passing
for the efficiency of direct, synchronous communication, there are
primitives like &PEEKPOKE for semaphoring and &PEEKINC for simple
allocation.

Essentially all of my programming efforts have been directed toward
the creation of tools, which may not appeal to some on the face of it,
but if you look into the structure of the tools, you find methods for
handling very common problems.  ATTACH, the "remote console" program,
is a good example.  It uses 256-byte circular buffers to pass input
character streams and output characters into and out of the serving
machine, respectively.  On the (remote) serving side, a small machine
language program manages the communication, while on the client (user)
side, analogous communication is handled by an Applesoft program.

The methods for handling the circular buffer are quite general, and
would be applicable to many programs.

The first version of ATTACH used the Message Server, which handled the
necessary buffering, but the latest (circular buffer) version does not
require a Message Server, and so is applicable to even a 2-machine net.

> Anyway, enough of that and onward to more positive things and perhaps
> a discussion point: What could be done with 1 (or perhaps 2) slave
> machines attached to a developers primary Apple II? This is a
> configuration I think most of us could scare up easily

NadaPong was a (very) simple demonstration of two machines cooperating
on a peer-to-peer basis to support a simple game.  It trivially extends
to more machines with a single ball, or with more thought, to multiple
sprites moving simultaneously.

I was motivated to put it together after lunch because it was suggested
to me that something that graphically illustrated the communication that
was occurring would be more interesting and thought-provoking.

The fundamental problem with a gaming example is the natural emphasis
on real-time interaction.  It is axiomatic that machines can do only
one *real* real-time task at a time, and NadaNet is itself a real-time
task, so there are tricky problems to be overcome if state spread across
the network needs to be "displayed" in some sense on multiple machines
in "real-time".

It's fun to solve problems like this, but mainly because it *isn't*
easy!  As a result, it's probably not the best way for a NadaNet
programmer to get their feet wet.  ;-)


>                          and since we're
> talking developers how about ...
>
> An interactive, incremental,  Editor/Assembler/Debugger ?

Such an application would be straightforward if starting from scratch,
developing ones own apps.  It's probably not so easy to do by adapting
existing applications.

Sending an assembly or compilation to another machine raises the issue
of a common file system.  Although my File Server provides stateless
access, it does not support OPEN..(READ | WRITE)..CLOSE file access,
nor does it support sector- or block-level access.  It handles the
subset of ProDOS commands that do not require keeping state between
operations, for which the atomicity of command execution is sufficient
to ensure consistency.

As a result, it is well suited to supporting programs written to use
BLOADs and BSAVEs for disk I/O (which are quite sufficient), but it does
not support programs that depend on the existing DOS or ProDOS command
set beyond the stateless ones.

If the text editor (B)loads the file into memory and (B)saves it back
to disk, then it could easily be modified to do so using remote File
Server(s), which could then host the assembler(s) and/or compiler(s)
on its/their local file systems.  It would be a File Server that also
was an Assembler Server, for example.

A Print Server could be similarly implemented, assuming that it was
only necessary to print disk files.  (Of course, many Apple II apps
are not structured to place a disk file between the app and its printer,
so that could also be an issue for existing apps.)

You raise an interesting point--I have one //e that is configured for
general use:  editing, software development, etc., with a CFFA.  I have
so far not set up another capacious machine as a slave to run larger
apps, like assembly and compilation.  This sounds like it could be fun!

It will require modifying an editor to do its file I/O using the File
Server, but that shouldn't be hard if it is reasonably structured...

The more generic solution, providing patches to ProDOS and DOS to access
files stored on a remote machine, raises several issues (multi-machine
state, file and file system sharing, etc.) that I have chosen not to
address.  Perhaps someone more comfortable with the internals of these
OSs would like to try for something more general?

-michael

NadaNet 3.1 for Apple II parallel computing!
Home page:  http://home.comcast.net/~mjmahon/

"The wastebasket is our most important design
tool--and it's seriously underused."