(Cross-posted from cemetech for those who haven't seen it there)

I'm working on a project called "tinc", short for "TI netcat". My original plan was to write a program that can talk to a calculator and can either connect or listen for connections over the network. The current incarnation doesn't speak over the network but rather only over stdin/stdout, but it can still speak over the network with the help of nc (or perhaps even inetd). If I decide not to add networking functionality to tinc, I'll probably rename the project to "ticat".

I've been working with Lionel Debroux and Benjamin Moody to make it work with ticables reliably. Now it's at a point where it should be pretty stable (but it's still not ready for a real release yet). I've only tested it with TiEmu and Punix (not that the OS should make a difference).

Get tinc here: https://github.com/abbrev/tinc

Anyway, here's a little networked tinc demo (using nc for the network part):
$ mkfifo pipe
$ <pipe nc -l 8002 | ./tinc -c tiemu >pipeIn Punix on the calculator (TiEmu) I ran the "uterm" program, which  is a terminal program that talks over the link port (kind of like minicom in *nix or Hyperterminal in Windows). Then I browsed to http://localhost:8002/ in Firefox.

In the following screenshot, the first 9 lines (11 lines with line wrapping) starting at "GET / HTTP/1.1" are the HTTP request from Firefox. The next 6 lines (starting at "HTTP/1.1 200") are the HTTP reply that I manually typed on the calculator. Firefox displayed the text "Hello world!" in plain text as soon as I hit enter on the last line. Hooray for an impractical web server.




Another use for tinc is to use the Punix shell from a real terminal. This works only if Punix is listening for logins over the link port, which is not the case with the demo above (the link port can be opened only once at a time in Punix).

Anyway, here's a short run using the Punix shell in my Linux terminal:
$ ./tinc -c tiemu

server login: root
password:
stupid shell v0.2
root@server:~# help
available applets:
 tests     top       cat       echo      true      false     clear     uname
 env       id        pause     batt      date      adjtime   malloc    pid
 pgrp      poweroff  times     sysctltest ps        bt        crash     mul
 div       kill      time      exit      status    help
root@server:~# echo hello world!
hello world!
root@server:~# exit

server login:This was actually my first use of tinc, but I think the HTTP demo is more impressive.

I hope I can get tinc ready for release before too long, and I hope we all can find useful and innovative uses for tinc. I already thought about writing a VNC server for Punix as a sort of replacement for the TI screenshot functionality. Who knows what else we can come up with?

Nice, awesome job!!
What about an irc client ? The protocol isnt that complex

I thought someone already made one for Nspire

Nice, awesome job!!
What about an irc client ? The protocol isnt that complex

Thanks! I'd like to make one, but I have enough projects as it is, and my time is really limited right now. Maybe you could write a simple one in C that reads and writes to a pipe/socket/whatever and to stdin/stdout, and then I can port it to Punix. Note that the select() system call doesn't work yet, so you'll have to find another way to read from the socket/pipe and from stdin without blocking.

I thought someone already made one for Nspire

Someone probably did, but I'm working with a TI-92+. My primary OS on it is Punix, which makes it relatively easy to read and write to the link port. But tinc works with any calculator that uses the same low-level data protocol, which includes all of the TI-8x, TI-9x, and I'm sure the Nspire as well. What you do with the data that you read and write... well, that's up to you.

TI-netcat... so now we can plug a cat to our calculator to have Internet??

Just kidding I read the first post in overall. Sounds really great. I wonder if eventually there could be something like CALCnet but for 68K calcs?

I have some plans for making a similar protocol to CALCnet (called Chrisnet for now), but mine will be designed more for TCP/IP networking. globalCALCnet works by sending CALCnet frames over TCP using proxy server(s). With Chrisnet, it's the other way around: IP datagrams will be carried inside Chrisnet frames, much like IP is carried inside Ethernet frames. In fact, it will be similar to Ethernet in some ways. I also have ideas for building a hub to translate Chrisnet frames to Ethernet or SLIP or PPP frames, depending on the cost and complexity of parts needed to build one, so you can plug in your calculator and connect to the Internet over TCP/IP. I'm leaning toward SLIP or PPP since they are simpler and less expensive than Ethernet (which uses... CAT 5 cables! ). But I haven't even made a proof-of-concept for my protocol, so I'm really putting the cart before the horse until I can demonstrate that my protocol works.

(And I actually haven't worked on hardly anything calculator-related for the last few months, up until about a week ago. My job and family keep me plenty busy.)

Quote from: christop on August 16, 2012, 11:42:32 pm

Thanks! I'd like to make one, but I have enough projects as it is, and my time is really limited right now. Maybe you could write a simple one in C that reads and writes to a pipe/socket/whatever and to stdin/stdout, and then I can port it to Punix. Note that the select() system call doesn't work yet, so you'll have to find another way to read from the socket/pipe and from stdin without blocking.

I could do it, but I don't have much experience with sockets/pipes/etc, so I'll need to see.
What standard libs can I use in punix ?

Only the C standard library and POSIX system interfaces. Even those are incomplete (such as the select() system call).

Here is an incomplete list of functions that work which I think you would need to write a simple IRC client:

• open/close/read/write
• printf/sprintf/fprintf
• putc/putchar
• getc/getchar
• tolower/toupper/isalpha/isdigit/etc (all of ctype.h)
• malloc/realloc/calloc/free
• setitimer/getitimer
• atoi/strtol
• all str* and mem* (string.h) functions
• signal/sigaction

The lack of select() is slightly annoying, but you can get around that by setting an interval timer (with setitimer()) to run every 100ms or so to interrupt read() calls on the link port and the terminal. This is what I did in the uterm program. That reminds me: I need to implement the O_NONBLOCK flag for file descriptors which would make read() and write() non-blocking. That shouldn't be too difficult, at least compared to select().

Doh, I've missed the topics on both Cemetech and Omnimaga. Now subscribed.

But tinc works with any calculator that uses the same low-level data protocol, which includes all of the TI-8x, TI-9x, and I'm sure the Nspire as well.

Nope, the Nspire doesn't have a proprietary 2.5mm stereo jack female plug
The 84+ keyboard suitable for Clickpad/Touchpad models has one, but unless one is hot-switching the keyboards during a Ndless program that disables interrupts, the Nspire turns off when the standard keyboard is removed, and starts 84+ emulation mode when turned back on with the 84+ keyboard.

Why was this moved to TI-68K Projects? It's a computer program that works with nearly all calculator models (I just happen to use it with Punix in my demos).

Can we get a new sub-forum for calculator-related computer programs?

This is pretty amazing! I would be one very serious user** if you added TCP networking support!
The Nspire (and friends) would appreciate some Internet connectivity.

(For the Nspire, USB communication needs to be implemented Ndless side beforehand)

** By user, I don't mean just accessing the Internet, I also mean using it as a component for a major project!

Let me clear up some possible misconceptions.

First, if I add networking to tinc, it won't do anything that the regular nc (netcat) doesn't already do. It'll be able to talk with only one other computer at a time, and you'll have to pick the IP or host name of the other computer when you run it (or put it in listen mode, then one other computer can connect and talk to the calculator). The calculator can't select the IP to connect to, and it can't know what IP connects to it.

Second, the calculator link protocol has no way to detect or signal an end-of-file condition or, by extension, to either close a network connection or detect when one has closed. In the HTTP demo I had to explicitly put the "Content-length" and "Connection: close" header in the response which told the browser when to close the connection. The calculator didn't know that tinc had exited when the browser closed the connection.

Third (and this is not just a tinc issue), the TI link protocol is only half-duplex, which means only one side can send a byte at a time. Normally this isn't a problem--the two sides can take turns talking at a fast enough rate that it isn't noticeable--but if both sides try to talk at the same time, there is a problem. It's a double problem because the protocol sometimes makes it difficult or impossible to distinguish between a "collision" and the other side simply not responding, so it's usually not possible to recover from it, leading to lost data. This happens a lot during interactive sessions, such as using the calculator as a terminal or a terminal server (I've done both with Punix ). For example, if the computer is sending a lot of data (perhaps I cat a large file) and I try to type anything while it's sending data (say, Ctrl-C to kill cat), the outgoing data is likely to collide with the incoming data. There's nothing I can do with tinc to fix this problem, either. It's too bad TI didn't use a standard serial UART in their calculators as Casio did in theirs. (I am investigating adding a full-duplex "rs232" driver to Punix which will simulate a UART, but it will run at 2400bps at the very fastest.)

What Lionel mentioned (TCP/IP on the calculator) would fix the first two issues, but it's kind of heavy-weight for a calculator (but I would like to implement it in Punix anyway ).

What tinc with networking (or used with nc) will let you do is simple point-to-point communication with another calculator anywhere across the globe, as long as you have network connectivity between them. Imagine playing a multi-player game with someone in another country! The game won't even have to use any special protocols like Kerm's CALCnet/globalCALCnet (which I admit are pretty neat protocols). The latency might kill in some types of programs (action games), but I'm sure it'll still be fun.

Lionel: I've seen Samir's TCP/IP demo before, and I've also looked at TinyTCP (which his demo is based on) and other small TCP/IP stacks. My favorite at the moment is lwIP. It has a nice callback-driven API which looks like it might fit in well with the Punix kernel (the kernel would be lwIP's "application", and Punix already has timers, a memory allocator, and other necessities for lwIP to use).