It seems that on *few* TI, during File/Variable transfer ONLY, that there's a TIMEOUT due (maybe) to low data-rate.

I need a Hex Terminal for TI92 (.92p) (able to send AND receive byte, NOT Characters) to debug this. Is someone can give me this software (if exist) ???

New version : 1.2 (Time-Out bug corrected)
(sorry, nobody's perfect)

you can find it on the webpage project.

http://www.esil.fr.st


Stay informed :

ICQ : 41265941

i see interference as being a problem... does this work so well that you can transfer files from calculator to calculator without any corruption? if so i want a few of these... don't know if i want to build them, though

Yeah, corruption will be an issue. Protocalls like TCP/IP were designed with imperfect networks in mind, so they have built in error checking/protection, but the TI link protocall assumes that you have a direct cable connection and doesn't do any error checking.

If you could get the sending/receiving unit (not the calc, but perhaps the wireless connector), to do a cyclic-redundancy check on the data it sends and receives, it would be possible (so I've read in a magazine that I couldn't understand) to resolve errors...

It involved having the sender send a header byte, and somehow using that header to determine where the error was on the receiving calc (one bit per byte max I think... Which covers most interference mistakes). The entire article was much much more complicated than that (it was a program written in C), and if anyone thinks this could be useful, just mail me at
myownlittlworld (AT/PRESENT IN) hotmail (DOT/SPOT/PERIOD) com.

But yes, the disturbing thing was how the thing worked...

Why didn't you just write

myownlittlworld@hotmail.com? (url)

If your on this site most of the time, you have free time. He just took advantage of the fact.

Guess that's true.

<OT>
Does anybody know where I can get a good FREE non-trial flash developing kit... doesn't Macromedia make one (I doubt it's free)?
</OT>

Beats me (ouch). Have you not tried google or macromedia yet?

You woln't find one. Macromedia wouldn't allow it, as they have to make their paper.

Get a trial version and activate it. Activation codes are avalable at link (just make sure to have a pop-up stopper before you visit the site). If you are too moral to do that, pay the $100 and buy it.

mostly because of spam software...

They scan pages for email addy's and add them to their databases... So, if you screw up your mail, the spambot won't pick it up, and you won't get spammed...

That's why... Now, however, it'll still be picked up.

It's probably to trick spambots too.

I didn't read before I wrote. Someone else wrote the same thing. Heh. Oops.

Error checking is actually done by the TI. A checksum at the end of a file is sent to the TI calc along with the VAR. If the checksum is incorrect, the VAR is not accepted and is discarded. An error is also sent to the TI-Graphlink software and reports to the user an error in transmission.

Sorry, I'm not a specialist in hardware devices, but I just had a question : it is said the wireless cable works "like a normal cable", but is it so only for transfers following the TI protocol or can one use binary ("direct access") transfers? I guess the latter wouldn't be too realistic as the bitrate is said to be of only 2400 bps, but I just wanted to be sure. If it really acts as a normal cable even in binary mode, then maybe one could manage to make a program that would overcome the delay that, with the usual TI protocol, limits the rate to 2400 bps, but with a specially tuned algorithm could do better (i.e. not sending a single bit, waiting for acknowledgement and starting over)

Apart from that (transfer speed), I think that this cable is just cool :) This kind of project has been hanging around for years, and at last someone has made it... Well done!

the Z80 linkports are 9600bps and the 68K calc linkports are 56K. Or so i've heard.

If the 68k ports are 56kbps, then why do they only transfer at just over half that?

try sending to the 89 with a USB cable. Mad fast.

From what I've read, the data rate is not fixed at all for any of the calcs. The transfer program simply sets a bit (one of the wires) and then waits for the other calc to set the other wire to indicate that has received the bit. Then it goes to the next bit, and so on...

The calcs might be able to send data a bit at a time *without* checking the acknowledment after each bit, but this would require very careful timing on each side. Asynchronous transmission would probably be the best way to go to avoid/detect simple low-level errors, such as framing errors.

I think the wireless cable is just a TI-linkport to RF bridge which send/receive byte to/from the linkport according to the hardware protocol.
Given that the devices does not worry about the software protocol, it should work with binary transfers (such as communication between 2 calcs playing a game).

Can Nono confirm this ?

About the bitrate (2400) bauds: it's due to the RF modules. TI linkport can rate up to ~30kbits/s on Z80 calculators and ~50kbits/s on m68k calculators.
It has been rated by doing a screenshot with TiLP under Linux.

Hardware protocol is managed by bit-banging routines on Z80 machines whereas it's managed by hardware (the ASIC : barrel shifter + FSM) in m68k calcs.

Anyways, this is a great project ! I like these kind of guys because they do the work and then they release it.
Many people announce a project which is never finished !

Nono, maybe you should consider to release your source code under an OpenSource license (GPL, BSD, ...). It may be interesting to the community and to you !

I am aware people can make money with your project. It's the same thing for me: people are making money with TiLP. But, people can reuse source code, improve it, debug it and send patches to you. Thus, you have a product which is evolving and becoming better.

You've all right !!!

;)

So, it should work in binary mode? Then where does the bitrate limitation come from? Is it because the emitter/receiver somehow "blurs" the input (i.e. a discontinuous signal on input will result in a continuous signal on output), because it adds noise and thus we must wait longer before we are sure the transmitted bit really is a '0' or a '1', or because there is a delay introduced by the process (i.e. the '1' transmitted by the emitter will be received 1/4800 second later)?

Yes, it work in binary mode. Bitrate limitation is due to Aurel's module bandwith (max. 3~4Khz).

Sorry to bother you with this, but in the end, which of the limitations I mentionned does it result in? 1) blurring, 2) noise or 3) delay

I'm asking you this because I wonder if the transfer speed could ever be improved...