How do you generate the PWM signal? Do you just set the output high or low at each clock interrupt, and what is the clock rate of that interrupt?

I'm just wondering if you could alternate the output signal (pulses) more frequently, as in multiple times per WAV sample, in order to push the pulses into the inaudible frequency range, or at least into a range that can be filtered out with a low-pass filter. I would think that this can be done fairly easily with delta-sigma modulation.

BTW: Don't plug your speaker in before "Playing!" or you'll short 3,6 V (While playing, you only short ~1,8V)! Unplug them before exiting, the GPIO becomes high on reset! Don't use your amplifier, you may blow it!

Do you know how the GPIO port is driven? If it uses a pull-up resistor (this is what all the TI-8x and TI-9x calculators use in their link port hardware), shorting the port to ground will not harm the calculator (the pull-up resistor is between the 3.6V source and the GPIO pin).

What is the point of the "license" on the TI-OS download pages? You don't need permission to use it. Copyright law (at least in the US) already allows end-users to install and use software without permission from the copyright owner. The "license" doesn't actually give you anything or allow you to do anything that you didn't already have the right to do in return. You can already legally download a copy from TI's site and install and use it in your emulator as you wish, or download it and install it on your real calculator.

There's simply no need to agree to the terms and conditions of the "license" to download and use a TI-OS file (and downloading a file from the download page does not indicate agreement, despite what TI might claim).

Edit to add: if you dump the ROM from your calculator, you are also not subject to any "license". You did not have to agree to any license when you purchased the calculator, and some license on TI's site does not apply to your use of your own calculator.

Edit to add again:

@Keoni there's a EULA in the packaging which you agree to by using the calculator.

The TI-OS EULA (like virtually every other EULA) is a contract, and you are bound to the terms and conditions of that contract only if you indicate assent, and simply using the calculator does not indicate your assent to a contract that is packaged alongside the calculator.

When you bought the calculator, you own the copy of software on it*, and you have full rights to use the software without accepting any contract. Under copyright law, TI has the exclusive right to copy and distribute the software but not to use the software. Use of software (or book, CD, DVD, etc) is not even covered by copyright law (after all, it's not a useright law), except when copying is required to make use of a copyrighted work, as it is with software (but as I mentioned, this right is explicitly granted by copyright law to the owner of a copy of software).

*A lot of trolls in the software industry would claim that you only "licensed" the software and didn't buy it, but they are mistaken from a legal standpoint.

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).

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?

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().

(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?

Thank you for reading my article, I hope that machine translation was not too hard to read (but it's probably better than my poor english)

Nah, your English is better than Babelfish.

Do you know what would be incompatible with the HW1? Grayscale, sure, maybe the sound due to the 68k running at 10mhz, but there is something else?

Yeah, the sound would play slowly on HW1. The system real-time clock would also run slowly, and it would be affected by the battery strength, but that can be fixed somewhat with the adjtimex system call (currently planned) to adjust the system clock frequency. Even grayscale is possible on HW1, but I would have to add support for it in Punix. I can't think of anything else off the top of my head that would be incompatible.