Re: brad w. Re: Ethernet & Internet on Apple 2

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

brad wrote:

>"Glenn Jones" <rg.jones@rogers.com> wrote in message
>news:Ep2Ec.15$T6i.7@news04.bloor.is.net.cable.rogers.com...
>> "Michael J. Mahon" <mjmahon@aol.com> wrote in message
>> 20040628154227.10996.00000838@mb-m02.aol.com">news:20040628154227.10996.00000838@mb-m02.aol.com...
>> > Simon Williams wrote:
>> >
>> > >Michael J. Mahon <mjmahon@aol.com> wrote:
>> > >
>> > >> Thanks for the vote of confidence, but we all have to decide how we
>> > >> are going to spend our time.  I currently have other projects that
>are
>> > >> keeping me interested and happy.
>> > >
>> > >I recall you were working on a gameport network protocol some time
>> > >ago... did that ever amount to anything of interest?
>> >
>> > Funny you should ask...  ;-)
>> >
>> > I've been devoting some spare time to it, and how have it working
>> > as far as I can tell (tests and applications are next).
>> >
>> > I currently have three processor linked, and in the nexe couple of
>> > days I will have all eight Apple //e boards in the "AppleCrate".
>> >
>> > They boot over the network from the "master" machine, which is
>> > fully configured, while the AppleCrate boards are bare, with no
>> > I/O other than the network (and optional video monitors).
>> >
>> > I'm finishing plugging in the boards, and working on test and
>> > demo software, as well as writing a document on the concepts,
>> > software, and hardware.
>> >
>> > I've been waiting until it all worked before going public, but
>> > your question has nudged me into talking.  ;-)
>> >
>> > I'm in the process of identifying a nicely parallelized demonstration
>> > that can show off Apple II parallel computing!
>> >
>>
>> Well you definately have my interest ..... can't wait for more ...
>>
>> Very Cool and thank goodness it's not April 1st
>>
>> :O) Glenn

>read below...a parrallel computing apple // application using mutiple as far
>as i can tell apple //e cpu boards that run on a mac LCii...or at least that
>is what i read from below...
>
>nice to know people are crazy'er then we are
>
>if i ever have money again and can take a vacation we prob need to go to
>kansasfest 200? someday
>
>brad

Yes, it is a multiple Apple //e board system, with a fully-configured
Apple //e as the "master" machine and eight "bare" Apple //e
"slave" processors in a wooden frame (hence, "AppleCrate").

There is no Mac involved.

All the networking is on a baseband serial bus, driven by an
annunciator output on each machine and sensed by a pushbutton
input on each machine.

The original plan was to interconnect using only wires, but some
changes that Apple made to the pushbutton circuits starting with
the //e made it necessary to add some electrical buffering to drive
through the pullups/pulldowns on the boards.  Because there is
no "real" electronics involved (as opposed to no electronics at all),
I continue to call the network scheme "NadaNet".

The raw serial signalling speed is 9 cycles per bit, which grows
to 106 cycles per byte within a packet (allowing for synchronization,
etc.).  Each packet (1..256 bytes) has a check byte appended.

Protocols are controlled by 8-byte control packets, with n-byte
data packets included within a protocol as needed for payload.

The first protocols I implemented were PEEK (n-bytes), POKE
(n-bytes), and CALL from a requesting machine to a serving
machine.  

The network is peer-to-peer, with any machine able to request
any serving machine to perform a permitted service.  Since the
network does not use interrupts, a serving machine must be
"listening"--polling the network--to receive a message.

Since this interferes with asynchronous interactions between
multiple machines, I wrote a "message server" which runs on
a machine constantly listening.  It handles PUTMSG and
GETMSG requests from other machines, allowing them to
send "mail" to machines not currently listening.  These
messages are currently conceived of as "notifications"
and so are limited to 1..255 bytes.  Any large data payload
would be handled subsequent to a notification by a direct
PEEK or POKE, for example.

The latest protocol addition was the network boot protocol,
required to use machines that have no attached peripherals.

It currently works perfectly with two or three slaves, but
with a larger number (six), I have found that my original
idea for generating a (really) random ID at power-up is not
as random as I hoped.  ;-(  Apparently, the phase of the
video refresh is approximately standardized at power-on,
so waiting for VBL and counting does not generate a well
distributed set of distinct IDs.  (The arbitration scheme I
use depends on distinct IDs to allow each machine to
be addressed independently of the others.)

My recovery plan is to use the paddle timer to derive a
unique temporary ID, and to equip each board with a 
different resistor value that will ensure uniqueness.
(Since I'm already using a timing resistor in a paddle
circuit as an LED pulse generator to signal when a
machine is sending, this will only be a firmware change.)

Suffice it to say, things are coming along nicely, with
a sufficient rate of new probems to be solved to keep
it interesting!

BTW, the code for all of this fits in 2KB, with 1KB of
ROM space required for the network boot (replacing the
unenhanced //e's diagnostics).

-michael



-michael

Check out amazing quality sound for 8-bit Apples on my
Home page:  http://members.aol.com/MJMahon/