[A83] calculator networking - good idea?
[Prev][Next][Index][Thread]
[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
Follow-Ups: