Let me start my Cemetech membership with an announcement of the release of Punix beta 3.

You can download the TIB file or read the release notes. Punix is hosted on SourceForge.

Punix is a Unix-like OS for the TI-92+ and maybe later for the TI-89(Ti). The goal is to build a completely functional kernel and then port some small *nix utilities (shell, cat, echo, etc) to it. I'd like it to be as close to POSIX compliant as is practical on such a small platform.

Punix currently supports preemptive multi-tasking (with a scheduler that supports nice/priority levels), a VT100/VT220 style terminal (supports most escape codes), and device drivers for I/O port (one for audio and another for data transfer). It does not currently have a file system. That is the last major piece I have to write. I have a good design in mind already, but I have to integrate it into the actual kernel code. The file system will be stored entirely in FlashROM. (I might add a temporary filesystem in RAM some day. Who knows?)

Given the lack of a file system, I wrote some simple user programs inside the kernel. They run in user mode just as they would if they were loaded from binary files, but the executable code happens to be located inside the kernel. This includes the init program, a small shell, and a handful of simple *nix utilities. These are all stripped-down versions, as they are basically a demo, and they will be discarded (or moved outside the kernel) once there is a working file system.

Here's an animated screenshot:



(That was from a couple days ago, before vfork() worked, and before I added a CPU busy status indicator, but it's otherwise current.)

Nice work, if you ever get this ported to the 89 or 89Ti I'll have to try it out on mine. Can't wait to see where you go with this.

Have you put any thought into linking, or were you going to wait till you had the file system worked out first?

When you say "Unix-like", is it built from any existing *nix branch, or is it written from scratch? My apologies if you answered that aboth and I missed it. Great job on this, though. Also, what's that series of indicators at the bottom? They remind me of my CALCnet 2.2 debugging bitmaps.

My question exactly.

The more I'm reading, I'm tending to think from scratch, especially since he said he's been working on the project for about six years.

Welcome christop, another Christopher on Cemetech

The Punix documentation says:

For a while I was using Unix V6 and 2.11BSD (see The Unix Heritage Society) and other similar systems for the design and code, and later I started using bits of code from Linux, so it's kind of a mashup of different *nix systems. (I see Lionel answered that question too.) Also, I'm not calling my system Unix for trademark reasons, and because I think Punix sounds cool.

Those indicators on the left-hand side at the bottom are various counters and spinners I used for debugging so I could see where the kernel is spending its time and different values (eg, number of context switches). It's primitive but effective. I'll remove those once I'm confident that the corresponding module is working properly.


The 89 shouldn't take too much effort to port to, since only the screen and keyboard are different from the 92+. I've included some support for the different screen size and keyboard already, but it's not complete. The 89Ti will be more difficult with its different memory layout and USB.

Regarding linking, are you referring to linking from calculator to computer or to another calculator, or do you mean like a calculator network? If you mean the first one, then I was planning to leave that to a user program (either command line or graphical) to implement the equivalent of getcalc and sendcalc so it can talk to TI-Connect/TILP or another calculator as if it were running the TI-AMS. I implemented a basic getcalc routine in my user code that does just that. (A linking program can actually speak any or all of the different calculator link protocols to pretend to be different calculators, or even pretend to be a host computer, if they wanted to). Whatever protocol it uses, it just has to open the /dev/link file and then read and write bytes to it. The kernel takes care of all the buffering and the actual receiving/sending.

If you mean a calculator network, then I haven't thought much about that. That might take some extra work in the kernel to make it transparent to user programs (like a full TCP/IP network stack or something).

It's too bad A/UX isn't open source or that would be fun to port and run. Very nice work on so far on this though.

My guess is Kerm was asking about linking with the potential to support the Cn2.2 protocol in mind. I would guess that i/o through /dev/link wouldn't be low enough to support the clocking stuff involved with Calcnet though.

I would strongly suggest implementing CALCnet 2.2 in the kernel, since it's now fully-functional on the z80 calculator models, gCn allows it to be used for computer linking, and Lionel is working on a TI-89 (68k) port when his free time allows.

I wasn't thinking about implementing CALCnet2.2 in Punix before, but now I think you've convinced me.

I read the white paper and it seems like a pretty good protocol. The Cn2.2 frame reminds me of an Ethernet frame (since it serves the same purpose, that would make sense). Yes, I would have to implement in my kernel. The /dev/link driver only supports the TI bit- and byte-level protocol. I'll probably have to add networking support (sockets etc) to effectively use Cn2.2, though, and I probably won't get to this until I have a file system either. We'll see how it goes.

Nifty, I hope that it works out! If so, I would be more than happy to explain anything necessary to get things working.

Just to get the 89 port out of the way, I fixed up the keyscan routine and the display to work on the 89:


The 89 version has a 40x16 terminal rather than 60x20 as on the 92+.

I'm pretty sure nothing else has to change to make Punix work on the 89 from now on (except for some programs that might assume the terminal width or height).

What are your plans for CALCnet? Do you envision running UDP/IP and TCP/IP on top of it for globalCALCnet? (If you do already use TCP/UDP over Cn, then I apologize for not reading enough about it before asking you)

Now, as far as I understand the network layers, only TCP does retransmissions due to lost/corrupt packets. The lower protocol (Ethernet) does not retransmit. Ethernet only retransmits in the case of a collision. However, CALCnet2.2 does retransmit until it receives an ACK from the receiver. Wouldn't this conflict with one of the goals of UDP, which is to send packets without acknowledgement (basically "send a packet and hope it gets there")? Cn2.2 does this but only for broadcasts.

Maybe I'm just getting way ahead of myself this time...

gCn is Cn over TCP/IP, not the other way around, where we have a bridge on the network capturing packets from the Cn2.2 network and sending them to a computer where they can be broadcast over TCP.

I wouldn't be surprised if the 89Ti was able to act as a DirectUSB bridge for a Cn network given the more powerful hardware it has compared to an 84+/SE.

Oh. I was hoping to run TCP on my calculator so it could communicate with other hosts on the Internet (including other calculators across the Internet), by encapsulating TCP/IP packet data inside Cn frames. That way a Cn network would be just like any other network segment, with the bridge translating the lower-level protocols between segments.

But yeah, it might take more powerful hardware like the 68k calcs to run TCP over Cn.

By running Cn2.2 on top of TCP, you can indeed chat with other calculators across the internet; for chatting with non-calculator hosts, you just go through the gCn metahub, which runs on a few of my servers to link gCn with non-Cn/gCn services.

How does one go about accessing non-Cn services through the metahub?

You just write a translator module that speaks gCn on one side and (whatever) on the other side, and either run it on your own computer or server, or ask me to run it on one of mine. If you're a C# user, Merth already has a library to interface with gCn.

This is extremely relevant to my interests, I'd like to look into this more thoroughly when I get back home. To be honest, this idea has crossed my mind (a kind of TI-Linux) but A) I have no OS programming experience and B) I assumed that anything that might do Linux justice would be too intensive for a calculator.

@KermMartian: can tiCALCnet hardware and software be ported to the 92? O:

---

Just a useless aesthetic suggestion, dropping the serif on the 't' makes it easier to read, imho. I dig the tiny letters though, it's surprisingly easy to read for being mostly 3x3. (;

Progbeard, there's almost no hardware involved (and it's just CALCnet ). Lionel is already working on a TI-89 port in the minutes of free time that he has, which understandably are few; that more or less is directly a TI-92 port, so the short answer is yes.