[TI-H] Re: TI Networking.
[Prev][Next][Index][Thread]
[TI-H] Re: TI Networking.
Why not have the user specify an address, and have all calculators linked
when the game starts? Use consecutive addresses, and also input into the
calculator the total number of addresses. This would eliminated the need
for autodetection. Since the user's would be building the hub or linking
device, they be smart enough to set up everything in the software.
B Clark
----- Original Message -----
From: <rabidcow@juno.com>
To: <ti-hardware@lists.ticalc.org>
Sent: Wednesday, May 02, 2001 10:53 PM
Subject: [TI-H] Re: TI Networking.
>
>
> On Thu, 03 May 2001 00:57:23 +0200 Olle Hedman <oh@hem.passagen.se>
> writes:
> >
> > At 23:47 2001-05-02, you wrote:
> > >Is there any reason not to fill the address space from the bottom?
> > >
> > >Every time a calc makes its initial connection, it waits for a full
> > cycle
> > >to pass, then uses the largest address+1. When it's calc 0's turn,
> > it
> > >waits slightly longer before sending to give any newly connected
> > calc a
> > >chance to transmit.
> >
> > how do you know how many calcs are on the net? how do a calc know
> > its the last.
>
> The hard way would be to look for the long gap between the last and first
> packets, then count packets until it occurs again. Probably the easiest
> way would be to have a source address on each packet, then watch for
> where it rolls over to zero.
>
> The first calculator would have to wait a long time, say twice the
> expected length of a start/end loop gap before deciding it was number 0
> and transmitting.
>
> > if you start from the end or the beginning has no difference as all.
> > I thought of a scheme where the next calc sensed that a packet was
> > completly send, it starts to send, if it doesn't have anything to
> > sen it
> > sends a short (1 or 2 bytes) "I have nothing to send"-message, and
> > then the
> > next sends and so on.
>
> You'd have to use the hard method above, but a "nothing to send" packet
> could be as short as a single pulse. (2 transitions)
>
> > Still has this problem of knowing who is the last calc that makes it
> > a bit
> > strange...
>
> The last calc is the calc with the highest known address.
>
> The first calc is aware of one device (itself), so it counts one packet
> (its own) before sending another packet. (It also sees that it's number
> 0, so it waits slightly longer before sending to allow an unknown calc to
> transmit.)
>
> The second calc to connect knows of two devices, the first and itself, so
> it starts transmitting in its place (2nd), then counts 2 packets
> (including its own) before sending again. When the first calc sees the
> packet from this previously unknown device, it adds one to the number of
> known devices and waits for that count.
>
> And so on.
>
> > could just be that if there hasn't been any traffic for a while,
> > then it
> > starts from the beginnning..
> > hmm.. I realized this is pretty much exactly what you are
> > suggesting...
> > I don't think fixed time-intervalls else then the
> > "wait-to-se-if-more-sends"-delay, better to send packets as soon as
> > possible, as fast as the previous calc has send its packet.
>
> That requires at least that all calcs actually read and interpret each
> byte sent. With the end of packet gap, they just need to periodically
> poll the port, and if nothing has happened for a few samples, note that
> the packet has ended.
>
> A side effect of the gap is to align all calcs to an 8-bit boundary at
> the start of each packet in case of line error. If you think about it,
> line errors will either add or remove line transitions, so if you don't
> have a way of realigning, you can't find any full bytes intact after
> that.
>
> Also, there's the extra gap I proposed at the beginning of the ring to
> allow calculators to make the initial connection. (I should probably add
> that it's best if they're all PHYSICALLY connected before this whole
> thing takes place, otherwise you'll have garbled data.) Without that
> gap, you need to know before touching the link how many devices are out
> there.
>
> > This is pretty damn close to token ring, except shared medium...
> >
> > If we found a good way to encode bits on a single line, you could
> > connect
> > the calcs as a ring too...
> > would probably waste half the bandwith though, since most 1-line
> > protocols
> > I have seen needs two transitions per bit.
>
> Ah, now I understand your picture! :)
>
> The way I'm envisioning it, on two wires you can send 1.5 bits per
> transition, but only one transition on the network at a time. (and I
> think it would be more robust than anything you could do on one line, if
> that's what i mean...)
>
> With one line... Well I don't know how that would work, but from what you
> say you can send (effectively) .5 bits per transition, but each calc can
> theoretically send or recieve simultaneously.
>
> It sounds harder to set up, but with theoretically greater bandwidth as
> long as there's > 3 calcs. (or maybe 6)
>
> -josh
> ________________________________________________________________
> GET INTERNET ACCESS FROM JUNO!
> Juno offers FREE or PREMIUM Internet access for less!
> Join Juno today! For your FREE software, visit:
> http://dl.www.juno.com/get/tagj.
>
>
Follow-Ups:
References: