[A83] Re: calculator networking - good idea?
[Prev][Next][Index][Thread]
[A83] Re: calculator networking - good idea?
There has been equipment made before, one such set by james from my group
acz even.
So, it's possible. Just need to try to make it cheap and low-overhead on
sending stuff and quick handshaking and not a lot of redundancy for fast
speeds.
Or make it plyable in those areas.
The programming idea really isn't so bad, will just need a table of
calculator IDs. Calculator logs in, requests a network id, receives
one/etc...
Kind of like a token network unless you want to write a full blown hub.
corey
----- Original Message -----
From: "Jeff" <telepath75@hotmail.com>
To: <assembly-83@lists.ticalc.org>
Sent: Wednesday, January 29, 2003 10:59 PM
Subject: [A83] calculator networking - good idea?
> Hello all.
>
> I have been toying with an idea for some time now, and I want criticism on
> how practical, plausible, and possible my idea is.
>
> It seems that any calculator communications currently in existence deal
with
> an interface between one calculator and one storage device, modem, or
> another calculator. My idea is to create a TI-XX calculator network. Any
> TI calculator or compatible hardware could connect to the network once
> proper software is written. With this network any user on the network
could
> transfer variables to and from any other user (with permissions). But,
> multiplayer games and chat applications, etc., could also be developed.
> Devices such as modems, storage devices, and computers with link cables
> could be created or adapted for use on the network, too.
>
> Now, considering that the **very** fastest that the slowest TI-Calcs
> (TI-82,83) can communicate is about 16,000 bps, there will obviously be
> bandwidth constraints. Only one calc would be able to talk at a time,
too.
> But I think that the speed could be adequate for most puropses, if we
design
> a good packet format and a reliable protocol.
>
> My thoughts for the first, simplest calculator network hardware would be a
> hub with
> four or so 2.5mm jacks. The "red," "white," and "ground" conductors of
each
> jack would be respectively connected to the "red," "white," and "ground"
> conductors of the all other jacks. Would one calculator's link port have
> enough output current to power the inputs of three other calculators in
such
> an unpowered hub? A powered hub would have simple buffers to assert the
> outputs of each jack.
>
> As for the protocol, each calc on the network could be assigned a unique
> identifier of two bytes, perhaps. Each calc, when it signs on, would ask
> calc $0000 for an identifier. If the operation times out while the calc
> seeks an identifier, it assigns itself the identifier of $0000.
>
> The procedure for sending bytes should be different than the existing
> linkport protocol, which is designed for only two devices. My general
idea
> is that there should be a way to detect whether a transfer is already
going
> on, and wait until the transfer is done to start the next one. Data would
> be transferred in packets of about 20 bytes or so to prevent a huge
transfer
> from hanging up the system.
>
> So, what do you all think? This turned out a little longer than I
> expected...
>
> Jeff
>
>
>
References: