I could send all processes a SIGPWR signal, unless any process is catching or blocking that signal. But I'm not sure that's the most elegant way to handle the power off mode. I'll have to think about it some more before I commit to any method.

Lionel: I meant to ask you in an earlier post about libticables: is there a way to communicate with a calculator as if it were a regular serial device? That is, can I connect to it through a device file like /dev/ttyS0, so I can use a terminal program like minicom to talk to it? Or will I have to build a true serial converter device? I'd like to talk to a real calculator or even to Tiemu, since libticables obviously supports virtual cables too.

Unrelated edit: I finally installed Punix on my TI-92+!!! I was surprised that it works pretty well, especially considering that it's the first test on real hardware. Here's a live-action screenshot (aka photo):

If the calculator were talking TI's uncommon half-duplex protocol which requires direct wire access for bit-banging the lines, which is the normal usage of BlackLink / $4, ParallelLink / $5 and Gr[ea]yLink cables, probably not.
If you make it talk a standard serial protocol (implemented by minicom), why not, unless libticables hard-codes some assumptions about TI's protocol.


That would be a workaround, in case it's impossible to talk using standard serial protocols through libticables: a program which interacts with the real calculator on the one side, and TIEmu on the other side (through VTI or TIEmu links).

Also it would be great to use the 92+ as a pocket terminal to be able to connect to existing serial ports, and manage computers from his calc

With a BlackLink, GrayLink or ParallelLink, maybe.

Note that 89T calcs can expose themselves as HID mouse, HID keyboard, read-only mass storage device, or PL2303 serial adapter (one at a time)

Here's another wild and crazy idea that will go straight to my wishlist: use the link port for direct RS232 communications! I actually thought of this before you guys posted here today.

I would use Int5 for both detecting incoming data and sending outgoing data. One of the I/O signals would be TX, the other RX (so there's obviously no hardware flow control/handshaking). For hardware, all that's required to talk to an RS232 port is a TTL/RS232 level converter, which can be made with a few components (a couple transistors/MOSFETs, a few resistors, a couple capacitors, and (or course) a DE9 connector and a 2.5mm connector). This could even be built directly into the calculator, right next to a PS/2 port!

Since the Int5 timer runs at a maximum of 8192Hz, I will probably be able to reliably send and receive (full-duplex) RS232 data at 1200bps or 2400bps, and possibly up to 4800bps. The bit jitter might be too high at 4800bps, but on the other hand, the signal rise and fall times are probably negligible at that rate so it might not matter too much. 9600bps and higher are out of the question since it's too fast for Int5 to keep up with it. Or I could make a hybrid interrupt/busy-loop driver, but even that is likely to drop bytes frequently.

So... instead of a Gray Link cable (a Black Link isn't true RS232, nor is the Parallel Link), just use a small adapter between the calc and the computer and connect away! Or connect to the calc and use the Punix shell from the computer! 2400bps should be plenty fast for managing a computer in a terminal.


By the way (this might be off-topic), I have a Black Link and a Silver Link cable, and the Black Link seems to be a lot more reliable than the Sliver Link. I don't know why, but in TILP I have to try sending an OS a few times before it finally works; it times out the first 2-3 times. I also have issues with the Silver Link in TiEmu when I connect to TiEmu from my calc. It doesn't seem to handle bidirectional data very well. I think if both sides are trying to send data at the same time, it just can't handle it. This happens when I type a few characters while stuff is currently coming down the wire. The BlackLink handles it fine, though, probably because the computer drives the link signals more directly. So I'll be sticking with the BlackLink for my computer-to-calc needs, despite the SilverLink being USB and newer and stuff. All this will be moot with RS232 on the calculator, since it'll be full duplex.

Oh ? Here, SilverLink is proving quite reliable for transferring OS, I don't experience 2-3 timeouts.
I usually trigger OS transfers only when the boot code is running.


Probably, indeed. The SilverLink is designed for strict observance of TI's half-duplex protocol, so if something deviates (and both sides trying to talk at once would be a deviation), it probably bails out


Indeed.

I transfer my OS when the calculator says "Waiting to receive..." which is displayed when I press "I" in the boot installer screen. Is that what you mean by the boot code?

My SilverLink is actually my sister's (and it might actually be my parents' who let her borrow it), so I don't know how much abuse it has taken when she had it. Or maybe I have an old version of libticables that has an old bug. I'm not at home to check the version right now.

Yes, that's the boot code

Even with older versions of libticables, I seldom get timeouts when trying to transfer the OS.
Bugs that the maintainer has trouble reproducing are fun

More than a year after the last release, I'm happy to announce the release of Punix beta 5!

All files: http://sourceforge.net/projects/punix/files/betas/

TI-89: punix-89-beta5.89u
TI-92+: punix-9x-beta5.9xu
Source: punix-beta5.tgz


I also noticed that Punix was recently added to the Levenez Unix History page!

Firstly, I'm very happy to hear that this project is progressing! Keep it up! I know that there have been a few OSs for z80 calcs, but a full (non-testing) OS for the 68k calcs is very cool indeed.

Secondly, I will ask it as someone else is probably thinking the same: "What does Punix have to offer right now? What makes it beta 5? How usable is it (as-in can it be safely put on-calc)?"

Some *nix-like features on a TI-68k calculator; PedroM aims at keeping good compatibility with AMS, and adding some POSIX features, but does not provide a real *nix API.
As a result, PedroM can run the vast majority of TI-68k/AMS games and non-math, non-BASIC utilities, while Punix cannot; but it's easier to port programs from other platforms to Punix than to PedroM.


Many improvements since beta 4
Among others, sound and grayscale, IIRC.


AFAIK, it can be safely put on a real 92+; christop himself is doing it.

Yes, you can run Punix safely on the calculator (TI-89 and TI-92+, currently). I've tested it only on my TI-92+, though.

Other new features include:

• 4-level grayscale with anti-aliased console font
• Demo audio clip (1:31 from The Blue Danube Waltz)
• Improved process scheduler (audio plays without skips even with high CPU load)

It's not much (I haven't had much time these last several months to work on Punix), but I feel it deserves a new release since it does at least run on a real calculator now.

This release is quite a bit larger than beta 4 (280KB vs 76KB) mostly because of the audio data. Without the audio data it would be 96KB. Even if I included 9 minutes of audio data (stereo, 1 bit, 8192Hz), it would still be a tad smaller than AMS v2.09 (1.2MB).

More details are in the README at the bottom of http://sourceforge.net/projects/punix/files/betas/.

Edit: contrary to Lionel's post, Punix has had sound for quite awhile (since at least beta 3), but until now the audio demo was just a few synthesized test tones (left/right/both channels). I finally decided to include real audio data for the "ooh" and "ahh" factor.

Super Exciting Fun Necro Bump! dTal and others were talking about third-party 68k OSes on IRC today, and Punix came up. Do you still have anything going on with this project? Does it still lack a filesystem? Is this petite FAT file system implementation at all useful?

I'd like to chime in that I'd be interested in the latest source - you mention fixing a power consumption issue on your development blog, but the latest beta on SourceForge predates that.

Does it work on TI Voyage 200?