[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: NadaNet and AppleCrate



Ed Eastman wrote:

>Thank you for the verbose description.  I really enjoyed the process you 
>described in puting togther the ideas with the hardware.
>
>Cool, very cool.

Thanks!

>But unfortunately, I am having more random thoughts...

Hey, random thoughts are good.  ;-)

>It's funny, I was thinking 'just put a resistor in incrimenting sizes on 
>a paddle port in the apple crate and use that to assign temporary ID 
>numbers".

Yep, that was one of my early ideas, and now I've come back
to it--at least for the time being.

>I was also thinking about your 'hands-off' approach to booting.  Since 
>you are only wanting to throw one switch at power up, why not change the 
>reset length of each board using the same (add a resistor) technique to 
>cause each board to hold it's power-on reset signal a little longer. 
>(This can be done using a card in a slot if necessary to hold the reset 
>line low on power-up.  Each A2 would still cascade boot and get the next 
>available ID number, per my previous thoughts.

Yes, this would be workable if the //e used an RC circuit to generate
/RESET.  But it is generated by the IOU, and is a side effect of the
vertical scan generator, conditioned by the power-up signal (according
to Sather).

>Something I didn't quite realize is that you are buring custom ROMS to 
>do the NADA net so one could theoretically just 'hard code' an ID number 
>  and then not have to worry about temp and permanent IDs.    If a 
>hardware failure occurs, pull the rom and drop it onto another board and 
>insert it back in the rack.  The only time a reassignment would need to 
>occur is if the message server went missing from the network.  You'd 
>still need to keep track of operation ID numbers so one could assign 
>tasks, but ID arbitration would be a lot less necessary on boot.

True, the board's "permanent" ID could just be burned into the EPROM.
But I had hoped to avoid such customization, hoping instead that it would
be possible to take the "random number" approach.  For the more
symmetric case of multiple //e's with I/O, I even thought of them joining
and leaving the network dynamically, so that a protocol would be needed
to "elect" a master machine--maybe in November it will seem more relevant!  ;-)

>So now that I understand where you are coming from, and what you hope to 
>accomplish; IE, a network of JUST wires and software with no additional 
>hardware...  what would happen if you tied the game port to the 
>interrupt signal on the slot of the next board?  Not necessarily true 
>fault tolerent parallel processing, more like cascade assignment and 
>processing.  Since each board would be under the control of the next 
>board up.  Of course if you go this far, why not wire the slots together 
>(Pick a slot) and move and entire byte at a time using the slot latch...

The booting problem is now solved well enough with the custom-chosen
paddle resistors.  But I may decide to return to a daisy-chain approach,
where a signal from another of each board's annunciator outputs is routed
to another pushbutton input of the next board.  That would allow for a
simple cascading GETID process, and would, for better or worse, tie
the allocation order to the physical board order.

I'm leary about allowing boards to interrupt each other, for the reason
that you suggest--a faulty board or program could bring other boards
down.  I have also studiously avoided using any interrupts in NadaNet
so far.

This has led naturally to the idea of a message server to connect
machines that are doing enough work that they cannot constantly
poll the network.  The message server also provides simple queuing
and "pooling" of work units and results.

And, of course, the idea of using a slot card to allow byte-wide
transfers departs from my original "no hardware" intent (as well as
preventing boards from being stacked closely, as in AppleCrate).

I encourage others to think about other interconnects and how
they might be used to extend the "laboratories" of our Apple II's.

-michael

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