Re: TI-H: TI Network - TIN
[Prev][Next][Index][Thread]
Re: TI-H: TI Network - TIN
>-----Original Message-----
>From: Grant Stockly <gussie@alaska.net>
>To: ti-hardware@lists.ticalc.org <ti-hardware@lists.ticalc.org>
>Date: Tuesday, October 20, 1998 12:42 AM
>Subject: Re: TI-H: TI Network - TIN
>
>
>>
>>>1. As a programmer, you should know that a compiled app for one calc will
>>>not run on another without an "emulator" of sorts. I don't think that an
>86
>>>prog would run on an 82, do you? And what about the 89/92? They even
>have
>>>a different processor! How the heck could you run an 82/83/85/86 prog
>>>natively on an 89/92/92+? The ZTetris linking protocal is the only thing
>>>cross-calc about it. If you don't believe me, find someone at school with
>a
>>>different calc than yours without ZTetris, and try to send it to them.
>>
>>Yes. But porting an easy program like the I2C driver is easy. Most of it
>>is simple timing and I/O. Comeon. As a programmer, you should know that.
>>:)
>
>
>=) I was referring to the programs that were going to be stored on the e(2)
>not the drivers themselves.
>
>>>2. I think that the best way to handle multi-calc storage is for the calc
>to
>>>attach an ID to the stored file, so another calc could see that "hey, this
>>>just isn't my thing", and wouldn't run it. I do not know if things such
>as
>>>lists and matrices are cross-calc or not, but I imagine that an 82/83 list
>>>would need to convert to an 85/86 list, which would need to convert to an
>>>89/92 list. (I hope I am wrong here.)
>>
>>The lists can be stored anyway you want. It depends how you store the
>>bytes to the EEPROM. If you knew the formatting you could just store it in
>>a generic format and then format it specifically for each calc when the
>>driver writes it to ram.
>
>
>So is that how the CBL/CBR does it?
>
>>>3. And about addresses, this just means that more calcs can attach, right?
>>>So, if everyone in school that had a calc, they all would be able to use
>>>this network? How is this going to be implemented? I don't think that
>>>someone is acctually going to build a 200+ hub/connector. Or, is it
>>>possible to connect multiple hub/connectors together?
>>
>>I'm working on an ethernet to parallel/I2C converter so you could just
>>subnet I2C networks using the UDP protocall. :) That would be cool... If
>>I spent the time to figure out the new ARM+NET chip we could have dial-in
>>access for calcs and they could use the net. :)
>>
>>
>>I think a special 'basic' (or such) should be written for all calcs, but
>>programs can be run off the I2C net. THe programs could be tokenized and
>>calcs like the 85/86/89/92 could just stretch the screen output to size an
>>82/83 calcs. Just an idea... Then every netprogram would work on any
>>calc...
>>
>>Grant
>
>Are we talking about inter network connections throught the school's
>network?? I am not familar with the ARM+NET chip. But the words "dial-in"
>makes it sound like you plan to go through a modem. =\
NET+ARM contains onboard TCP/IP/UDP and PPP and twisted pair. There is
also app notes on ftp/http/telnet programs. Its only $27 for 12MIPS.
>Isn't TI-BASIC for all calcs anyway? If a BASIC program was written on the
>82, wouldn't all the other calcs be able to run it? Besides, this goes back
>to the compatability vs optimum performance. It's basically well known that
>BASIC games are fading out, and everyone will want the graphical assembly
>games and give crap about being compatible with the other calcs. Why invent
>a new language that will die before it's used?
Not all calcs use the same basic. I'm not talking about games, but about
teacher stuff... OR simple games.
Grant
References: